[HN Gopher] How to Stop Endless Discussions
___________________________________________________________________
How to Stop Endless Discussions
Author : candost
Score : 222 points
Date : 2021-01-03 15:07 UTC (7 hours ago)
(HTM) web link (candost.blog)
(TXT) w3m dump (candost.blog)
| jonwalch wrote:
| 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.
| unabst wrote:
| 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.
| tylerg wrote:
| I am very disappointed this comment thread has not yet turned
| into an endless discussion.
| JoeAltmaier wrote:
| 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 wrote:
| 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.
| WC3w6pXxgGd wrote:
| This is called bike-shedding, and I see it every day at work.
| musingsole wrote:
| >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.
| qznc wrote:
| ...and if someone naive enough steps up to take
| responsibility, they don't provide enough authority/resources
| to achieve the task. This is how organizations destroy
| autonomy in their employees.
| hashkb wrote:
| This can be by design, so your risk takers always fail, and
| thus you can say you encourage risk takers but always have
| cause to fire them, resulting in a team of sycophants with
| a "culture of autonomy".
| xondono wrote:
| This.
|
| 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.
| crispyambulance wrote:
| > but they will refuse to ask for help until too late.
|
| 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.
| [deleted]
| tipsysquid wrote:
| >So far my only weapon against this has been to be very
| selective while hiring.
|
| What are some things that you look for in a candidate for a
| successful hire?
| gregmac wrote:
| > I has bosses that expected me to do things their way
|
| 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.
| MattGaiser wrote:
| > 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.
|
| 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.
| alanfranz wrote:
| I understand what you say; you want people to solve problems,
| not to execute tasks. But, there're some points that I
| figured out myself during my career that may be useful:
|
| > 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.
| watwut wrote:
| > think that their view is the Only One View; who does
| things differently is Just Wrong (as you say yourself about
| your past bosses)
|
| This is 100% my experience.
|
| I am not mind reader.
| wool_gather wrote:
| You're right, but it's not even really an "attitude", and
| it's not necessarily malicious or even stemming from a
| power relationship.
|
| 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.
| hashkb wrote:
| You can't just go around recognizing what people don't
| understand. That's what got Socrates killed. You've gotta
| make them understand what they don't understand without
| making them want to kill you. That's what makes a great
| teacher / leader / etc.
| alanfranz wrote:
| > You've gotta make them understand what they don't
| understand without making them want to kill you
|
| That's a different problem. You need to tell them what
| you want, unless it's a mathematical, universal truth.
| the_arun wrote:
| Requirements or the asks need to be clealy documented
| before someone goes for a solution. The problem usually
| is they discover more use case while reasearching the
| solution.
| alanfranz wrote:
| > 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.
|
| 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?
| PicassoCTs wrote:
| Doing things differently is not only wrong, its also often
| perceived as a power-play challenge. For if the captain
| does not steer the ship, what good for is a captain? So the
| creative worker, is perceived as a challenge by lots of
| management, that thinks it has to defeat this with micro
| management.
| vjeux wrote:
| 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 wrote:
| 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.
| cuddlecake wrote:
| 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]
| wwweston wrote:
| > 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 wrote:
| you can check how Rust Programming language uses RFC. Also
| Internet Society RFCs have different format as well. :)
| telesilla wrote:
| 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.
| exceptione wrote:
| > Getting sign off from peers can be tricky when everyone is
|
| > busy
|
| 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.
| gingerlime wrote:
| We use a similar process, inspired by Basecamp[0]. For us it
| seems like the biggest challenge is getting feedback from the
| right people. Mostly due to the sheer number of pitches (RFCs,
| project proposals). And we're a small team. Also it's a bit
| difficult to decide what goes first and how to make sure we
| don't bite more than we can chew.
|
| 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.
|
| [0] https://basecamp.com/shapeup
| lazyant wrote:
| You don't get sign off (approval) from peers but comments from
| them. It's important the RFC is public and anyone can comment
| on it.
|
| 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.
| dwr3k1ng wrote:
| 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 wrote:
| > 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 wrote:
| 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_m
| atr...
| maroonblazer wrote:
| I do something similar and, depending on which group a given
| stakeholder falls into, determines how much effort I put into
| getting their input.
|
| 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.
| leetrout wrote:
| RFCs are used to great success (IMO) at HashiCorp.
|
| See more info at:
|
| https://www.hashicorp.com/blog/redesigning-hashicorp-consul-...
|
| https://www.hashicorp.com/resources/closing-keynote-research...
|
| 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.
| simonw wrote:
| 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).
| wombatmobile wrote:
| 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 wrote:
| 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.
| tchalla wrote:
| > 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.
| mwilliamson wrote:
| Similarly, I've found one of the most useful questions to pose
| for each option is "What would need to be true for this to be a
| good idea?". This is helpful whether you're initially
| supportive of or opposed to the idea. In either case, you have
| to be explicit about the conditions/facts you think are
| necessary for success and why they're either true or false,
| which tends to lead to a more concrete discussion with more
| space for agreement and shared understanding. If you're
| supportive, this makes it easier to acknowledge that those
| conditions/facts might not necessarily be true. If you're
| opposed, this makes it easier to appreciate the idea and work
| on it despite your reservations.
| tchalla wrote:
| > Similarly, I've found one of the most useful questions to
| pose for each option is "What would need to be true for this
| to be a good idea?".
|
| 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".
| Smaug123 wrote:
| This sounds very related to one of David Marquet's credos
| from "Turn The Ship Around!". Don't ask "Are we ready?";
| instead, ask "How ready are we?". Everything needs to be
| phrased so as to invite people to express the knowledge they
| have, rather than demanding what amounts to a declaration of
| tribal identity.
| phkahler wrote:
| 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.
| tchalla wrote:
| 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.
| phkahler wrote:
| >> I have rarely seen only one approach to "it works".
|
| 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.
| ssss11 wrote:
| 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.
| spaetzleesser wrote:
| 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.
| jancsika wrote:
| > 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.
| [deleted]
| macca321 wrote:
| 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.
| veddox wrote:
| ... 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.
| smegma2 wrote:
| Is this a criticism of the format? What format would you
| suggest that doesn't have this quality?
| psim1 wrote:
| 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.
| spodek wrote:
| How to stop endless discussions is another variant of xkcd's How
| Standards Proliferate https://imgs.xkcd.com/comics/standards.png
| 5tefan wrote:
| 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?
| Veen wrote:
| They've reinvented the memo.
| midrus wrote:
| 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.
| siliconc0w wrote:
| 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 wrote:
| 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 wrote:
| 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.
| lorax wrote:
| I really wish comments were disabled on this article, that would
| really fit with the headline
| tobylane wrote:
| 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 wrote:
| Where did you get the idea HN is libertarian? Most people
| around here aren't that heartless and cruel.
| wombatmobile wrote:
| > 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?
| spacekitcat wrote:
| We do RFCs, I dislike the concept. It feels like an extension of
| this troubling trend of taking away autonomy from engineers.
___________________________________________________________________
(page generated 2021-01-03 23:00 UTC)