Review Load: Is One Person Your Whole Safety Net?

TL;DR: Every team has the reviewer - the person whose approval everyone waits for. That concentration is three problems wearing one face: a queue bottleneck (your pickup time is their calendar), a burnout risk (reviewing is invisible work stacked on a full plate), and a bus factor forming around the one person who reads everything. Measure the top-reviewer share per area, treat it as a system signal and never a leaderboard, and deliberately grow a second qualified reviewer for every part of the codebase.

You know who it is on your team. The person tagged on every PR that matters, whose approval is the real merge criterion whatever the branch protection says, whose vacation weeks are visible in the cycle-time chart. The part that gets missed: that person isn't your problem. They're the patch over your problem, and the patch is wearing out.

What is review load distribution?

Review load distribution is who does the reviewing: the share of reviews each person performs, per area, over a window. It completes a trio with two metrics we've covered before. Review coverage asks whether anyone read the change, pickup time asks how fast, and load asks who. The interesting number is the concentration, not anyone's raw volume. What share of reviews in this repo does the top reviewer hold? How many people reviewed here at all this quarter? Is that count growing or shrinking?

A concentration reading isn't automatically bad. A tiny team, a specialized area, or a deliberate apprenticeship period can legitimately concentrate review for a while. What the metric catches is the unchosen version: centralization that nobody decided, arriving one reasonable routing decision at a time, discovered only when the one reviewer is on a beach and the queue stops moving.

Why review load concentrates

Nobody plans this. It emerges from three forces, each locally sensible:

• Expertise gravity. The fastest good review comes from the person who knows the area best, so that's who gets asked, every time. Each individual routing is optimal; the sum is a monopoly. The better someone reviews, the more review they attract, and the less anyone else learns the area: a loop that tightens itself.
• Ownership structure. A CODEOWNERS file with one name per path is a review monopoly with a config syntax. Strong single-owner setups have real benefits, but every trade-off in code ownership models applies double to review, because review was the one channel by which non-owners still learned the code.
• The conscientiousness tax. The person who reviews promptly and thoroughly gets asked more: reliability is rewarded with load. It's the same dynamic as any glue work, invisible in the plan, essential in practice, and distributed by who says yes rather than by who should.

None of these forces announces itself, which is why load needs measuring. It drifts in silence and presents, months later, as "reviews are slow" or "only one person understands billing."

What concentrated review load costs

Three bills, arriving on different schedules:

1. The bottleneck, billed daily. When one person holds most of the review, the team's pickup time is that person's calendar. Their crunch week is everyone's crunch week; their day off is a queue freeze. Every fix in the review-speed playbook underperforms while the load stays centralized, because you can't parallelize a queue with one server.
2. The burnout, billed monthly. Review is real cognitive work that appears on no roadmap and in no sprint plan. Your top reviewer is doing a second, unplanned job. Per Microsoft's research, the hardest part of review is understanding the change, which means the load is concentration-heavy, interrupt-driven, and invisible in every capacity conversation. People carrying that combination quietly are exactly the people who eventually leave loudly.
3. The bus factor, billed later with interest. Review is how code knowledge spreads as a side effect of normal work: Google's study names education a core purpose of review, and Microsoft's found knowledge transfer among its main measured outcomes. Route all review through one person and that transfer still happens - into one head. The truck-factor study of 133 popular GitHub systems found about 65% have a truck factor of 2 or less, and 34% depend on a single developer; concentrated review is one of the quiet mechanisms that gets a codebase there. And the day the silo bites, it costs broadly: in the Stack Overflow 2024 survey, 45.2% of professional developers agree knowledge silos prevent ideas moving across the org. Your reviewer bottleneck today is a key-person risk with a delivery date.

How do you measure review load?

Two numbers per repo or area, monthly: top-reviewer share (reviews by the busiest reviewer ÷ all reviews) and distinct-reviewer count (how many people reviewed at all). Watch the trend rather than the snapshot: a share drifting from a third to two-thirds over two quarters is centralization in progress; one busy month is noise. Segment by path, because the org-wide average hides the one subsystem where a single person reads everything.

And the guardrail that keeps the metric honest: this is a rebalancing signal, not a leaderboard. High review share is not a badge, and it is definitely not an accusation. It's the system telling you where it has quietly built a single point of failure out of a generous person. Thank the person. Fix the system.

How do you rebalance review load?

Without dropping the quality bar, which is the constraint that makes it interesting:

• Grow a second reviewer per area, on purpose. Apprentice model: the learner reviews first, the expert skims after and reviews the review. You pay a teaching tax for a few weeks; you get a real second reviewer instead of a rubber stamp with a login. Google's median of one approver stays intact day to day. Resilience is about who could review when the first choice is out.
• Route by growth, not only by speed. The fastest reviewer is the default answer; the right answer, one PR in three, is the person who needs the context. Slightly slower today is how "slightly" stays the size of the cost.
• Widen the ownership map. Add second names to single-owner paths and let the ownership model do the routing for you, instead of everyone's muscle memory tagging the usual suspect.
• Make review count as work. Put expected review load into planning like meetings and on-call. Invisible work gets distributed by conscience; visible work gets distributed by agreement.
• Keep PRs reviewable by more people. A 150-line change with a clear description has five potential reviewers; an 800-line one has one hero. Small PRs widen the set of people who can plausibly say yes, on top of being faster to read.

The goal, one quarter out: every area of the codebase has two people who can competently review it, and no one person holds most of any repo's review load without it being a choice someone actually made. Your best reviewer keeps their standards and loses the monopoly - which, ask them, is the retention plan they'd have requested anyway. A safety net with one anchor point isn't a net. It's a rope, and it's fraying politely.