Lead time for changes

Lead time for changes is the duration between a code commit and its arrival in production. It encompasses every stage of the delivery pipeline: code review, automated testing, staging deployments, manual approvals, and the production deployment itself. It is the developer-facing equivalent of asking "how long until my work reaches users?"

This metric is distinct from the broader concept of lead time used in operations, which measures the total time from when a request is made to when it is fulfilled. In the DORA context, lead time for changes starts at the commit, not at the moment someone decides to build a feature. Product lead time (idea to production) is a valuable metric but a separate one.

The metric is also distinct from cycle time, which measures the active working time on a task. Lead time for changes includes all the waiting time between stages: the time code sits in a pull request awaiting review, the time a build queues behind other builds, the time a change waits for a deployment window. Often, this waiting time dominates the total.

Elite-performing teams, as defined by the DORA research, achieve a lead time for changes of less than one hour. This does not mean they write code faster. It means their pipeline has minimal wait states, high automation, and no unnecessary gates between commit and production.

Within the DORA framework, lead time for changes and deployment frequency together measure throughput, while change failure rate and mean time to recovery measure stability. The research consistently demonstrates that these are not trade-offs: elite teams achieve the best scores across all four metrics simultaneously.

Lead time for changes and deployment frequency are correlated but measure different things. A team might deploy frequently but still have long lead times if changes are batched and queued. Conversely, a team might have short lead times for individual changes but deploy infrequently because they produce few changes. Tracking both metrics reveals whether the delivery pipeline is both fast and regularly exercised.

The interaction between lead time and change failure rate is particularly important. Long lead times often indicate large batch sizes, and large batches have higher failure rates because they contain more changes and are harder to test thoroughly. Reducing lead time naturally reduces batch size, which tends to reduce the change failure rate as a side effect.

Lead time for changes is the sum of time spent in each stage of the delivery pipeline. A metric tree breaks the total into stage-by-stage durations and surfaces the bottlenecks.

In most organisations, the majority of lead time is spent waiting rather than processing. Code review time often dominates because it depends on human availability. A pull request opened at 4pm might not receive its first review until the next morning, adding 16 hours of wait time for just a few minutes of actual review work.

The CI pipeline time is typically the most measurable and improvable stage. Build and test duration can be optimised through parallelisation, caching, and test selection. Queue wait time can be reduced by scaling CI runners. These are infrastructure investments with predictable returns.

Approval gates often represent the largest hidden cost. A change advisory board that meets weekly adds up to 7 days of lead time regardless of how fast the rest of the pipeline operates. Replacing these manual gates with automated policy checks and post-deployment monitoring can eliminate days of waiting while maintaining or improving safety.

1. 1

   Measure each pipeline stage independently

   Before optimising, instrument each stage of the pipeline to understand where time is actually spent. Many teams assume the build is the bottleneck when code review or approval gates consume far more time. Stage-level measurement directs effort to where it will have the most impact.

2. 2

   Set code review SLAs and reduce batch size

   Establish an expectation that pull requests receive first review within a defined window, such as 4 hours. Smaller pull requests are reviewed faster and with higher quality. Teams that review 50-line changes in minutes often take days to review 500-line changes.

3. 3

   Parallelise and cache CI pipelines

   Run independent test suites and build steps in parallel rather than sequentially. Cache dependencies and build artefacts between runs. Use test impact analysis to run only the tests affected by each change. Target a total CI time under 10 minutes.

4. 4

   Replace manual gates with automated checks

   Audit every manual approval step and ask whether it can be automated. Security checks, compliance policies, and change risk assessments can often be encoded as automated rules that run in the pipeline. Reserve human review for genuinely exceptional cases.

5. 5

   Enable continuous deployment

   If every change that passes automated tests is deployed to production automatically, the deployment stage adds minutes rather than hours or days. Combined with feature flags and canary deployments, continuous deployment is both fast and safe.

Lead time for changes directly affects the speed at which an organisation can respond to opportunities and threats. A team with a one-hour lead time can fix a critical production bug within hours of discovery. A team with a one-month lead time must wait for the next release cycle, leaving the bug in production for weeks.

The same dynamic applies to feature delivery. When a competitor launches a new capability, the organisation with shorter lead times can respond faster. When customer feedback reveals a product problem, shorter lead times enable faster iteration. Over months and years, this speed advantage compounds into a significant competitive moat.

Lead time also affects developer satisfaction and retention. Engineers who see their work reach users quickly feel a stronger connection between effort and impact. Those who wait weeks or months for their code to reach production often experience frustration and disengagement. In a competitive hiring market, engineering velocity is itself a retention tool.

For organisations already tracking throughput and cycle time, lead time for changes provides the specific, measurable view of how long the software delivery pipeline takes from end to end.

KPI Tree lets you model lead time for changes as a stage-by-stage metric tree that connects each pipeline phase to the total. Each stage, from code review to deployment, becomes a node with its own duration data, making bottlenecks visible at a glance.

The tree can be segmented by team, repository, and change type to identify whether lead time patterns are uniform or concentrated in specific areas. A team might have fast lead times for bug fixes but slow lead times for features, revealing that the bottleneck is specific to how feature work flows through the pipeline.

Connecting lead time to deployment frequency and downstream metrics like customer satisfaction score provides a complete view of whether pipeline speed improvements are translating into better delivery outcomes and user experience.