A team's lead time from commit to production is three days. Which component is usually the largest, and how is it found?

The usual largest component

Waiting, not working. Broken down, a typical three-day lead time is mostly:

• Review latency — the change sits waiting for someone to look at it. Frequently the single largest component and invisible inside the aggregate, because nobody measures it separately.
• Queue time for a shared environment or a scarce pipeline resource.
• Batching, where changes wait for a release window rather than deploying when ready.
• Approval wait, where the approval is granted in two minutes after waiting a day.

Actual build and test time is usually a minority of the total, which is why teams optimising build speed find lead time barely moves.

How to find it

Instrument the transitions, not just the endpoints: commit to review requested, review requested to first review, first review to approval, approval to merge, merge to deploy start, deploy start to production.

Each transition is either work or wait, and the waits are where the time is. That breakdown usually takes a day to build and immediately identifies the constraint — which is rarely where the team assumed.

What to do about each

• Review latency: set a response-time expectation, reduce change size (a large change gets fewer comments than a small one, which is a signal about attention rather than quality), and automate everything mechanical so reviewers spend attention on what matters.
• Environment contention: ephemeral per-branch environments, created and destroyed automatically.
• Batching: deploy on merge rather than on a schedule, with progressive delivery providing the safety that the batch was providing.
• Approval wait: reserve human approval for a defined significant minority and automate the rest.

Why it matters beyond speed

Lead time is the feedback loop. A team that learns whether a change worked three days later learns slowly, and the cost compounds: more changes in flight, larger batches, harder attribution when something breaks.

Reducing lead time improves change failure rate, which is counter-intuitive and robustly observed — small changes are individually attributable and individually reversible.