11 ms·

How to Stop Endless Discussions

344 points by candost 6y ago

wombatmobile 6y ago
So, the article is saying that by getting proponents to make their case in writing, it forces them to think things through and avoid fecklessness. 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?
- Raidion 6y ago
  I think this can turn (or devolve) into a discussion about the flaws of democracy, but which really don't apply in these situations. At most companies, there is a pretty clear escalation pathway to help resolve those who refuse to align with the organization's reality. Even in open source projects, there can be some sort of "vote" to establish the organization's "truth" and remove those who disagree. The US government has guarantees that certain people have voices (even if the specific mouthpiece can be unseated in a few edge cases), and those guarantees don't exist in most private or even somewhat public institutions.
cuddlecake 6y ago
The first paragraph is killing me. Had that exact situation in a startup I joined. It was annoying and it ruined my passion for the project, because the outcome of that "one" discussion shaped the project for two years. 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.
- deleted 6y ago
  [deleted]
- ipodopt 6y ago
  Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a solid simpler designs. Always on projects I was ether fully or partly coding. 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.
5tefan 6y ago
Can't remember a single company where anyone was willing to write or read beyond some (shitty) slides. I am sick of management by slides. Leadership needs to know their experts and whom to follow when and then trust them to get the job done. For that of course you need the real experts. Know what I mean?
- kubanczyk 6y ago
  > Leadership needs to [some opinions] So, what are you going to do about it?
unabst 6y ago
I think the evidence points to discussions as naturally tending towards endlessness. Without an end definiting goal or a line drawn, discussions tend to feed themselves to ad infinitum. Basically, the more people you put in a room together, the more they will keep on talking until it's time to go home or someone stands up and tells everyone to shut up. In this scenario, you almost question the person that doesn't talk, and almost urge yourself to join this "discussion". Without moderation, topics could digress anywhere. So you have egos competing to make their mark in this amalgamation of a "discussion" that is supposedly supposed to self moderate and direct itself to a conclusion? The more frustrated those responsible for a needed outcome get, their words and tone become less "fun", as does anyone frustrated about anything said. 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.
psim1 6y ago
Rules of order can help. I have been in meetings where certain people essentially filibuster simply because their idea is not well liked but they think that by repeating themselves and talking endlessly, they will win everyone over. End result: it doesn’t work, wastes everyone’s time, and leaves the entire group tired and frustrated. Setting hard time limits for ideas, feedback, and open discussion can help curb this.
corytheboyd 6y ago
I’ve often wondered what it would be like to work with others through something as formal as RFCs, because honestly it sounds like it would only work if you have massive amounts of time to invest in planning. It seems really easy for one or more people to spend tons of time working the perfect proposal only for one or more people to shoot it down. It’s probably just the environments I have worked in that lead me to feel this way, I’m sure this process actual works well for some teams.
- BlargMcLarg 6y ago
  From my experience, the biggest problem with RFCs comes from the upfront planning costs quickly demanding the feature to be implemented, regardless of the understanding of how detrimental it is in the long run changing later on. There is always that case where someone goes "wait, this doesn't work unless we do X, which hurts us in the long term, so we should change things and do Y". Except now management and the client are so stuck, they demand the RFC regardless of X. Part of this can be mitigated by prototypes, but it is not a fail safe. Or worse, management tries to cut down the costs by involving only one technical person for a short time, who then completely misses a few critical points and the same problem forms. 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.
  - corytheboyd 6y ago
    Good points indeed. I think you can even further say that people will just make mistakes regardless of the process. If engineers take too long to deliver it’s “over-engineering” or if the deliverable fails at any point the engineers “didn’t know what they were doing”— if requirements change suddenly along with deadlines it’s “mismanagement”. I’m not saying these are not real problems, it’s more that they’re inevitabilities and the processes we come up are just to mitigate them, not eliminate them entirely.
