Lead Time for Changes: Measuring Your Development Pipeline Efficiency

Defining Lead Time for Changes

Lead time for changes, in the DORA context, is specifically the time from when a code change is committed to the version control system to when it is successfully deployed to production. This is narrower than the broader concept of lead time used in lean manufacturing, which would include the time from when work is requested to when it is delivered.

This metric captures the efficiency of your development pipeline: code review, automated testing, build processes, staging validation, and deployment. Each stage contributes to the total lead time, and understanding where time is spent allows you to target improvements effectively.

It is worth distinguishing lead time for changes from cycle time, which typically measures from when work begins (e.g., a ticket moves to 'in progress') to when it is complete. Lead time for changes focuses specifically on the post-commit pipeline, making it a more precise measure of your CI/CD effectiveness.

How to Measure Lead Time for Changes

To measure lead time accurately, you need to capture two timestamps: when the first commit for a change is made, and when that change is deployed to production. The difference between these timestamps is your lead time. Most source control and CI/CD tools can provide this data through their APIs or built-in analytics.

Calculate lead time as a median rather than a mean, as the distribution is typically skewed by occasional outliers. Track the median alongside the 90th percentile to understand both typical and worst-case scenarios. A large gap between median and 90th percentile indicates inconsistency in your pipeline that warrants investigation.

• Measure from first commit to production deployment, not from ticket creation
• Use median values rather than averages for a more representative picture
• Track the 90th percentile to identify worst-case pipeline delays
• Break lead time into stages (review, build, test, deploy) for targeted improvement
• Automate data collection through CI/CD pipeline instrumentation

Lead Time Benchmarks

Elite performers achieve lead times of less than one hour, meaning code goes from commit to production within the same working session. High performers have lead times between one day and one week. Medium performers fall between one week and one month, whilst low performers may have lead times exceeding six months.

These benchmarks highlight the enormous variance across the industry. A team with six-month lead times is operating fundamentally differently from one with sub-hour lead times. The former likely uses large batch releases with extensive manual testing, whilst the latter has a fully automated pipeline with comprehensive test coverage.

When setting targets, focus on halving your current lead time as an initial goal. If your median lead time is two weeks, aim for one week. Each halving requires progressively more sophisticated automation and process improvements, creating a natural roadmap for your engineering investments.

Strategies to Reduce Lead Time

The most common bottleneck in lead time is code review wait time. Developers often submit pull requests and then wait hours or days for review. Establish clear review SLAs (for example, initial review within four hours), encourage smaller pull requests that are quicker to review, and consider pair programming as an alternative to asynchronous review.

Automated testing is the second major lever. Manual testing gates can add days to your lead time. Invest in a comprehensive automated test suite that runs quickly and reliably. Flaky tests erode trust and lead to manual verification, so prioritise test reliability. Consider parallelising test execution and using test impact analysis to run only relevant tests.

• Set and enforce code review SLAs to reduce review queue wait times
• Keep pull requests small (under 200 lines of changed code) for faster reviews
• Automate all testing stages and eliminate manual QA gates where possible
• Parallelise CI/CD pipeline stages to reduce total build and test time
• Implement automated deployment with rollback capabilities for confidence

Lead Time and Team Health

Long lead times have a measurable impact on developer satisfaction and team morale. When developers must wait days or weeks to see their work reach users, they lose the sense of progress and impact that drives engagement. Short lead times create a tight feedback loop that keeps developers motivated and connected to user outcomes.

Lead time also affects your team's ability to respond to incidents and customer feedback. A team with sub-hour lead times can ship a fix within minutes of identifying a problem. A team with week-long lead times faces difficult choices between emergency process bypasses and leaving issues unresolved for extended periods.

As an engineering manager, monitor lead time trends as a proxy for pipeline health and team satisfaction. Increasing lead times often signal growing technical debt, process bloat, or tooling issues that need attention before they compound into larger problems.

Key Takeaways

• Lead time for changes measures the time from commit to production deployment, revealing pipeline efficiency
• Elite performers achieve sub-hour lead times through comprehensive automation and streamlined processes
• Code review wait time and manual testing are the most common bottlenecks in lead time
• Use median and 90th percentile measurements rather than averages for accurate assessment
• Short lead times improve developer satisfaction, incident response, and time to market