Engineering & Reliability

Lead Time for Changes LTFC

CTO VP Engineering Director Engineering

Lead Time for Changes measures the elapsed time from when a code commit is made to when that change is running in production. It is one of the four DORA metrics and reflects the efficiency of the entire software delivery pipeline from development through testing, review, CI/CD, and deployment. Shorter lead times enable faster feedback loops and more responsive product development.

Lead time for changes should be measured from first commit in a branch to production deployment, capturing the full cycle including code review, automated testing, and any approval gates.

Formula
Average Time from Code Commit to Production Deployment
Where It Lives
  • LinearBDORA metrics including lead time by team and repository
  • JellyfishEngineering productivity metrics including lead time
  • GitHub InsightsPR cycle time as a component of lead time
  • CircleCIPipeline build and deploy duration analytics
What Drives It
  • CI/CD pipeline speed and parallelization
  • Code review turnaround time and batch size
  • Automated test suite execution time
  • Manual approval gates in the deployment process
  • Feature branch duration (how long branches live before merging)
Benchmark

DORA elite teams achieve lead time under 1 hour; high performers under 1 day; medium performers 1 week–1 month; low performers above 1 month.

Common Questions About Lead Time for Changes

What is the biggest contributor to long lead time in most engineering teams?
Code review wait time is typically the largest component of lead time in most organizations, often exceeding CI build time and deployment time combined. Reducing PR size (smaller, more focused changes) reduces review time. Establishing team norms around review turnaround (e.g., first review within 4 hours) and using async review practices reduces the time code spends waiting for human review before it can progress.
How does trunk-based development reduce lead time?
Trunk-based development (TBD) requires developers to integrate code into the main branch at least once per day, keeping branches extremely short-lived. This eliminates the lead time caused by long-running feature branches that accumulate days or weeks of divergence before merging. TBD, combined with feature flags, allows code to be integrated frequently without exposing incomplete features to users.
How do manual approval gates affect lead time?
Manual approval gates (change advisory boards, manual QA sign-off, deployment approvals) add hours or days to lead time for every change. For low-risk, frequently deployed services, these gates often add more lead time cost than their risk-reduction value justifies. Teams should audit which manual gates still apply to automated, tested deployments and replace them with automated quality gates where the risk profile allows.
Should lead time targets vary by change type?
Yes. A critical security patch should have a fast-path lead time of under 1 hour with expedited review and approval. A routine feature addition may have a standard lead time target of 1–2 days. An architectural change touching many services may warrant longer lead time with more thorough review. Defining deployment risk tiers with corresponding lead time targets and review requirements allows teams to move fast on routine changes while being appropriately careful on high-risk ones.

Related Metrics

Deployment Frequency | Deployment Frequency CFR | Change Failure Rate MTTR | Mean Time to Recovery Technical Debt Ratio | Technical Debt Ratio
free, one business day

Want to know what is holding your Lead Time for Changes back?

Give us your website and we will send back the specific pages hurting your Lead Time for Changes, in the order worth fixing. You will have it within one business day, free, with no obligation.

No newsletter. We reply once, from a person.