Decision Deadlock - When a team gets stuck

“Before taking this live, we need to coordinate with C-level. This can have strong implications on our sales.”

“I still need to coordinate with my Head on that.”

“That affects the other team. We need to clarify if they’re OK with that.”

“We’re still waiting for the agency’s input, but then we have to get started right away or we’ll run out of time. Can’t you guys prepare something already?”

Instead of making a decision and moving on, a team is blocked and can’t continue to work on the most important thing.

There is a (very) long list of concerns that is repeated again and again. People jump from one point to the next, agreeing here and there, without getting even a little bit closer to the solution.

The deadline gets closer and closer and nothing happens.

The team is stuck. Diagnosis: “Analysis Paralysis” or “Decision Deadlock”.

How does a team get out of this? First we need to understand the team’s situation a little better, especially the dilemma in which it is stuck.

The Dilemma: fast vs. safe

Briefly summarized, the team faces the following dilemma:

• On the one hand, the team must get started and make decisions now in order to be able to finish on time.

• On the other hand, the team must not yet get started and make decisions in order to take all relevant influencing factors into account and to talk to all affected parties.

Both conditions must be fulfilled for the project to be successful: The team must finish on time and take into account all relevant influencing factors as well as discuss implications with all affected parties.

To resolve this dilemma, let’s take a closer look at the underlying assumptions.

The assumptions

If we don’t know all the relevant factors, we can’t get started, because otherwise we run the risk of losing users and thus revenue, or failing to meet (implicit) expectations.

• It is very likely that you don’t know all relevant factors, no matter how long you analyze the situation. Given the complexity of today’s systems (by which I mean not only the software, but the entire company and its customers), it is impossible to know and understand all influences.

• Furthermore, there is always the risk of losing sales due to software changes. The risk for a specific change depends on the impact on the user and the possibility of reversing the changes. The smaller the impact on the user and the easier it is to reverse a change, the lower the risk.

It is significantly more expensive to reconcile and wait for a long time than to occasionally do something wrong.

• This assumption is underlying the ‘bias to action’. The desire to get started right away without doing much (or any) research. While tempting, this statement is not true in all cases. If, for example, the decision leads to users no longer being able to use the platform properly, this can very well result in high costs and have a strong impact on the company. Especially if it is very costly to reverse the decision. It is also possible that the damage to the company’s image is irreversible.

There are certainly plenty more assumptions underlying this dilemma. But these two already help us to move one step closer towards a solution.

The solution

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups. - Jeffrey P. Bezos

With his categorization of decisions into Type 1 and Type 2 decisions, Jeff Bezos provides the first building block for the solution: If a decision can be easily reversed (Type 2), it is not worth talking about it much and for a long time, it is easier to act. This fits well with the analysis of the second assumption, but in my view it is not completely sufficient.

Another dimension emerges from the discussion of the assumptions above: The user impact or business impact. If a decision does not have a major impact on the hard business value of a company (such as the exact wording in a survey or a purely technical refactoring), it can be approached differently than anything that directly impacts revenue.

This leads us to the following four cases (see Figure 1):

Low Business Impact / Easily Reversible

Just do it. Here is no need to do big tuning or testing, such decisions can be made locally in a team. Examples are:

• Changes to a data structure / minor refactorings

• All adjustments that are not on the central user journey (playout of user surveys, FAQ pages, additional information in various places…. )

Low Business Impact / Hardly Reversible

Here, a short coordination with or information to the affected stakeholders is useful. Examples can be found mainly in the context of technical restructurings. To keep the risk low, it makes absolute sense here (in my view) to break the task down into smaller steps in order to keep the risk low and to be able to learn quickly during the process and correct it if necessary.

High Business Impact / Easily Reversible

In this case, it is good to take the experimental route. In other words, brief coordination and then testing, e.g. through an AB test or before/after comparison. This applies above all to changes in the central user journey, such as the purchasing process in an online store.

High Business Impact / Hardly Reversible

This is the most difficult category (surprise!). The first question you should ask yourself here:

Is there any way to break the problem into smaller steps so that you end up in a different quadrant for each step?

This is almost always possible. If no way can be found, however, things become interesting. Then it might be necessary to do talk to (almost) everyone and gather as much information as possible. Personally, though, I’m not a big fan of this and would do everything I could to break the problem down into smaller, lower-risk steps.

Conclusion

To resolve the Decision Deadlock, you should first understand what you are dealing with. Two questions need to be asked here:

• How strong is the impact on the user / business?

• How easy is it to reverse the change?

If you know where you are, it’s much easier to determine how much coordination effort and safety measures are needed before you can get started.

As soon as you realize that something is hard to reverse, it is - from my point of view - absolutely necessary to break down the big picture into smaller steps in order to minimize the risk.