Three architects review designs for 26 teams. Requests arrive at about 9 a week; a review takes 4 focused hours and each architect has roughly 10 reviewable hours a week. The backlog has grown from 4 items to 22 over a quarter and the group is asking for a fourth architect. Work out whether a fourth architect fixes it and what number should be published instead.
Show the full answer Hide the answer
The assumptions, stated
Arrival rate 9 reviews a week. Service capacity: 3 architects x 10 reviewable hours = 30 hours a week, at 4 hours a review, so 7.5 reviews a week. Both numbers are measurable from the tracker and the calendar, which is the only reason this estimate is worth doing.
The arithmetic
Utilisation is 9 / 7.5 = 1.2. Above 1, the queue has no steady state: it grows by 1.5 items a week forever. Over a 13-week quarter that is 19.5 items, which is why the backlog went from 4 to 22. The backlog is not a sign of disorganisation; it is the arithmetic of an over-subscribed queue.
A fourth architect brings capacity to 10 reviews a week, so utilisation drops to 0.9. That is stable, and it is still bad. For a single-server queue the expected number waiting goes as rho^2 / (1 - rho):
| Utilisation | Items waiting | Mean wait at 9/week |
|---|---|---|
| 0.50 | 0.5 | ~0.4 days |
| 0.80 | 3.2 | ~2.5 days |
| 0.90 | 8.1 | ~6 days |
| 0.95 | 18.1 | ~14 days |
Between 80% and 95% utilisation the wait grows by 5x while capacity changes by 16%. A fourth architect buys a six-day mean wait. A fifth buys utilisation of 0.72 and a two-day wait - and is a worse use of a headcount than almost anything else the group could do.
The number to publish instead
Share of production changes that passed through the queue, and intake-to-decision time in days. The second number is the one that falsifies the first. The moment decision time exceeds the time a team needs to ship the change anyway - typically a sprint - teams stop queueing and the coverage number becomes fiction while looking healthy. Twenty-two waiting items at 9 arrivals a week is already a two-and-a-half-week wait, so this has probably started.
What to change, in order
- Cut the arrival rate, not the service time. Publish criteria that route a change past review entirely: it uses an approved pattern, its blast radius is one service, it is reversible by one team. Removing 5 of 9 weekly arrivals takes utilisation to 0.53 with three architects.
- Cap work in progress at about 2x the server count - six items for three architects. Beyond that, items are not in progress, they are in storage, and the holder of each one is paying context-switch cost.
- Measure the routed-around share - production changes with no recorded review - and treat a rise as the real failure signal rather than the backlog length.
When this is the wrong answer
When utilisation is genuinely below 0.7 and people still wait. Then the delay is batching, not load: a weekly review board makes the mean wait half a week no matter how idle the reviewers are. The fix is to cut the batch interval or allow asynchronous decisions, and adding capacity does nothing. The five-minute diagnostic is to compare arrival rate against service capacity before anyone draws a cause-and-effect diagram.