Your Bottleneck Is Code Review, and You Have Never Measured It

The complaint

A four-person team building a B2B scheduling product. Two senior engineers, one junior, one founder who still writes code on Fridays. In a retro someone said the thing everyone had been thinking: "we're slower than we were a year ago, and there are more of us now."

The theories were the usual ones. The codebase has grown. The junior needs more support. There are more meetings. Somebody suggested that the founder's Friday commits were creating more cleanup than they were worth, which did not go down well.

Nobody suggested code review, because code review was not a step anybody was waiting on. There was no queue, no reviewer assignment, no rule. You opened a pull request and somebody looked at it.

What the timestamps said

They pulled every merged pull request from the previous quarter and computed two numbers per item: time from first commit to pull request opened, and time from pull request opened to merged.

Median time writing the code: about a day and a half.

Median time from pull request open to merge: a little over three days.

Two thirds of the elapsed time on a typical change was spent with the work already finished, waiting for somebody to read it. On the slowest quartile the ratio was worse: five to six days of waiting against two days of writing.

The reframe

The team had not got slower at building things. They had got slower at looking at things other people built.

Which is a completely different problem with a completely different fix. Every theory in the retro was about the cost of producing code, and every one of them was addressing a third of the elapsed time. You could have made the writing twice as fast and cut the delivery time by twenty-five percent.

There is also a reason the problem grew as the team grew, and it is not the one people expect. More engineers means more pull requests per person to review, and reviewing is the task that always loses to your own work, because your own work is the thing you will be asked about.

Why review time hides

Review waiting is invisible to almost every metric a small team looks at, for three specific reasons.

Nobody is blocked. The author opened the pull request and moved on to the next thing. They are working. The reviewer is working. Ask anyone on the team whether they are blocked and the honest answer is no. The item is blocked; no person is.

It does not look like a stage. Teams that track stages track "in progress" and "done". A pull request awaiting review is in progress by every definition on the board, so the board shows a normal week.

It is nobody's task. Work that is assigned gets chased. Review is a diffuse obligation on everybody, which in practice means an obligation on whoever feels guiltiest.

This is the general shape of the thing: the slowest step in a system is usually the one that belongs to no one. See flow efficiency, which is the metric that makes waiting visible, and expect a number between five and twenty percent the first time you measure it.

What to change on Monday

One rule: review before you start. Before picking up a new item, check whether there is an open pull request you could read. Not a policy document, not a rota, not a service-level agreement on review time. One habit at the moment of choosing what to do next.

It works because it attaches the obligation to a moment that already exists. The decision "what do I do now" happens several times a day per person and is exactly when a queued review is cheapest to pick up. It also composes with a WIP limit: if you have hit your limit, reviewing is one of the two legitimate things to do. See WIP limits.

The team above cut median time-to-merge from three days to under one within a month, with no other change. Total delivery time dropped by roughly forty percent, which no amount of writing code faster would have achieved.

The metric to watch

Time from pull request opened to merged, as a median and an 85th percentile. It takes ten minutes to compute from your Git host's API and you can do it for the last quarter retroactively.

If that number is larger than your median time-to-write, you have found your bottleneck and everything else you were considering is a smaller lever. Then read cycle time vs lead time to see whether the same waiting is happening before work starts as well, which for most teams it is.