Code review is where quality, culture, and delivery speed collide. These norms keep reviews fast and useful as headcount grows.
Set a review latency budget
Review latency is a product metric. If PRs wait two days, engineers batch work, context rots, and "LGTM" becomes a rubber stamp.
Pick a target (for example, first response within four business hours) and staff for it. Rotate a reviewer-on-call for critical paths.
What review comments are for
Comments should improve correctness, clarity, or maintainability — or ask a genuine question. Style debates that a formatter can settle are noise.
Separate blocking from non-blocking. Label suggestions so authors are not forced to guess whether a comment is a gate.
A review that cannot say "this is fine" is not a review; it is a rewrite request queue.
- Block on: bugs, security, data loss risk, broken contracts.
- Suggest: naming, structure, tests that would help.
- Prefer pairs or design docs for large architectural disagreements.
- Approve when the change is safe to ship, not when it is perfect.
Ownership without bottlenecks
Code owners help focus attention on the right reviewers. They should not become a single-maintainer gate. Define primary and secondary owners for every package that ships weekly.
If every PR needs the same two staff engineers, your ownership model is broken or your modules are too coupled.
PR hygiene that respects attention
Small PRs get better reviews. Describe intent, risk, and how to test. Link the issue. Call out migrations and rollout plans.
Authors should self-review before requesting review. A focused diff is a kindness to the reviewer's afternoon.
Key takeaways
- Measure and staff for review latency; it is a delivery metric.
- Separate blocking from non-blocking comments.
- Use code owners as focus, not single points of failure.
- Keep PRs small, described, and self-reviewed.
- Approve when the change is safe to ship.