Your Code Reviews Are Slower Than You Think

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.

For definitions of each latency stage — time to first review, approval waits, approval-to-merge, and median vs P90 — start with Pull Request Review Latency: How to Measure It and Find Bottlenecks.

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 to Compare Against

There is no universal "good" latency number that fits every org. What matters is measuring the same stages consistently, separating median from P90, and watching whether your own baseline is drifting.

If your p90 first-response time is much larger than your median, reviewers are likely context-switching too much or the review load isn't distributed evenly. If approval regularly takes multiple days while first review is fast, 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. GitHub PR analytics in GitQuick do this 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.