The most common explanation for slow engineering teams is that people aren’t working hard enough or fast enough. In my experience, that’s almost never the real problem.
The real problem is usually decision friction. Teams slow down when it’s unclear who can decide what, when decisions need to be revisited, and when escalation is appropriate. The result is a kind of organizational drag — engineers waiting for clarity before they can move, or moving without clarity and then having to redo their work.
The fix isn’t working harder. It’s making decisions clearer.
What decision friction looks like
Decision friction shows up in a few recognizable patterns.
The most common is the approval bottleneck: someone has to sign off on something, they’re not available, and work stops. This isn’t usually a people problem — it’s a structural problem. The system requires a human in the loop who isn’t available when needed.
The second pattern is unclear ownership. When it’s not obvious who is responsible for a decision, one of two things happens: either it gets made redundantly by multiple people who weren’t coordinating, or it doesn’t get made at all because everyone is waiting for someone else.
The third pattern is decision instability. A decision gets made, work proceeds based on it, and then it gets revisited — not because new information arrived, but because someone with authority didn’t feel heard the first time. This is particularly destructive because it retroactively invalidates work and teaches teams that execution is risky.
The taxonomy of decisions
Not all decisions are the same, and treating them the same is one of the main sources of friction.
Some decisions are easily reversible and low-stakes. Make them quickly, at the lowest level, without ceremony. The cost of getting them wrong is low and the cost of the decision process itself is significant.
Some decisions are hard to reverse and high-stakes. These deserve deliberation, the right people in the room, and explicit commitment. Rushing them creates rework.
The confusion between these two categories — treating low-stakes decisions as high-stakes, or vice versa — is a major source of organizational dysfunction.
What clarity actually requires
Decision clarity isn’t about having more meetings or more detailed documentation. It requires three things.
Explicit ownership. Someone’s name is attached to this decision. They are responsible for the process, for ensuring the right input was gathered, and for the outcome.
Visible criteria. The factors that matter for this decision are articulated in advance. This makes the decision auditable and teaches the team how to think about similar decisions in the future.
Committed outcomes. Once a decision is made, it is treated as a commitment until the criteria for revisiting it are explicitly met. This is different from stubbornness — it’s the recognition that teams need stability to execute.
The manager’s role in all of this
Engineering managers often underestimate how much their own behavior shapes decision dynamics on their teams.
If you frequently override team decisions, the team will stop making decisions without your approval. If you revisit decisions without clear rationale, the team will treat all decisions as provisional. If you’re slow to respond when input is needed, decisions will pile up waiting for you.
The fastest teams I’ve worked with have managers who are deliberate about all of this — who make their decision-making visible, who explicitly delegate and don’t override without cause, and who move quickly when their input is genuinely needed.
Speed is a team property. It’s produced by structure, not effort.