Flow Efficiency: Why Everything Takes Forever
WAITING USUALLY WINS
Flow efficiency splits elapsed time into working and waiting - and waiting usually wins. How to measure it honestly and shrink the queues eating your weeks.
Flat and well above the elite reference - a signal, not a verdict.
Illustrative example
TL;DR: Flow efficiency is the ratio of time spent working on an item to the total time it spent in your system. Ask why the feature took six weeks and the answer is almost never six weeks of typing. It's days of work marinating in queues: waiting for pickup, review, answers, deploy windows. Exact "active time" is unmeasurable and faking precision about it is theater; what's honestly measurable are the waits, from timestamps you already have. That's good news twice over: the waits are where the calendar goes, and removing a wait is the only delivery improvement that asks nobody to work faster.
"Why does everything take so long?" is the most common question in engineering leadership, and it comes with a built-in wrong answer: because people work slowly. Flow efficiency exists to replace that answer with an honest one. It won't flatter anyone, but it points the fix at queues instead of people, which is both kinder and correct.
What is flow efficiency?
Flow efficiency is a lean-manufacturing import: of all the calendar time a work item spent in your system, what fraction was someone actively working on it?
Flow efficiency = active time ÷ (active time + wait time)
An item that took 20 elapsed days with 4 days of actual hands-on effort ran at 20% flow efficiency. The other 16 days it sat in a queue: waiting to be picked up, waiting for review, waiting for an answer, waiting for the deploy train, waiting for someone to notice it was blocked. Nothing was wrong with the work. The work was fine. The work was also, for four-fifths of its life, not happening.
The reframe this metric forces is the valuable part: your delivery timeline is not a work problem plus overhead. It's a waiting problem with some work sprinkled in. Speeding up the work attacks the small slice; shrinking the waits attacks the big one.
How to measure flow efficiency honestly
Here's where this article diverges from most of what ranks for this keyword: you cannot measure active time precisely, and you shouldn't try. No tool knows when a human is truly working: ticket states are updated late, "In Progress" routinely means "on my list," and the surveillance-grade alternatives (keystroke tracking, activity monitors) destroy the trust your data depends on while still measuring motion rather than thought. A flow-efficiency figure quoted to one decimal place is a confession that someone confused a definition with a measurement.
What you can measure honestly is the other side of the fraction. Waits leave timestamps:
- Queue before work: ticket created → work actually started.
- Pickup: PR marked ready → first reviewer action. LinearB's benchmarks (8.1M+ PRs, 4,800+ teams) band this from under an hour (elite) to over 16 hours (needs focus) - same code, same author, a full working-day of difference in pure waiting.
- Review round-trips: each exchange where the item waits on the other party.
- Post-approval: approved → merged → deployed. Approval that waits days for a release train is a wait with a suit on.
So operationalize flow efficiency as a stage decomposition: report work-stage time versus wait-stage time per item, using the cycle-time stage breakdown, and let "flow efficiency" be the honest, rough ratio those stages imply. Rough is fine. The decision you're making - which queue do we kill first - doesn't need decimals. It needs the widest wait, named.
This is also why you should distrust cross-company flow-efficiency comparisons and any "industry typical" percentage: the number is hostage to how each shop defines active time. Compare your own trend, and benchmark the waits, where published bands actually exist.
Why wait time dominates: the receipts
If waiting were a minor tax, none of this would matter. It isn't, and the evidence is consistent everywhere the timestamps have been studied:
- Review itself is fast; the queue around it isn't. Google's study of ~9 million reviewed changes found the overall median time to first reviewer response was under 4 hours, and small changes got feedback in under an hour. When a team's review stage runs to days, the difference is a finished artifact sitting in a queue, plus oversized batches that make reviewers flinch. (The fix for both lives in reducing PR review time.)
- Every wait bills twice. The calendar delay is the visible cost. The invisible one: waits force context switches, and Parnin & Rugaber's study of 10,000+ programming sessions found only ~10% of interrupted sessions resumed editing within a minute, while about 30% took more than 30 minutes to get back to the code. A three-hour wait costs three hours plus a re-immersion toll on a human who moved on to something else, twice (once for the author, once again on the return trip).
- Waits breed waits. An author whose PR waits a day starts something new to stay busy, raising their work in progress, which lengthens everyone's queues in turn. That spiral has a brake, and it's called a WIP limit.
How to improve flow efficiency
Attack the waits in order of width. In most teams the ranking is remarkably consistent:
- Kill the pickup queue first. It's usually the widest wait and always the cheapest fix: nothing about the work changes, the queue just has to move. Working agreements on pickup time, review-first mornings, small PRs that don't intimidate reviewers.
- Cap work in progress. Queue math is not optional: the more you start, the longer everything waits. Start less, finish more.
- Count round-trips, not just duration. Three review round-trips means the item crossed the waiting line six times, paying the context-switch toll at every crossing. Clearer PR descriptions and richer first-pass reviews convert three trips into one.
- Decouple from calendars. Deploy trains, weekly release windows, and approval meetings are institutionalized waits. Every one you remove pays out on every item forever.
- Make "blocked" a first-class state with an age. Untracked blockage is where flow efficiency goes to die quietly. A visible, aging blocked queue turns "we're waiting on the other team" from an excuse into a managed dependency.
Notice what's missing from that list: anyone working faster, longer, or under more pressure. That's the quiet gift of this metric.
Flow efficiency is the rare number that gets better by removing strain from the system rather than adding it. The waits were never anyone's effort in the first place, so reclaiming them costs no one their evenings. It's the closest thing delivery work has to found money, and the delivery-metrics scoreboard is where you watch it get picked up.
Frequently asked
What is flow efficiency?
Flow efficiency is the share of a work item's total elapsed time that was active work rather than waiting: work time divided by (work time + wait time). A feature that took four weeks of calendar time but only days of hands-on effort has low flow efficiency: the rest was queues.
How do you calculate flow efficiency?
In principle: active time ÷ total elapsed time. In practice, exact active time is unknowable: no tool honestly logs it and you shouldn't try to. The workable version decomposes elapsed time by stage using timestamps you already have (ticket states, PR opened, first review, merge, deploy) and reports work stages versus wait stages, without pretending to single-digit precision.
Why is wait time worse than work time?
Waiting adds calendar delay without adding value, and every wait forces a context switch on resume. In one study of 10,000+ programming sessions, about 30% of interrupted sessions took over 30 minutes to get back to editing code. Waiting is also the cheapest thing to fix: removing a queue asks nobody to work faster.
What is a good flow efficiency percentage?
Be suspicious of any published 'typical flow efficiency' figure: the metric depends entirely on how active time is estimated, so cross-team comparisons are mostly definitional noise. Compare your own trend instead, and judge stages against published queue benchmarks like PR pickup time, where elite is under an hour and over 16 hours needs focus.