Your team's PRs wait over a day for review and keep getting bigger. What is the causal loop and how do you break it?

Slow reviews make authors batch work into large PRs to avoid waiting repeatedly; large PRs get shallow reviews and take longer, slowing reviews further. Break it with a response-time agreement (hours, max one business day), shared reviewing instead of a single gate, and small PRs.

What should a code review focus on, and what should it leave to tools?

Correctness and design, tests, security and data handling, readability of intent. Formatting and style should be enforced by linters and formatters.

When can a change skip pre-merge review?

For low-risk changes under an agreed policy such as Ship/Show/Ask: e.g. documentation or a trivial config fix may be 'shipped' or 'shown' after merge, while risky changes are 'asked' first.

Code Review Standards and Speed — The Tech Lead Handbook

Scenario

Example team: the payments team (seven engineers) requires two approvals, one of them from the tech lead. Engineers open pull requests in the morning and get the first review the next afternoon. To avoid waiting twice, they batch work into large PRs of 800+ lines.

What you see on the team

Median time to first review over a day; PRs open for 3–4 days.
Large PRs with superficial reviews ("LGTM") and bugs found later.
Long comment threads about style that a linter could settle.
Engineers starting new work while waiting, so many changes are in flight at once.

The common mistake

Treating review as a quality gate owned by a few senior people, with no expectation on response time and no agreement on what review is for.

Why it happens

Reviewing feels like an interruption to "your own" work, so it gets postponed. A single mandatory reviewer turns every PR into a queue. Long waits push authors toward big batches, which are harder to review — a loop that makes both speed and quality worse. Google's public code review guide is explicit: "One business day is the maximum time it should take to respond to a code review request."

The playbook

Agree what review is for, in priority order: correctness and design, tests, security and data handling, readability. Style is the linter's job.

Set a response expectation: first response within a few working hours, never more than one business day. Reviewing others' work comes before starting new work.

Keep PRs small (a few hundred lines at most) and describe intent, risk and how it was tested.

Remove the single gate. Any trained engineer can approve; require a specific reviewer only for high-risk areas (ledger, auth, migrations).

Label comments so authors know what must change: blocking:, suggestion:, nit:, question:.

Consider lighter modes for low-risk changes: Rouan Wilsenach's Ship / Show / Ask distinguishes changes you merge directly, merge and show, or ask about first.

This model compares a single lead reviewer with shared review on the same week of PRs:

Review wait time: one gatekeeper vs shared reviewingTry it yourself

import random
import statistics

random.seed(7)
# 30 PRs arrive during a 5-day week (working hours 0..40); a review takes ~30 minutes.
arrivals = sorted(random.uniform(0, 40) for _ in range(30))

def simulate(sessions, per_session):
    # sessions: (time, reviewers); each reviewer clears up to per_session queued PRs per session
    queue, waits = list(arrivals), []
    for t, reviewers in sessions:
        ready = [a for a in queue if a <= t][: per_session * reviewers]
        for i, a in enumerate(ready):
            done = t + 0.5 * (i // reviewers + 1)
            waits.append(done - a)
        queue = [a for a in queue if a not in ready]
    return waits

# The lead reviews in one 2-hour block at the end of each day (4 PRs).
lead_only = simulate([(day * 8 + 6.0, 1) for day in range(10)], per_session=4)
# Four engineers each review one PR at 09:00 and 13:30 (after standup and lunch).
shared = simulate([(day * 8 + o, 4) for day in range(10) for o in (1.0, 4.5)], per_session=1)

for name, waits in [("lead reviews once a day", lead_only), ("4 reviewers, twice a day", shared)]:
    waits.sort()
    p90 = waits[int(len(waits) * 0.9) - 1]
    print(f"{name:26} median wait {statistics.median(waits):4.1f} h   p90 {p90:4.1f} h   (working hours)")

import random
import statistics

random.seed(7)
# 30 PRs arrive during a 5-day week (working hours 0..40); a review takes ~30 minutes.
arrivals = sorted(random.uniform(0, 40) for _ in range(30))

def simulate(sessions, per_session):
    # sessions: (time, reviewers); each reviewer clears up to per_session queued PRs per session
    queue, waits = list(arrivals), []
    for t, reviewers in sessions:
        ready = [a for a in queue if a <= t][: per_session * reviewers]
        for i, a in enumerate(ready):
            done = t + 0.5 * (i // reviewers + 1)
            waits.append(done - a)
        queue = [a for a in queue if a not in ready]
    return waits

# The lead reviews in one 2-hour block at the end of each day (4 PRs).
lead_only = simulate([(day * 8 + 6.0, 1) for day in range(10)], per_session=4)
# Four engineers each review one PR at 09:00 and 13:30 (after standup and lunch).
shared = simulate([(day * 8 + o, 4) for day in range(10) for o in (1.0, 4.5)], per_session=1)

for name, waits in [("lead reviews once a day", lead_only), ("4 reviewers, twice a day", shared)]:
    waits.sort()
    p90 = waits[int(len(waits) * 0.9) - 1]
    print(f"{name:26} median wait {statistics.median(waits):4.1f} h   p90 {p90:4.1f} h   (working hours)")

Output

lead reviews once a day    median wait 18.8 h   p90 24.2 h   (working hours)
4 reviewers, twice a day   median wait  3.9 h   p90  5.9 h   (working hours)

What to say

Team agreement (put it in the repository README):

Code review agreement
- Reviews come before starting new work. First response within 4 working hours.
- PRs under ~400 lines; describe intent, risk and testing.
- Any engineer can approve. Ledger, auth and migrations need one of the area owners.
- Label comments: blocking / suggestion / nit / question. Style is the linter's job.

When a PR is too big:

"This is hard to review well at 900 lines. Could you split the migration from the API change? I'll review the migration first today."

Trade-offs

Faster reviews interrupt focus; batching into two review slots a day keeps waits short without constant context switching.
Removing the lead as gate risks inconsistency; area owners for risky code and a clear standard handle that.
Small PRs need feature flags for incomplete work.

Signals it's working

Median time to first review under four working hours.
PR size trends down; "LGTM" with no comments on large PRs disappears.
Fewer style debates; more comments about design and tests.
Work in progress per engineer drops.

Key points

Review is for correctness, design, tests and security; style is automated.
Respond within one business day at most — ideally a few hours; reviews before new work.
Small PRs, labelled comments, and any trained engineer can approve outside high-risk areas.
Slow reviews cause big batches, which cause worse reviews: fix the speed first.