Your feature spends 80% of its life waiting

Because it is sitting in a queue. Across most software organisations a work item is actively worked on only 15-40% of the time between the idea and production; the other 60-85% is spent waiting — for review, for an approval, for a shared environment, for another team. The constraint is rarely how fast anyone types. It is how long work waits between the people who touch it.

What does 15-40% flow efficiency actually mean?

Flow efficiency is a single ratio: active work time divided by total elapsed lead time. If a feature takes three weeks from committed-to-backlog to live, and hands-on-keyboard work accounts for four of those days, flow efficiency is roughly 27%. The rest is queue. Empirical measurements across engineering organisations — from lean delivery studies at BusinessMap to published internal data from teams like the ASOS engineering blog — cluster in the same unflattering band: 15-40%. A team that feels busy, ships regularly and never misses a stand-up is still, on the calendar, mostly waiting.

This is the first thing that trips up leaders. Flow efficiency below 40% is not a symptom of a lazy or unskilled team. It is the default state of any system with handoffs, approvals and shared resources. Getting to 40% is respectable. The interesting question is not why so low but which specific waits make up the missing 60-85%.

Which queues eat the calendar?

The waiting is not one big block; it is a series of small, individually reasonable pauses that compound. A LinearB study of roughly 3,000 development teams put the average commit-to-production cycle at about seven days — and that measures only the tail end of the journey, from first commit to release. It says nothing about the days or weeks a request waits in a backlog before anyone commits at all, and nothing about organisations on fixed release trains, where the gap between done and shipped stretches to weeks or months.

Map a single feature onto its calendar and the pattern is hard to miss:

Every waiting row is a queue in front of a person, a gate or a shared environment. None of them is individually outrageous. Added together, they are the product.

Why doesn't adding engineers fix it?

Because engineers are not the bottleneck; the queues are. This is where the arithmetic turns counter-intuitive. Halving the time people spend actively working on an item moves total delivery time by only about 10%. Halving the time work spends waiting in queues moves it by around 40%, per flow analyses such as those from em-tools. When active work is a fifth of your lead time, optimising it is optimising the wrong fifth.

Adding people usually makes queues worse, not better. Little's Law tells you the average wait rises with utilisation, and near-full utilisation the curve turns vertical: the difference between 80% and 95% busy is not a 15% longer wait, it is a multiple. Teams already run hot — we have written before about how 42% of engineering time never touches a feature — so new headcount lands on systems that are already saturated, pushes utilisation higher and lengthens exactly the queues that dominate lead time. The result is more work in progress and slower delivery of any single item.

Why is all this waiting invisible?

Because the standard dashboards measure the 15-40%, not the 60-85%. Velocity, story points and sprint burndown track the active phase — the part where someone is demonstrably doing something. The waiting lives in the gaps between tracked events, and worse, it lives across organisational boundaries where no single team owns the clock. A request that crosses from a product team to a shared platform team, to a security reviewer, to an offshore vendor, to a change-approval board is invisible on every one of those boards individually.

Those boundaries are where lead time actually accumulates. The first years of a distributed team are dominated by handoff cost — the productivity loan you take out when you offshore — and every clarification round-trip is a queue. Approval forums are queues with a calendar invite; the coordination overhead quantified in the 300,000-hour meeting is largely people waiting for other people to be free enough to decide. None of it registers as work, so none of it gets managed as work.

The way out is to measure the whole clock rather than the active slice: instrument lead time end to end, find the single largest queue, and attack that one before touching anyone's coding speed. In practice the biggest queues sit at system boundaries — the handoffs between order capture, stock, delivery and finance — which is why we build our route-to-market suites on one event bus instead of stitching six systems together with tickets and nightly batches. Fewer boundaries mean fewer queues.

The teams that pull ahead over the next few years will not be the ones that write code fastest; that lever is nearly exhausted and worth only its 10%. They will be the ones who start treating waiting as the primary engineering problem — measuring queue time as rigorously as they measure test coverage, and shaping both their org and their architecture to remove handoffs rather than to shove work through them faster. Once you can actually see the 80% your feature spends waiting, most of your improvement roadmap is already written.