A team I worked with shipped a change that took 18 weeks from request to production. When we walked the item back through its history, engineering had held it for 9 working days.
Everything else was waiting.
Waiting to be prioritised. Waiting for a director to decide which of two products it belonged to. Waiting for legal to approve as it touched the dreaded copy on the cookie page. Waiting for a security review that took 4 days of work and 5 weeks of calendar time. Waiting for a decision to be reversed and then reversed back.
18 weeks of elapsed time. 9 days of build.
Nobody in that organisation believed they had a decision problem. They believed they had a delivery problem, and they were 3 months into a programme to fix it by measuring velocity more aggressively. They were optimising the work. The delay was in the queues around the work.
Organisations build two systems and only manage one#
Every organisation has a delivery system, and most now manage it deliberately. Work is visible, limited, aged, forecast. That discipline took 20 years to become normal.
Alongside it sits a second system that almost nobody manages. Decisions arrive, wait, get serviced or abandoned, and pass downstream (or not). They arrive faster than they’re answered. They batch. They queue. And because that system is invisible, its delay gets attributed to the visible one.
Delivery queues are managed. Decision queues are not. So delay accumulates where nobody is looking, and then gets counted where everybody is.
Six things fill the decision queue.
- Nobody agrees on priority, because several priorities exist at once. Commercial concerns rank the same work differently from technical ones, and regulatory differently again, so teams do the only rational thing available: they wait for someone else to resolve the conflict.
- Nobody owns the decision, which is worse than a slow decision maker. At least a slow decision maker is identifiable. When nobody can say who decides, work circulates until someone senior enough becomes frustrated enough to stop the loop. That’s escalation masquerading as process.
- The answer keeps changing. Sometimes that’s exactly what should happen, because new evidence should change decisions. But when nothing has changed except who was in the meeting, reversal is churn dressed up as responsiveness.
- Stakeholders optimise for different things. Commercial wants speed; security wants confidence; operations wants stability; product wants measurable value. Every objective is legitimate, and the work sits still until someone is prepared to make the trade-off. No workflow tool has ever solved that.
- Governance manufactures calendar time. A monthly board turns a 5-minute decision into a 30-day wait. Add another approval stage, and you haven’t doubled control; you’ve doubled the queue.
- Everything gets batched. Quarterly planning, steering groups and investment reviews bundle dozens of unrelated decisions together, and the batch moves at the speed of its single most contentious item. Eleven uncontroversial choices wait behind one argument about headcount.
Not one of those six is a technical problem. Every one is a question waiting on a person, which is uncomfortable, because it means the fix doesn’t live where most improvement programmes go looking.
Go back to the team with the 18 weeks. Their improvement programme was aimed squarely at the 9 days. Halve that, and the change ships in 17 weeks instead of 18. Three months of effort pointed at a tenth of the elapsed time, while nobody measured the queue that owned the rest.
The obvious objection, which is partly right#
Sometimes the problem really is engineering.
If deployments are painful, if testing is manual, if every release carries risk nobody wants to own, then the constraint is technical, and no amount of decision hygiene will touch it. I’ve also seen teams reach for the decision argument precisely because it moves responsibility somewhere else, which is a misuse of the idea.
So don’t take this on faith, including from me. How much of your elapsed time is spent waiting for an answer rather than doing the work? That has a specific answer in your organisation, and neither of us knows it yet.
Treat decisions as work items#
A decision has a starting point, when someone asks, and an ending point when someone answers. That means it has cycle time. It has age while it waits. It has throughput and work in progress. Everything you already know about managing flow applies to it without modification, because a decision is a work item that happens to be serviced by leadership rather than a delivery team.
I’m deliberately not reaching for flow efficiency here. It requires knowing exactly when work was active and when it was idle, which almost nobody can observe reliably, and it pulls attention back towards keeping people busy.
There’s a second reason. Flow efficiency can’t see age. It’s a ratio you calculate on the work that finished, so the decision still sitting in the queue never shows up in it at all, and that’s the one wrecking your predictability. Outliers do the damage. A measure that hides them is a crap measure.
You don’t need it. These four things you can actually see will do:
- Decision cycle time is the headline. From request to answer, how long? Most organisations track delivery commitments obsessively and have never once measured how long their own governance takes to respond.
- Age of open decisions is the measure that changes behaviour fastest, because it operates while you can still act. A decision that has been open for 40 days is a live problem today, and an ageing chart puts it in front of people in a way that a retrospective average never will.
- Decision work in progress tells you why the queue is slow. A leadership group holding 30 open questions is suffering exactly what a delivery team carrying 30 items suffers, and for the same reason.
- Discards after commitment expose the cost of changed minds. Work started and abandoned is real investment that produced nothing, and it converts a conversation about alignment into a number finance understands immediately.
You already run all four of these on delivery work. The only thing that changes is which queue you point them at, and that costs nothing except the willingness to look.
Capturing this on Monday#
The usual objection is that the data doesn’t exist, and it doesn’t, because no tool recorded the moment someone first asked. Don’t wait for tooling.
Start a decision log with four columns: what was asked, who asked, the date it was raised, and the date it was answered. Nothing else. A shared sheet is enough, and a physical wall is better because the ageing is visible without anyone opening anything.
Add decisions to it at the moment a team says they’re waiting on one. That single habit is most of the work. What’s been missing is the arrival timestamp.
Give it 6 weeks, and you’ll have a distribution. Not a precise one, but precise enough to say that 85% of decisions are answered within some number of days, which is a sentence nobody in your organisation can currently say out loud.
What to change#
- Name the decision maker before work begins. One person, not a forum. Forums ratify what a person has already concluded, or they defer until someone does.
- Set a service level expectation for decisions, exactly as you do for delivery. If teams commit to finishing most work within a stated number of days, ask what the equivalent commitment is from the people who approve and fund it. In most organisations the asymmetry becomes obvious the moment the question is asked out loud, and asking it changes behaviour before any process does.
- Separate the reversible decisions from the irreversible ones. Tea without milk you can fix. Earl Grey, you have to pour away and start again. If being wrong is cheap, the team decides now, and governance is reserved for the choices that cost something to undo. Treating both classes identically is the most common cause of governance drag and usually the cheapest thing to fix.
- Limit decision work in progress. 30 open questions is 30 decisions being deferred in parallel.
- Increase governance frequency rather than adding stages. A weekly 15 minutes with authority beats a monthly hour without it. The instinct when decisions go badly is to add a gate, which lengthens the queue that caused the problem.
- Publish the waiting. Put decision age next to work item age, on the same wall, in front of the same people. Delay behaves differently once it has a name and an owner.
None of those six is hard to start on Monday. That’s also what makes the idea easy to misuse.
The part that people get wrong#
There’s a version of this argument that becomes a weapon. Delivery stops taking responsibility, every miss becomes “we were blocked,” and a systems observation turns into blame allocation.
Slow decisions are rarely caused by slow people. They come from structures that separate accountability from authority, and that make invisible delay safer than a visible mistake. Those are design choices, and design choices can be changed.
You already manage one queue carefully. Start measuring the other one.
