3 June 2026

Diagnosing a stuck code review habit

Signals that review lag is a process problem rather than a tooling shortage—and experiments that teams can run in two weeks.

Long-lived pull requests rarely mean engineers are lazy. More often, review ownership is unclear, batches are too large, or reviewers are punished for slowing a release that was already promised.

What we look for first

In process diagnosis work we measure median time to first comment, not average time to merge. Averages hide the lonely request that sat for nine days. We also ask who may merge without a second pair of eyes—and whether that privilege matches risk.

Two-week experiments

  • Cap open review count per person; overflow goes to a named backup reviewer.
  • Require a size estimate before opening; anything above the team’s agreed limit must be sliced.
  • Protect a daily review window on calendars the way you protect planning.

If those experiments fail, the issue may be staffing depth or unclear architecture ownership—topics that belong in CTO advisory, not another checklist.

Mild warning

Do not introduce review SLAs as punishment. Teams notice when numbers are used to shame rather than to schedule help.


← All field notes