sbpayne 6y ago
In my experience (mostly large tech cos), getting anyone to pay attention to your design doc/RFC (regardless of quality or length) was fairly difficult. Its been a consistent complaint of many engineers at every company I’ve worked at.
bitwize 6y ago
Here's how to do it in the 2020s: 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.
hda111 6y ago
At my workplace everything is discussed and decided verbally. Taking notes is usually only done by the person in charge of the new task, so the person knows how they are expected solve the ticket. The RFC approach cannot work here. But I think this RFC approach is better and more efficient because you can discuss several ideas at the same time and without a meeting. I tried to convince the coworkers to use RFC some time ago but it’s been ignored by everyone. All RFCs are from me without any comment.
andrekandre 6y ago
nabc sounds good, but i might be inclined to augment it with a "d" that being "disadvantages" in addition to "advantages" 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...
- candost 6y ago
  it’s true. I also thought about adding disadvantages. But alternatives and approach showed them in general. Also, people who comment on RFCs tend to focus on the disadvantages as well. I’ll think about it a bit more.
jonwalch 6y ago
I worked at a unicorn that implemented the RFC process. I found it extremely useful for solidifying my own thinking. 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.
lorax 6y ago
I really wish comments were disabled on this article, that would really fit with the headline
- tobylane 6y ago
  This is a libertarian free speech place. We aren’t discussing a consideration for a subcommittee to form a panel to investigate whether W1A accurately dramatises the BBC. There’s a time and a place for RFCs.
  - DonHopkins 6y ago
    Where did you get the idea HN is libertarian? Most people around here aren't that heartless and cruel.
- wombatmobile 6y ago
  > I really wish comments were disabled on this article, that would really fit with the headline 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?
telesilla 6y ago
Does anyone have any experience how this might fit inside a company? Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, and as long as everyone is given the opportunity and time frame it sounds like a fair way to move forward with design decisions.
- dwr3k1ng 6y ago
  I think you can even bring this topic up with an RFC in the format that author mentioned directly and open it for comments. The process can start evolving from there.
- tchalla 6y ago
  > Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, 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.
  - KineticLensman 6y ago
    The UK military (amongst others) map stakeholders into one of four categories: Responsible, Accountable, Consulted and Informed. (RACI) [0]. Stakeholders tend to sit up and take notice if they think they might be Responsible let alone Accountable for something. 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. [0] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...
tchalla 6y ago
> Then the competition section comes. It is the part the authors have to consider competitors of their proposal. Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions. 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.
- phkahler 6y ago
  I like the idea of looking at implications and limitations. That discussion can be useful for understanding. However, at the end I think all options need to be filtered through "will it work?" Because if it doesn't there is no point. That discussion may also result in a change to the definition used for weather it works or not.
  - ssss11 6y ago
    Yeah in my projects we usually end up with options on a scorecard against various metrics such as feasibility, cost, security, important features etc.. its not always an exact science which can rattle some participants but the approximate/relative scoring should give the group an answer to all hopefully align with, take to the decision maker and pitch for that desired option.
  - tchalla 6y ago
    I see where you are coming from. I would like to add two points. First, I have rarely seen only one approach to "it works". There are always more than one ways to "will it work?". Second, in order to get around the definition of "working" - I encourage people to specify success criteria upfront. Now, even if the definition of success criteria change later - they are all transparent. Everyone involved in the process has accountability and responsibility to oversee the right success criteria, change of success criteria.
spaetzleesser 6y ago
I work in medical and we have a ton of review processes. Problem is that you don’t get the time to do a real review. There is also no real process of handling the review feedback so even if you find the time to understand the issue management will still go ahead with what they wanted to do anyway. Not sure how to handle this. It seems there is no amount of process to ensure that people act in good faith.
- 0xbadcafebee 6y ago
  If your people aren't acting in good faith, you're screwed. Nothing can fix that but working on the culture, and process can't fix culture.
vjeux 6y ago
One thing that I found to work well is to create an escalation process. By default people are trusted to make decisions but if they fail to do so, then there is a higher authority that will make it and has the trust in the organization to do so. I’ve used this for open source projects with prettier and excalidraw and at work too.
- PragmaticPulp 6y ago
  Most org structures have this sort of decision escalation process built in, even if it's not explicit. If a team fails to arrive at a decision, their boss should step in to pick a direction. 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.
