SEO from $300/mo AI-powered, human-verified No agency markup Transparent platform included
/// 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)
Causal Analysis: Decomposing lead time into specific phases (coding, review wait, CI build, deploy) reveals which phase is the primary bottleneck and where investment in process or tooling will causally reduce overall lead time.
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 Mistake
Measuring only CI/CD pipeline time and excluding code review wait time, which is often the largest component of total lead time.

How Different Roles Think About This Metric

Each function reads LTFC through a different lens and takes different actions when it changes.

CTO
The CTO uses lead time as a strategic indicator of engineering agility and uses it to benchmark the team's ability to respond quickly to market opportunities.
VP Engineering
VP Engineering tracks lead time by team to identify which squads have bottlenecks in their delivery pipeline and to prioritize tooling investments.
Director Engineering
Directors analyze lead time decomposition data to identify specific phase bottlenecks and implement process changes that reduce overall cycle time.

Common Questions About Lead Time for Changes

Click any question to expand the answer.

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

Metrics that are commonly analyzed alongside LTFC.

Deployment Frequency | Deployment Frequency CFR | Change Failure Rate MTTR | Mean Time to Recovery Technical Debt Ratio | Technical Debt Ratio

Role Guides That Include This Metric

See how each role uses LTFC in context with the full set of metrics they own.

CTO Guide → VP Engineering Guide → Director Engineering Guide →
/// get started

See What’s Actually Moving Your LTFC

askotter connects your data sources and applies causal analysis to tell you exactly why your metrics are changing, not just that they changed.

Book a Conversation →