We (Griffin's engineering team) were disappointed by the effectiveness of previous decision-making processes we'd used. We found that:

• hierarchical decision-making was slow and inaccurate, and often stymied innovation and autonomy
• traditional consensus-based decision-making was also slow and ineffective, and skewed us towards middle-of-the-road solutions

So we decided to roll up our sleeves and try to solve this challenge from first-principles. Our goal was to make decisions faster and more accurately, while keeping the whole process empowering for everyone.

As a remote-first company, we knew our decision process needed to be asynchronous-first, and prioritise time for deep-work over meetings.

This blog post explains how we achieved our goals.

Why not just use decision meetings?

Meetings can be incredibly valuable for brainstorming, designing, planning, team building, and even deciding. However, they don't always take full advantage of the group's collective intelligence, nor are they always an effective use of people's time.

As I explained in my last blog post meetings interrupt deep work, force context switching, and are sequential rather than parallel. They're also time-consuming, require schedule coordination, prioritise fast thinkers over slow thinkers, allow loud voices to dominate, and are prone to bias and groupthink.

The solution is asynchronous consensus-based decision making

Asynchronous consensus-based decision making solves all of these challenges.

• Everyone chooses when to switch context from deep work to decision making.
• Everyone works in parallel on clarifying the problem, generating potential solutions, and voting on the decision.
• Slow thinkers/talkers aren't excluded from the process.
• The entire decision process is clearly documented.
• One loud voice can't dominate the discussion and lead to biased decisions.

How to do effective asynchronous consensus-based decision making

1. Identify a decision that is complex, important, or irreversible.
2. Document and share the challenge.
3. Collaboratively brainstorm potential solutions.
4. Use a decision matrix to compare the identified solutions.
5. Use an anonymous poll to select a preferred solution.
6. If total consensus isn’t reached in the poll, hold a decision meeting.

1. Identify a decision that is complex, important, or irreversible

At Griffin, “autonomy by default” is part of our culture. This means individuals and teams are empowered to use their best judgement when making decisions that are unlikely to find disagreement within the rest of the company and where the wrong decision would be easily fixed.

In engineering, most decisions are small enough to be made by the individual or pair who is working on the solution, without needing to consult with their team or a wider group of peers. But sometimes the impact of a decision is so large or a challenge is so complex that taking the time to analyse the available options and decide on the right solution together is worth the cost of that process.

When someone identifies a complex or important decision, they become the decision catalyst, i.e the person who initiates the consensus-based decision process.

Build a culture that rewards–not punishes–people for getting problems into the open where they can be solved.

2. Document and share the problem

The decision catalyst should document the problem they've identified, and capture any initial solutions that they've considered.

We use Notion for this, as it encourages collaborative editing and commenting, and has plenty of block types to help the decision catalyst clearly structure their thoughts‍—‌but any collaborative online writing tool would work.

A perfect formulation of a problem is already half its solution.

The decision catalyst should share their document (we call it a “Request For Comments”, or RFC) with anyone they think would be interested and useful for solving the problem. Usually that's others from their team, but depending on the scope of the problem, people from other teams, or even other departments may need to be involved.

3. Collaboratively brainstorm potential solutions

Everyone who has been invited to the RFC now has a chance to read and understand the problem, and think about the presented solutions. Now ideas can be challenged via comments, and new ideas are generated collaboratively via the discussion. This type of asynchronous brainstorming session means that “slow thinkers” and people who are less comfortable speaking up during meetings are empowered to share their thoughts and contribute to the decision.

We always try to come up with at least three solution options for any given problem.

Before deciding on a course of action, come up with three alternatives. To have one option is no choice, two is a dilemma, three offers new possibilities.

4. Use a decision matrix to compare the identified solutions

Decision matrices are the best tool for collaboratively comparing different solutions, because they add clarity and objectivity, and enable comparison, discussion, and documentation.

How to create a decision matrix

1. Create a blank table
2. Describe the problem in cell A1
3. List all the decision criteria as rows
4. List all the potential solutions as columns
5. Describe the aspects of each solution-criteria in the matrix

Decision matrices give teams a shared understanding of the physics of the problem they're solving.

5. Use an anonymous poll to select a solution

An anonymous poll is our preferred option for measuring consensus on a chosen solution, because they make it:

• more comfortable to disagree, especially if there’s a power imbalance in the group (e.g. the CTO or VP of Engineering is part of the discussion); and
• easier to change our minds, because we haven’t publicly committed to a position.

We use Simple Poll on Slack.

6. When total consensus isn’t reached in the poll, book a decision meeting

When total consensus (i.e. 100% agreement on the preferred solution) is achieved in the poll, record the decision, and get to work on the solution!

When total consensus isn't achieved, then the decision catalyst books a decision meeting.

How to run an effective consensus-based decision meeting

If we're going to have a meeting, then we want it to be as effective as possible. That means being clear about the expected outcome, and driving everyone towards it from the beginning.

1. Randomly select the decision driver and note taker

Randomly select the decision driver, who leads the discussion and acts as an adjudicator.

Random selection helps us to reduce decision-making biases by not encouraging the loudest or most senior team members to force their views through. It has the added benefit of giving everyone practice at leading meetings and guiding a group towards consensus.

Randomly select the note taker, who ensures that the discussion and ensuing decision is minuted.

2. Aim to reach rough consensus

The decision driver should ask for people to share their concerns about the potential solutions. The decision driver should emphasise that any “concerns” should address the "fundamental flaws" of the proposed solutions, rather than getting stuck on non-critical feedback and nit-picking. The decision driver can help the group converge on a solution by asking everyone if they can “live with it”, and if not, “why not?”

Rough consensus is reached when the decision-driver believes all the raised issues have been addressed, and one of the proposals has the strong support of the group.

Do not force the team to come to consensus; that results in whitewashing differences and dissenting votes.

3. The decision driver should make a unilateral decision if rough consensus isn’t reached

In rare situations, a group might not be able to converge on a single preferred solution. This usually means that there are two viable options, and people in the group simply have different preferences.

If the decision driver has failed to help the group reach rough consensus through multiple attempts at discussion, then it’s time to make a unilateral decision.

The decision driver should only make a unilateral decision when all the "fundamental flaws" in the proposed solution have been addressed to their satisfaction. If they haven’t, the discussion should continue.

The decision driver is free to pick their preferred option, but they should try to take into account the arguments and discussions from the decision meeting, and not blindly stick to the choice they brought into the meeting.

If the decision driver doesn't feel comfortable making a unilateral decision, they can defer the decision to a leader that attended the decision meeting.

If the decision is reversible, then the decision should be treated as an experiment. The team should disagree and commit to the chosen solution, but agree that a retrospective will take place to review and potentially adjust the choice.

Conclusion

At Griffin, we think democratised decision-making is an innovative path towards more impactful, inclusive, and effective decisions.

By marrying the principles of consensus and asynchronous work, we’re able to tap into the collective wisdom of our teams without sacrificing autonomy or disrupting deep work. This helps us empower everyone in our team, encourage diversity of thought, and foster an environment that values each individual's unique input.

We're thrilled with the impact we've seen this process make at Griffin, and we can't wait to hear how these strategies enhance your own decision-making processes. Give it a try, and let's improve the way we make decisions, together!