The PR lag: where software delivery quietly loses days.

The delay is rational locally - and expensive as a system

Developers are usually doing exactly what the delivery system asks of them: completing a story, resolving an issue and protecting enough uninterrupted time to solve the next problem. A review request arrives while that work is in progress. Stopping immediately would destroy focus, so the pull request waits. Google's published engineering guidance recognises the same trade-off: review responses should be fast, but engineers should wait for a sensible break point rather than interrupt focused coding.

Now add a large or complex change, a small pool of qualified reviewers, a failed pipeline check or a comment that needs the author. The author has already moved to another scope. The state changes, but attention does not move with it. Each decision makes sense in isolation; together they create a queue that nobody owns.

This is why PR lag is not evidence that developers are slow. It is evidence that the delivery system has allowed waiting work to become less visible than active work.

PR lag is more than time to first review

Pickup lag is the wait from opening the PR until meaningful review begins. Response lag is the time between a reviewer leaving feedback and the author responding. Check lag accumulates while a failed or pending pipeline is not acted upon. Approval lag is the wait between approval and merge. Handoff lag is the time between the code becoming ready and QA being able to plan, receive and test it.

A single cycle-time number hides these different causes. A stage timeline exposes them. That distinction matters because the remedy for reviewer pickup is different from the remedy for a forgotten failed check, a large change or an unclear QA handoff.

The second-task trap

The most common pattern is simple. A developer opens a PR, asks for review and moves to the next story. Later, the PR is approved, receives comments or fails a pipeline check. Unless that change reaches the developer where they are already working, it competes with the new task for attention and can remain stale for hours or days.

The organisation then carries two pieces of work: the visible task being coded and the nearly-finished task waiting behind it. Work in progress rises without appearing to rise. Delivery looks busy while completed value moves slowly.

The knock-on effect reaches QA and product

QA does not receive a smooth, predictable stream of work. It receives uncertainty followed by a batch. Testers chase updates because the issue tracker says one thing while the pull request, approvals and checks say another. A task that could have arrived earlier appears near the end of the sprint, forcing QA to compress testing or pushing the item into the next delivery window.

Product managers see the same uncertainty as forecast risk. A story can look nearly complete while most of its remaining elapsed time is still hidden in pickup, review, check and handoff queues. The sprint commitment is not missed because coding took too long; it is missed because nobody could see when the work would actually become testable.

The leadership consequence is not only slower delivery. It is weaker coordination between engineering, QA and product - more status chasing, more rescheduling and less confidence in the plan.

Measure the queue, not the person

Start with the distribution of time to first review, comment-to-response time, time spent with failed checks, approval-to-merge time and total PR age. Segment by team, repository, PR size and work type. Look at the median and the tail rather than relying on one average, because the small number of long-stale items often creates the operational pain.

Add reviewer concentration and queue depth. If a small number of people carry most reviews, the constraint is capacity and knowledge distribution, not motivation. The purpose of measurement is to identify the stage and condition that creates waiting - never to rank individual developers.

Working agreements turn visibility into behaviour

A working agreement is a team-owned expectation for how work should move. It might define when review should be picked up, when a failed check should be acted on, how large a PR should become before it is split, or how a handoff to QA is signalled. The exact threshold belongs to the team and its context; it is not a universal benchmark.

Adoption comes from making the agreement useful rather than punitive. The team chooses it, warnings appear before the agreement is missed, escalation goes to a focused team channel, and retrospectives examine the repeated constraint rather than naming a culprit. Over time the agreement becomes part of the operating rhythm because it prevents forgotten work and protects everyone from end-of-sprint surprises.

Put the signal where the next action happens

A dashboard can explain yesterday. Reducing PR lag requires a signal at the moment attention should return to the waiting change. Pacia surfaces PR activity and pickup-agreement warnings in VS Code, including a direct action to open the PR. Focused Microsoft Teams or Slack channels can notify the relevant group when an agreement is approaching or has been missed.

This respects focused work while shortening the gap between state change and response. The developer does not need to remember to poll several systems; the next useful action arrives in the workflow the team already uses.

Join the story timeline to the development timeline

The issue-tracker story, pull request, review state, checks and QA readiness should not be separate narratives. Pacia links the planning timeline to the development timeline so delivery leaders can see where an item really is, while QA can see work likely to reach them and the confidence behind that forecast.

That changes the conversation from “Is it nearly done?” to “What state is it in, what is it waiting for, and when is it likely to become testable?” QA can plan capacity earlier, product can see delivery risk sooner, and engineering can address the actual constraint before the sprint ends.

A practical CTO playbook

First, establish the baseline by stage and make stale work visible. Second, identify whether the dominant constraint is pickup, PR size, reviewer concentration, failed checks or the QA handoff. Third, let teams define one or two working agreements that address that constraint. Fourth, deliver warnings in the tools teams already inhabit. Finally, review the flow across engineering, QA and product together, not as three separate performance conversations.

The goal is not instant interruption or faster typing. It is less unmanaged waiting, smaller queues and a delivery forecast based on the real state of the work.

Evidence and further reading

Google Engineering Practices, “Speed of Code Reviews,” explains why team velocity depends on prompt review responses while also protecting developers from interruption during focused work: https://google.github.io/eng-practices/review/reviewer/speed.html

Bacchelli and Bird's Microsoft Research study, “Expectations, Outcomes, and Challenges of Modern Code Review,” reports observations, interviews and survey evidence on the benefits and challenges of tool-based code review: https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/

Czerwonka and Greiler, Microsoft Research, describe code review as often the longest part of code integration and argue for more precise review workflows: https://www.microsoft.com/en-us/research/publication/code-reviews-do-not-find-bugs-how-the-current-code-review-best-practice-slows-us-down/