Why Are Code Reviews Taking So Long? (It's One Queue)

TL;DR: When reviews take days, the instinct is to blame diligence and install a nagging bot. But review time is almost never spread evenly across the team; it's piled in front of one or two people everything secretly queues behind. Reading code is the fast part; waiting for the person who always reviews it is the slow part. The free fix: split pickup time from review duration on your last twenty PRs, count reviews per reviewer for one month, and look at the concentration. Then fix the queue you find - carefully, because it formed for a reason.

You've already tried the polite fixes. The retro where everyone agreed reviews should be faster. The Slack channel for review requests. The bot that pings after 24 hours, which everyone has learned to unsee. And still: a PR goes up Tuesday morning, and the author is refreshing it Thursday like a teenager checking for likes.

Here's what the retro couldn't see, because it was asking the whole team a question whose answer isn't about the whole team: your review time isn't slow on average. It's slow in one place. Pull up your merged PRs and check who actually did the reviewing. Most teams find a shape they never chose: one or two names on most of the approvals, and a queue in front of those names that the org pretends is "review being slow."

Reading was never the slow part

Split any PR's review time into two stages and the diagnosis mostly makes itself: pickup (PR ready → first reviewer activity) and review (first activity → approval). Teams that measure this for the first time almost always find the same thing: the days are in pickup, the reading itself is hours. Pickup time is the metric nobody watches, and it's precisely the one that grows when load concentrates.

Calibration, so nobody argues from vibes: Google's study of ~9 million reviewed changes found the overall median for the entire review process was under 4 hours, with small changes getting first feedback in under an hour, and a median of one approver per change. LinearB's benchmarks across 8.1M+ PRs band pickup as elite under 1 hour and "needs focus" above 16. If your PRs wait two days for a first comment, you are not near any published band, and the gap isn't reading speed.

Why does the queue form in front of the same person? Because review competence isn't fungible. Bacchelli & Bird's study at Microsoft found that understanding the code under review is the central challenge of reviewing, so everyone routes PRs to the person who already understands, which is rational per-PR and catastrophic in aggregate. The expert accumulates review load on top of their own delivery work, review becomes the task that fits between meetings, and the queue stretches. Meanwhile PR size feeds the same spiral: the SmartBear/Cisco study found defect detection drops sharply when review speed exceeds ~500 lines per hour, and a PR too big to review properly is exactly the one a loaded reviewer keeps not starting.

This is worth fixing for more than comfort. DORA's 2023 research found teams with faster code reviews report ~50% higher software delivery performance. Review wait is a primary delivery bottleneck, and it's payroll you're already paying while the work sits. It's also how In Progress columns go quietly dead: the blocked author starts something else, and now two things are half-done.

The free diagnosis: three numbers, one month

No tools required beyond your git host's API or, honestly, patience and a spreadsheet.

1. Split pickup from review on your last twenty merged PRs. Timestamps: PR marked ready, first reviewer activity, approval. Two medians. If pickup dominates - it will - stop scheduling "review faster" conversations and start scheduling "queue" conversations.
2. Count reviews per reviewer over one month. Approvals and substantive review comments, per person. You're looking at the shape of the distribution: if a large share of reviews flow through one or two people, you've found the queue, and probably explained why it's invisible. The bottleneck is your most senior, most trusted, busiest person, and nobody wants to say their name in a retro. Good news: you don't have to. The fix is structural, not personal.
3. Check the size of what waits longest. Sort those twenty PRs by pickup wait and look at their diff sizes. LinearB bands elite PRs under 100 changed lines; if your slowest-picked-up PRs are the big ones, smaller PRs are part of the cure, and your authors can do a lot from their side too.

Then fix the concentration the slow, real way. Pick the two areas with the worst queue and build a second reviewer for each: pair-review with the expert for a few weeks, route the low-risk PRs to the trainee deliberately, and hold a pickup working agreement (first response within a business day is achievable for most teams; Google's median shows how much headroom exists). What doesn't work: a rota that assigns names without building understanding. That just converts your queue into approval theater, a review that happens fast and means nothing, which is a worse trade than the queue. The rest of the craft - norms, checklists, culture - is the code review best practices playbook; the queue diagnosis is the part that has to come first, because practicing better inside an unmeasured bottleneck improves nothing anyone can feel.

How you'd actually see this in Busfactor

The month of counting is exactly the kind of thing that gets done once, changes one decision, and never gets repeated - while the queue quietly re-concentrates the next time someone leaves or an area changes hands. Busfactor runs the counting continuously from your GitHub data and draws the part you can't get from a spreadsheet: the review network - who reviews whom, load, breadth, reciprocity, the one-way streets, and the areas where a single reviewer is the entire safety net. Pickup and review duration are split per stage, per team, per person, and every claim links to the PRs behind it, so "reviews are slow" becomes "these two areas queue behind one person, here are the fourteen PRs that waited longest" - a sentence with a fix attached.

The honest limits: Busfactor sees the events GitHub sees. It cannot see the review that happened over a screen-share, the "can you look at mine?" DM, or the hallway approval. Orgs with heavy out-of-band review will look worse on pickup than they are, and the numbers say so rather than pretend otherwise. And a concentrated review queue is not automatically a dysfunction: sometimes it's a deliberate quality gate on a critical area, staffed by exactly the right person. The data can show you the concentration and what it costs in waiting; whether that trade is worth it is a judgment call the tool hands back to you - with receipts, both readings stated, never a verdict on the reviewer carrying the load.

The door

Pull twenty PRs and compute the two medians this week - pickup and review. One of them will embarrass you, and it's nearly always the fixable one. Then, if you want the queue watched permanently instead of once, get your org's free read and see your review network drawn from your real data: whose queue the team is actually waiting in, what it costs, and where the second reviewer needs to grow. Your best engineer, currently buried under everyone's PRs, will thank you for making it about the system.