Queues, not speeds

The arithmetic that decides whether faster writing helps

Delivery is a pipeline of stages, and the throughput of a pipeline is set by its slowest stage. That is not a metaphor. It has arithmetic, the arithmetic is simple, and it predicts what most teams have observed since they adopted these tools: more activity, the same delivery.

Start with Little’s Law, which holds for any stable queue regardless of what it contains:

L = λ × W

Work in progress equals arrival rate times time in system. Rearranged, the version you will use daily is W = L / λ.

A team merges 20 pull requests a week and has 25 open at any moment. Average time from open to merged is 25 / 20 = 1.25 weeks. Nobody needs a dashboard to compute that, and it is usually the first honest number a team has ever had about itself.

What happens when you double the input

The writing stage gets faster. Pull requests arrive at 40 a week instead of 20. Review capacity is unchanged, because reviewing is done by the same humans with the same days.

If review can service 20 a week, the queue does not settle at a longer wait. It grows without bound: 20 extra items each week, for ever, until something breaks: usually the review, which gets shallower until the arrival rate and the service rate match again. That is not a metaphor either. That is what a shallow review is: the system finding its equilibrium by lowering the service quality.

Utilisation is the number that surprises people

Even below saturation, the wait time is not linear. For a single-server queue with ordinary variability in arrival and service times, average waiting time scales roughly with ρ / (1 − ρ), where ρ is utilisation. In units of one service time, that gives:

• 50% utilised: about 1 service time of waiting
• 70%: about 2.3
• 80%: about 4
• 90%: about 9
• 95%: about 19

A reviewer who is 80% booked and becomes 90% booked has not got 12% busier. The queue in front of them has roughly doubled. This is why a team can add a modest amount of work and see review latency triple, and why everyone experiences it as a sudden collapse rather than a gradual slide.

It is also why slack is not waste. A reviewer with free hours is what keeps the pipeline’s wait time small, and that free time will always look like the obvious thing to fill.

Find your constraint before you optimise anything

Take the last thirty changes that reached production and record the timestamps at each stage. Most issue trackers and git hosts hold all of this already.

1. Request understood → specification agreed
2. Specification → first commit
3. First commit → pull request opened
4. Pull request opened → first substantive review comment
5. First review → approved
6. Approved → merged
7. Merged → deployed
8. Deployed → confirmed working

Take the median of each. In most teams that have measured this, stages 4 and 7 dominate and stage 2 (the actual writing) is a small fraction of the total. That is the whole argument of this module in one table of your own numbers, and it is much more persuasive to a sceptical manager than anything in this course.

The Theory of Constraints move

Eliyahu Goldratt’s sequence is worth memorising because it prevents the most common mistake:

1. Identify the constraint.
2. Exploit it: make sure the constraint never idles. If review is the constraint, a reviewer should never be waiting for context, a rebase, or a green build.
3. Subordinate everything else to it. Other stages run at the constraint’s pace, on purpose.
4. Elevate it: add capacity. More reviewers, or better tooling for reviewers, or smaller changes so each review is cheaper.
5. Repeat, because the constraint will move.

Step 3 is the one people refuse. Deliberately not writing more code, because review cannot absorb it, feels like laziness and shows up badly in any activity metric. It is nonetheless the correct action, and refusing it is how a growing pile gets built.

The counterintuitive prescription

If review is your constraint, the correct response to a faster writing stage is to lower work in progress, not raise it.

Concretely: cap open pull requests per person at two. When you hit the cap, you do not open a third: you go and review, or you go and help get one of yours merged. This looks like reducing output and it increases delivered throughput, because it moves effort to the constraint and shortens every queue in the system.

One more, cheaper still: shrink the unit of work. A queue’s wait time depends on service time, and a 200-line change is reviewed properly in twenty minutes while a 2,000-line change is reviewed properly in nobody’s afternoon. Halving diff size does more for lead time than any tool you can buy, and it is free.