PR review as a leadership lever

What it is

Code review is usually treated as a quality gate. It is also the largest hidden cost in a team's cycle time and the highest-frequency cultural artifact the team produces, which makes it one of the few things a lead can change that affects delivery speed, code quality and how people treat each other at the same time.

Four settings, each with a defensible number:

REVIEW SLA        first response within 4 business hours,
                  published. Not "reviewed", RESPONDED TO.

PR SIZE           under ~400 lines changed. Review quality
                  collapses beyond that, and large PRs get
                  approved rather than reviewed.

COMMENT TAXONOMY  prefixes: blocking: / suggestion: / nit: /
                  question: / praise:
                  Cheap to introduce, and it removes the
                  ambiguity that causes most review friction.

REVIEW ORDER      correctness -> design and boundaries -> tests ->
                  readability -> nits. In that order, explicitly.

What this is confused with: review as gatekeeping. A gate asks "should this be allowed in." A review that works asks "is this correct, is the design right, and what will the next person need to know." The gate framing produces reviewers who look for reasons to object and authors who write defensively.

Also confused: review latency and review thoroughness. They are independent, and teams routinely trade the wrong one: a review that takes two days and then rubber-stamps a 900-line diff has the worst of both.

The problem it solves

Review latency is usually the single largest component of cycle time, and it is invisible because nobody measures the waiting.

An item with a 14-day cycle time, sampled:

  2.5 days   active development
  4.1 days   waiting for review
  1.2 days   waiting for re-review after changes
  6.2 days   other waiting

Review accounts for 5.3 of 14 days: 38% of the item's life,
spent on work that is finished.

And the cost compounds: a PR waiting two days is a PR the author
has context-switched away from, so responding to comments now
costs a re-orientation, and the branch has drifted from main.

And unreviewed ambiguity produces interpersonal cost that nobody attributes to the review process.

A comment: "Why not use a map here?"

Author reads it as: you must change this.
Reviewer meant:     I'm curious, this is fine either way.

Result: the author rewrites, the reviewer is surprised, and both
conclude the other is difficult. Between two seniors this
escalates, because each assumes the other's intent is clear.

The prefix `question:` costs seven characters and removes the
entire failure mode.

Mechanics

The review SLA

Published: "First response within 4 business hours."

Two deliberate details:

RESPONSE, NOT APPROVAL. The commitment is that the author is not
  waiting in silence. A response can be an approval, a set of
  comments, or "this needs an hour of focus, I'll do it at 3pm."
  All three unblock the author's planning; silence does not.

BUSINESS HOURS. A PR opened at 5pm is not late at 9am. Making
  this explicit prevents an SLA from becoming an evening
  expectation.

Making the SLA achievable is the lead's job, not the reviewers':

- A scheduled review slot on everyone's calendar. 20 to 30
  minutes, daily, at a fixed time. This is the single highest-
  impact change, because it converts review from an interruption
  into planned work.
- Explicit reviewer assignment. "Anyone can review" means nobody
  does, and round-robin assignment with a bot removes the
  social cost of asking.
- Review is counted as work. If a person reviewed six PRs and
  shipped nothing, they had a productive day, and saying so in
  public is what makes the SLA real.
- Measure: time-to-first-review (p50 and p90), review queue
  depth, and PRs older than 24 hours. Three numbers on the
  team's dashboard.

The reason a scheduled slot works where exhortation does not is that review competes with focused work, and focused work always wins in the moment. Putting it on the calendar makes it lose once, in advance, which is the same governance move as any other declared budget.

PR size

Under ~400 lines changed. The specific number comes from the
review-effectiveness research (see production evidence), which
consistently finds defect-detection rate falling sharply past a
few hundred lines and review speed becoming implausible past
about 500.

The observable symptom of an oversized PR:

   120 lines   14 comments, 3 substantive
   450 lines    9 comments, 4 substantive
   900 lines    2 comments ("LGTM", "nit: typo")
  2,100 lines   1 comment ("approved")

Comment count per line falls off a cliff, and the reason is
that past a certain size the reviewer cannot hold the change in
their head, so they check the parts they understand and approve
the rest.

