The person who has been charged with a task, should have authority to carry it out as best they see fit. Ok, after folks have a chance to review. But letting somebody gate-keep results in stagnation and no progress.
I think this is the most common problem in the tech world, and it’s source it’s on hiring.
When I hire someone to do a job, I don’t want to tell them how to do it. I want them to figure it out, and ask for help if they need it. For some reason, that’s not how most people work. A lot of them expect you to tell them how, but they will refuse to ask for help until too late.
When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better.
So far my only weapon against this has been to be very selective while hiring.
> I want them to figure it out
Can they actually figure it out without someone explaining some oddly specific detail related to the company/domain/country?
If you have some very precise requirement that you absolutely want to be satisfied, are you telling them, or do you expect them to "figure it out" because "it's the only right way to do it"?
If they cannot figure it out, and they cannot REALIZE they should have until too late, will they be punished for their mistakes, or are they allowed to make mistakes while learning by themselves?
I find that many people, especially bosses/managers/CEOs/whoever has/thinks having the power, think that their view is the Only One View; who does things differently is Just Wrong (as you say yourself about your past bosses), but they DO NOT CARE about explaining their wishes to whoever is working with them. Since this is quite a prevalent attitude, people tend to ask details about their jobs. This isn't bad, and most people, once they feel safe and properly valued, just stop, in my own experience.
It's just a fundamental cognitive blind spot that humans have about assuming that what's obvious to ourselves is obvious to everyone else. Every one of us who's jumped into a question about something they're working on and had the other person say "I don't understand the context" has done this.
The opposite is what makes great teachers, authors, and other communicators great: they recognize what the other person doesn't understand.
Unfortunately, you are right that there are people who are extremely threatened by the Socratic Method. In Plato's Cave, Socrates talks about how some people strive to explore and learn while others have no desire to broaden their knowledge as "they know no better life."
That's a different problem. You need to tell them what you want, unless it's a mathematical, universal truth.
Sometimes. Not always. I think everybody holds ideas in a spectrum from "absolute truth" to "totally my biased opinion". The problem arises if I hold an opinion as an absolute truth and I ask other people to work for me. I won't bother about telling them absolute truths, won't I?
I know I considered leaving a project when it became rational in my mind to do exactly that.
If I ask somebody to cook for me, I expect the food to be palatable _to me_. But since I'm Italian, I'm probably picky about food, and I may not like some kind of exotic tastes. That's totally ok.
What is not ok is to say to somebody "cook for me", then classify the food as shit because "I don't like it". I should probably investigate a bit with the other person about my tastes (and the other person should, rightfully, ask questions!). They will still have plenty of opportunities to exercise their creativity, without pushing too many boundaries. Mind you: I think that boundaries should be pushed, but it's unwise to push them too hardly at first.
This is 100% my experience.
I am not mind reader.
Because that is not how many bosses or jobs work. It is certainly not how school works. Teachers, parents, and plenty of managers have a very particular idea of what work product they want completed.
With them, your choices as a student/employee are to pester them and check in with them constantly until you have narrowed down exactly what you want or be told to go redo it after you figure out how to do it and get it wrong.
That's because you're setting that up, perhaps inadvertently, by expecting them to figure it out and ask for help __if__ they need it. You don't even have to explicitly say that's what you expect, it's likely apparent by your demeanor.
There's something about software workplaces that discourages thinking out loud and exploring ideas. Carelessly asking the wrong question in such a place can instantly and permanently red-flag someone as incompetent. It's like people have taken the weird culture from Stackoverflow and ingrained it in their workplace.
Sure "endless" discussions or bike-shedding can be bad, but it's a much worse problem to have an environment where there's no sense of psychological safety for discussions and asking questions.
The OP article, it appears, is proposing a turgid RFC process for deciding things within one organization. That's fine, I guess, if you're a standards body coming up with rules for literally an entire industry, but it's too much for a single team. Sometimes talking things out is good as long as people can be reasonable with each other.
I actually encourage it (or at least try). I just prefer it to be 1 on 1 (not necessarily with me), because we can’t really afford doing all of our work on a whiteboard, at some point we have to deliver. Also, I think this exercises are useful up to 3 people, then conversations quickly become too unfocused.
What I meant is that a lot of people are unable to recognize that they are stuck or very behind the schedule, and fear saying so, even if it’s not their fault.
I get it, I also had bosses who “killed the messenger”, and I’m convinced that this is in some sense a feedback loop. My point is that it’s very hard to break this loop with most people, they seem to either get it immediately or to be incapable of it, no matter how much I try.
The SO culture is actually considerably more sane, because when downvoting, you also automatically decrease your own "status" (score). Whereas in many real settings, you get +100 points if you "downvote", i.e. point out someone made a mistake.
This is a reason you need to learn to manage up.
I'm pretty clear that I'm oriented around the final objective: I don't want to be told how to do something (though I'm happy to collaborate and listen to suggestions). If someone starts telling me the "how" before the "what" and "why" I interrupt and steer the conversation there first. If you really want to be telling someone only the "how" I'm not the right person to employ, and I'm clear about this early on.
The very few times I've got in trouble with this there's been some hidden objective or constraint I wasn't made aware of, and the discussion I have afterwards is that is not compatible with my way of working. This has always resolved successfully and I've never had this issue with someone more than once.
I’ve had this, but working in hardware development, this things are big problems.
I have to admit though, and in those situations the main problem was conveying to the manager (who tends to be an experienced engineer) that they’ve messed up and the specifications they’ve agreed to are physically impossible to construct.
Software is an industry in which people are criticized frequently for doing things differently than how others would've done them. This results in devs (that are less confident with that type of confrontation) over-asking how a company wants something done, and then feeling anxiety around getting it wrong and needing to ask for help. It might not necessarily be the responsibility of the direct manager to define _how_ things are done from a technical perspective on that team, but it's certainly someone's. "I expect you to know how to write software in our codebase" kind of falls apart, given the infinite options for how problems are approached within a given problemspace.
If you're seeing this type of behavior, your org might have trouble with A.) responding to aggressively with developers building something differently than expected, B.) valuable criticism. Pull requests are exhausting, in my experience, because they oftentimes turn into theoretical debates about the validity of different approaches.
Pull requests are the correct time to offer actionable criticism on submitted work. Pull requests are not a place to complain about an implementation strategy, or to suggest the developer should've done something totally differently. If the submitted solution is so far away from correct that that type of criticism comes up, your workflow has already fallen apart (as a developer was able to build and submit a solution without realizing their work wouldn't pass review).
> When I was on the other side, the opposite was true too, I has bosses that expected me to do things their way, even if I could demonstrate that there were better.
I think ultimately either is "fine" - things just need to be defined appropriately. If a developer is given the freedom to basically do whatever they want, they need to be told so, and that ideal has to be supported through the entire dev lifecycle. Meaning your team's culture has to have the restraint to not complain about implementation details. In my experience, almost no org is actually comfortable with this method though. In my experience it's best to literally define "how" a team solves the problems it is tasked with.
That does not scale.
If you hire the exact person you want and they get exactly the results you want, you’ve just installed a black box in to your company. You cannot duplicate them and cannot replace them seamlessly if something happens.
In a real way you are now reliant on that specific person and they only have so many hours in a day (and only so much motivation).
Experience tells me that the “20% time” way is the right balance: Support employees in exploring unknown (and possibly much better) ways, and spend 80% of the time following processes that are known to work. Black boxes can cripple a company if work is 100% at the will of single employees, and so much valuable insight is lost when it swings 100% the other way.
What are some things that you look for in a candidate for a successful hire?
- At least 2 years experience.
- Having built projects on your own is always good, but I’ve seen that having built “weird” stuff is better.
There’s a lot of typical projects, in hardware development building a power supply or a 3D printer are quite common. I find that uncommon projects (even if unsuccessful) tend to be a better predictor of what I’m looking for.
- Uncommon educational paths: having changed majors, or pursued other stuff later (e.g. people that do physics in college but after 2 years working they switch to coding and join a masters in ML)
In the end you are trying to find people that are independent, emotionally stable, a little non conformist, but ideally don’t have serious communication problems. That is said easier than done though..
That requires specifically assigning someone the task and authority. This is the part most orgs fail on because to accept ownership is to take on risk. Organizations tend to focus on mitigating risk, and so it becomes increasingly difficult to actually have a person designated as responsible for the thing.
"Everyone needs to own the tickets" quite quickly shows that you own the responsibility and blame, but none of authority.
I work at a company that has a management team that historically thinks they need to prioritize initiatives for the organization. A little over a year ago we had a conversation with the management team and explained we would like them to focus on outcomes instead of telling us specifically what to do. It didn’t go over well, they basically ignored the entire conversation and told us what to do.
We are one year later and now undergoing a shift to focusing the organization on outcomes using OKRs and spotify style agile. People are starting to get it now and we’re having a lot of discussions with the very same leaders on a more individual basis which I think helps.
One thing is for certain, people (and culture) are hard to change.
One of the most powerful tools I have found towards constructive discussions is moving away from binary (works or does not work) to options (implications and imitations). The encouragement of generating multiple options allows discussions to consider different ideas. It also allows to think about limitations and implications. The best part is that it puts decision makers to accept these limitations and implications for the upside that they give. On the other side, it allows employees clarity on where the decision makers want to go.
Thanks for mentioning this. I think, it's the principle of inversion. I can resoundingly echo your comment. Personally, it has proven to be very useful for me to get people out of "tunnel vision".
Oh I completely agree. And all the other considerations are important to pick when more than one option will work. But I've seen too many things that don't work get through.
One thing that was particularly valuable was ensuring every proposal came with a "alternatives" section (called "competitors" in the NABC model). We also made sure that every proposal included "do nothing" as one of the alternatives, to provide an anchor for a discussion about what would happen if we simply didn't take on the problem at all (or stuck with whatever imperfect solution we were currently using).
I often scroll to the alternatives section first thing to see whether at least a few alternatives were honestly evaluated. Too often I just find some bullet points with abstract URLs (without any summary for the reader) and a statement that they would not be as great as the proposed solution - or no section at all.
It becomes impossible to provide constructive feedback at that point. It leaves me with the dreaded “Have you considered Alternative X, Y, Z?” or a passive-aggressive “Could you do an unbiased research of alternatives against the requirements?”
Even though the alternatives section tends to be towards the end of the document it doesn’t mean that it should be filled out at the end.
Won't this process end up ultimately filling the team's/project schedule with revisions of previous decisions?
The TTLs are tracked in the decision log which is reviewed in project retrospectives. You can schedule these in a slot a week you hold open for presentations, document reviews, demos, wheel of misfortunes (debugging simulated production problems if on-call), production reviews, etc.
It is not that one of the proposals is wrong and the other is right, it is just that they make different trade offs and the teams/engineers behind them have different preferences and backgrounds, probably both would work, with different long term consequences.
At this point I think it is where you need A) Strong management/tech leads/seniors/principals/architects/whatever which can make a call of what direction to take, and B) Clear company principles which would guide those leaders into making the decision, such as "We go with option 1 because we value more simplicity over performance, using external services over NIH, etc...
Once a decision is made to resolve the conflict, some people will not be happy. But that's better than having everyone unhappy because everyone is blocked on working on competing solutions at the same time.
This company I was working for, had a TERRIBLE (the worst I've ever seen) management/leaders... (and some of those leaders where even very popular opensource developers) you had the ones that just didn't care about anything except they paycheck, and the ones that just said yes to everyone and to everything to keep everyone happy, which led more than once to competing solutions implemented in parallel (just imagine the codebase we had....). I even remember one time some team decided to go crazy with monorepos and building an entire platform of tooling around it and when we asked for the Proposal (our name for RFCs) they just wrote it on the fly and showed it a few days later.... no need to say they had to "invent" the need to make their already built solution "fit".
So yes, this process is great, but you also need 1) Great/responsible leaders and 2) A not so shitty culture.
It didn't work well at the organization because gate keepers would come in, criticize your design, but offer no alternatives. Process can't fix poor culture.
Guy (formerly a friend) got hired 2 months after me, decided that the backend I'm working on had no architecture, so forced me to discuss architectures with him (he had never designed, developed or worked on web applications before) for two months, in the end filled with animosity, until we settled on an architecture he proposed (because he befriended the CEO better than I did). It frustrates me, whenever I think about how 2 years of problem solving were wasted on a futile architecture that we had to completely rewrite into something more akin to what I initially worked on.
I would try to get agreement on the people it would effect and nearly always rejected. Then everything I pointed out would go wrong but:
"This was completely unexpected"
"really interesting problem..."
At one point our ($100 million USD) security monitor product was down for a month until a customer noticed on our behalf and flipped out. Due to a several problems I had repeatedly pointed out (and fixing any one of them would of prevent it).
If I full sailed ahead then I would get alot of grudges. Culminating in "I found this bug and its your fault" (which was nearly always end up being because that very persons regression) or some other baseless attacks during meetings. It was tiring.
My managers always liked me however. shrug
In turns out almost every time my peers and betters actually never understood our discussions (but of course it would look bad if they actually asked questions). As my career went on I would start forcefully asking questions to confirm their understanding. And indeed this was nearly always the case. So I started making really nice layouts and explanations. And this got me a bit further. But if someone is missing years of required background you can't teach them in a realistic amount of time.
I am careful about who I work with now. I establish during interviews that your future team (or teammate) has the needed technical capacity for the problem set they have relative to their position. I think about the problem set the day before and discuss with them how they are solving it and it has saved me many a time. People are often critical of domain specific problems when given in an interview but I always start there and work my way down to the applicable fundamentals. The higher up they can answer the more senior. It also avoids the problem of asking out of scope questions/coding problems.
The structure (who is doing what, seniority, and how both are established) should always be crystal clear and changeable. Something to be aware of are non-formal structure in an org. Like a junior dev. on random team x has the CEO's ear. These are much harder to find and deal with. The worst problems an org can have IMO.
I’ve used this for open source projects with prettier and excalidraw and at work too.
This is one of the many hidden problems in flat org structures: Without an obvious person to break up disagreements and point teams in the same direction, you end up with small groups of people working in different directions or even working against each other. In practice, someone like the CEO usually steps in and overrules these messes, but it's not efficient to have to escalate all the way to the CEO.
It's also important to build teams that can disagree but commit to decisions they don't particularly like. At some point, it's more important that the teams work together on anything rather than debate endlessly.
Not really. The headline was about "endless discussions". What you propose would end "discussion" before it began.
What would be the benefit/s of that?
OK, what are the competitors to this model? :)
I guess it boils down to what kind of culture you want in your organisation. I‘m involved in a national students‘ association where we have some very strict structures and are highly organised in the way we work. A close partner association of ours is much more free-wheeling, embracing individual freedom and spontaneity over formal processes.
In my experience, our structure helps to give us continuity in the face of constant high member turn-over (students are usually only around a few semesters). This gives us stability, and ideally means that we can concentrate on developing content rather than organisational details. The other association rarely manages to conduct projects on the scale we often work on. In that sense, our structure is highly effective.
On the other hand, we sometimes get lost in the process - ideas die in committee, that sort of thing. Because we don‘t want to move fast and break things, we sometimes struggle to move at all. And like you say, not everybody enjoys working in such a structured environment - those students tend to join the other association. To be fair, they often have more things going on than us, in part because they aren‘t scared of just giving it a go and seeing where it takes them. Their flexibility can be a big strength as well as a weakness.
So it depends on what you want, and I think that in many cases, people join (or stay at) organisations whose style of working suits their own structur-flexibility preferences.
Its been a consistent complaint of many engineers at every company I’ve worked at.
I feel this way about tests. The ones I write probably haven't caught bugs in CI. But often, writing a test clues me in to the fact that an interface is hopelessly borked. That usually leads to a reimplementation that removes a class of bugs.
See more info at:
Now my personal opinions on the subject:
Working at HC it’s really insightful to have the RFCs to review and understand where things came from. At the same time, in my very limited experience there, they were used for gate keeping both on the authoring side and on the review side. Certainly some level of gate keeping is necessary and intended but I hold the opinion today that RFCs could / should be used everywhere and that extra work should be put in to ensure contributions and reviews are fair and welcome. On at least one occasion an RFC had a VP or higher say “no thanks” and then in out-of-band conversations it gets approved. I think I was just too naive and thought decisions and discussions would be very open.
Also a couple teams worked without creating RFCs and I don’t think that was healthy, either. That’s the legalistic side of me coming out... if there’s a process for some but not all what are the exemptions and why?
Managers would tap some people to write RFCs and would dissuade others. Again, probably to be expected in a large, political org and just something to be aware of if you implement RFCs at your org.
I think, you have kind of answered the question yourself. Personally, I like to group people into three categories : understand, accept and agree.
The agree group is the one that you need to get 100% on board. Typically, this is the group that provides you resources (time, money and employees). The accept group is the one that doesn't need to agree but needs to accept the decisions taken. That is, they need to accept the structure in place to make decisions and understand that they are important. The accept group typically are people who are fence sitters and close watchers. They like what they see but do not have to necessarily agree with everything. Finally, the understand group is the ones who do not agree or accept but just understand what's going on. Typically, these people can influence projects outside the working sphere but as long as they understand it; they would not be difficult.
Note: the distinction between Responsible and Accountable is really important but not always understood. If a manager puts an untrained employee in charge of something, it is the manager who should be accountable when something bad happens, not the employee.
For those in the 'agree' group I plan ahead to ensure I can get time with them 'in person' to discuss and debate the proposal in real time.
For those in 'accept' I email/post the document and ask for comments/feedback by a specific, reasonable, deadline. If they're too busy to respond then they've forfeited any right to criticize, complain or block the proposal later on. If they provide feedback that I don't implement then I need to have good reasons why I'm not and share that with them.
The 'understand' group tends to be upper mgmt who trust me and, so long as I've gotten everyone in the 'agree' group onboard, will support the decision/proposal. This is typically done in a regular 'check in' or via email.
Overall I agree with the article that the biggest benefit is from writing things and thinking about them in a structured way. Some ideas sound great, but once you start digging, problems emerge. Being able to pull the brakes even before starting, or refining the idea to a much smaller core is perhaps the most valuable and non-intuitive benefit.
The article mentions that you as the rfc creator ultimately takes the decision how to go forward, and should not seek consensus.
from the post:
> The process seeks a consent-based environment, not a
> consensus-based one. If some people care about a topic a
> lot and come up with a written document that explains many
> things in detail, everyone can (and should) trust them.
> The authors shouldn't wait for everyone's confirmation of
> their proposal. When they get enough feedback, they should
> be able to continue further with or abandon the idea. It's
> their decision. Since they prepared the doc and collected
> many comments on it, they can have a better judgment.
If after a period of time there are no objections expressed in the doc (people are busy etc) then that means the objections were not that important and we can move forward.
I guess what I'm trying to say is: no planning or development method is going to magically cure mismanagement, unwillingness to listen and a tendency not to kill the darlings.
So half the solution of "write it down instead" is simply not putting people in a room. Basically, avoiding as much "discussion" as possible.
Whenever you need progress, you need a process. Discussion on its own is hardly a process. It takes determination and skill to have a constructive, time-efficient conversation.
too many times engineers dont think clearly about the negatives of an approach/proposal (every idea has a negative or disadvatageous aspect) and people should go into a proposal with both eyes open
i cant count how many proposals i have seen that have only mentioned advantages and "alternative" approaches similar to the proposed ones...
Isn't that how the court system works? And yet, despite rulings from the supreme court, a significant number of elected representatives and, according to opinion polls, voters, continue to challenge the result of the US presidential election.
What conclusion might we draw from this?
I'm not asking for advocacy about the legitimacy of the election so much as examining the process for establishing the legitimacy of the result. How's that going?
1) Get authoritative persons or organizations to agree with you -- managers, journalists, distro maintainers if it's a Linux thing, etc. Go over your opponents' heads to get buy-in.
2) Spread the narrative around that your opponents are graybeards who refuse to upskill, luddites, reactionaries, racists/sexists, covert Nazis, pedophiles, etc. Get your authoritative friends on board with this explanation of your opposition. Make their opposition to your proposal their problem, and tie that opposition in to whatever undesirable qualities they possess or are purported to possess.
3) Soldier onward as if it were a fait accompli. Convince your authoritative friends from step 1 that it is a fait accompli. March to victory unopposed, since no one would want to be associated with whatever undesirable group you chose in step 2.
So, what are you going to do about it?