Lead Time for Changes

Lead time for changes is one of the four DORA metrics, measuring how long it takes from when a developer starts on a piece of work to when that work is live in production and available to users. It covers the entire journey: writing the code, getting it reviewed, running automated checks, going through any approval steps, and finally deploying it. Lead time for changes is the most complete measure of how quickly an organization can turn an idea into a real product change.

The metric was defined by the DORA research team as part of their framework for measuring software delivery performance. It reflects an organization's ability to deliver value quickly while keeping quality high. Short lead times mean the team can experiment fast, fix problems quickly, and respond to new business needs without long delays. Long lead times mean every change carries more risk (because many changes pile up together before deploying), slower customer feedback, and less organizational flexibility.

Lead time for changes is often confused with cycle time, but they measure different things. Cycle time ends when code is merged; lead time for changes continues through the deployment process until the code is actually running in production. For teams that deploy automatically right after merging, the difference is just minutes. For teams with manual release steps, approval processes, or staged deployments, the gap between cycle time and lead time can be days or weeks -- and that gap is worth understanding.

Why Lead Time for Changes Matters

Lead time for changes matters because it determines how quickly an organization can respond to anything: customer feedback, competitive pressure, security vulnerabilities, or market opportunities. A team with lead times measured in hours can ship a critical fix the same day it is identified. A team with lead times measured in weeks may batch that fix with dozens of other changes, increasing risk and delaying the resolution.

For engineering leaders, lead time is a proxy for organizational agility. Short lead times correlate with smaller, more frequent deployments, which in turn reduce the risk of each individual deployment. The DORA research consistently shows that organizations with shorter lead times also have lower change failure rates -- the counterintuitive finding that shipping faster actually improves quality because each deployment is smaller and more reviewable.

How to Measure Lead Time for Changes

Lead time for changes is measured from the timestamp of the first commit on a change to the timestamp when that change is verified running in production. For teams using continuous deployment, this may be captured automatically through deployment event tracking. For teams with staged releases, measurement requires tracking which commits are included in each production deployment.

Teams typically report median lead time rather than average, because a few long-running changes can skew the average significantly. The DORA framework classifies lead time performance as: Elite (under one hour), High (between one day and one week), Medium (between one month and six months), and Low (more than six months). Most teams find their lead time is dominated by either the review process or the deployment pipeline, and measurement helps identify which component to optimize first.

Common Mistakes When Tracking Lead Time

The most common mistake is measuring only the deployment pipeline portion and ignoring the development process that precedes it. True lead time for changes starts at the first commit, not at the point where code is merged or a release is triggered. Organizations that measure only deployment speed miss the often-larger bottleneck of code review and approval processes.

Another error is treating lead time as purely an engineering problem. Long lead times are often caused by organizational factors: change advisory board schedules, compliance approval processes, manual QA gates, or infrequent release windows. Reducing lead time in these environments requires process changes at the organizational level, not just technical improvements to the CI/CD pipeline.

Related Metrics

Lead time for changes is one of four DORA metrics and works in concert with the other three. Deployment frequency measures how often code reaches production. Change failure rate measures the reliability of those deployments. Mean time to recovery measures how quickly teams respond when deployments cause problems. Together, the four metrics balance speed (lead time, deployment frequency) against stability (change failure rate, MTTR).

Cycle time is the closest related metric, measuring the development process portion of lead time. The difference between cycle time and lead time reveals how much of the delivery timeline is consumed by the deployment pipeline versus the development process. Developer velocity and engineering team health are broader concepts that incorporate lead time alongside other dimensions of team performance.

Key Takeaways

• •Lead time for changes measures from first commit to production deployment -- the full delivery pipeline.
• •It is one of four DORA metrics and captures organizational agility in responding to change.
• •Elite teams achieve lead times under one hour; high performers range from one day to one week.
• •Lead time differs from cycle time by including the deployment pipeline after code is merged.
• •Long lead times are often caused by organizational process (approval gates, release schedules), not just technical infrastructure.

How CodeVitals Helps

CodeVitals tracks how long work takes from start to merge across your GitHub repositories, giving you a clear picture of where time is going in your delivery process. The health score combines this alongside other signals to give you a single, plain-language verdict on how quickly your team is delivering. When lead times increase, CodeVitals shows you where the slowdown is -- whether reviews are the bottleneck or something further downstream -- and gives specific coaching recommendations on what to fix.

Related Reading