How to actually get small PRs, since "write smaller PRs" is not an instruction anyone can follow:

- STACKED PRs: a chain of small PRs each based on the previous,
  reviewed and merged bottom-up. Tooling exists because git does
  not model the chain.
- SEPARATE MECHANICAL FROM SEMANTIC. A rename touching 60 files
  and a behaviour change should never be the same PR. Land the
  rename first, alone, and say so in the description.
- FEATURE FLAGS. Incomplete work merges behind a flag, so a
  feature is five small PRs rather than one large one.
- A SIZE WARNING, NOT A BLOCK. A bot that comments "this is 780
  lines; consider splitting" is useful. A hard block produces
  three PRs with an artificial split and a broken main.

The comment taxonomy

blocking:    I will not approve until this changes. Use sparingly
             and always with a reason.
suggestion:  I think this would be better. Author decides.
nit:         trivial, take it or leave it, and I do not need a
             reply.
question:    I genuinely do not know. Not a disguised objection.
praise:      this is good and I want you to keep doing it.

The taxonomy does three things that are hard to get otherwise:

1. It makes the reviewer's authority explicit, so the author
   knows what they must do versus what they may do.
2. It forces the reviewer to decide how strongly they feel,
   which reduces the number of blocking comments, because
   typing `blocking:` on a stylistic preference feels wrong,
   correctly.
3. `praise:` gets used. Without a prefix inviting it, review
   comments are 100% criticism by construction, which is a
   strange thing to do to people every day.

question: is the one that resolves senior-to-senior friction, because the ambiguity between "I'm curious" and "you should change this" is exactly where two experienced engineers most reliably annoy each other.

A convention worth adding: a blocking comment must say why in terms of consequence.

Weak:     "blocking: don't use a mutable default here."
Better:   "blocking: mutable default argument, so the list
           persists across calls and the second caller sees the
           first caller's items."

The second is teachable and unarguable. The first is an
assertion of authority.

Automate everything mechanical

Humans should never comment on:
  formatting            -> formatter, enforced in CI and on save
  import order          -> linter with autofix
  naming conventions    -> linter where mechanical
  line length           -> formatter
  trailing whitespace   -> formatter
  test coverage floor   -> CI check
  dependency licences   -> CI check

Every one of these as a human comment costs a round trip, and
each round trip costs hours of latency for something a machine
decides deterministically.

The argument to make when someone resists the formatter: it is not about which style is better, it is that no human minute should ever be spent on it. Adopt the language's default (gofmt, black, rustfmt, prettier) so the style choice itself is not a discussion.

Review order, said out loud

1. CORRECTNESS       does it do what it claims? edge cases, error
                     paths, concurrency, the failure modes
2. DESIGN AND        is this the right place for this code? does
   BOUNDARIES        it put a dependency where it does not belong?
                     will the next change be harder?
3. TESTS             do they test behaviour? would they fail if
                     the code were wrong?
4. READABILITY       will the person who reads this in a year
                     understand it?
5. NITS              everything else

The order matters because reviewer attention is finite and front-loaded. A reviewer who starts with naming has spent their attention before reaching the concurrency bug.

And it matters because of what a review comment costs the author: a design comment on the first pass is a redesign, and a design comment after three rounds of nit fixing is a demoralising rewrite. Get the expensive comments out first.

Reviewer assignment

ROTATE, deliberately:
  - spreads context, so the bus factor on each area rises
  - prevents the single-owner bottleneck, where one person
    reviews everything in an area and becomes the constraint
  - is a growth mechanism: reviewing a system is one of the
    cheapest ways to learn it

PAIR-REVIEW FOR ONBOARDING: a new joiner reviews alongside an
  experienced reviewer for their first weeks. They learn the
  codebase and the review norms simultaneously, and it is far
  more effective than reading the style guide.

TWO REVIEWERS only where it earns its cost: security-sensitive
  paths, migrations, anything touching money. Everywhere else it
  doubles latency and produces diffusion of responsibility, where
  each reviewer assumes the other looked properly.

