There's a category of work that doesn't appear on any dashboard but dominates engineering productivity: the unreviewed PR.
It's been open for three days. The author has moved on to other work. The reviewer hasn't gotten to it. It just... sits there.
This seems like a minor inefficiency. It's actually a major velocity killer—and the damage extends far beyond the delayed PR itself.
The True Cost of Waiting PRs
Direct Cost: Delayed Delivery
The obvious impact. If a PR waits 3 days for review, the feature arrives 3 days late. Multiply by every PR in the queue.
But this is the smallest cost.
Indirect Cost: Context Loss
When the author moves on, they lose context on their own PR. Three days later, when review comments arrive, they have to re-load the work into their head:
- "What was I trying to do here?"
- "Why did I make that decision?"
- "What was the state of the codebase?"
Research suggests context reload takes 15-30 minutes for complex work. Every time.
Indirect Cost: Review Quality
Reviewers reviewing stale PRs are also missing context:
- The codebase may have changed
- Related discussions may have happened in other channels
- The reviewer may not remember the requirements discussion
Stale reviews are worse reviews.
Indirect Cost: Merge Conflicts
The longer a PR sits, the more likely it is to conflict with other work. Resolving conflicts takes time and introduces risk.
A PR that would have merged cleanly on Monday might require significant rework by Friday.
Indirect Cost: Cascading Delays
Other work may depend on the waiting PR:
- Another developer needs the API it introduces
- A feature can't ship until the underlying change lands
- Technical decisions are blocked waiting for this approach to be validated
One stalled PR can block multiple people.
Detecting the Problem
Velocinator surfaces unreviewed PRs automatically:
The "Aging PRs" View
PRs sorted by how long they've been waiting for review:
- Green: < 4 hours (healthy)
- Yellow: 4-24 hours (getting stale)
- Red: > 24 hours (blocking velocity)
This simple view often reveals surprising backlogs.
Review Pickup Time Metric
Track the median time from "PR opened" to "first review comment":
- Elite: < 4 hours
- Good: 4-12 hours
- Needs improvement: 12-24 hours
- Critical: > 24 hours
If your pickup time is high, you have a systemic problem.
Per-Reviewer Analytics
Some reviewers consistently pick up PRs quickly. Others consistently let them sit.
This isn't about blame—it's about understanding. Maybe the slow reviewer is:
- Overloaded with review requests
- Not seeing notifications
- Deprioritizing reviews in favor of their own work
- Unclear that review speed matters
The data enables the conversation.
The Goalkeeper Pattern
Many high-performing teams use a "goalkeeper" or "on-call shield" to protect focus:
How It Works
- One team member per sprint is designated as the goalkeeper
- They handle all interruptions: support questions, bug triage, urgent reviews
- Everyone else gets protected maker time
- The role rotates so no one burns out
Why It Works
- Most interruptions don't require the specific person being interrupted—anyone on the team could handle them
- Concentrating interruptions on one person means one person has a bad week (fragmented), but everyone else has a great week (focused)
- The goalkeeper can batch work: handle all reviews in morning and afternoon blocks, not randomly throughout the day
Measuring Impact
Teams implementing the goalkeeper pattern typically see:
- 40-60% reduction in review pickup time
- Increased focus for non-goalkeeper team members
- No increase in overall review time (just better distributed)
Review Time Agreements
If the goalkeeper pattern doesn't fit your team, try explicit SLAs:
The 4-Hour SLA
"All PRs receive first review within 4 business hours."
This is achievable if:
- PRs are reasonably sized (< 400 lines)
- Reviewers check for review requests at natural break points
- The team is appropriately sized for the work volume
Making It Visible
Post the current review queue where everyone can see it:
- Slack channel with daily "PRs waiting" summary
- Dashboard showing queue depth
- Standup check: "Any PRs blocked on review?"
When delays are visible, people address them.
Escalation Path
If a PR has been waiting 24+ hours:
- Author pings reviewer directly
- If no response in 4 hours, escalate to team lead
- Team lead either reviews or reassigns
Clear escalation prevents PRs from languishing indefinitely.
Reducing Review Burden
Sometimes PRs wait because reviewers are overwhelmed. Reduce the load:
Smaller PRs
The #1 lever. A 100-line PR takes 10 minutes to review. A 1000-line PR takes hours (or gets skimmed).
Set team norms: PRs over 400 lines require justification.
Clear PR Descriptions
Help reviewers understand quickly:
- What does this change?
- Why is this approach used?
- What should reviewers focus on?
Good descriptions cut review time in half.
Automated Checks
Every check that can be automated is a check humans don't have to do:
- Linters for style
- Type checking
- Unit tests
- Security scanning
If CI is green, reviewers can focus on logic and design, not formatting.
Review Rotation
Instead of "whoever knows this code" reviewing, establish rotation:
- Everyone on the team is capable of reviewing everything
- This spreads knowledge and load
- Prevents bottlenecks when specific people are busy
The Metrics Loop
Track and improve continuously:
Weekly Check
- How many PRs are currently waiting > 24 hours?
- What was median pickup time this week?
- Which reviewers are below/above target?
Monthly Trend
- Is pickup time improving or degrading?
- Are certain times of week/month worse? (Sprint ends, releases)
- What's the correlation between review wait time and cycle time?
Quarterly Review
- Are our SLAs appropriate?
- Do we need to adjust team capacity?
- Should we implement new patterns (goalkeeper, review blocks)?
The Cultural Shift
Reducing unreviewed PR wait time requires a cultural shift:
Old mindset: "My job is to write code. Reviews are a favor to teammates."
New mindset: "Unblocking teammates is as important as my own work. A teammate waiting on my review is blocked—that's my problem too."
When everyone on the team internalizes that reviews are work (not interruptions), pickup time drops dramatically.
Your PR queue is a leading indicator of velocity. An empty queue—PRs reviewed promptly and merged quickly—is a team operating at full speed. A growing queue is velocity slowly strangling.
Check your queue. What's it telling you?