macca321 6y ago
I think a process like this works well for enabling the success of the kind of people who like the sound of a process like this.
- smegma2 6y ago
  Is this a criticism of the format? What format would you suggest that doesn't have this quality?
- veddox 6y ago
  ... just as a more flexible model would favour people who prefer that mode of working. 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.
spodek 6y ago
How to stop endless discussions is another variant of xkcd's How Standards Proliferate https://imgs.xkcd.com/comics/standards.png https://imgs.xkcd.com/comics/standards.png
JoeAltmaier 6y ago
So often in our business, there are few that understand the whole picture of your problem area. Inviting too much critique results in uninformed objections or redundant suggestions that have already been considered and rejected. 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.
- rubyfan 6y ago
  We’re attempting to undergo a culture and operating model change shifting from gate keeping to focus on outcomes. Please wish us luck. 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.
- musingsole 6y ago
  >The person who has been charged with a task, should have authority to carry it out as best they see fit. 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.
  - p_l 6y ago
    exactly. Sometimes it's even worse: "Everyone needs to own the tickets" quite quickly shows that you own the responsibility and blame, but none of authority.
  - 6y ago
Veen 6y ago
They’ve reinvented the memo.
tylerg 6y ago
I am very disappointed this comment thread has not yet turned into an endless discussion.
- ryanwwest 6y ago
  Same here.
siliconc0w 6y ago
My ideal process - authors draft a design document. There is a team review. If there are strong objections (i.e beyond suggestions) a comparative doc is written with a summary from both positions and a commentary from each side on each other's position (~1-2 pages). Then one or more senior technical engineers make a call and document why in the document. After this decision, the discussion is closed for a TTL agreed to in the comparative doc (i.e lets try this for six months and re-evaluate). This is all documented in a project's decision log. This allows decisions to be quickly made with accountability for decision makers while giving anyone on the team an opportunity to propose an alternative approach. Ideally, given a need/objective you are usually considering multiple approaches which is a good opportunity for junior engineers to contribute to processes usually dominated by more senior engineers (i.e even asking a junior engineer to write a document arguing, "we do nothing" as an option is useful). Basically make sure this is encouraged in the organization and so that culturally this is celebrated and is seen as just an important of a contribution as authoring the 'winning' design.
- egman_ekki 6y ago
  Interesting. How do you keep track of all the in progess TTLs? How do you decide the TTL length? Won't this process end up ultimately filling the team's/project schedule with revisions of previous decisions?
  - siliconc0w 6y ago
    The TTL is based on the cost, time to implement, and time needed to gather enough signal to make a determination. So if you doing normal 'mvp' style of development where you ship intermediaries you should have some signal whether something works in at least six months, ideally sooner. Sometimes this means you might reconsider or even reverse a decision or apply what you learned to a new problem but mostly this just builds confidence and trust in the team that the decision making process is generally 'good enough'. 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.
simonw 6y ago
We implemented a RFC-style process at a previous employer. It worked pretty well. 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).
- sirlantis 6y ago
  A too short or complete lack of an alternatives section has become red flag for me when reviewing proposals. 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.
jancsika 6y ago
> I think it achieves a way more significant benefit by only writing the document itself. Writing shapes thoughts. 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.
wwweston 6y ago
> We used the NABC model from Stanford. The model starts with defining the Need, followed by Approach, Benefits, and lastly, Competitors... the competition section is the part the authors have to consider competitors of their proposal. Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions. With these four parts, the NABC is a pretty good model. But it's not the only one. OK, what are the competitors to this model? :)
- candost 6y ago
  you can check how Rust Programming language uses RFC. Also Internet Society RFCs have different format as well. :)
spacekitcat 6y ago
We do RFCs, I dislike the concept. It feels like an extension of this troubling trend of taking away autonomy from engineers.
deleted 6y ago
[deleted]
midrus 6y ago
I worked for a company that followed a similar process. This worked really well, except for one thing which I blame the terrible culture at that company, which is: Some times people would have strong disagreements on how to do something, so you end up with two competing RFCs to solve the same problem, which basically divided engineering into three camps: one for each proposal, and the people which don't care. 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.

