Hand-off Cadence Delay
The share of lead time created by how often a stage is worked rather than how long the work takes - about half the serving interval per hand-off - which is why faster stages often move lead time by nothing.
A team measures its delivery path and finds 11 hours of hands-on work inside a lead time of eight working days. The response is predictable and wrong: hire, automate, make each stage faster. The waiting is not caused by anyone being busy. It is caused by when each stage runs.
A stage worked once a week serves a queue that arrived uniformly over seven days, so the average item waits about half the interval — roughly 3.5 days — whether the stage takes two minutes or two hours. Hand-off cadence delay is that term, measured per stage and summed across the path, and in most organisations it is the majority of lead time.
Why it matters
It redirects improvement money. Four stages at daily, daily, twice-weekly and weekly cadence contribute about 0.5 + 0.5 + 1.75 + 3.5 days, or 6.25 of an 8-day lead time, with flow efficiency near 19%. Doubling throughput everywhere takes the 1.5 days of work to 0.75 and leaves 6.25 days untouched. Doubling cadence halves the wait.
It also explains why adding people to a waiting-dominated path makes it slower: more items arriving at the same fixed serving intervals means more items waiting, and more coordination at each gate.
Implementation patterns
- Instrument two timestamps per stage: when the item arrived in the queue and when a human or job first acted on it. The difference, not the duration of the work, is the number.
- Report cadence delay separately from work time, because a single lead-time figure lets everyone argue for their own remedy.
- Attack the largest interval first. One weekly stage usually contributes more than three daily ones combined.
- Convert cadence to continuous where the gate must stay: a standing rota that triages on arrival, or an automated check that runs per commit, removes the interval without removing the control.
- Count rework explicitly. An item that fails a gate and re-enters pays the full half-interval again, so a 20% rework rate at a weekly stage adds about another day to the mean and far more to the tail.
Industry example
The mechanism is standard queueing applied to delivery; Reinertsen's Principles of Product Development Flow (2009) is the reference treatment of batch size and queue cost, and the DORA research programme's finding that elite performers deploy on demand rather than on a schedule is the same effect seen from the outcome end. In practice, teams that measure arrival-to-action time for four weeks usually find two of four stages are removable rather than optimisable, which is the cheapest available outcome.
Failure scenarios
- A weekly architecture board that becomes the single largest term in the lead time of every cross-team change, while every member reports a light workload.
- Release trains on offset weeks across three teams, adding 5 to 10 working days per hand-off that appears in nobody's estimate.
- Cadence improvements applied to a saturated stage. Above roughly 80% utilisation, queueing time dominates and meeting more often simply queues the same backlog more visibly.
- A daily stand-up treated as a cadence fix when the gate it feeds still meets weekly.
Trade-offs
Shortening a cadence is paid in attention: a board that meets daily costs its members more calendar fragmentation than one that meets weekly, and the decisions get less preparation. Removing a gate is paid in risk, and the honest version of that argument names the failure the gate has actually caught in the last year — often zero.
| Lever | Gains | Pays |
|---|---|---|
| Double the cadence | Halves that stage's wait | Fragmented calendars and thinner preparation |
| Delete the stage | Removes the wait entirely | The risk the gate was covering |
| Add capacity | Helps only above roughly 80% utilisation | Headcount, with no effect on cadence |
When not to use it
When a stage is genuinely saturated — the queue grows week on week, or half of what arrives is deferred — cadence arithmetic understates the wait badly, because queueing time rises steeply near capacity. Measure utilisation first. And in a single-team path with no hand-offs, this metric has no subject: there the lead time is work time plus review latency, and the useful measure is batch size.
Interview question
Q: Leadership has funded a £600k pipeline programme to cut an 11-day lead time where hands-on work is four hours. How would you check whether the programme can succeed before it starts?
What a strong answer covers: separate cadence delay from work time per stage; compute each stage's serving interval and utilisation; show how much of the 11 days the pipeline could possibly touch; name the two stages whose intervals dominate; and propose the cheaper intervention — cadence or removal — with the risk each gate was covering stated explicitly.
Quick check
Quiz: A stage meets weekly and has spare capacity. Roughly how much lead time does it add and what fixes it? About 3.5 days, half the interval; meeting more often or removing the gate, not working faster.
Flashcard: Why does doubling every stage's throughput often leave lead time unchanged? Because the time is spent waiting for stages to run, not waiting for them to finish — cadence, not capacity, is the constraint below about 80% utilisation.