Lead Time for Changes, Explained: How to Decode It and Cut It

Step 1: Check Deployment Frequency First

Lead time and deployment frequency are mechanically coupled. If you deploy once a week, no amount of review speed gets a commit to production faster than your next release train — rare releases raise lead time at the arithmetic level, before any engineering cause. Fix cadence first: the cheapest lead-time win for most teams is simply deploying more often, not working faster.

Step 2: Median vs P90 — Where Is the Tail?

A flat median with an exploding P90 means a targeted problem, not a systemic one: some PRs are stuck while the typical one flows. Look at what the tail PRs share — a service, a critical-path team, a review queue, a risky deployment procedure. A flat P90 together with a rising median is the opposite: a systemic slowdown that eventually shows up everywhere. The two cases call for different fixes, and the aggregated lead time number cannot tell them apart.

Step 3: Segment by Service

A monolith and a spike-service produce garbage statistics when averaged. Segment lead time by service and by team: the number that matters is the one attached to the code path you actually care about this quarter. Mixed statistics are how teams "prove" nothing is wrong while the critical service quietly spends a week per change.

If you cannot decompose your lead time by stage, by percentile and by service, you have a feeling, not a metric.

The Levers, In Order of Return

1. Deploy more often

Mechanical and immediate. Smaller batches also shrink risk per deploy, which is why high deployment frequency and low change failure rate go together rather than against each other.

2. Shrink the work

PRs of 200–400 lines max. Review time scales super-linearly with size, and large PRs sit in queues longer at every stage. Smaller changes are the force multiplier behind every other lever.

3. Kill CI queue time

Underutilized CI capacity behaves like a hairpin: queues explode non-linearly as utilization approaches 100%. Parallelism and caching are cheap compared to eleven-sub-unit CI waits for every PR.

4. Merge-on-green

If CI is green, merge — no approval-latency lottery triggered by whoever is on lunch. Requires trustworthy CI, which is exactly why the flaky-test work pays for itself.

5. Review norms

First review within one working hour, blocking/non-blocking comment discipline, and balanced review load. These are organizational dials, and they are what the improvement to lead time usually looks like when it arrives.

How to Track It

Lead time for changes is derived from repository and deployment events — first commit of a change through reviews to the production deploy — so once it is instrumented it costs nothing to maintain. Track it at the team level, decomposed per stage, with the P90 visible beside the median.

DevLyTicks computes lead time for changes and its decomposition automatically from your GitHub repositories — watch it move at devlyticks.com.

Conclusion

Lead time for changes is not a vanity number: decoded per stage, per percentile and per service, it tells you exactly which bottleneck to hit first. Start with deployment frequency, watch the tail, and pull the levers in order of return — cadence, size, CI queue, merge-on-green, review norms.