Software Delivery in a Minute
Lead Time for Changes
Lead time from commit to production: definition choices, uses, and common misreads.
In one sentence
Lead time for changes measures how long it takes a committed change to reach a production-like environment.
Why it matters
Long lead times hide batching, review queues, and fragile release paths. Short lead times can also mean weak review if other controls are missing.
How it works
- Pick start and end events consistently (e.g., commit merged to main → successful production deploy containing that commit).
- Measure the distribution, not only the mean—outliers matter.
- Segment by service or team when systems differ.
- Investigate process delays separately from build/test duration.
Example
If commit A merges at 10:00 and the deploy that includes A finishes at 16:00 the same day, that change’s lead time is six hours under a merge-to-deploy definition. A commit waiting days for review never enters that clock until it merges—so the definition must be stated.
What this proves
Lead time proves elapsed time between your chosen start and end events for the changes you measured.
What this does not prove
It does not prove that faster changes are safer, that engineers are working harder, or that product discovery time is short.
Sources
Last reviewed 2026-09-06. Title for citation: Software Delivery in a Minute: Lead Time for Changes.