344 points by candost 6y ago

So, the article is saying that by getting proponents to make their case in writing, it forces them to think things through and avoid fecklessness. 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?

Raidion 6y ago
I think this can turn (or devolve) into a discussion about the flaws of democracy, but which really don't apply in these situations. At most companies, there is a pretty clear escalation pathway to help resolve those who refuse to align with the organization's reality. Even in open source projects, there can be some sort of "vote" to establish the organization's "truth" and remove those who disagree. The US government has guarantees that certain people have voices (even if the specific mouthpiece can be unseated in a few edge cases), and those guarantees don't exist in most private or even somewhat public institutions.

cuddlecake 6y ago

The first paragraph is killing me. Had that exact situation in a startup I joined. It was annoying and it ruined my passion for the project, because the outcome of that "one" discussion shaped the project for two years. 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.

deleted 6y ago
[deleted]
ipodopt 6y ago
Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a solid simpler designs. Always on projects I was ether fully or partly coding. 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.

5tefan 6y ago

Can't remember a single company where anyone was willing to write or read beyond some (shitty) slides. I am sick of management by slides. Leadership needs to know their experts and whom to follow when and then trust them to get the job done. For that of course you need the real experts. Know what I mean?

kubanczyk 6y ago
> Leadership needs to [some opinions] So, what are you going to do about it?

unabst 6y ago

I think the evidence points to discussions as naturally tending towards endlessness. Without an end definiting goal or a line drawn, discussions tend to feed themselves to ad infinitum. Basically, the more people you put in a room together, the more they will keep on talking until it's time to go home or someone stands up and tells everyone to shut up. In this scenario, you almost question the person that doesn't talk, and almost urge yourself to join this "discussion". Without moderation, topics could digress anywhere. So you have egos competing to make their mark in this amalgamation of a "discussion" that is supposedly supposed to self moderate and direct itself to a conclusion? The more frustrated those responsible for a needed outcome get, their words and tone become less "fun", as does anyone frustrated about anything said. 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.

psim1 6y ago

Rules of order can help. I have been in meetings where certain people essentially filibuster simply because their idea is not well liked but they think that by repeating themselves and talking endlessly, they will win everyone over. End result: it doesn’t work, wastes everyone’s time, and leaves the entire group tired and frustrated. Setting hard time limits for ideas, feedback, and open discussion can help curb this.

corytheboyd 6y ago

I’ve often wondered what it would be like to work with others through something as formal as RFCs, because honestly it sounds like it would only work if you have massive amounts of time to invest in planning. It seems really easy for one or more people to spend tons of time working the perfect proposal only for one or more people to shoot it down. It’s probably just the environments I have worked in that lead me to feel this way, I’m sure this process actual works well for some teams.

BlargMcLarg 6y ago
From my experience, the biggest problem with RFCs comes from the upfront planning costs quickly demanding the feature to be implemented, regardless of the understanding of how detrimental it is in the long run changing later on. There is always that case where someone goes "wait, this doesn't work unless we do X, which hurts us in the long term, so we should change things and do Y". Except now management and the client are so stuck, they demand the RFC regardless of X. Part of this can be mitigated by prototypes, but it is not a fail safe. Or worse, management tries to cut down the costs by involving only one technical person for a short time, who then completely misses a few critical points and the same problem forms. 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.
- corytheboyd 6y ago
  Good points indeed. I think you can even further say that people will just make mistakes regardless of the process. If engineers take too long to deliver it’s “over-engineering” or if the deliverable fails at any point the engineers “didn’t know what they were doing”— if requirements change suddenly along with deadlines it’s “mismanagement”. I’m not saying these are not real problems, it’s more that they’re inevitabilities and the processes we come up are just to mitigate them, not eliminate them entirely.

sbpayne 6y ago

In my experience (mostly large tech cos), getting anyone to pay attention to your design doc/RFC (regardless of quality or length) was fairly difficult. Its been a consistent complaint of many engineers at every company I’ve worked at.

bitwize 6y ago

Here's how to do it in the 2020s: 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.

