Make it Faster with Slow Decision Making

We should cross that bridge when we get there.

For any project, a team will make decisions on different levels. What to build, how to build it, in which order to do it?

High energy and time constraints within projects make it easy to fall into the trap of deciding to get things moving. Fast decision making leads to faster results, at least in theory.

Analysis paralysis is a problem. But I hope to highlight that:

1. making decisions too quickly or at the wrong level is likely to cause more harm than good.
2. delaying decisions doesn’t come for free, but the investment in it is worth the effort.

When fast becomes slow

I’ve seen the following problems play out on many projects I’ve worked on.

Designing without feedback. There is a feature set and various opinions on the user experience. There is no time to test it, though, so a call must be made. That decision leads to design and engineering work occurring with a lot of assumptions. And results in a feature the team needs to build again.

Making engineering decisions far from execution. Product work is defined, and there is no certainty on how to implement it. Still, the tech lead plans the details, specifying the technical path to follow without enough context of the codebase details. That decision leads to an overcomplicated solution that requires more time to build.

It comes in many shapes. Making a decision when you could wait to get more information is a suboptimal strategy. In many situations, companies are running as fast as they can because they have to much to do when only a small part of the work is going to prove valuable.

When slow becomes fast

Iterative product development calls for a different perspective. It requires fast learning and delaying decision making. The question should be:

What’s the most straightforward step we can take until the next learning opportunity?

Delaying decisions allows a team to wait for the last responsible moment. It will not only result in more information. It will also delegate the decision making responsibility to the person closest to the problem.

Last responsible moment. When the cost of deferring becomes higher than the cost of waiting.

It doesn’t come for free, though. Delaying is only possible if you have the processes and people geared towards that. For example:

Close iteration between product/engineering/design: when you allow for all aspects of a solution to be adapted daily, you create opportunities for late decisions that can generate better results. From a design that became too hard to implement and can be made easier with a few changes to a feature that is not as important and can be left out of a release. These are optimizations that can only be made if there is space for it.

Continuous delivery and automated testing: from an engineering perspective, the testing infrastructure and fast release cycles will allow a team to adopt a strategy of building simple and refactoring. And it can reduce the need for a series of architectural decisions that can be done later.

Having shared principles: if you can align on core principles for the team, it creates space for the trust that different people will make similar decisions. Aligning on how much testing needs to be done, for example, helps people to make decisions when they are executing work.

User testing and feedback: keeping in close contact with users allows the team to take micro risks and see the results. It can be implemented at the start of the cycle, by having frequent UI testing sessions, for example. Or at the end by having systems for feature-flagging and experimentation with the end-user.

There’s nothing new with the practices above. What’s sometimes hard to realize is that they are not just making your solution better. They reduce work by deferring decisions as much as possible.

When you are investing in iterative processes and tools, you are not only investing in quality. You are gaining more effective decisions.