We profile everything. p99 response times, cold starts, CI pipelines that run thirty seconds too long — engineering culture has turned latency into a moral cause. Yet the slowest process in most companies never shows up in a dashboard, and as this case for treating the priciest delay a business ever absorbs makes clear, it is rarely the code that's slow — it's the human gap between the moment a choice becomes necessary and the moment somebody finally makes it. Call it decision latency. It compounds quietly, it never throws an exception, and it almost always costs more than the thing your team is afraid to get wrong.
The cost nobody puts on the invoice
There's a discipline in product engineering called cost of delay, and its core insight is brutal: every week a valuable change sits unshipped, you are paying for it whether or not you record the expense. Suppose a feature would generate $20,000 a week once live. Deliberate for eight weeks and you haven't "saved" anything — you've spent $160,000 of opportunity, money that never lands on any ledger. The author Don Reinertsen put it bluntly: if you only quantify one thing, quantify the cost of delay. Most teams never do, because a number with a dollar sign feels riskier than a story-point estimate that commits to nothing.
The data backs the discomfort. In a survey of more than a thousand executives, McKinsey found that the speed-versus-quality trade-off most leaders assume is largely a myth — and their reporting on why good decisions don't have to be slow ones shows that organizations making high-quality decisions quickly are roughly twice as likely to post strong financial returns, while executives burn close to 40% of their time deciding things and consider most of that time poorly spent. Speed, it turns out, is not the enemy of quality. Indecision is the enemy of both.
Why good engineers freeze
So why do capable teams stall? Partly because engineering rewards correctness, and correctness has no natural stopping point — there is always one more edge case, one more benchmark, one more stakeholder to loop in. Gathering information feels like progress long after it has stopped producing any. The deeper trap is treating every decision as permanent. Jeff Bezos's framing is useful here: some choices are one-way doors you can't walk back through, and those deserve caution; but most are two-way doors. You can ship, observe, and reverse course cheaply. Spending one-way-door deliberation on a two-way-door decision is how an entire quarter evaporates.
How to put a price on your delays
The fix is not "move fast and break things." It's making the cost of waiting visible enough that postponement stops feeling free. A lightweight routine most teams can adopt this sprint:
- Estimate the weekly stakes. What does this thing earn, save, or unblock per week once it ships? A rough number beats no number.
- Name the door. Reversible or not? Two-way doors get a bias toward action; one-way doors earn real scrutiny.
- Set a decide-by date. A decision without a deadline is a decision deferred indefinitely. Put it on the calendar like any other dependency.
- Assign a single owner. Diffused responsibility is where decisions go to die.
- Default to the cheaper-to-reverse option when the deadline arrives without consensus.
That fourth point carries more weight than it looks. The classic Harvard Business Review argument in "Who Has the D?" is that organizations stall not because people are incapable but because nobody can say who actually owns the call — so decisions ricochet between meetings, accumulating delay at every bounce. Clarity about who decides does more for velocity than any amount of added process.
Make decisions a first-class artifact
Developers already own the right tool and rarely point it at decisions: write them down. Architecture Decision Records — short documents capturing what was chosen, what the alternatives were, and why — turn a decision into something concrete and reviewable. The act of writing forces closure. It also kills the silent re-litigation that drags a settled question back into every standup. Pair decision logs with timeboxing and an explicit "disagree and commit" norm, and you replace consensus-by-exhaustion with momentum. Smaller batches help too: a decision about a two-week slice is easier to make, and far cheaper to get wrong, than one about a two-quarter epic.
The asymmetry that should change how you ship
Here's the asymmetry worth internalizing. A reversible decision made quickly and turning out wrong costs you a correction — an afternoon, a revert, a follow-up PR. The right decision made too late costs you the entire window in which it mattered: the market moved, a competitor shipped, the user found another tool. One has a bounded downside. The other does not. Framed that way, the instinct to "wait until we're sure" reveals itself as the expensive habit it is. You are not protecting quality by waiting — you are paying interest on a decision you already had enough information to make.
Ship the decision. You can always refactor it.
Top comments (0)