Your team's pull requests wait two days for a first review. How do you diagnose and fix that as a lead?

## Frame it correctly Review latency is a queueing problem: arrival rate, service time, and the number of servers. Every effective intervention changes one of those three, and most failed interventions are exhortations that change none of them. Framing it this way also keeps the conversation off individual diligence, which is almost never the binding constraint. ## Measure before acting Impressions are unreliable — the loudest complaint usually comes from the author of the largest pull requests. Pull the data instead. Pull request and review events carry timestamps, so you can compute **time from ready-for-review to first review** (not to merge, which mixes in the author's own response time), **size in changed lines**, and the **distribution of review load across people**. Look at the shape, not the mean. Common findings: the median is fine and the tail is terrible, which points at specific repositories or specific change types; or two senior engineers are named on eighty per cent of reviews, which is a routing problem wearing a latency costume; or the wait is concentrated in one time zone pairing, which is a staffing question. Exclude draft time and count from the moment the pull request became reviewable, otherwise you measure how long people leave work in progress. ## Reduce service time: size The strongest lever is almost always **pull request size**. A 100-line change gets reviewed in a gap between meetings; a 1,500-line change needs a booked afternoon, which is why it waits until Thursday. Halving typical size does more for latency than any reminder ever will. Getting there is engineering work, not policy: decomposition habits, feature flags so partial work can land safely, and separating mechanical changes from behavioural ones so the big diffs are the boring ones. This is where a lead's leverage actually is. ## Reduce queueing: routing A review request broadcast to a large team belongs to nobody. Two mechanisms fix that. **Ownership-based routing** ensures the people who must look are requested automatically, and **team code review assignment** turns a team request into named individuals using round robin or load balance, with absent members excluded. The pull request then shows a human who is on the hook rather than a team handle everyone assumes someone else will answer. Watch the ownership rules for a specific failure: if one shared directory routes every change to one small team, you have created a bottleneck by configuration, and no amount of goodwill will clear it. ## Change the norm Most teams have never actually agreed **when** review happens. Making it explicit — a stated turnaround for first response, and treating review as scheduled work rather than the thing done after everything else — converts it from interrupt-driven to planned. A first response that says "I can look properly this afternoon" is worth far more than silence, because it lets the author decide whether to wait or find someone else. Time zones deserve deliberate handling rather than hope: if the reviewer pool is nine hours away, a request sent at 5 p.m. costs a day by arithmetic, and the fix is coverage in the author's window, not urgency. ## Automate the cheap findings If reviewers are spending their pass on formatting, import order and lint rules, they are doing work a check should do — and worse, the expensive findings get less attention because the cheap ones filled the review. Move all of it into automated checks so human review is spent on design, correctness, security and the interfaces that will be costly to change. ## Beware the metric Once time-to-first-review becomes a target, it will improve and quality will not. Approving without reading is the fastest possible review. Keep the number as a diagnostic you look at with the team, pair it with signals that move the other way when review degrades — escaped defects, rollback rate, revert frequency — and never put it on an individual's performance page. ## What good looks like Small changes arriving steadily, routed to named people who have agreed when they respond, with mechanical feedback automated away so the human pass is about the parts that matter. Latency falls out of that as a consequence. Chasing the number directly, by reminders and dashboards, produces faster approvals and worse code — which is the failure mode a principal-level interview is checking that you can see coming.