Code review works fine at five engineers on shared context and vibes. At fifty, the informal version breaks in predictable ways: review queues back up, standards drift by reviewer, and the loudest reviewer's preferences start functioning as unwritten policy. Scaling review isn't about better tooling first — it's about making the informal parts explicit before they cause damage.
Separate "Must Fix" From "Consider"
The single highest-leverage habit is distinguishing blocking feedback from optional feedback, explicitly, in the comment itself:
[blocking] This query is unindexed on a table with 40M rows — will time out in prod.
[nit] Could inline this variable, up to you.
[question] Why retry here instead of at the caller?Without a convention like this, every comment reads as equally mandatory, and authors either bikeshed on nits — extending review time for no quality gain — or learn to numbly resolve everything without judgment, including the comment that actually mattered. Prefixing severity costs the reviewer three seconds and saves the author from guessing.
Write Down What "Good" Means
Most review friction isn't about correctness — it's undocumented style preference dressed up as an objective critique. A short, living style guide (even one page: naming conventions, error handling patterns, when to add a comment) turns "I'd do this differently" into either "this violates our documented convention, please fix" or "this is a genuine preference, not a blocker" — and makes it possible to update the convention itself when enough people disagree with it, instead of relitigating it in every PR.
Bound the Review, Don't Just Bound the Diff
"Keep PRs small" is common advice and still correct, but the part usually left out is bounding review turnaround time, not just PR size. A team norm of "first response within one business day" does more for velocity than any diff-size limit, because the actual cost of slow review isn't the time spent reviewing — it's the context-switch tax on the author who has moved on to something else and now has to reload a PR from three days ago.
| Failure mode | Root cause | Fix |
|---|---|---|
| PRs sit for days | No SLA on first response | Explicit turnaround norm, tracked |
| Same argument every PR | No written standard | Style guide, updated by consensus |
| Author demoralized by tone | No shared severity convention | Tag comments blocking/nit/question |
| One reviewer bottlenecks everything | No load balancing | Rotate reviewers, don't let ownership calcify |
Automate What Doesn't Need a Human Opinion
Formatting, import ordering, basic linting, and test coverage thresholds should never appear as PR comments — they should fail CI before a human looks at the diff. Every one of those comments a human writes is attention not spent on the things a linter genuinely can't judge: is this the right abstraction, does this handle the actual failure mode, does this match how the rest of the system already does things. Teams that skip this step end up with senior engineers spending review time on semicolons.
The Cultural Part
None of the above works if review is treated as a gate to survive rather than a second pair of eyes genuinely trying to catch what the author missed. That tone comes from the top of the team, not from a guideline doc — reviewers who ask questions instead of issuing verdicts, and authors who don't take blocking comments personally, are a leadership example more than a written policy. The mechanics above just remove the friction that makes a bad culture worse; they don't substitute for the culture itself.