Change lead time

Most engineering leaders know their team is slow, but they cannot pinpoint where time is actually going. Change lead time is the metric that answers that question: it measures how long it takes for a code commit to reach production. When this number is high, your delivery pipeline has a bottleneck, and your squad is absorbing the cost in the form of delayed releases, frustrated stakeholders, and compounding work-in-progress. This page covers the definition of change lead time, how to measure it against published benchmarks, how to improve it, and how DevStats surfaces it automatically.

Key takeaways

• Change lead time measures the total elapsed time from when a player first commits code to when that change is live in production. It is one of the four DORA metrics and a direct signal of how efficiently your delivery pipeline is operating. Teams with shorter change lead times ship value to customers faster and recover from incidents more quickly.
• Change lead time is calculated as: time of production deployment minus time of first commit, averaged across all changes in a given period. According to the 2023 DORA State of DevOps Report, elite teams achieve change lead times of less than one hour, while low performers take more than six months.
• The most common mistake teams make is treating change lead time as a coding speed metric. In practice, the majority of elapsed time accumulates in code review queues, staging environments, manual approval gates, and deployment pipelines, not in the time a player spends writing code. Optimizing the wrong stage produces no measurable improvement.
• DevStats tracks change lead time automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. You can see your squad's numbers broken down by stage, compared to peers, and trended over time. Start a free trial to see your numbers in under two minutes.

Change lead time definition

Change lead time is the total time it takes for a code change to travel from a developer's first commit to running in production. It is one of the four core DORA metrics used to measure software delivery performance, alongside deployment frequency, change failure rate, and mean time to restore.

Technically, change lead time spans from the timestamp of the first commit on a branch to the timestamp of the production deployment that includes that commit. It is typically expressed as a median or 75th-percentile value across all deployments in a rolling window. Teams that track it with precision pull data from their Git provider (for commit timestamps), their CI/CD pipeline (for build and test durations), and their deployment tooling (for release timestamps). Shorter change lead times mean your squad can respond to customer feedback, fix bugs, and ship features without waiting days for a release window. That responsiveness is a direct competitive advantage. DevStats connects these data sources through its DORA metrics feature, giving you a unified view of where time is accumulating across the delivery pipeline.

Why change lead time matters for engineering teams

When squads do not track change lead time, slow delivery becomes invisible. Work piles up in review queues, staging environments sit idle waiting for approvals, and deployment windows become bottlenecks that no one owns. The result is missed sprint commitments, growing work-in-progress, and players who spend more time waiting than building. By the time a VP of Engineering notices the problem, it has usually been compounding for weeks.

Change lead time connects directly to the KPIs most engineering leaders are accountable for: on-time delivery, release cadence, and the ability to respond to production incidents quickly. A team with a change lead time measured in days cannot hotfix a critical bug without a painful manual exception process. A team measured in hours can. That difference shows up in customer satisfaction scores, SLA compliance, and the engineering team's own morale. Tracking delivery speed at the process level gives you the evidence to have those conversations with product and leadership without guessing.

Change lead time is one of the four DORA metrics, which are grounded in years of research correlating delivery performance with organizational outcomes. Measuring it is the first step. The engineering leader is the one who decides where to intervene once the data makes the bottleneck visible.

How to measure change lead time

To calculate change lead time, subtract the timestamp of the first commit on a branch from the timestamp of the production deployment that ships that branch. Average this across all deployments in your measurement window, and report the median alongside the 75th percentile to avoid outliers skewing the picture. You need three data sources to do this accurately: your Git provider (GitHub, GitLab, Bitbucket) for commit timestamps, your CI/CD pipeline for build and test durations, and your deployment tooling or release management system for production timestamps. If your team also tracks issues, connecting your issue tracker adds context about how long work sat in backlog before coding even started, which is a related but distinct measurement. DevStats's benchmarks feature lets you compare your change lead time against teams of similar size and stack, so you know whether your numbers are competitive or lagging.

The benchmarks below are drawn from the 2023 DORA State of DevOps Report.

Change lead time in practice: a real example

A VP of Engineering at a 45-person SaaS company noticed that their squad's change lead time had crept from three days to eleven days over a single quarter. The commits were going out at a normal pace, but PRs were sitting in review for an average of four days before anyone picked them up. The VP pulled the data, saw that two senior players were the only ones approving infrastructure-related PRs, and recognized the bottleneck immediately: a de facto review monopoly that no one had explicitly created.

She restructured the review rotation, expanded approval rights to three additional engineers who had the relevant context, and set a squad norm of a 24-hour first-review SLA. She measured PR cycle time weekly for the following month. Change lead time dropped back to four days within six weeks. The intervention was simple once the data made the problem visible. The tool did not fix anything. She did.

How to improve change lead time

1. Break work into smaller pull requests. Large PRs take longer to review, longer to test, and longer to deploy safely. Set a squad norm for PR size (under 400 lines of changed code is a reasonable starting point) and track whether average PR size correlates with review wait time. Smaller batches move faster through every stage of the pipeline.
2. Set and enforce a first-review SLA. The biggest time sink in most pipelines is not CI or deployment; it is PRs waiting for a first reviewer. Agree on a response window (24 hours is standard for high-performing teams) and make it visible in your code review data. If the SLA is being missed consistently, the problem is usually capacity allocation, not willingness.
3. Automate your deployment pipeline end to end. Manual deployment steps are the most predictable source of delay. Audit your pipeline for any step that requires a human to click a button, approve a ticket, or run a script. Each one is a candidate for automation. Track deployment frequency alongside change lead time: teams that deploy more often tend to have shorter lead times because they are forced to keep the pipeline clean.
4. Reduce work-in-progress limits per player. When a player has four branches open simultaneously, none of them move quickly. Limiting concurrent work-in-progress forces prioritization and keeps code moving through review and into production rather than aging on a shelf. Monitor throughput to confirm that reducing WIP increases actual delivery rate rather than just reducing activity.
5. Audit your staging and approval gates. If your squad has a multi-stage staging environment with manual sign-off at each gate, measure how long changes actually sit at each stage. Often, 80% of the total lead time is concentrated in one or two gates. Eliminating or parallelizing those gates has a disproportionate impact on overall change lead time.

Change lead time vs. cycle time

Change lead time and cycle time are related but measure different spans of the delivery process, and conflating them leads to incomplete diagnosis.

Use change lead time to assess your end-to-end delivery capability, and use cycle time to diagnose what is happening within the development and review stages specifically.