Code review latency in your team averages one day. What do you change and what do you measure?

What is being tested

Whether you treat review latency as a first-order delivery metric rather than as a politeness issue.

Why a day is expensive

The author has context-switched. Returning to a change a day later costs more than the review saved, and the cost is paid on every change. A team where review takes a day has added a day to every change's lead time, which appears directly in delivery metrics and indirectly in morale.

Worse, it creates pressure toward larger changes — if each review costs a day, batching work into one bigger change is a rational response, and larger changes get worse reviews. The dynamic is self-reinforcing.

What to change

1. Make changes smaller. Everything else follows from this. Change size is the strongest predictor of review quality: beyond a few hundred lines, defect detection falls off sharply because attention does. A 40-line change is reviewed in five minutes; a 1,000-line change is approved without being read.

2. Set a response-time expectation. Review as the first task of the day and after lunch, with an agreed target of a few hours. A cultural norm, not a tool.

3. Distribute reviewers. One bottleneck reviewer whose absence stops the team is a single point of failure. Rotate, and use review deliberately for knowledge distribution.

4. Automate what a machine can check. Style, formatting, obvious defects, dependency scanning, coverage thresholds. Human attention should go to what only a human can assess — design, naming, missing edge cases, and the change that is technically correct and architecturally wrong.

5. Distinguish blocking from non-blocking comments. A reviewer's preference marked as such does not require another round trip.

6. Discuss design before implementation. The most demoralising failure mode is an architectural objection raised for the first time on 800 lines of finished work. A short design conversation beforehand prevents it and takes ten minutes.

7. Consider pairing for complex work, which reviews continuously and removes the latency entirely.

What to measure

• Time from ready-for-review to first review. The number under discussion.
• Time to merge, which includes review rounds.
• Change size distribution. If the median is 400 lines, that is the finding.
• Number of review rounds. Many rounds suggests design was not agreed beforehand.
• Reviewer distribution, to detect a bottleneck person.

What not to do

Do not respond by making review optional or by rubber-stamping. That removes the cost and the value together. The goal is fast, meaningful review, and it is achieved almost entirely through change size.