Most teams measure execution speed. Almost no teams measure decision speed.

This is a blind spot with significant consequences. A team can have excellent engineers, clean code, fast CI, and still ship slowly — because the decisions that determine what gets built, how it gets built, and when it gets built are taking days or weeks longer than they should.

Decision latency is the time between when a decision needs to be made and when it actually gets made. It's invisible in most project tracking tools. It doesn't show up in sprint velocity. It's felt as "things are stuck" and diagnosed as "we need more process."

The actual problem is usually narrower: someone needed to make a call and didn't.

The Compounding Effect

Decision latency compounds because it creates work stoppage.

When a decision is pending, everything downstream of it stops. The engineer waiting for the answer can't proceed, or proceeds under the wrong assumption and has to redo the work. The designer waiting for clarity produces work that may not survive the eventual decision. The product manager, if they haven't locked the direction, may be holding open multiple tracks of work simultaneously — multiplying the exposure.

One unresolved decision can block dozens of person-hours of work. Multiply that by the number of open unresolved decisions in a typical organization at any moment and you get a significant tax on throughput that nobody is measuring.

Ryne Hadeed's writing on decision velocity makes this concrete: the measure of an organization's decision health isn't the quality of its decisions in isolation — it's how fast it makes decisions relative to the rate at which decisions are needed.

How to Reduce Decision Latency

Name the decision and the decision maker. Not "we need to discuss this" — "X needs to decide whether we do A or B by Thursday." Make the decision and the deadline explicit. Without this, decisions tend to drift.

Limit the chain. For most decisions, two approvers is enough: the person who owns the domain and the person who will be most affected if it goes wrong. Extra reviewers add latency without proportionate quality improvement.

Default to action. In the absence of a clear reason to wait, decide now. The cost of a reversible wrong decision is usually smaller than the cost of the delay.

Use pre-mortems. Before committing to a slow decision process, run a two-minute pre-mortem: what are the two or three biggest risks if we make this call quickly? If the risks are manageable, the decision deserves a quick path. If they're genuinely catastrophic, that's the signal that this is actually a Type 1 decision worth slowing down for.

Separate the decision from the communication. The decision and the announcement of the decision are not the same thing. A decision can be made and not communicated until it's ready. Using "we need to socialize this" as a reason to delay a decision is often a way of avoiding the decision itself.