Deployment Frequency vs Lead Time: Which Metric Should You Optimise First?

2026-07-06 · 6 min read · GitHub & Metrics

If you're starting to track DORA metrics, you'll quickly notice that deployment frequency and lead time often point to the same underlying problem — but not always. Understanding what each one is actually measuring helps you avoid the mistake of optimising the wrong thing first.

They Measure Different Parts of the Same System

Lead time measures the journey a code change takes from when a developer commits it to when it's live in production. It spans PR review, CI pipeline, approval gates, and the release process itself.

Deployment frequency measures how often you complete that journey. A team that deploys once a week has the same lead time regardless of whether each release contains 10 changes or 200.

The relationship between them is instructive: you can have a fast lead time (individual changes move quickly through the pipeline) but low deployment frequency (you batch those fast changes into infrequent releases). Or you can deploy frequently but with a long lead time if each change spends days waiting in review before finally being included in a release.

Elite teams have both: changes move quickly and they ship often.

Start With Lead Time

If you can only improve one metric first, start with lead time. Here's why: deployment frequency is usually a consequence of lead time, not independent of it.

When lead time is long, deploying frequently feels risky. The more changes you accumulate between releases, the harder it is to know which one caused a problem when something breaks. Teams respond rationally by batching changes and deploying less often, adding more approval steps, and increasing the ceremony around each release.

Shortening lead time breaks this cycle. When a change moves from commit to production in hours rather than days, deploying it becomes low-stakes. Frequent deploys stop feeling like events and start feeling like routine.

The question to ask: where does time accumulate in your lead time? The answer is usually one of:

PR review wait time. Code sits in an unreviewed queue. Sometimes this is a capacity problem (reviewers are stretched); sometimes it's a culture problem (reviews are deprioritised); sometimes it's a process problem (too many required approvals, reviews take too long because PRs are too large).

CI pipeline duration. A test suite that takes 40 minutes to run means every change waits 40 minutes before it can merge. This compounds quickly in a team of ten engineers.

Manual steps in the release process. Anything that requires a human to click a button, write a change request, or wait for an approval window slows lead time. These steps usually accumulated over time as responses to past incidents, each one reasonable in isolation but collectively creating a significant bottleneck.

Large batch sizes. When PRs are large, everything slows down — reviews take longer, CI runs take longer, and the blast radius of any problem is bigger.

When to Focus on Deployment Frequency Instead

There are situations where deployment frequency is the right place to start.

Your lead time is already short but you're still deploying rarely. If changes move through the pipeline in hours but you only release weekly, the bottleneck is organisational, not technical. Someone is holding a release gate open. That's a process and culture problem.

You're working on a team that's never deployed frequently. Sometimes infrequent deployment is a habit rather than a rational response to risk. Starting a practice of more frequent deploys — even when lead time is still long — builds the organisational muscle for it and often reveals which parts of the process need to change.

Your change failure rate is low and your MTTR is fast. If you can deploy safely and recover quickly when something goes wrong, the cost of deploying frequently is low. There's no technical reason to hold back.

The Hidden Relationship With Change Failure Rate

Both metrics interact with change failure rate in ways that are easy to miss.

Teams with high lead times tend to have higher change failure rates, not lower. This seems counterintuitive — surely more time to review means fewer mistakes? The research says otherwise. Long lead times mean larger batches, and larger batches mean more surface area for problems. When a 200-change release breaks something, isolating the cause takes far longer than debugging a 3-change release.

This is one of the most practically important insights from DORA: the instinct to move slowly to be safe often produces the opposite of safety. Deploying small changes frequently is safer than deploying large changes infrequently.

A Simple Framework

When you're looking at both metrics together:

The goal is a system where changes move through your pipeline quickly and you deploy them often. One makes the other easier. Start where the constraint is.