A worked example: 38 percent of cycle time spent on finished work

A team of eight, median cycle time 14 days, complaints in both directions: engineers said reviews were slow, and the lead's read from the retro was that people were "not prioritising review."

Measured for three weeks, 96 PRs:

time to first response      p50  9.4 hours   p90  38 hours
time to merge               p50  2.8 days    p90  6.1 days
PR size                     p50  340 lines   p90  1,180 lines
comments per PR             p50  4           p90  9
PRs merged with 0 or 1
  substantive comment                        41%
review round trips          p50  2           p90  5

Reviewer distribution: 2 of 8 people did 61% of all reviews.

Three findings, and the second one inverted the retro's conclusion:

1. The 9.4-hour p50 was almost entirely queueing, not reviewing.

Sampled 20 reviews, measuring actual time spent in the review:
  median time spent reviewing:    11 minutes
  median time the PR waited:      9.4 hours

So the cost was not reviewer effort, it was that review had no
scheduled place and lost every contest against focused work.

2. Forty-one percent of PRs merged with no substantive comment, concentrated in large PRs.

By size bucket, share merged with 0-1 substantive comments:

  < 200 lines       12%
  200-400           19%
  400-800           47%
  > 800             81%

Reading: past about 400 lines the review stops being a review.
The team was not under-reviewing because people were lazy; they
were under-reviewing because the artifact was unreviewable.

"Not prioritising review" was the wrong diagnosis, and the measurement is what changed it.

3. Two people did 61 percent of reviews, and both were the ones complaining loudest about interruption.

Cause: informal norm that the two most senior engineers reviewed
"anything important", which had grown to mean everything. Both
were the single reviewer for their areas, so both were a
bottleneck AND a bus factor.

The changes, in order of effect:

1. A DAILY 25-MINUTE REVIEW SLOT on everyone's calendar, 10:35,
   after standup. Not optional, and counted as work.
   -> time to first response p50 9.4h -> 2.1h, p90 38h -> 7h
   This was one calendar change and it was the largest single
   improvement in the whole programme.

2. A SIZE WARNING BOT at 400 lines, plus a stacked-PR workflow
   and a rule that mechanical changes ship separately.
   -> p50 PR size 340 -> 180, p90 1,180 -> 410
   -> PRs merged with 0-1 substantive comments 41% -> 17%

3. THE COMMENT TAXONOMY, introduced in one 10-minute standup and
   added to the PR template.
   -> review round trips p90 5 -> 3, because `nit:` comments
      stopped triggering a re-review cycle and `suggestion:`
      stopped being read as mandatory
   -> two specific recurring conflicts between senior engineers
      stopped, which the lead had previously been mediating
      about once a fortnight

4. ROUND-ROBIN REVIEWER ASSIGNMENT with a bot, excluding the
   author, weighted lightly toward people who had not touched
   that area.
   -> reviewer concentration 61% by 2 people -> 34%
   -> the two senior engineers' review load halved
   -> a side effect nobody predicted: two engineers who had
      never touched the streaming code reviewed it enough over
      a quarter to become secondary responders for it

5. FORMATTER AND LINTER made blocking in CI, with autofix on
   save.
   -> style comments per PR 2.1 -> 0.1

The formatter change was the least interesting and removed about a tenth of all comments, each of which had been costing a round trip.

Results after one quarter:

                            before      after
time to first response       9.4h        2.1h
time to merge (p50)         2.8 days     0.9 days
median cycle time            14 days     8 days
PR size (p50)               340 lines    180 lines
merged with 0-1
  substantive comments        41%         17%
review round trips (p90)       5           3
reviewer concentration
  (top 2 people)              61%         34%
escaped defects per
  month                        6.2         3.8

Escaped defects fell while review latency fell, which is the counter-intuitive part and the point of the exercise: the team was reviewing faster and better, because smaller changes are both quicker to review and possible to review properly.

One thing that did not work:

An initial attempt at a hard 400-line block in CI, before the
stacked-PR workflow existed, produced three PRs split at
arbitrary boundaries that individually did not compile, and one
merge that broke main.