hda111 6y ago

At my workplace everything is discussed and decided verbally. Taking notes is usually only done by the person in charge of the new task, so the person knows how they are expected solve the ticket. The RFC approach cannot work here. But I think this RFC approach is better and more efficient because you can discuss several ideas at the same time and without a meeting. I tried to convince the coworkers to use RFC some time ago but it’s been ignored by everyone. All RFCs are from me without any comment.

andrekandre 6y ago

nabc sounds good, but i might be inclined to augment it with a "d" that being "disadvantages" in addition to "advantages" 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...

candost 6y ago
it’s true. I also thought about adding disadvantages. But alternatives and approach showed them in general. Also, people who comment on RFCs tend to focus on the disadvantages as well. I’ll think about it a bit more.

jonwalch 6y ago

I worked at a unicorn that implemented the RFC process. I found it extremely useful for solidifying my own thinking. 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.

lorax 6y ago

I really wish comments were disabled on this article, that would really fit with the headline

tobylane 6y ago
This is a libertarian free speech place. We aren’t discussing a consideration for a subcommittee to form a panel to investigate whether W1A accurately dramatises the BBC. There’s a time and a place for RFCs.
- DonHopkins 6y ago
  Where did you get the idea HN is libertarian? Most people around here aren't that heartless and cruel.
wombatmobile 6y ago
> I really wish comments were disabled on this article, that would really fit with the headline 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?

telesilla 6y ago

Does anyone have any experience how this might fit inside a company? Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, and as long as everyone is given the opportunity and time frame it sounds like a fair way to move forward with design decisions.

dwr3k1ng 6y ago
I think you can even bring this topic up with an RFC in the format that author mentioned directly and open it for comments. The process can start evolving from there.
tchalla 6y ago
> Getting sign off from peers can be tricky when everyone is busy, but perhaps only a few reviewers are needed, 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.
- KineticLensman 6y ago
  The UK military (amongst others) map stakeholders into one of four categories: Responsible, Accountable, Consulted and Informed. (RACI) [0]. Stakeholders tend to sit up and take notice if they think they might be Responsible let alone Accountable for something. 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. [0] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...

tchalla 6y ago

> Then the competition section comes. It is the part the authors have to consider competitors of their proposal. Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions. 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.

phkahler 6y ago
I like the idea of looking at implications and limitations. That discussion can be useful for understanding. However, at the end I think all options need to be filtered through "will it work?" Because if it doesn't there is no point. That discussion may also result in a change to the definition used for weather it works or not.
- ssss11 6y ago
  Yeah in my projects we usually end up with options on a scorecard against various metrics such as feasibility, cost, security, important features etc.. its not always an exact science which can rattle some participants but the approximate/relative scoring should give the group an answer to all hopefully align with, take to the decision maker and pitch for that desired option.
- tchalla 6y ago
  I see where you are coming from. I would like to add two points. First, I have rarely seen only one approach to "it works". There are always more than one ways to "will it work?". Second, in order to get around the definition of "working" - I encourage people to specify success criteria upfront. Now, even if the definition of success criteria change later - they are all transparent. Everyone involved in the process has accountability and responsibility to oversee the right success criteria, change of success criteria.

spaetzleesser 6y ago

I work in medical and we have a ton of review processes. Problem is that you don’t get the time to do a real review. There is also no real process of handling the review feedback so even if you find the time to understand the issue management will still go ahead with what they wanted to do anyway. Not sure how to handle this. It seems there is no amount of process to ensure that people act in good faith.

0xbadcafebee 6y ago
If your people aren't acting in good faith, you're screwed. Nothing can fix that but working on the culture, and process can't fix culture.

vjeux 6y ago

One thing that I found to work well is to create an escalation process. By default people are trusted to make decisions but if they fail to do so, then there is a higher authority that will make it and has the trust in the organization to do so. I’ve used this for open source projects with prettier and excalidraw and at work too.

PragmaticPulp 6y ago
Most org structures have this sort of decision escalation process built in, even if it's not explicit. If a team fails to arrive at a decision, their boss should step in to pick a direction. 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.

