Every engineering team I've talked to can recite how long their test suite takes. Almost none can tell me how long a finished change sits untouched before a human looks at it. That asymmetry is expensive, and the finance world already built the vocabulary we're missing: an argument about the real price of waiting in modern business frames delay as a balance-sheet exposure rather than a scheduling annoyance, and that reframe transfers almost perfectly to software delivery. Cash trapped in receivables and code trapped in review queues are the same category of problem. Both look harmless on any single day. Both quietly determine what your organization can survive.
The Metric You Almost Certainly Don't Have
There's a number from lean manufacturing called flow efficiency: the percentage of total elapsed time that anyone was actually working on the thing. Touch time divided by wall-clock time.
Run it on your last ten pull requests. A typical result looks like this: the author spent 40 minutes writing the change, the reviewer spent 12 minutes reading it, CI burned 9 minutes of compute. That's about an hour of real work. The PR was open for three and a half days.
Flow efficiency: roughly 1.5%.
I have never seen a team guess this number correctly before measuring it. Engineers consistently estimate 40–60%. Reality in most organizations lands somewhere between 5% and 15%, and anything above 25% is genuinely unusual. The reason the intuition fails is that we experience our own work as continuous — from the inside, you were busy the whole time. But you were busy on other tickets while this one sat in a queue. The work item's experience of the week was almost entirely waiting.
This matters because we optimize what we can see. Build time is visible, gets dashboards, gets a dedicated performance sprint. Queue time is invisible, distributed across calendars, and owned by nobody. So teams spend six weeks shaving four minutes off a build that contributes 2% of lead time, while a two-day review wait contributing 60% goes unexamined.
Little's Law Does Not Care About Your Roadmap
The math here is uncooperative in a useful way. Little's Law says:
Cycle Time = Work in Progress ÷ Throughput
Read that again with hiring in mind. If throughput is roughly fixed in the short term — and it is, because onboarding takes months — then the only lever that moves cycle time this quarter is reducing WIP. Not working harder. Not "prioritizing better." Carrying fewer things simultaneously.
Queueing theory makes it worse, or better, depending on temperament. Kingman's formula tells us wait time scales with ρ / (1 − ρ), where ρ is utilization. Plug in numbers:
At 50% utilization, the wait factor is 1. At 80%, it's 4. At 90%, it's 9. At 95%, it's 19.
That's not linear degradation, it's a wall. A team booked to 95% capacity doesn't deliver 15% more than a team at 80% — it delivers dramatically slower because every arriving item queues behind a system with no slack to absorb variance. Every manager who has ever proudly reported "the team is fully utilized" has announced a latency problem in the language of an achievement.
This is the single most counterintuitive thing in delivery performance, and it's why "just add more parallel work" reliably makes things slower.
Speed Is a Financial Signal, Not a Vanity Metric
The pushback is predictable: shipping fast is an engineering preference, not a business outcome. The research disagrees, and it's been disagreeing for a decade. Google's DevOps Research and Assessment program has spent years correlating delivery behavior with organizational results, and their work on the metrics that actually predict delivery performance found that change lead time and deployment frequency track with commercial and operational outcomes — not just developer happiness. The gap between elite and low performers isn't a rounding error; low performers measure lead time in months while elite teams measure it in hours.
The mechanism is straightforward once you stop thinking about it as speed and start thinking about it as exposure. Long lead times mean large batches. Large batches mean risky deploys. Risky deploys mean more process, which means longer lead times. The loop tightens on itself. Meanwhile every unreleased feature is capital you've already spent that hasn't returned anything, and every hour a bug sits unfixed is reputational damage accruing interest.
A team with a two-hour lead time can respond to a security disclosure, a competitor launch, or a broken checkout flow on the same day. A team with a six-week lead time cannot, regardless of how talented its engineers are. The talent is real; it's just stuck in a queue.
Latency Reshapes Human Behavior Before It Reshapes Metrics
Jakob Nielsen's classic thresholds on how long users tolerate a system's response identify three limits: 0.1 seconds feels instantaneous, 1 second preserves an uninterrupted train of thought, and 10 seconds is roughly the ceiling on sustained attention before people go do something else.
Scale those up by four orders of magnitude and you have a startlingly good model of engineering organizations. Ten minutes to CI feedback and developers stay in the change. Ten hours and they've moved on, so returning requires rebuilding context that was free ten hours ago. Ten days and the original author has genuinely forgotten the reasoning, which means the review is now archaeology.
Long feedback loops don't just delay work. They change what people build. When merging is slow, engineers batch changes to amortize the pain, which produces larger diffs, which get worse reviews, which produce more defects. When environments are scarce, people test less and hope more. The latency creates the behavior, and then we blame the behavior.
Where the Waiting Actually Hides
Before optimizing anything, find the queue. In practice it's almost always one of these:
- Review latency — time from "PR opened" to "first human comment," usually the single largest block in the whole cycle
- Environment scarcity — one shared staging box, booked out days ahead, functioning as a de facto global lock on the org
- Approval ritual — change boards and sign-offs that add days of calendar time and, per the DORA research, no measurable stability benefit
- Cross-team handoffs — every boundary crossing introduces a fresh queue with its own priorities and its own idea of urgency
- Flake-driven re-runs — a 7% flake rate on a 20-minute pipeline turns "merge it" into a lottery with a multi-hour expected wait
The Experiment Worth Running This Week
Don't buy a platform. Pull timestamps from your git host: commit authored, PR opened, first review, approval, merge, deploy. Compute the gaps. Plot the distribution rather than the mean, because the mean will lie to you and the p85 is where the pain lives.
Then resist the urge to fix the biggest technical number. Fix the biggest waiting number. Usually that means a review SLA measured in hours, a WIP limit that people actually respect, or ephemeral environments that end the staging queue permanently.
Speed isn't about typing faster or heroics. It's about deleting the periods when nothing is happening — and once you can see those periods, they turn out to be most of the calendar.
Top comments (0)