Approval Wait

A three-day lead time from commit to production is usually not three days of work. Decomposed, it is mostly waiting: review latency, environment contention, batching for a release window, and approval wait where the approval itself takes two minutes after sitting for a day.

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

Why it matters

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 it improves change failure rate, which is counter-intuitive and robustly observed: small changes are individually attributable and individually reversible.

Implementation patterns

• Instrument the transitions, not 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. A day to build, and it usually identifies a constraint that is not where the team assumed.
• Set a response-time expectation for review, since it is frequently the largest wait and is entirely a matter of convention.
• Reduce change size, which reduces review time superlinearly — a large change gets fewer comments than a small one, which is a signal about attention rather than about quality.
• Automate everything mechanical so reviewers spend attention on approach and missed cases rather than on formatting.
• Replace shared environments with ephemeral per-branch ones, removing contention.
• Deploy on merge rather than on a schedule, with progressive delivery providing the safety that batching was providing.
• Reserve human approval for a defined significant minority.

Industry example

Product teams such as Linear's and Postman's that ship continuously treat review latency as a first-class operational metric rather than as a cultural matter, and the intervention that moves it most is usually a convention about response time rather than any tooling change.

Failure scenarios

• Only endpoint-to-endpoint lead time measured, so the constraint is invisible.
• Build speed optimised while the dominant wait is human.
• Review treated as a cultural issue rather than as a measurable queue.
• Large changes, which lengthen review and reduce its effectiveness simultaneously.
• Batching retained after progressive delivery is available, keeping a wait that no longer buys anything.

Trade-offs

Pressing on review latency risks producing faster, shallower review, which is a genuine loss — a review that happens quickly and finds nothing is not an improvement.

The mitigation is the change-size lever rather than the speed lever: small changes are reviewed both faster and better, so reducing size improves both variables at once. Pushing on speed alone trades one for the other.

Interview question

"Your lead time is three days. Break it into components for me, tell me which you expect to be largest, and what you would do about it this week."