Flow Efficiency

Flow efficiency is active work time divided by total elapsed lead time. If a feature takes eight weeks from commitment to delivery and involves six days of actual work, flow efficiency is around 15% — and the other 85% is queueing, waiting for a decision, waiting for a handoff, or waiting for a release window.

The number is almost always far lower than teams expect, and measuring it changes where improvement effort goes.

Why it matters

Engineering organisations measure and optimise the part they can see: velocity, throughput, deployment frequency. Those measure the work time. If work time is 15% of lead time, doubling engineering productivity improves delivery by about 8% — which is why teams that get measurably faster still deliver features at the same pace, and nobody can explain why.

Where the wait time is

• Before work starts. Ideas awaiting prioritisation, specification, or a decision nobody owns. Frequently the largest block, and invisible in engineering metrics because the clock has not started.
• Handoffs. Each is a queue, and its length is a function of the receiving team's utilisation — which is why fully-utilised specialist teams create long waits everywhere upstream.
• Batching. Completed work held for a release train or a marketing moment. Finished value not yet delivered, usually unmeasured.
• Approvals — architecture, security, change advisory. Each defensible, collectively weeks.
• After release. Flagged off, gradual rollout, enablement. The gap between "deployed" and "usable by customers" is real and frequently unowned.

Implementation patterns

• Measure the ratio explicitly, not just lead time. The ratio is what makes the argument.
• Limit work in progress. Reducing concurrent work reduces queue lengths and, counter-intuitively, increases throughput.
• Deliberate slack in the constrained step. A team kept fully busy maximises its own efficiency and maximises the queue in front of it. Slack in the bottleneck reduces total lead time even though it lowers that team's utilisation — which is why it is rarely done without the mapping to justify it.
• Remove handoffs by changing team boundaries, so a stream-aligned team owns a slice end to end.
• Reduce batch size, since smaller batches queue less and fail more cheaply.
• Make waiting visible. Queues that are not measured are not managed, and most are not measured.

Industry example

Platform companies with high engineering throughput and slow feature delivery are the classic case. The engineering metrics are excellent, the business perceives the organisation as slow, and both are correct.

Mapping typically finds that the bottleneck is not engineering at all: a specialist team acting as a queue for everything, a decision waiting for a monthly forum, or a batching policy holding finished work for a release cycle. None of these appears in a velocity chart.

The uncomfortable corollary is that the intervention with the largest effect is often organisational rather than technical — changing a team boundary, removing an approval, or accepting slack in a fully-utilised specialist team — which is why the measurement matters: it is the only thing that makes that argument winnable.

Failure scenarios

• Optimising utilisation, which maximises queues and lengthens lead time.
• Measuring only the engineering segment, which is the part already efficient.
• Adding people to the busy team, when the constraint is a queue elsewhere.
• Local optimisation that improves one step and moves the queue rather than removing it.

Trade-offs

Improving flow efficiency usually means reducing utilisation somewhere, which looks like waste and is resisted. It also means smaller batches and more frequent releases, which requires deployment and testing maturity that may not exist yet.

For an organisation with genuinely scarce specialist capacity, some queueing is unavoidable — the honest response is to make the queue visible and prioritised rather than to pretend it does not exist.

Interview question

"Your team ships twice as fast as last year and the business says nothing has changed. What do you measure, and what would you expect to find?"