What Is Lead Time for Changes? A Practical Guide for Startup Engineering Teams

Lead time for changes is the time it takes a code change to get from commit to running in production, and it is one of the four DORA metrics used to gauge software delivery performance. It tells you less about how fast your developers type and more about how fast your system lets finished work reach customers.

That distinction matters for startups. Small teams tend to assume they are fast because they ship often, then discover that a pull request sits for a day and a half waiting on the one person who can approve it. This guide covers how to define and measure lead time for changes, what a healthy number looks like, why it moves, and how to use it without turning it into a scoreboard that people learn to game.

Lead Time for Changes Defined: From Commit to Production

DORA, the DevOps Research and Assessment program now run within Google Cloud, defines lead time for changes as the elapsed time from a code commit to that change running successfully in production. The research behind it was popularized in the book Accelerate (Forsgren, Humble, Kim, 2018) and has been updated in DORA's annual State of DevOps reports since. Teams differ on exactly where the clock starts (first commit on a change, or merge), which is why the next section says to pick one and write it down.

Here is a hypothetical example. A developer makes the first commit on a pull request Monday at 10:00. It is merged Tuesday at 15:00 and deployed to production Wednesday at 09:00. The lead time is 47 hours: 29 hours from commit to merge, plus 18 hours from merge to deploy. Notice that the code might have taken three hours to write. The rest is waiting and pipeline time.

Where it sits among the four DORA metrics

DORA tracks four key metrics in two pairs. Lead time for changes and deployment frequency measure throughput: how quickly and how often you deliver. Change failure rate (the share of deployments that cause a failure needing remediation) and time to restore service measure stability. The pairing is deliberate. Speed without stability is just a faster way to break things, so the metrics are meant to be read together.

What it is not

Two neighboring terms get confused with it:

• Cycle time usually starts when someone begins work on a ticket (for example, it moves to "In Progress" in Linear) and ends when the work is done. It covers the development process but often stops before production.
• Lead time in lean and Kanban starts when a request is made, so it includes the time an idea sits in the backlog. It measures responsiveness to customers, not delivery pipeline health.

DORA's version deliberately excludes the backlog and design phases. It isolates the delivery pipeline, which is the part engineering can most directly improve.

How to Measure It with the Tools You Already Have

You do not need a new system to get a first number. Most startups already have the raw timestamps in GitHub, a CI/CD tool, and a tracker like Linear. The work is in deciding what to count and applying it consistently.

Choose and document your start and end events

For the start, use either the first commit on the change or the moment the pull request is opened. First commit is closer to DORA's definition; PR opened is easier to measure reliably and avoids noise from local commits made days before anyone is ready for review. For the end, use the production deploy event, not the merge. Merged code that has not shipped has not reached anyone. Whatever you pick, write it down. A number is only useful over time if the definition does not quietly change.

Connect the data sources

• GitHub provides commit, PR-opened, review, and merge timestamps.
• CI/CD or release tags provide the deploy timestamp. If you do not log deploys explicitly, a tagged release or a deployment workflow run is a workable proxy.
• Linear links PRs to work items, which lets you slice by project, work type, or initiative rather than looking at one undifferentiated pile.

Report the median and a high percentile

Do not use the mean. A handful of long-running PRs, such as a migration that sat open for three weeks, will drag the average far from what a typical change experiences. Report the median for the typical case and the p85 or p90 for the tail. The p85 is the value that 85 percent of changes beat; it shows how bad things get for the slower changes without letting one outlier dominate. A median of 20 hours with a p85 of 6 days tells you there are two different stories in your data.

Settle the edge cases up front

• Squash merges collapse many commits into one, so original commit times disappear. Measuring from PR opened sidesteps this.
• Reverts are new changes. Decide whether to count them or exclude them, and apply the rule consistently.
• Feature-flagged code that ships dark is deployed but not released. Count it as deployed; the flag decision is a separate product question.
• Batch deploys with many commits give each change a different lead time, because older commits waited longer. Measure each change against the shared deploy time rather than averaging by deploy.

What Counts as a Good Lead Time?

DORA's State of DevOps reports (Google Cloud/DORA) have grouped teams into performance bands, historically from low to elite, based on how their lead time and other metrics cluster. Elite-level teams have generally been those that get changes into production in under a day. Be careful with specific thresholds, though: the bands and their cutoffs have been revised between report editions, and the exact tiers differ by year. Before quoting any figure in a deck or a planning document, check the most recent report and cite its year.

Treat the benchmark as a direction, not a target. A team building a payments ledger and a team shipping a marketing site have different appropriate risk profiles, and neither is served by chasing someone else's number.

The startup advantage, and how it erodes

Startups start with real advantages: small codebases, few approval layers, and no change advisory board. Many early teams have a lead time measured in hours without trying. The advantage tends to erode in one specific place, which is review. When only one or two senior engineers are trusted to approve changes, pull requests queue behind their calendars. The team grows, PR volume rises, and the reviewers become the bottleneck without anyone deciding that they should.

Compare against yourself

The most useful comparison is your own trend over weeks. Is the median drifting up as the team grows? Did the p85 jump after you adopted a manual release step? A steady 30 hours that is improving tells you more than a 10-hour figure from another company with a different architecture, release process, and definition of "deployed." If you are choosing what else to track alongside it, this overview of engineering metrics for startups covers what is worth measuring and what to ignore.

Where the Time Goes: Breaking Lead Time into Stages

