DEV Community

loading...

When to use Consensus Decision Making

Walker Lindley
Programmer, cyclist, baker, and brewer. Used to make games, now I wrangle clouds. Opinions are my own.
・6 min read

How should we make decisions? A few weeks ago, I helped my team decide on a new, more structured process for planning and doing work. Previously we’d worked in a fairly ad-hoc way and wanted more structure and rigor in how we work together. It clarified for me when consensus processes are and are not effective. I’d like to share with you what I learned.

Kinds of Power

Let’s start with some quick definitions for different kinds of power. These aren’t the only kinds, but they’re the ones I’ll be focusing on.

  • Role power is the power and influence you get from your position in an organization. As you move up, your role power increases.
  • Relationship power comes from the interpersonal relationships you build with coworkers over time
  • Expertise power comes from your experience in the field.

Setting the Stage

My team made actually made two big decisions that week and the difference between them was stark. Let’s look at each in turn:

First, the process decision. I’m a senior engineer and I’ve been on my team for just shy of a year, but I’m not the manager or the technical lead, so I don’t have role power on the team. I couldn’t, and didn’t want to, just tell my team we were going to change the way we worked together. Instead, I wanted to get the whole team involved in deciding on our new process. I started by writing a proposal and sending it out to the team a few days ahead of time so everyone had a chance to read it. Then I facilitated a meeting where we discussed what we wanted our process to look like. We made sure everyone understood each part of the new process and felt good about it. We also ensured everyone spoke, gave feedback, and raised any concerns they had and that those concerns were addressed. At the end of an hour, we had a new team process defined and everyone was on-board with it. The consensus process worked great!

The next day, my team needed to make a technical decision about which of two ways we would implement part of the system we’re building. Someone suggested using the same consensus process we had used the day before. We wrote a fast proposal on the whiteboard and started going through the pros and cons. Most of us were leaning in the same direction, but no one wanted to make a firm decision. Since this decision would impact other teams, it wasn’t clear who would communicate the decision to them or up the chain to our team’s larger organization. And if we got pushback, who was going to respond? What about changes to our schedule? Could anyone on the team make a decision that changed delivery dates? There were a lot of unanswered questions and the conversation petered out before a decision was made. We had stalled. The consensus process failed us.

What was different about these decisions? Why was one easier for the group to make than the other? Why did one situation lead to alignment and buy-in while the other led to confusion and lack of engagement?

While thinking about this, I was reminded of a startup I once worked at. This startup was experimenting with flat structures and ways to run a company without explicit role power. We hoped that relationship power and expertise power would be enough to hold the company together and work effectively.

We spent a lot of time thinking about how groups of people can make decisions when there’s not someone clearly in charge. Through a lot of trial and error, we discovered that making decisions this way was consistently slow and painful. However, these decisions often created a lot of long-term buy-in and support from the team. Other times, we’d just keep discussing the question and never actually make a decision. That led to wasted time and paralyzation as we talked in circles. Just like what my team experienced.

When to Use Consensus

As I thought over what I learned at my previous company, a few patterns started to emerge. Consensus decision making works well when you need a high level of support from the team and you have time to lay the groundwork for a successful decision making meeting, when leading change in a group where you lack role power, and in situations where the group is unsure who can or should make a decision.

When the group isn’t sure who should make a decision, a consensus process can be effective for deciding who should make the decision. This works well because the group can usually agree that making a decision is important, and can usually identify one or two people who can be trusted to listen to everyone’s point of view. For this to work, the team needs to throw their support behind this person.

Alternatively, when you don’t have role power or don’t want to use it, consensus decision making can be an effective way to get a high level of support from your team. These two situations are good fits for consensus and they’re the only ones I’d recommend consensus for.

How to Use Consensus

When you do decide to use consensus decision making, I recommend following these steps:

  1. First, write a summary of the situation, a few of the options, and the decision to be made. This reduces ambiguity and the possibility of confusion.
  2. Send this summary out to the group a few days ahead of time. This gives people who prefer to process information privately a chance to think it through and develop an opinion. It also gives folks a chance do any other research or preparation they want to do.
  3. During the decision making meeting, make sure everyone’s voice is heard. In particular, there are likely quieter people in the group and you may need to explicitly ask for their input. Takes notes or update the document in real time to reflect the conversation.
  4. Once the conversation slows down, ask each person whether or not they support the decision. Record any unanswered questions or outstanding issues.
  5. Afterward, follow up with anyone that didn’t agree and work with them to update the document until everyone’s on-board.
  6. Send the document out one last time and ask everyone to provide one final confirmation. This again gives people with different processing speeds a chance review everything and feel confident about the outcome.
  7. Finally, record the decision in some sort of document store where the team can easily reference it.

If the above sounds like a lot, it is. And that’s just the easy stuff. Additional, complicated dynamics can emerge from privilege, class, and other kinds of power differences. This process can take a week or two when everything goes smoothly and much longer when it doesn’t. It’s an expensive process with a lot of overhead. But it also gets everyone engaged in the process and bought into the result. Most decisions can’t justify this level of investment which is why I don’t recommend it in most cases. A very small number of decisions, though, can really benefit from this approach.

When to Avoid Consensus

Most of the time, consensus based decision making is the wrong choice. Generally decision making is more effective when it’s a single person’s responsibility. Crucially this doesn’t mean the person makes a decision in a vacuum, they should still seek advice and feedback from those around them, weigh the options, make a decision, communicate it to the group, and take responsibility for the consequences if things go wrong. Additionally, this allows everyone else to focus on other work, making the team more effective.

Compare that to the costs of consensus decision making. Everyone must fully understand the context of the decision to participate in making it. Once everyone has that context, they have to stay in sync until a decision is made. And after the decision is made, it still has to be recorded and communicated to everyone in a way they understand and agree with.

Due to the cost and complexity of consensus processes, I recommend having individual decision makers in the vast majority of cases. When in doubt, the group’s structure should help to make clear who the decision maker is (role power in action!). And remember that decision making can be delegated, in fact that’s one of a manager’s primary jobs.

Conclusion

The decision to change our team’s process benefited from the consensus process because we were willing to invest the time and wanted the long-term support we’d get in return. Whereas the technical decision needed to be made quickly and there was already a clear decision maker. Hopefully this helps you better understand when to use consensus processes and when to avoid them. If you’ve used consensus decision making in the past, share your story below in the comments.

Discussion (0)

Forem Open with the Forem app