Decision latency: When choices that aren’t made slow the team down

How unresolved decisions gradually erode pace, standards, and ownership

Many teams go through periods where the pace drops. Not dramatically. Not suddenly. Just gradually. Tasks sit a little longer. Pull requests take more rounds than necessary. The same discussions keep coming back. Everything works, but nothing flows.

Often it’s not because of wrong choices. It’s because of choices that were never made.

When questions stay open

Decision latency is not a technical problem in itself. It’s a pattern. A question gets identified. Someone has input. More information is wanted. Maybe a little broader anchoring. Then time passes. No one decides. No one closes it.

A single postponed decision rarely does harm. But when it happens often enough, it becomes part of the culture.

The quiet cost

What makes decision latency demanding is that it’s rarely felt immediately. It’s felt in small things: a little more hedging in the code, a little more flexibility than necessary, slightly less distinct standards, and slightly less ownership.

Over time, this creates friction.

Just as technical debt doesn’t arise from one big wrong choice but from many small compromises, decision slowness arises through many small clarifications that were never made. This mirrors the mechanism described in Technical debt as a team phenomenon (in Norwegian). Not dramatic, but gradual.

When caution becomes standstill

There’s rarely bad will behind it. People want to do it right. They want to avoid locking themselves in. They want to hear every voice. But without a clear closure, caution becomes standstill. Experienced teams are often the most exposed. They know what wrong decisions can cost, so they postpone them. But not choosing is also a choice. And that choice has consequences.

Standards are shaped by decisions

Standards don’t emerge from documentation alone. They emerge when a team actually makes up its mind. When choices stay open, practice stays fluid. It becomes harder to know what “the way we do it here” is.

As described in Standards that actually stick (in Norwegian), agreeing on principles isn’t enough. They have to be anchored through concrete choices. Without a decision, there is no shared direction.

The tech lead’s quiet responsibility

As a tech lead, this is rarely about being right. It’s about making sure questions actually get closed. Not to win discussions. Not to push through preferences. But to protect the pace. Sometimes that means saying: “We know enough now.” “We can adjust this later.” “Let’s pick a direction.” That’s not authoritarian. It’s responsibility.

Momentum is a choice

Teams rarely lose momentum because of one bad decision. They lose momentum when decisions stay open too long.

Decision latency doesn’t create drama. It creates wear.

Progress doesn’t come from perfection. It comes from direction.

Choosing – even with uncertainty – is part of the quiet responsibility we carry as technical leaders.