Pull requests that sit in review for days are a system problem, not a people problem. Here's how we fixed the system.
Small PRs are a forcing function
Our rule: no PR over 400 lines of meaningful change. Large PRs don't get reviewed properly — reviewers rubber-stamp them because the cognitive overhead is too high. Small PRs are reviewed quickly, deeply, and correctly.
This requires a different approach to feature development: stack PRs, use feature flags, ship incomplete features behind flags. The code hits production sooner, the review stays small, and the feedback loop tightens.
The 24-hour SLA
Every open PR in our team has a 24-hour review SLA. If a PR isn't reviewed within 24 hours, the author pings the reviewer directly. Not in a group channel — directly. This makes the delay visible without being punitive.
PR description as communication
Good PR descriptions eliminate most review back-and-forth. We require: a summary of what changed and why, screenshots/recordings for UI changes, a note on what was not changed (and why), and any follow-up items. A reviewer who reads the description should understand the PR before looking at a single line of code.
Review as teaching, not gatekeeping
The tone of code review matters enormously. Comments that say "this is wrong" create defensiveness. Comments that say "I've seen this pattern cause X problem at scale — consider Y instead" create learning. We optimise for the latter.
Approve and fix
For non-blocking comments, reviewers use "approve with suggestions" and the author decides whether to address them before or after merge. This prevents the approval-hostage situation where a PR is blocked on minor nitpicks for days.