Lead Time for Changes

Between "development is done" and "users can use it" sat a stretch of time nobody was counting. A feature would be reported complete and weeks later nothing on the screen had changed. Ask what happened in between and the answers were always the same shape: the reviewer was busy, the test environment was occupied, the scheduled release was next week.

When Mia asked whether a feature had not finished last week, Theo would say the code had, and that the release was going out with the end-of-month batch. Both statements were true. The engineering schedule held and the customer waited another month, and there was no number to point at.

Lead time for changes puts a name and a value on that stretch. How fast code gets written was already managed several different ways, but where finished code spent its days on the way to a user was nobody's record. Teams that start measuring it usually find that most of the value is waiting.

Take the gap between the moment a change lands in the code repository and the moment that change is running in production, measure it per change, then read the median.

Where the clock starts is a team decision. The common choice is the moment a pull request — the request to merge a change into the main line — gets merged. Some teams start from the first commit instead, which pulls the time spent writing code into the value and blurs the point of looking at the release path at all. The end is fixed at one thing: running in production. A change sitting on a test server, or shipped with its feature switched off, has not reached a user and is not finished.

The calculation has three steps.

1. Pull the list of changes actually included in recent releases. Deployment tooling or the repository history shows which change rode in which release.
2. For each change, take the difference between when it merged and when the release carrying it completed.
3. Gather around thirty recent changes and read the median. An average lets one change that dragged three weeks while its owner was away pull the whole number away from the real state of things.

A single value doesn't say what to fix, so the span gets cut into pieces: merge to review approval, approval to tests passing, tests passing to release. The first time Pagedeck measured this, the median was 6 days, and 4 of those were spent waiting for code review. It was the kind of six days that hiring more engineers does not shorten.

In the research, top-performing organizations stay under a day while the lower end reports the same value in weeks or months. The band thresholds shift between editions of the survey, so comparing your team's last quarter against this one beats memorizing a specific figure. Whether 6 days became 4 is the more useful question than whether it cleared one day.

What to fix is what the piece-by-piece breakdown tells you. The longest piece almost always sits on a step a person performs by hand. There is one reviewer whose calendar sets the pace for everyone, or a release needs sign-off in a meeting, or the scheduled release runs once a week so a change finished on Tuesday waits until Monday. Remove those steps one at a time and the value follows. Putting in continuous integration and continuous delivery (CI/CD) — automatic checks on every change, and a path to the server when nothing fails — is the single change that moves it most.

The size of each release matters too. Batch three weeks of work into one release and whatever finished first waits for the rest, and when something breaks, working out which change caused it costs several more days. Shipping small and often cuts both of those.

Pushing only on this value makes skipping verification the easy way to move it. That is why change failure rate, the share of releases that turn into incidents, sits next to it as a pair. If one goes down while the other goes up, the time wasn't removed — the risk was moved.

"The median is six days and four of them are waiting on review."

What needs fixing is the review queue, not how fast anyone writes code.

"The goal this quarter is under a day. Let's start by dropping the end-of-month release."

Batching changes up for a fixed date is the biggest thing holding the value up.

"That's build time. You have to start counting after the code is written."

The clock was started in the wrong place, so a different span is being measured.

At Pagedeck, Theo breaks the value into pieces every quarter. The first measurement showed four days waiting on review, so the team added a second reviewer and set an alert after a day idle, and the median went from six days to three. The quarter after that they dropped the end-of-month release and shipped whatever was ready, which brought it to a day and a half.

Mia uses the number in scheduling conversations. When someone asks when a feature reaches users, the date engineering finishes on doesn't answer the question. Adding this value to the expected completion date lands much closer to what actually happens.

The most common mistake is assuming a shorter time costs quality. Everyone has watched a rushed release go wrong, so the reading comes easily. But in a team with a long value, what shrinks is waiting rather than verification. Cutting four days of waiting for review down to one is not the same as skipping review. If anything, a team that moves from three-week batches to shipping daily makes each release smaller, which makes the cause easier to find when something does break. Left in place, this belief keeps teams defending the fixed release date in the name of safety while the batch going out each time keeps growing.

Expecting tooling to fix it on its own is the other one. It looks like an automation problem. Yet plenty of teams install automated deployment and watch the value stay flat. The release itself now takes five minutes, but the weekly sign-off meeting in front of it is untouched, so the number of days waiting doesn't change. Buying tools before cutting the span into pieces leaves steps like that exactly where they were.