Skip to content

Latest commit

 

History

History
77 lines (59 loc) · 5.89 KB

Team-decision-making.md

File metadata and controls

77 lines (59 loc) · 5.89 KB
Raw
description last_modified
Some tips on making decisions as a team
2020-12-24 14:15:34 UTC

Team decision-making

Contents

Consent as an alternative to consensus

Some typical ways of making decisions in a team:

  • Autocratic decision-making: someone (manager, lead, ...) makes a decision, and that's it
    • Extremely fast
    • Only the decision-maker can be held accountable for the decision
    • No involvement from the team, which makes the team less likely to support the decision
    • Can be useful in some extreme cases
  • Majority vote: let people vote on a set of options, the option with most votes wins
    • Pretty fast
    • Each team member can give input (their vote) and that input influences the final decision in a straightforward way
    • Pretty superficial, discourages in-depth discussion
    • Can be useful for low stakes decisions where the cost of making suboptimal decisions is not huge
  • Consensus: discuss with the team until everybody agrees on the best way to move forward
    • Very slow, sometimes no decision reached at all within an acceptable time frame
    • Tends to have people trying to find the "perfect" solution, instead of something that is just "good enough"
    • Risk of people focusing too much on their individual preferences instead of on moving forward
    • Can be useful for very high-risk decisions

An alternative way of making decisions is consent:

  • What you're looking for here is a solution thats good enough for now and safe enough to try
  • Instead of taking a potential solution and looking for reasons to do it that way, you take a potential solution and look if there are any reasons not to do it that way
    • The light is green, unless we find an important reason why it should be red
  • Important ingredients:
    • When a proposal is made, make sure that people understand what the proposal means (this doesn't include opinions about the proposal yet)
    • Then, look for any valid objections to the proposal
      • These objections can contain very important insights
      • An objection can lead to the proposal being dropped, but it can also lead to the proposal being improved
    • If no objections are deemed important enough to block the proposal, the proposal is approved
      • It can make sense to log any objections that you didn't see as showstoppers

Some benefits of consent:

  • Typically a lot faster than consensus, while still involving the entire team in the decision and giving the possibility to discuss some important concerns in-depth
  • Can also be used outside of meetings: When you are about to do something that people might not be expecting, announce it to the team and give them the chance to stop you or suggest an alternative approach

There is no one-size-fits-all here, and all of these are useful to have in your toolbox. Sometimes, it even makes sense to combine them. For example, you could go for consensus within a small sub-team and then ask for consent from the rest of the team.

Synchronous and asynchronous decision-making

  • Synchronous decision-making: the entire team sits together in a meeting room or call to discuss potential approaches, pros and cons
  • Asynchronous decision-making: people analyze potential approaches or come up with new ones by themselves (or in small sub-teams) and then share their results

The synchronous option typically seems like the default one: "Let's get together so we can reach a decision". However, there is also a lot of value in asynchronous decision-making, as it gives people the time and space to really explore the problem and potential approaches, do some research and maybe even practice some Hammock-driven development.

Often, you can get the best results (while minimizing total time investment) by combining the two options:

  • Before a meeting, provide people with clear information regarding what will be discussed, any resources that they can use to better understand the problem, any approaches that are already being considered, ...
    • It also helps to be explicit about what is expected by the time the meeting starts. Do we just want people to have a clear understanding of the problem and context, or do we expect people to bring their own proposed solutions?
  • Give people the time and space to properly prepare themselves for the meeting by doing the necessary reading, analysis, research, experimentation, ...
  • It can be useful to give people a shared space to document their findings, which helps prevent duplicate work and can also trigger some asynchronous discussion
    • Asynchronous discussion makes sense for a few well thought out messages. If the conversation requires a lot of back-and-forth, synchronous discussion probably works better.
    • Writing things down has some benefits of its own, see also Why does writing matter in remote work?
  • Once the meeting starts, you can use the earlier asynchronous work to make optimal use of the higher communication bandwidth that meetings provide

Resources