Your Code Reviews Are Slower Than You Think
Most teams underestimate review latency because they never measure it. Here's how to fix that.
Ask an engineering manager how long code reviews take on their team, and you'll usually hear "a few hours" or "same day." Then you look at the data. The real number is almost always worse.
The gap between perception and reality is the core problem. You can't fix what you don't see.
Review Latency Isn't One Number
When people say "review time," they're conflating at least three distinct stages:
- Time to first response. How long until someone looks at the PR at all? This is the biggest source of developer frustration. A PR sitting untouched for a day feels like being ignored.
- Time to approval. How long from opening to the final approving review? This includes back-and-forth, requested changes, and re-reviews.
- Time to merge. How long from approval to actually landing the code? Surprisingly, this gap is often non-trivial - PRs sit approved but unmerged for hours or days.
Each stage has different causes and different fixes. Lumping them together as "review time" hides the actual bottleneck.
Why Teams Underestimate It
Selective memory. You remember the PR that got reviewed in 20 minutes. You forget the one that sat for two days because the reviewer was in meetings.
Excluding weekends and off-hours. A PR opened Friday at 4 PM and reviewed Monday at 10 AM feels like "next morning." It's actually 66 hours of wall-clock time - and that's what your shipping cadence actually feels.
Ignoring the long tail. Averages lie. If most PRs get reviewed in 4 hours but 15% take over 2 days, your team has a serious problem that the average completely masks. The median and p90 tell the real story.
What "Good" Looks Like
There's no universal benchmark, but industry patterns from well-functioning teams tend to cluster around:
- First response: Under 4 hours during working hours
- Time to approval: Under 24 hours for standard PRs
- Time to merge: Same day as approval
If your p90 first-response time is over 8 hours, reviewers are likely context-switching too much or the review load isn't distributed evenly. If approval regularly takes multiple days, PRs might be too large, or the team lacks enough qualified reviewers for certain areas of the codebase.
Three Things You Can Do This Week
1. Start measuring. You can't manage this with gut feel. Pull your PR data and look at the actual distribution - not just the average. GitQuick does this automatically by analyzing your GitHub PR metadata and breaking latency down by stage and repository.
2. Set a first-response SLO. Even an informal one helps. "We aim to leave a first comment within 4 business hours" gives the team a shared expectation. It doesn't need to be a hard rule - just a visible target.
3. Watch the long tail. Sort your PRs by review time descending. The bottom 10% will tell you more about your process problems than any dashboard summary. Look for patterns: same reviewer? Same repo? Same time of week?
The Compounding Cost
Slow reviews don't just delay one PR. They cascade. A developer waiting on review either context-switches to something else (expensive) or starts stacking dependent PRs (risky). Multiply that across a team of 8-10 engineers and the drag on shipping velocity is significant - even if no single review feels "that slow."
The first step is seeing the real numbers. Most teams are surprised by what they find.