Lead time for changes

Elite engineering teams ship code to production in under an hour. Most squads take days or weeks, and they often have no clear picture of where that time is going. Lead time for changes measures how long it takes from the moment a developer commits code to the moment that code is running in production. It is one of the four DORA metrics and one of the clearest signals of how well your delivery pipeline actually works. This page covers the definition, how to measure it, published benchmarks, a real example, and how to reduce it.

Key takeaways

• Lead time for changes measures the elapsed time from a code commit to a successful production deployment, giving engineering leaders a direct view into how fast their delivery pipeline moves. Teams with short lead times can respond to customer needs and production issues faster, which directly affects product competitiveness and user satisfaction.
• The measurement starts at the first commit associated with a change and ends when that change is deployed to production. According to the DORA State of DevOps 2023 report, elite teams achieve lead times of less than one hour, while low performers measure their lead time in weeks or months.
• The most common mistake teams make is confusing lead time for changes with PR cycle time. PR cycle time only covers the review and merge window. Lead time for changes is broader: it includes everything from the first commit through CI/CD pipelines, approval gates, and the final deployment step.
• DevStats tracks lead time for changes automatically by connecting to your Git provider and deployment tooling, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

Lead time for changes definition

Lead time for changes is the total time it takes for a code change to move from the first commit to running in production. It captures the full delivery pipeline, from the moment a player writes code to the moment users can access it.

Technically, it is calculated as: Lead time for changes = deployment timestamp minus first commit timestamp, averaged across all changes in a given period. This metric sits at the intersection of your PR cycle time, CI/CD pipeline duration, and deployment process. When lead time is long, it signals friction somewhere in that chain. Shortening it means faster feedback loops, faster bug fixes, and faster feature delivery, all of which translate directly into business agility.

Why lead time for changes matters for engineering teams

Without visibility into lead time for changes, engineering leaders are flying blind on delivery speed. Squads feel busy, PRs get merged, and standups sound productive, but the actual time from code to customer stays invisible. That invisibility makes it impossible to identify whether delays are coming from slow reviews, flaky pipelines, manual approval gates, or deployment bottlenecks. Missed sprint commitments and frustrated stakeholders are often symptoms of a lead time problem no one has measured yet.

Lead time for changes connects directly to the KPIs engineering leaders are held accountable for: on-time delivery, release predictability, and the team's ability to respond to production incidents. If your squad takes two weeks to get a fix into production, your mean time to recovery suffers alongside your lead time. Teams that track this metric can have specific, evidence-based conversations with product and business stakeholders instead of vague reassurances. You can see the full picture of your DORA metrics in DevStats, including how lead time trends over time and where it compares to high-performing teams.

Lead time for changes is one of the four core DORA metrics and maps to the Efficiency dimension of the SPACE framework. Measuring it is the starting point. The engineering leader is the one who decides what to do with the data.

How to measure lead time for changes

To calculate lead time for changes, you need two timestamps for every change: the first commit timestamp and the production deployment timestamp. The delta between those two points, averaged across all changes deployed in a period, is your lead time. You will need data from your Git provider (GitHub, GitLab, Bitbucket) and your deployment tooling (GitHub Actions, CircleCI, ArgoCD, or similar). Some teams also pull from their issue tracker to capture time spent in planning before the first commit, though the DORA definition starts at commit.

The benchmarks below are drawn from the DORA State of DevOps 2023 report. DevStats surfaces these comparisons automatically through its benchmarks feature, so you can see where your squad stands without building a spreadsheet.

Lead time for changes in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that her squad was consistently missing sprint commitments even though PR merge rates looked healthy. She pulled lead time data and found that the average time from first commit to production was 11 days. The code review window accounted for about two days. The remaining nine days were split between a manual QA sign-off step and a deployment queue that only ran twice a week. The data did not tell her what to do, but it made the bottleneck visible in a way that gut feel never had.

She made two changes: she moved QA sign-off to an automated smoke test suite that ran on every PR, and she shifted to daily deployments. Four sprints later, lead time had dropped to just under three days. She tracked deployment frequency alongside lead time to confirm the pipeline was actually shipping more often and not just appearing to. The squad reported less end-of-sprint pressure because changes were flowing continuously instead of stacking up before a release window.

How to improve lead time for changes

1. Reduce PR size. Large pull requests sit in review longer and create merge conflicts that delay deployment. Set a team norm for PR size, something like 200 lines of changed code as a soft ceiling, and watch your PR cycle time as a leading indicator. Smaller PRs move faster through review and are easier to deploy safely.
2. Automate your deployment pipeline. Every manual step in your CI/CD process adds latency. Identify the handoffs that require a human to click a button and ask whether a passing test suite could replace that gate. Automated deployments are the single biggest structural driver of elite lead times.
3. Increase deployment frequency. If your squad deploys once a week, changes stack up and lead time grows with the queue. Moving to daily or on-demand deployments reduces the batch size and shortens the wait. Use DevStats's deploy tracking to monitor whether frequency is actually increasing after process changes.
4. Audit your code review process. Review wait time is often the largest single contributor to lead time. If PRs sit unreviewed for more than four hours on average, look at reviewer assignment, squad availability patterns, and whether review is treated as a first-class responsibility alongside writing code.
5. Measure issue cycle time alongside lead time. If you want to extend your view upstream, issue cycle time captures how long work takes from ticket creation to completion. Long issue cycle times often predict long lead times before the first commit is even written.

Lead time for changes vs. cycle time

Lead time for changes and cycle time are often used interchangeably, but they measure different windows of your delivery process.

Use lead time for changes when you want a full-pipeline view from code to customer. Use PR cycle time when you want to isolate the review and merge portion of the process.