How to assign code reviewers without creating a bottleneck
Othman Shareef · September 2, 2026 · 6 min read
Ask a team how to assign code reviewers and you will usually get a shrug: “whoever knows that code.” It sounds reasonable and it is how, eighteen months later, one engineer is the reviewer for half the codebase, merges wait on their calendar, and nobody else can safely touch the payment path. Reviewer assignment is a real design decision with three basic strategies, one seductive trap, and a knowledge-transfer lever most teams never use on purpose.
How to assign code reviewers: the three models
Every assignment scheme is one of three ideas, or a blend:
- Round robin: reviews rotate through the team regardless of familiarity. Even load, even knowledge spread, zero routing thought. Cost: reviewers regularly land on code they have never seen.
- Expertise-based: the person who knows the area reviews it. Highest-quality feedback per review. Cost: expertise concentrates, and the expert becomes a queue.
- Load-based: route to whoever has the fewest open reviews. Best turnaround times. Cost: optimizes for speed while ignoring both context and learning.
None of these is the answer alone. The teams that do this well run round robin as the default, override to expertise for changes with real blast radius, and use load only as a tiebreaker. The override list should be short and explicit (auth, payments, migrations, public APIs), which is the same tiering logic that belongs in a CODEOWNERS file.
You do not need custom tooling for the default, either. GitHub’s team review assignment can rotate requests through a team automatically, with round robin and load-balancing flavors built in, and that is a perfectly good baseline. What no platform automates is the override judgment: knowing which changes are risky enough to leave the rotation and go to a domain owner. That list lives in your head or in a document, and writing it down is most of the work of a real assignment policy.
The expertise trap
Routing everything to the expert is the trap because every individual decision is correct. For any single PR, the domain expert will give the best review, so each routing choice is locally optimal, and the sum is a disaster: a single human gate in front of an entire subsystem. The failure arrives on three fronts at once. Throughput: their review queue sets the team’s merge rate. Resilience: their vacation is a freeze, their departure is a crisis, and the bus factor of the whole area is one. Quality: review volume grows until skimming is the only way to keep up, at which point you have the bottleneck and shallow reviews.
The uncomfortable part is that experts rarely fight this arrangement. Being the mandatory reviewer is status, and handing off reviews feels like risk. The team lead has to break the loop deliberately, because it does not break itself; it only deepens.
Assignment is how knowledge actually spreads
The research is consistent that review is not mainly a defect filter. Microsoft’s study of practice at scale found knowledge transfer among the top outcomes reviewers and authors actually value (Bacchelli and Bird), and Google’s Critique case study lists education as an explicit goal of its review process, with most changes reviewed by a single reviewer. We covered the defect-finding evidence in do code reviews find bugs; the practical consequence for assignment is that every reviewer choice is also a teaching choice. Assigning the newcomer to review the subsystem they will inherit next quarter is not a diversity gesture; it is the cheapest onboarding the team has. Pairing them with a domain owner as second reviewer for the first few rounds, as in our first code review guide, converts review time directly into bus-factor insurance.
Self-selection cultures
Some teams skip assignment entirely: PRs land in a shared queue and reviewers pick what they take. At its best this is the fastest model, because motivated reviewers grab work they care about the moment it appears. It fails in two predictable ways. Unglamorous PRs (dependency bumps, test refactors, docs) age in the queue while interesting ones are fought over, and quiet team members review far more than loud ones. Self-selection works when paired with a backstop: anything unclaimed after a few hours gets assigned by rotation, and the queue is visible enough that aging PRs embarrass the team into action. Without the backstop, self-selection is just unassigned work with better branding.
Route by who can unblock what
Whatever model you choose, the question that should drive the day-to-day is not “whose turn is it” but “which review, done next, unblocks the most.” A release-blocking fix waiting on review outranks a refactor, whoever the assigned reviewer is; a teammate stuck until their PR lands outranks one who has moved on to other work. Most tools make this invisible, which is why we built a team view in ours (Pyor) that ranks waiting reviews by unblock value rather than by age. Tooling aside, the principle stands on its own, and it pairs with honest capacity planning: assignment decides who reviews, but priority decides what gets reviewed first, and teams that only manage the first half still ship late.