A single lead time number tells you that something is slow, not what. To find the cause, split the clock into stages:

1. Coding time: first commit to PR opened.
2. Wait for review: PR opened to first review.
3. Review time: first review to approval.
4. Wait for merge or release: approval to merge, and merge to the start of deployment.
5. Deploy pipeline: the deploy starting to the change running in production.

In many teams, a common pattern is that most of the elapsed time is waiting rather than working. Code sits idle in a review queue, an approved PR waits for someone to press merge, a merged change waits for the next release window. The people involved are busy the whole time, which is why the delay is easy to miss: nobody is idle, but the change is. Tracking pull request cycle time is one way to make those queues visible.

Each cause leaves a different fingerprint

• Large pull requests inflate both coding time and review time. Reviewers postpone them because they are daunting, so they also wait longer.
• Flaky tests stretch the pipeline stage and add re-runs, which often show up as a long gap between approval and merge.
• Manual release approvals create a wait between merge and deploy that has nothing to do with code quality.
• Weekly release trains put a floor under lead time. A change merged right after the train leaves waits nearly a week regardless of how fast everything else is.

An example diagnosis

Suppose a team has a median lead time of three days. Broken into stages, coding takes about four hours, review takes three hours, the pipeline takes twenty minutes, and the first review does not arrive until two days after the PR opens. The instinct might be to ask developers to code faster or to speed up CI. The data says neither would help. The problem is review coverage: nobody is assigned to look at new PRs promptly, or the few capable reviewers are overloaded. Fixing that one stage would cut lead time by two-thirds, while optimizing anything else would barely register. A guide to stalled pull requests detection shows how to catch this kind of queue before it compounds.

How to Shorten Lead Time Without Sacrificing Quality

Once you know which stage dominates, the fixes are fairly well understood. The discipline is to apply them to the stage that actually hurts and to keep an eye on stability while you do. For a broader playbook, see these cycle time improvement strategies for startup engineering teams.

Make changes smaller and more frequent

Small pull requests are reviewed faster, fail less often, and are easier to roll back. Set a soft norm, such as aiming for changes a reviewer can read in one sitting, rather than a hard line count that invites gaming. Use feature flags (conditional switches that turn code paths on or off at runtime) to separate deploying code from releasing it to users. That lets unfinished work merge and ship behind a flag instead of living on a long-lived branch.

Agree on how review works

• Set a first-response expectation, for example that every PR gets a first look within a working half-day.
• Rotate reviewers so knowledge and load spread across the team rather than concentrating on one senior engineer.
• When a PR is blocked, pair on it. A 20-minute conversation often resolves what a day of comment threads will not.

Automate the path to production

Reliable CI is the foundation: a pipeline people trust is one they do not re-run out of habit. Deploy automatically on merge where your risk profile allows it, and invest in a faster test suite by parallelizing and removing slow or flaky tests. Every manual handoff between merge and production is a place for a change to wait.

Watch stability alongside speed

Track change failure rate next to lead time. If lead time falls while incidents and rollbacks rise, you have not become faster, you have moved the cost downstream. Recovery speed matters here too, which is what mean time to recovery captures. The metrics are meant to be read together.

Where Progress fits

The hard part for a lead is usually noticing which changes are stuck without opening five dashboards. Progress reads your GitHub and Linear activity and flags stalled work and change pressure, so you can see which pull requests are waiting and where review is backing up. You can also ask it plain-language questions about recent activity instead of assembling the picture by hand.

Common Mistakes When Tracking Lead Time

Ranking individual developers

Lead time is a property of the system: review capacity, pipeline reliability, release process. Putting individual names next to it measures things developers do not control, and it rewards the wrong behavior. People respond by splitting work into trivial PRs, approving reviews without reading them, or avoiding hard problems that make their numbers look worse. Keep it a team-level metric. If you want a healthier framing, this guide on how to measure developer productivity explains how to look at the system rather than the individual.

Treating the number as the goal

Goodhart's law says that when a measure becomes a target, it stops being a good measure. If the team is told to hit a lead time figure, they will hit it, possibly by means that defeat the purpose. Use the number as a symptom to investigate. A rise is a prompt to ask what changed, not a failure to be punished.

Averaging incomparable work

A one-line hotfix, a docs change, a dependency bump, and a multi-week feature are different kinds of work. Blending them into one figure hides more than it shows. Segment by work type, at least separating urgent fixes and routine maintenance from feature work, so each trend means something.

Ignoring the people behind the numbers

A falling lead time is not automatically good news. If it comes with slowing momentum, rising rework, or visible fatigue, the team may be cutting corners or running hot, and the improvement will not last. Delivery metrics describe the pipeline, not the people inside it. That is why it helps to pair them with a read on team momentum and morale, which Progress surfaces alongside delivery signals, so a gain in speed is not quietly paid for in burnout. Learning to spot developer burnout early is a useful complement.

Start with One Month of Data and One Stage to Fix

Lead time for changes is a diagnostic for flow. Its value is less in the number itself than in what it reveals about where changes wait. You can get useful results this week without new tooling.

1. Define your start and end events, and write them down.
2. Pull the median and p85 for the last month from your GitHub and deploy data.
3. Split the clock into stages and find the single longest waiting stage.
4. Fix that one stage, then re-measure in a few weeks.

If you want those stalled-work and change-pressure signals without assembling them by hand, Learn more about our services.