Replaced with a warning plus tooling. The lesson: do not
constrain an artifact before providing the workflow that makes
the constraint achievable.

Production evidence

Cisco's large-scale code review study (Cohen et al., via SmartBear's published analysis) examined roughly 2,500 reviews across 50 developers and found defect-detection effectiveness dropping sharply with review size, with the practical recommendations of reviewing fewer than 200 to 400 lines at a time and limiting review sessions to about 60 minutes. Those are the numbers behind the 400-line guidance.

Google's code review practice, documented in its engineering practices guide, specifies both a fast response expectation (respond within one business day, and faster is better) and a change-size preference for small changes, with the explicit rationale that small changes are reviewed more thoroughly and merged faster.

Conventional Comments (conventionalcomments.org) is the published form of the prefix taxonomy, with labels including praise, nitpick, suggestion, issue and question, and its stated purpose is removing ambiguity about how strongly a comment is held.

Microsoft's and Google's published research on modern code review consistently finds that the dominant benefits reported by practitioners are knowledge transfer and design feedback rather than defect detection, which is the argument for reviewer rotation as a capability-spreading mechanism rather than only a quality one.

The DORA research programme's findings on batch size and lead time provide the systems-level version of the small-PR argument: smaller changes flow faster and fail less.

Automated formatting as a settled question is the position taken by Go (gofmt, with the explicit stance that the formatter's style is nobody's favourite and that is the point), Rust (rustfmt), and Python's black, all of which exist so that formatting stops being a review topic.

The debate

Is a review SLA realistic? Yes, if it is a response SLA rather than an approval SLA and if a scheduled slot exists. Without the calendar slot it is exhortation, and review loses every contest against focused work in the moment, which is exactly what the 9.4-hour p50 against 11 minutes of actual review time shows. The counter-argument, that scheduled review interrupts flow, is real and is why the slot goes immediately after an existing interruption like standup.

Should PR size be enforced? As a warning, yes; as a hard block, only after the workflow exists. A block without stacked-PR tooling produces artificial splits that do not compile, which is worse than a large PR. The observation that carries the argument is that past about 400 lines the comment rate collapses, so an unenforced norm plus visible data usually changes behaviour without a gate.

Is the comment taxonomy worth the ceremony? It is five prefixes, learned in a standup. The return is disproportionate because it removes the specific ambiguity that causes senior-to-senior friction, and because praise: is the only mechanism that makes review comments something other than uniformly negative. The failure is enforcing it with a bot, which makes it feel like process rather than a shared vocabulary.

Should two reviewers be required? Only where the cost is earned: security-sensitive paths, migrations, money. Everywhere else it doubles latency and produces diffusion of responsibility, where each reviewer assumes the other looked carefully, which measurably reduces the depth of both reviews.

Is code review the right place to catch defects? Partly, and the published research suggests the larger benefits are knowledge transfer and design feedback. That reframing matters for the lead, because it means reviewer rotation is a capability investment rather than an overhead, and it justifies assigning reviews to people who need the context rather than to whoever is fastest.

Should a lead review everything? No, and the instinct to is the same one that keeps a lead writing code. A lead who reviews everything is a bottleneck and a bus factor, and the two engineers doing 61 percent of reviews in the worked example were both the constraint and the ones most frustrated by it.

Follow-up Q&A

"Why is review latency the largest hidden cost in cycle time?"

Because it is time spent on work that is already finished, and nobody measures the waiting. In one measurement an item with a 14-day cycle time spent 5.3 days waiting for review and re-review, 38 percent of its life. The cost also compounds: a PR waiting two days is one the author has context-switched away from, so responding to comments requires re-orientation and the branch has drifted from main. The waiting was not reviewer effort at all: median actual review time was 11 minutes against a 9.4-hour median wait.

"How do you actually make a review SLA hold?"

Put a 20-to-30-minute review slot on everyone's calendar at a fixed time, immediately after an existing interruption like standup, and count review as work in public. Review competes with focused work and loses every contest in the moment, so the calendar makes it lose once, in advance. Then assign reviewers explicitly rather than relying on "anyone can review," which means nobody does. Commit to a response rather than an approval, so "this needs an hour of focus, I'll do it at 3pm" satisfies the SLA and still unblocks the author's planning. In one case that single calendar change took time to first response from 9.4 hours to 2.1.

