Time to first review: the wait that dominates cycle time

DevPerform defines time to first review as the median hours from PR open to the first non-author engagement — a review event or a reviewer comment. Counting comments, not just formal approvals, matters: on GitLab and Bitbucket a lot of review happens in comment threads, and an approval-only definition under-reports it.

This is pure waiting. Nothing is being built, tested, or reviewed while a PR sits in the pickup phase — it’s just latency, and latency compounds across every change a team ships.

In most teams, pickup time is a bigger share of total cycle time than the review itself. A change that takes twenty minutes to review can wait a day and a half to be picked up. Because the wait sits at the front of the pipeline, it also delays everything downstream and encourages developers to start yet another branch while they wait — which grows work-in-progress and makes the next PR slower too. Attack pickup time and the whole cycle-time distribution usually shifts left.

LinearB’s 2026 benchmarks put elite pickup time at <1h, good at 1–4h, fair at 5–16h, and “needs focus” at >16h. In other words, the best teams get eyes on a pull request within an hour. That’s an aggressive target, but it’s achievable for co-located or timezone-overlapping teams with the right habits — and even halving a multi-day pickup time is a large, visible win.

• Set a review SLA. Agree as a team on a target — e.g. “first review within 2 hours during working hours” — and make it visible. A named expectation is most of the battle.
• Cap work-in-progress. A WIP limit forces people to finish reviews before opening new work, which is the single most reliable way to shrink pickup time.
• Fix notifications. Route review requests to a channel the team actually watches. DevPerform can send opt-in, self-only Slack notifications when your review is requested — a nudge, never a manager report.
• Keep PRs small. Reviewers pick up a 40-line change far faster than a 900-line one. Small PRs shorten both the wait and the review (see PR size).
• Watch unreviewed merges. The flip side of slow pickup is skipping review entirely; LinearB’s guidance is that fewer than 5% of PRs should merge without review (hotfix and automation exceptions aside).

DevPerform surfaces pickup time as its own phase of cycle time, trended over weeks and reported at the team level so it drives a working agreement rather than a personal scorecard. Benchmark any public repo to see its pickup time scored against these bands.