Lead time for changes measures the amount of time it takes a code commit to go from being written to running successfully in production. It's one of the four DORA metrics used to gauge software delivery performance, and it specifically covers the technical path a change takes, through code review, automated testing, staging, and deployment, rather than the broader product journey from idea to release. A short lead time means a change an engineer finishes today can realistically be in front of users today or tomorrow. A long lead time, weeks or months, means there's a lot of friction sitting between a finished piece of code and a working feature.
The reason lead time for changes exists as a distinct, tracked metric is that engineering organizations needed a precise way to answer a specific question: once code is written, how long does the delivery pipeline itself take to get it live? For years, teams talked about delivery speed in vague terms, "releases feel slow," without a shared, measurable definition of what "slow" actually meant or where the slowness was coming from. Lead time for changes gives that vague feeling a number, measured in hours or days, and because it starts specifically at the commit rather than at the initial idea or ticket creation, it isolates the technical delivery pipeline from the separate, and very real, problem of how long ideas sit around before anyone starts building them.
What distinguishes lead time for changes from the more general term "lead time" used in product and project management is precisely that starting point. General lead time, as used in Lean and Kanban contexts, often starts when a customer request or ticket first enters the system. Lead time for changes, as defined within the DORA framework, starts at the code commit. This is a deliberate scoping choice: it isolates the engineering delivery pipeline, code review, testing, deployment, from upstream product and prioritization decisions, so a team can talk specifically about how efficient its technical path to production is, without conflating that with a separate conversation about how well the organization prioritizes and queues work before an engineer ever starts writing code.
By 2026, lead time for changes is one of the most commonly tracked metrics in engineering organizations of any real size, built into DevOps analytics platforms, CI/CD tooling, and internal engineering dashboards as a near-default measure. Its prominence comes largely from its inclusion in the DORA research as one of the strongest predictors of high organizational performance, and from the fact that, unlike some engineering metrics, it maps directly onto concrete, fixable parts of a delivery pipeline: slow code review, flaky or slow test suites, manual deployment steps, and infrequent release windows.
This page covers exactly what counts as the start and end of lead time for changes, how it relates to and differs from cycle time and general lead time, what specifically drives it up or down inside a real pipeline, where it's genuinely useful and where teams misapply it, and how to actually shorten it without compromising the quality of what ships. The durable idea underneath the metric is that the technical distance between a finished change and a working feature in front of users is a design choice, not a fixed cost, and a team that understands what's adding distance in its own pipeline can deliberately shrink it.
Getting precise about what starts and stops the clock matters more with lead time for changes than with almost any other engineering metric, because teams that define it loosely end up with numbers that aren't comparable even within their own history. The starting point is generally agreed to be the code commit, specifically the point at which a change is committed to the codebase, typically to a feature branch or directly to the trunk depending on the team's branching strategy. This is a deliberately narrow starting point. It doesn't include the time an engineer spent thinking about the problem, researching an approach, or writing code locally before that first commit, because that upstream work is much harder to measure consistently and varies enormously based on the nature of the task.
The end point is the change running successfully in production. This sounds simple but has a few subtleties worth being clear about. "Running successfully" usually means the deployment has gone out and the system is healthy, not just that a deploy button was clicked. Some teams draw the end point at the moment the deployment pipeline reports success; others draw it slightly later, once monitoring confirms the new version is stable and not throwing elevated errors. Teams using feature flags add another wrinkle, because code can be deployed to production while still being turned off for users, which raises a genuine question of whether lead time should be measured to the deploy event or to the flag being flipped on. Most organizations measure to the deploy event, treating flag activation as a separate, deliberate product decision rather than part of the technical delivery pipeline being measured.
Multiple commits complicate a single lead time number, and most real features involve several. The common approach is to calculate lead time per commit, then look at the aggregate, usually the median, across a period of time, rather than trying to define a single lead time for an entire multi-commit feature. This keeps the metric consistent and comparable across different kinds of work, whether a change is a single-commit bug fix or part of a larger feature built up over a dozen commits merged over several days.
Consistency in how a team defines these boundaries matters more than which specific definition a team lands on. Two teams can reasonably draw the line in slightly different places and both have a useful, valid metric, as long as each team applies its own definition consistently over time. What breaks the metric's usefulness is a team that changes its definition every few months, or where different engineers on the same team have different informal understandings of when the clock starts and stops.
Lead time for changes and cycle time overlap enough to confuse people regularly, and it's worth being precise about the relationship. Cycle time, as commonly used, often starts when work begins on a ticket, which might be before the first commit, during initial design or investigation, and ends when the work is considered done, which teams define in various ways. Lead time for changes, within the DORA framework specifically, starts at the commit and ends at successful production deployment. In practice, for many teams, the two numbers end up close to each other because most of the elapsed time between starting a ticket and finishing it is spent in the coding-to-deployment path anyway, but they are not strictly the same measurement, and a team that conflates them can end up comparing numbers that aren't actually apples to apples.
Deployment frequency, another of the four DORA metrics, is closely related but answers a different question. Deployment frequency asks how often an organization ships to production at all, while lead time for changes asks how long any individual change takes to get there once committed. The two tend to move together in practice: organizations with a short lead time for changes usually also have high deployment frequency, because the same underlying capabilities, small batch sizes, strong automated testing, low-friction deployment, that shrink lead time also make frequent deployment practical and safe. But they're not mechanically identical. A team could theoretically have a short lead time for individual changes while still batching those changes up and only releasing weekly, which would give a shorter lead time than deployment frequency alone would suggest.
Understanding this relationship matters because it points toward where a team should look when trying to improve either metric. If lead time for changes is long, the friction is almost always somewhere in the technical pipeline itself: slow code review, a flaky or slow test suite, manual deployment steps, or infrequent release windows imposed by process rather than technical necessity. If deployment frequency is low despite a reasonably short lead time for changes, the issue is more likely organizational or risk-related, a policy of batching releases, a fear of deploying too often, or a manual approval gate that isn't really about the technical readiness of any individual change.
Change failure rate, the third closely related DORA metric, acts as the check against lead time for changes being improved dishonestly. It's entirely possible to shrink lead time by skipping code review or cutting corners on testing, and if that's happening, change failure rate will climb as a direct consequence. A team should never look at an improving lead time for changes in isolation; it needs to be read alongside change failure rate to confirm that the speed gain is coming from genuine efficiency rather than reduced quality control.
Code review wait time is, in most organizations that measure this carefully, the single largest contributor to a long lead time for changes, and it's frequently invisible until someone actually breaks the metric down by stage. A change that took an engineer three hours to write and test locally can sit for two full days waiting for a reviewer with bandwidth to look at it, and that waiting time counts fully against lead time even though nobody involved is doing anything wrong in isolation. Teams with a culture of treating review as a background task, done whenever someone finds a spare moment, tend to have dramatically longer lead times than teams that treat review as a prioritized, time-boxed responsibility.
Test suite speed and reliability is the second major factor, and it compounds in an ugly way. A slow test suite adds direct waiting time to every single change moving through the pipeline. A flaky test suite, one that fails intermittently for reasons unrelated to the actual change being tested, adds even more time indirectly, because engineers end up re-running builds, investigating false failures, and sometimes manually overriding failed checks, all of which eats into lead time and, worse, erodes trust in the automated testing process itself. Organizations with fast, reliable test suites report from that automation almost immediately, which keeps a change moving instead of sitting in a queue waiting for a rerun.
Deployment mechanics contribute a layer of friction that's often organizational rather than purely technical. Manual deployment steps, required sign-offs from people outside the immediate team, scheduled release windows that only happen once a week or once a sprint, and multi-stage approval processes all add elapsed time to a change that might otherwise be ready to ship within minutes of passing its tests. Teams that have invested in continuous deployment, where a change that passes automated checks deploys automatically without waiting for a human to manually trigger and babysit the release, tend to see this stage shrink from days to minutes.
Batch size ties all of this together and amplifies whatever friction already exists in the other stages. A large, complex change takes longer to review carefully, is more likely to fail tests or trigger a back-and-forth with a reviewer, and is riskier to deploy, which often triggers extra caution and manual scrutiny that a smaller change wouldn't need. Teams that get disciplined about breaking work into small, independently deployable commits see improvements in lead time that come not from any single fix but from every stage of the pipeline handling smaller, simpler units of change more quickly and with less friction at each step.
Lead time for changes fits well as a focused diagnostic for an engineering organization's technical delivery pipeline specifically, separate from broader product and prioritization questions. It answers a narrow, useful question well: once we've decided to build something and an engineer has written the code, how efficiently does our pipeline get that code safely in front of users? That narrow scope is a genuine strength, because it lets a team improve its technical delivery process without getting tangled up in the separate, harder conversation about how well the organization prioritizes and plans work in the first place.
It fits poorly when used to compare organizations or teams without accounting for very real contextual differences. A team shipping a mobile app that goes through an app store review process will structurally have a longer lead time for changes than a team shipping a web service that deploys directly, and that difference reflects the platform's constraints, not a gap in either team's engineering discipline. Similarly, a team working in a heavily regulated industry, where deployments to certain systems legally require documented approval steps, will show a longer lead time than a team with no such requirement, and treating that difference as a performance gap misunderstands the constraint entirely.
Teams misuse the metric when they optimize it in isolation, without watching change failure rate at the same time. It's straightforward to shrink lead time for changes by reducing code review to a rubber stamp or by disabling parts of an automated test suite that feel like they're slowing things down. Both moves will show up immediately as an improved lead time number and, usually within a short window, a rising change failure rate, because the quality checks that were cut were doing real work. Reading lead time for changes without also watching the metrics meant to catch this kind of corner-cutting is a reliable way to end up with numbers that look great and a production environment that's quietly become less stable.
It fits best as one part of a broader conversation about delivery health, alongside deployment frequency, change failure rate, and time to restore service, and ideally alongside some honest qualitative sense from the engineers actually doing the work about where the real friction is. Used in isolation as a single number to chase, it's easy to game. Used as one lens among several, with a team genuinely curious about where its own pipeline creates unnecessary friction, it becomes a durable, useful tool for improving how software actually gets shipped.
The most reliable starting point for shortening lead time for changes is breaking the total time down by stage, exactly as with cycle time, because the aggregate number alone doesn't tell a team where to focus. A team might discover its lead time is four days, and assume coding itself is slow, only to find through actual measurement that three and a half of those four days are spent waiting for code review, with the actual coding, testing, and deployment stages accounting for a small fraction of the total elapsed time. That breakdown changes where a team invests its improvement effort entirely.
If code review turns out to be the bottleneck, the fix usually isn't asking engineers to review faster in a rushed, careless way, it's changing the team's norms and workload distribution around review. That might mean setting an expectation that pull requests get an initial response within a few hours rather than whenever someone has spare time, spreading review responsibility more evenly across the team so it doesn't bottleneck on one or two senior engineers, or adopting smaller pull requests specifically because smaller changes are faster and less draining to review carefully.
If the test suite or deployment mechanics are the bottleneck, the fix is usually a genuine investment in automation: parallelizing test suites to run faster, fixing flaky tests that erode trust and cause wasted reruns, and building out continuous deployment so a change that passes its checks can go live without needing a person to manually shepherd it through several approval steps. This kind of investment often competes for the same engineering time that would otherwise go toward product features, which is exactly why it tends to get deprioritized in busy periods, even though the long-term payoff in reduced friction is usually significant.
Reducing batch size is, again, close to a universal lever, because smaller, more frequent commits move through every stage of the pipeline faster and with less friction than large, infrequent ones. This shift often requires practice and a change in how engineers and product managers think about breaking work down, since decomposing a feature into small, independently deployable pieces is a skill that takes deliberate effort to build, especially for teams used to thinking and planning in terms of whole features rather than incremental slices. Teams that build this skill tend to see lead time improvements that compound, because smaller changes are also easier to review, easier to test, and safer to deploy, improving the whole pipeline at once rather than any single stage in isolation.
Lead time for changes is a DORA metric that measures the time it takes a code commit to go from being written to running successfully in production, capturing the efficiency of the technical delivery pipeline including code review, testing, and deployment.
General lead time, as used in product and project management, typically starts when a request or ticket first enters the system, while lead time for changes starts specifically at the code commit, which isolates the technical delivery pipeline from upstream prioritization and queuing issues.
The two often overlap in practice, but cycle time commonly starts when work begins on a ticket, which can be earlier than the first commit, while lead time for changes specifically starts at the commit and ends at successful production deployment, making it a narrower, more standardized measure within the DORA framework.
In the DORA research, Elite performing organizations tend to have a lead time measured in less than a day, often just a few hours, though the right target for any given team depends on the type of system, regulatory constraints, and platform limitations like app store review processes.
The most common causes are slow or delayed code review, slow or unreliable automated test suites, manual deployment steps requiring human approval, infrequent scheduled release windows, and large batch sizes that add friction at every stage of the pipeline.
It's best read alongside change failure rate and deployment frequency, since lead time can be shrunk artificially by cutting corners on review or testing, which typically shows up as a rising change failure rate soon afterward.
Most teams measure lead time to the point of successful deployment rather than to when a feature flag is turned on for users, treating flag activation as a separate product decision from the technical act of deploying the code itself.
Only with caution, since factors like app store review requirements, regulatory approval steps, and the maturity of a team's existing pipeline create real differences in lead time that have nothing to do with which team is more disciplined or skilled.
Reducing batch size by shipping smaller, more frequent commits tends to have the broadest impact, since smaller changes move faster through every stage of the pipeline, though the specific bottleneck, often code review wait time or deployment friction, should be identified through measurement before deciding where to focus improvement effort.
