120 engineers wait on a 45-minute pipeline, merging about 6 times a week each. Estimate the annual cost of that wait, and say what the number does and does not justify.

The assumptions, stated

• 120 engineers × 6 merges per week × 45 engineer-minutes of wait = 32,400 minutes per week = 540 hours.
• 46 working weeks → roughly 24,800 hours per year.
• Fully loaded cost of an engineer-hour: take $100 as an order of magnitude for a mixed team in 2026 terms.
• Naive answer: about $2.5M a year.

The correction that matters

That number is wrong, and the direction it is wrong in is the interesting part. Engineers do not sit watching the pipeline; they switch to something else. So the raw wait is not lost time. What is lost is the context-switch cost on both ends, and it is not proportional to the wait — it is roughly a step function above the threshold where waiting stops being tolerable.

A defensible correction: assume 30–50% of the wait converts to real loss for waits long enough to force a switch, and near zero for waits short enough to hold attention. That puts the annual figure at roughly \(0.7M–\)1.3M, with the dominant error being the conversion factor, not the arithmetic.

There is a second, larger cost the arithmetic does not reach: long pipelines change behaviour. Engineers batch changes to amortise the wait, batches are harder to review and riskier to deploy, and change failure rate rises. That effect shows up in incident cost, not in salary cost, and it is usually the bigger number.

What the estimate rules in and out

• Rules in: a dedicated effort of one or two engineers for a quarter. At even the conservative end, a two-engineer quarter costs well under the annual loss, so the payback is inside a year.
• Rules in: buying faster build machines. Hardware that costs \(60k a year against a \)700k loss needs only a 10% improvement to pay for itself. This is the cheapest lever and it is routinely skipped because the budget line is visible and the loss is not.
• Rules out: a year-long platform rewrite justified on this number alone. The estimate's error bar is wider than the difference between competing approaches at that size.
• Rules out: treating the 45 minutes as the target. Find the distribution first. If the p50 is 12 minutes and the p95 is 45, the fix is the tail and the mean was never the problem.

When this is the wrong answer

When the pipeline is reliable and the team is not constrained by it — a team shipping at the cadence the business wants, with no queueing and no batching behaviour — the calculated loss is an accounting artefact. Cost-of-wait arguments are only real when someone is actually waiting. The diagnostic is whether merge frequency rises when the pipeline gets faster; if it does not, the constraint was somewhere else.