What Slow Code Review Costs You in Payroll

TL;DR: A pull request waiting for review is not resting. It is payroll paying for a queue. The cost has two parts you can actually defend: the author's lost context when the review finally lands, and the work that was genuinely blocked while it waited. Price both with your loaded hourly cost, count conservatively, and "reviews feel slow" becomes a number your leadership team cannot wave away. Then fix pickup time first, because it is the cheapest stage to fix.

Why a waiting PR costs real money

Nothing about a stalled PR looks expensive. Nobody is idle; everyone is busy. That is exactly the trap: the cost of a review queue is paid in fragments - a context switch here, a re-read there, a dependent task quietly parked - and fragments never show up in a budget review on their own.

The context switch is the part with the strongest research behind it. Parnin and Rugaber analyzed 10,000 recorded programming sessions from 86 programmers and found that in only 10% of sessions did the first code edit come within a minute of resuming work. In roughly 30% of sessions, more than 30 minutes passed before the first edit (Resumption Strategies for Interrupted Programming Tasks).

Resuming work is not free. Every round-trip your review process forces - author writes it, forgets it, reviewer responds days later, author reloads the whole mental model to answer one comment - buys that resumption tax again, at both ends.

So the queue costs you twice: once in the delay itself when downstream work is blocked, and once in the re-context toll every time the conversation crosses the gap.

The math: pricing your review queue

You need two inputs, and one of them you should already have.

Input one: loaded hourly cost. Not salary: the fully loaded figure including employer taxes, benefits, and overhead, which U.S. data puts far above wages alone (benefits were 29.7% of private-industry employer compensation costs in the BLS March 2025 release). If you have not computed yours, do that first: Fully Loaded Cost of an Engineer walks through it. It is an afternoon of work and it powers every calculation like this one.

Input two: where review time actually goes. From your own repo: how long PRs sit before first review (pickup), how many review round-trips they take, how many are stuck right now. Your git history has all of it.

Then count conservatively. The honest formula is not "PR waited 3 days × 8 hours × hourly rate". The author was doing other things, and a CFO will spot that inflation in one breath. Count only what you can defend:

• Re-context cost: for each review round-trip, a realistic resumption toll at both ends, priced at loaded hourly cost. Even at a modest fraction of an hour per switch, multiplied by every round-trip on every PR in a quarter, this compounds fast.
• Blocked-work cost: hours where a dependent task, release, or teammate was genuinely waiting. Verifiable hours only.
• Abandonment cost: the occasional PR that stalls long enough to rot and gets redone. That one is 100% loss, and every team has them.

A deliberately hypothetical illustration of the shape: a team of ten with a $78 loaded hourly rate, averaging two avoidable re-context switches per PR at half an hour of combined toll each, across 40 PRs a month, is paying roughly $3,100 a month for round-trips alone, before counting a single blocked hour. Your numbers will differ. The point is that yours are computable from your own data, and small-looking frictions multiply into salaries.

What the benchmarks say about "normal"

Published reference points exist, with caveats. LinearB's benchmark study (8.1M+ pull requests across 4,813 teams) puts elite pickup time (PR opened to first review, at the 75th percentile) at under about an hour, with middle bands running to several hours and the weakest band beyond sixteen (LinearB Engineering Benchmarks). Two honesty notes when you compare. Their percentile and stage definitions may not match your tooling's. And a benchmark tells you where you stand; only your loaded-cost math tells you what it costs you.

The useful signal in the benchmark is which stage dominates. Across the industry's own published data, the long pole is the wait before review starts, rarely the reviewing itself. That is excellent news, because waiting is the one stage you can compress without touching quality.

Fixing it without rubber stamps

Speed bought with shallow approvals is a loan against your incident budget. The fixes that shorten the queue while keeping review real:

• Make pickup time visible and social. Most teams have no idea how long PRs sit. Surfacing it (per team, never as a per-person shame board) changes behavior on its own.
• Shrink PRs. Small changes get picked up sooner and reviewed properly instead of skimmed. Review quality goes up while wall-clock time goes down.
• Spread reviewer load. If one person is the whole safety net, your queue has a single point of failure and so does your knowledge. Watch where review concentration lives and rotate deliberately.
• Triage the stuck ones weekly. A PR that has been open for weeks is blocked, abandoned, or radioactive - three different problems with three different fixes. Deciding which one you have is a five-minute conversation that beats another week of silence.

One more place this number earns its keep: work that dies in review is pure operating expense, while work that ships can be a balance-sheet asset. The split matters more than most engineering leaders realize, and Capitalizing Software Development Costs in Agile explains why.

The door: this week, pull your median pickup time, multiply your round-trips by your loaded rate, and put one conservative monthly figure in front of your team. The figure is not there to shame anyone. It gives the fix a budget, and queues get fixed when they get priced.