Guide
Lead time for changes
Lead time for changes is the time between a change being committed and that change running in production. It is one of the four DORA metrics, and the most diagnostic of them — because unlike the other three it can be decomposed into stages that each point at a different fix.
How it is calculated
The clock starts at the first commit on the branch that carries the change and stops when that change is live in production. Most teams report the median rather than the mean, because lead time distributions have a long tail — one pull request that sat open for six weeks will drag a mean into meaninglessness.
Note what is excluded: the time before anyone started work. Lead time for changes is not the time from idea to production, which is a different and also useful measure sometimes called lead time for value. Conflating them is the most common definitional argument in this area.
Why the stage breakdown is the whole point
A lead time of thirty hours is not actionable. The same thirty hours split into eleven hours coding, ten hours waiting for a first review, six hours in review and three hours waiting to deploy is immediately actionable, and it usually surprises people.
The stage that dominates in most organisations is pickup — the dead time between a pull request opening and anyone starting to review it. It is dead time in the purest sense: nothing is happening, nobody is blocked on a decision, the work is simply sitting there. It is also the cheapest stage to improve, normally by agreeing a review expectation and making the queue visible rather than by changing anything technical.
The second most common finding is that the pull requests with the worst lead time are the largest ones. Size and review latency are strongly related, which is why a pull request size agreement often does more for lead time than anything aimed at review speed directly.
What good looks like
The DORA bands put elite performance under one day and high performance between one day and one week. In practice, most organisations that measure this honestly for the first time find themselves in the high band and are surprised — the perception is usually worse than the measurement, because memory is dominated by the outliers.
The more useful target is not a band. It is a reduction in the stage you have identified as dominant, measured over a quarter, with the working agreement that produced it written down.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Using the mean instead of the median
Lead time has a long tail. One abandoned pull request reopened after two months will move a mean by hours and tell you nothing.
Starting the clock at the pull request, not the first commit
This hides the coding stage entirely and flatters teams that work in long-lived branches.
Stopping the clock at merge
Merge is not production. For teams that release weekly, merge-to-production can be the largest stage of all.
Reporting one figure for the whole organisation
A platform team and a mobile team have structurally different lead times. The organisation-wide median is an average of two unrelated distributions.
Frequently asked questions
Is lead time for changes the same as cycle time?
They overlap and the terms are used loosely. Lead time for changes, as DORA defines it, runs from commit to production. Cycle time is usually used more broadly for the time from starting work to finishing it, and in pull request tooling often means open-to-merge. The important thing is to state which you mean.
What is a good lead time for changes?
Under one day is elite by DORA’s banding; one day to one week is high. But the useful target is a downward trend in whichever stage dominates your own breakdown, not a band.
How do you measure it without deployment tracking?
You cannot measure it accurately, and a tool that claims to without deployment data is measuring time-to-merge and calling it something else. Connecting deployment events is what makes the metric real.
Why is our lead time so much worse than our perception of it?
Almost always pickup time. Nobody experiences the hours a pull request spends unopened, because by definition nobody is looking at it. It is the largest single stage in most organisations and the least noticed.
See lead time for changes for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.