"Why 400 lines?"

Because defect-detection effectiveness falls sharply past a few hundred lines, and the observable symptom is that comment density collapses. Measured by size bucket in one team, the share of PRs merged with zero or one substantive comment was 12 percent under 200 lines, 47 percent between 400 and 800, and 81 percent above 800. Past that size the reviewer cannot hold the change in their head, so they check the parts they understand and approve the rest. The team was not under-reviewing out of laziness; the artifact was unreviewable.

"What does the comment taxonomy buy?"

Three things. It makes the reviewer's authority explicit, so the author knows what they must change versus what they may. It forces the reviewer to decide how strongly they feel, which reduces blocking comments because typing blocking: on a stylistic preference feels wrong, correctly. And it makes praise: a thing that happens, which matters because without a prefix inviting it, review comments are 100 percent criticism by construction. The highest-value prefix is question:, because the ambiguity between "I'm curious" and "you should change this" is exactly where two senior engineers reliably annoy each other.

"What is the right review order and why?"

Correctness, then design and boundaries, then tests, then readability, then nits. Two reasons. Reviewer attention is finite and front-loaded, so a reviewer who starts with naming has spent it before reaching the concurrency bug. And the order matters for what a comment costs the author: a design comment on the first pass is a redesign, while the same comment after three rounds of nit-fixing is a demoralising rewrite. Get the expensive comments out first.

"Why rotate reviewers?"

It spreads context, so the bus factor on each area rises; it removes the single-owner bottleneck, which is usually also the person most frustrated by review load; and it is one of the cheapest ways to learn a system. The published research on modern code review finds that knowledge transfer and design feedback are the benefits practitioners report most, more than defect detection, which reframes rotation as a capability investment rather than an overhead. In one case round-robin assignment took the top two reviewers from 61 percent of all reviews to 34, and two engineers who had never touched the streaming code reviewed it enough over a quarter to become secondary on-call responders for it.

Common misconceptions

"Reviews are slow because people are not prioritising them." In one measurement the median review took 11 minutes and waited 9.4 hours. It is a scheduling problem, not a willingness problem.

"A thorough review takes a long time." Latency and thoroughness are independent. A two-day wait followed by a rubber stamp on a 900-line diff is the worst of both.

"Big PRs get more scrutiny because they matter more." Comment density collapses with size: above 800 lines, four in five merge with essentially no substantive comment.

"Requiring two reviewers is safer." It doubles latency and produces diffusion of responsibility. Reserve it for security, migrations and money.

"A comment is a comment." Without a prefix, a curious question reads as a mandate, which is the most common source of review friction between experienced engineers.

"The lead should review everything." That makes the lead a bottleneck and a bus factor, and it is the same instinct as a lead who keeps writing the code.

Interview delivery note

Say this verbatim: "Review latency is usually the largest hidden cost in cycle time, and it is a scheduling problem rather than a willingness problem. We measured the median review at eleven minutes of actual work and a nine-and-a-half-hour wait, so we put a 25-minute review slot on everyone's calendar after standup and time-to-first-response went to two hours." A measurement that reframes the problem and a fix that is one calendar change.

The senior-versus-staff separator is using the comment-density-by-size data to reject the obvious diagnosis. A senior lead asks people to review faster. A staff lead measures the share of PRs merged with no substantive comment by size bucket, finds it at 81 percent above 800 lines, and concludes that the team was not under-reviewing out of laziness but because the artifact was unreviewable, so the fix is PR size and the stacked-PR workflow rather than exhortation.

The second signal is not constraining an artifact before providing the workflow. Saying "we tried a hard 400-line block first, got three PRs split at arbitrary boundaries that did not individually compile and one broken main, and replaced it with a warning plus stacked-PR tooling" shows you learn from your own failed intervention and that you understand a constraint without an enabling workflow just relocates the problem.

The Staff & Team Lead Interview Reference