Spreedly Engineering

Consensus is Overrated, Build Clarity Instead

In stark contrast to more authoritarian models of decision making, “building consensus” sounds downright agreeable. What kind of animal wouldn’t want to strive for consensus when making important decisions!?! Well, we want to present a framework that isn’t so much based on consensus as it is on clarity instead. It’s a subtle but important distinction that can directly affect your culture.

It might seem like folly to try and create a framework for something so soft and squishy and tactical as making a decision. However, it’s something we find ourselves using quite frequently when supporting our Engineering teams, and think it’s important to have a consistent intellectual framework around how decisions are made. What better way to enforce consistency than to write it down on paper? Here it goes…

Organizational structure

First, some background.

While Spreedly may have a somewhat traditional Engineering org chart (CTO/VP of Engineering → Engineering Managers → small teams of engineers), operationally we do almost the complete opposite. If we look at decision making authority, the org chart is flipped on its head.

We expect our Engineers to be making and justifying their decisions to their peers and managers, who are there to support them in making well-reasoned decisions vs. making decisions for them. The CTO/VP of Engineering is then there to support the Engineering Managers in their support of Engineers etc…

But, with great power comes great responsibility. Surely we don’t let our Engineers run around making whatever decisions they want? Well, central to placing this much responsibility on your Engineers is making sure they’re supported in making decisions that are aligned with larger company goals. How do we do this with so much decision making authority pushed to the edges?

Building clarity

What we’ve been unintentionally creating the last few years is a loose framework that focuses on exposing a specific set of objective properties about the topic at hand, upon which a consistent set of organization-specific values are applied to produce an actual decision. The framework aims to achieve clarity first, then gives ultimate decision-making authority to the person most responsible for the decision. Here’s the basic approach:

1. Identify potential solutions

Given a particular problem or choice to made, the first step is to list out potential solutions. This doesn’t need to be an exhaustive list, just a “here are the set of reasonable solutions to consider for this issue” kind of thing.

2. Acknowledge tradeoffs

Great. Now we have a concrete list of potential solutions. But, there is no such thing as a perfect solution. Every option has some set of pros and cons. If you can’t list at least one for each category, you probably don’t understand the proposed solution and need to dig a little deeper. If you’re having issues coming up with one or the other, here’s a hint: An option’s greatest strength is often the source of their greatest weakness. E.g., solution X is highly distributed! 💥. Well, that probably means it’s also more complex than other solutions or incurs a higher operational burden.

At this point you have a rough matrix of solutions and their pros/cons. Be sure to evaluate the pros and cons consistently across all options, e.g., “complexity” across all options, “cost” across all options etc…

3. Apply organizational priorities

Now that you have an objective list of options, and an objective list of associated strengths/weaknesses, it’s time to apply the part of the process that takes into account the larger organizational priorities. Often times these are a common set of guarantees or constraints you know to be true. For instance, “correctness over speed” or “design comes first” - whatever it is these should be specific to your organization. (If these aren’t clear, then you’re flying blind and that should be resolved before all else).

Given these priorities, note which tradeoffs that are most relevant and supportive. If correctness is more important than speed, then all the tradeoffs that enforce consistency carry more weight than the tradeoffs that emphasize execution speed (as a crude example). These are rarely mutually exclusive properties, but this process tends to at least assign priority to each axis, which is important for the next step.

4. Decide

Remember when we talked about our inverted org structure? Here’s where the rubber meets the road, where the person who’s in charge of actually implementing the solution or who “owns” the results of the decision gets to make the final call. In our case, that’s almost always the engineer responsible for the feature/system.

That might seem like a lot of pressure, but let’s look at where we are. At this point you should have an objective set of potential solutions, an objective list of tradeoffs for each solution, and an objective set of company or team priorities that are applicable to the problem domain. You have achieved clarity in solutions and the properties of those solutions. Making a decision from such a stable foundation when all subjectivity has been squeezed out is often a simple proposition.

Choose the solution that most directly addresses the problem at hand while also supporting company priorities. Or, in other words, having weighted solutions by their support of your company values and constraints, one of the solutions usually rises to the top. That’s not to say there’s no discussion to be had at this point, only that by striving for clarity at each discrete step so far, you should have the raw material clearly presented in a way that allows you to make the best decision for your current reality.

One of the benefits of this approach is that it separates the contentious part of the process, where the decision is actually made, from the substantive part of the process, which is in identifying the solutions and their objective properties. This isolation of concerns alone makes for a much simpler, predictable, and amenable process.

5. Reflect

It’s always good to reflect on past decisions to learn from their outcome. Did the decision turn out to be the right one? Did it achieve its purpose? If not, why not? One of the many benefits to a clarity-based approach is that you can usually go back and review how you came to the conclusion you did. You will probably find there are very few bad decisions, only decisions based on incomplete, imperfect, or unknowable (at the time) information. Acknowledging this reality is a great way to reinforce a blame-less culture.

Putting it all together

All that just to make a decision?!? Obviously going to such lengths for every decision is ludicrous. Two things: 1) Yes, we tend to only capture the output from this process for larger, more complex decisions and 2) Once you apply the process to your work a few times, it becomes a very natural and lightweight way to think, providing benefits for decisions of varying magnitude.

Providing a consistent framework for making well-reasoned decisions allows everybody in your organization to be part of the decisions that most affect their work and liberates decision-making from the few, often disconnected, people at the top of the food chain. Yet, it does so while acknowledging what’s right for one organization may not be right for another. And it does so without sacrificing transparency. What a rare but sweet balance!

At Spreedly, it’s been a big win – and I think it can be applied to your organization too. If you’d like to work in a place that empowers you to make decisions in this way, take a look at our jobs page or ping me on Twitter if you don’t see an open position listed.