A change to a customer-facing service must pass four stages before it reaches production. Security triage is worked once a day. The release train runs once a day. A change-approval board sits twice a week. A data-model review meets weekly. Hands-on work across the four stages totals about 11 hours and none of the four is short of capacity. Roughly what is the lead time and which lever cuts it more - doubling each stage's throughput or doubling how often each stage runs?

The assumptions, stated

Work arrives at each stage at roughly uniform times through the week. Each stage is worked on a fixed cadence rather than continuously. None of the stages is capacity-bound, which the question gives you — so the wait is created by the gap between servings, not by a backlog. For a stage served every T, uniform arrivals wait on average about T/2.

The arithmetic

• Security triage, served daily: about 0.5 working days of wait.
• Release train, daily: about 0.5 days.
• Change-approval board, twice weekly: the gap averages about 3.5 calendar days, so about 1.75 days of wait.
• Data-model review, weekly: a 7-day gap, so about 3.5 days of wait.

Cadence wait totals roughly 6.25 working days. The 11 hours of actual work is about 1.5 days. Lead time lands near 8 working days, with a plausible range of 6 to 12 depending on where in the week the change starts and whether a stage sends it back.

Flow efficiency is 1.5 of 8, or roughly 19%. Four fifths of the elapsed time is a change sitting still while nobody is short of capacity.

Which assumption dominates the error

The weekly review. It contributes 3.5 of the 6.25 days of waiting — more than the other three stages combined — so the estimate is far more sensitive to that one cadence than to the 11-hour work figure. If the review actually meets weekly but only looks at items submitted two days before, add another 2 days. Measure that one gap before you measure anything else.

What the number rules in and out

Doubling throughput at every stage changes almost nothing here, because a stage that is not capacity-bound has no queue to clear — it would cut the 1.5 days of work to 0.75 and leave the 6.25 days of waiting untouched, taking lead time from about 8 days to about 7.

Doubling cadence halves the wait: the weekly review meeting twice a week takes 3.5 days to 1.75, and the board sitting daily takes 1.75 to 0.5. That alone gets lead time to roughly 5 days from 8, and it costs calendar time from the same people rather than new headcount. The decision rule: prefer cadence over capacity while utilisation at a stage is low, and reverse that above roughly 80% utilisation, where cadence changes make the queue worse and you must add capacity or delete the stage.

One failure mode this arithmetic hides: a stage that sends work back. A change that fails triage and re-enters the queue pays the full T/2 again, so a 20% rework rate at the weekly review adds roughly another day to the mean and far more to the tail.

When this is the wrong answer

If a stage is genuinely saturated — the board rejects or defers half of what arrives, or the queue grows week on week — this arithmetic understates badly, because queueing time rises steeply as utilisation approaches capacity and the T/2 term stops dominating. The honest version is to instrument arrival time and decision time per stage for four weeks. Teams that measure this in production usually find two of the four stages are removable rather than optimisable, and that is the cheapest outcome available.