Pickup time is the metric your dashboard is hiding

Open your delivery dashboard and look for the interval between a change being marked ready and the first human action on it. Most teams cannot find it. It exists inside cycle time, averaged together with review duration and approval-to-merge, and by the time those three are summed into one bar the only number left is going up and nobody knows which part is responsible.

That missing interval is pickup time, and on agentic pull requests LinearB’s 2026 benchmarks put it at roughly 5.3 times longer than on unassisted ones. It is the single most informative number in delivery right now, and it is informative for a reason that has almost nothing to do with queueing.

My position: pickup time is not a process metric. It measures whether people are willing to look, and willingness is the thing that broke.

Where the number goes missing

Three habits hide it, and all three are defensible in isolation.

It gets summed. Cycle time is a useful executive number precisely because it is one number. It is also a sum of intervals with completely different causes, and summing removes the only information that would tell you what to do.

It gets averaged. Pickup time has a long tail by nature. Most changes get looked at quickly by someone who was already in that part of the system, and a minority sit for days. A mean pulls those together into a figure that describes no actual change. The ninetieth percentile is where the missed deadlines are.

It gets measured per repository. A single figure across a repository mixes a two-line configuration fix with a nine-hundred-line generated refactor. Those are different phenomena and averaging them destroys the finding.

cycle time = 4d 6h
commit to ready        3h
ready to first look    3d 1h   <— everything is here
first look to approve  17h
approve to merge       2h

It measures willingness, not capacity

This is the part that changes what you do about it.

Review duration measures how long the work takes once someone has committed to doing it. Pickup time measures the gap before that commitment, and gaps before commitment are behavioural. Nobody is busy for three days continuously. What happens in that interval is that several people look at the change in a list, form an instant judgement about what opening it will cost them, and do something else.

So ask what makes an agentic change expensive to open. It is large, because generation is cheap. It is unfamiliar, because nobody typed it. Its description was frequently written by the thing that wrote the code, so it describes what changed rather than why. And the reviewer knows that if they approve it and something goes wrong, “the agent wrote it” will not be an acceptable answer from them.

That combination produces avoidance, and avoidance is what a 5.3 times increase looks like from the outside. It is a dread number.

Two other findings support that reading. Stack Overflow’s 2025 survey has developer trust in AI output down from around 40 percent to 29 percent, so people expect to find problems. And zero-review merges are up over 31 percent, which is what avoidance eventually resolves into when the deadline arrives. First people wait, then they wave it through.

Measuring it so it does not lie

Four rules, and they matter more than the tooling you use.

What actually moves it

Since the cause is the expected cost of opening the change, every effective intervention reduces that cost.

The named-assignment point is worth pulling out because it is free. A change assigned to a team is a change assigned to nobody, and diffusion of responsibility does the rest. Pick a person, and be willing for that person to say no.

Where this breaks down

High pickup time is sometimes correct. A low priority change waiting three days while people work on something that matters more is a functioning prioritisation system, not a failure. Chasing the metric down uniformly means treating every change as equally urgent, which is how you get reviewers spending their best hours on dependency bumps.

It is easy to game and the gaming is invisible. Publish it and the interval improves, partly through better behaviour and partly through fast meaningless approvals and delayed opening of pull requests. This is the strongest objection to putting it on a dashboard at all. The defence is to watch it beside the zero-review rate and the rework rate, because the gaming moves those in the wrong direction.

Capping change size is not free. Splitting a generated refactor into six reviewable pieces takes real work from someone, and the pieces may not be independently meaningful. There are legitimate large changes and a hard cap will produce artificial splitting that makes review worse rather than better.

The benchmark is not your number. A 5.3 times multiple came from a particular population of organisations and tooling. Your ratio could be two or twelve, and importing the figure into a leadership conversation without measuring your own invites the reasonable objection that you are quoting someone else’s problem.

And pickup time may not be your constraint. For plenty of teams the calendar is eaten by environment contention, a security queue or a release window that only opens fortnightly. Decompose first. If the ready-to-first-look row is not the dominant one, everything here is a distraction.

The takeaway

The interval you cannot see on your dashboard is where delivery time has moved, and it behaves differently from every other interval because it measures a decision rather than a duration. People are not slow to review these changes. They are slow to start them, and they are slow to start them because opening a large unfamiliar diff that nobody can explain is genuinely unpleasant.

Interventions that raise the cost of not looking fail. Interventions that lower the cost of looking work.

If you take one thing into next week: decompose cycle time into its four intervals for the last quarter and report the ninetieth percentile of each. In most teams one row dominates, and almost nobody guesses which one correctly.