macca321 6y ago

I think a process like this works well for enabling the success of the kind of people who like the sound of a process like this.

smegma2 6y ago
Is this a criticism of the format? What format would you suggest that doesn't have this quality?
veddox 6y ago
... just as a more flexible model would favour people who prefer that mode of working. 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.

spodek 6y ago

How to stop endless discussions is another variant of xkcd's How Standards Proliferate https://imgs.xkcd.com/comics/standards.png https://imgs.xkcd.com/comics/standards.png

JoeAltmaier 6y ago

So often in our business, there are few that understand the whole picture of your problem area. Inviting too much critique results in uninformed objections or redundant suggestions that have already been considered and rejected. 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.

rubyfan 6y ago
We’re attempting to undergo a culture and operating model change shifting from gate keeping to focus on outcomes. Please wish us luck. 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.
musingsole 6y ago
>The person who has been charged with a task, should have authority to carry it out as best they see fit. 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.
- p_l 6y ago
  exactly. Sometimes it's even worse: "Everyone needs to own the tickets" quite quickly shows that you own the responsibility and blame, but none of authority.
- 6y ago

Veen 6y ago

They’ve reinvented the memo.

tylerg 6y ago

I am very disappointed this comment thread has not yet turned into an endless discussion.

ryanwwest 6y ago
Same here.

siliconc0w 6y ago

My ideal process - authors draft a design document. There is a team review. If there are strong objections (i.e beyond suggestions) a comparative doc is written with a summary from both positions and a commentary from each side on each other's position (~1-2 pages). Then one or more senior technical engineers make a call and document why in the document. After this decision, the discussion is closed for a TTL agreed to in the comparative doc (i.e lets try this for six months and re-evaluate). This is all documented in a project's decision log. This allows decisions to be quickly made with accountability for decision makers while giving anyone on the team an opportunity to propose an alternative approach. Ideally, given a need/objective you are usually considering multiple approaches which is a good opportunity for junior engineers to contribute to processes usually dominated by more senior engineers (i.e even asking a junior engineer to write a document arguing, "we do nothing" as an option is useful). Basically make sure this is encouraged in the organization and so that culturally this is celebrated and is seen as just an important of a contribution as authoring the 'winning' design.

egman_ekki 6y ago
Interesting. How do you keep track of all the in progess TTLs? How do you decide the TTL length? Won't this process end up ultimately filling the team's/project schedule with revisions of previous decisions?
- siliconc0w 6y ago
  The TTL is based on the cost, time to implement, and time needed to gather enough signal to make a determination. So if you doing normal 'mvp' style of development where you ship intermediaries you should have some signal whether something works in at least six months, ideally sooner. Sometimes this means you might reconsider or even reverse a decision or apply what you learned to a new problem but mostly this just builds confidence and trust in the team that the decision making process is generally 'good enough'. 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.

simonw 6y ago

We implemented a RFC-style process at a previous employer. It worked pretty well. 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).

sirlantis 6y ago
A too short or complete lack of an alternatives section has become red flag for me when reviewing proposals. 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.

jancsika 6y ago

> I think it achieves a way more significant benefit by only writing the document itself. Writing shapes thoughts. 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.

wwweston 6y ago

> We used the NABC model from Stanford. The model starts with defining the Need, followed by Approach, Benefits, and lastly, Competitors... the competition section is the part the authors have to consider competitors of their proposal. Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions. With these four parts, the NABC is a pretty good model. But it's not the only one. OK, what are the competitors to this model? :)

candost 6y ago
you can check how Rust Programming language uses RFC. Also Internet Society RFCs have different format as well. :)

spacekitcat 6y ago

We do RFCs, I dislike the concept. It feels like an extension of this troubling trend of taking away autonomy from engineers.

deleted 6y ago

[deleted]

midrus 6y ago

I worked for a company that followed a similar process. This worked really well, except for one thing which I blame the terrible culture at that company, which is: Some times people would have strong disagreements on how to do something, so you end up with two competing RFCs to solve the same problem, which basically divided engineering into three camps: one for each proposal, and the people which don't care. 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.