Designing a CI/CD pipeline developers will not route around
A pipeline succeeds when it is fast enough to trust and strict enough to matter. Getting that balance wrong is why teams disable checks.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Throughput and stability improve together in strong teams.
- The metrics are diagnostic instruments, not performance targets.
- Derive them from systems of record, not self-reporting.
- Track your own trend rather than external benchmarks.
What the four measure
Deployment frequency and lead time for change describe throughput — how often you ship and how long it takes from commit to production. Change failure rate and time to restore describe stability.
The pairing matters. Throughput without stability is recklessness; stability without throughput is stagnation. Research consistently finds strong teams improve both together rather than trading one for the other.
Use them to find the constraint
The value is diagnostic. A long lead time with fast builds points at review or approval delay. Frequent changes with a high failure rate points at test coverage or environment fidelity. Slow restore times point at observability and rollback capability.
Measure first, then act on what the numbers indicate rather than on what the team assumes.
Where they get misused
- Comparing teams with different risk profiles as though the numbers are equivalent.
- Setting deployment frequency as a target, which produces trivial deployments.
- Ignoring change failure rate while celebrating throughput.
- Measuring individuals rather than the delivery system.
Any measure used as a target eventually stops measuring what it did. Treat these as instruments, not objectives.
Collect them honestly
Derive the numbers from systems of record — version control, the pipeline, the incident tracker — rather than from self-reporting. Define terms precisely: what counts as a deployment, what counts as a failure.
Then review the trend rather than the absolute value. Improvement in your own numbers is meaningful; comparison against a published benchmark from a different context usually is not.
Improving lead time specifically
Lead time is usually the most actionable of the four, because its components are separable. Break it into coding time, review waiting time, pipeline duration and deployment waiting time, then measure each.
In most organisations the largest component is waiting for review, not building or testing. That is an organisational fix — smaller changes, clearer review expectations, agreed response times — rather than a tooling one.
Measuring the breakdown once usually surprises the team and redirects effort from optimising builds to reducing queueing, which is where the time actually goes.
Frequently asked questions
It depends entirely on context. What matters is whether you can deploy when you need to, safely. A team deploying weekly with confidence is in better shape than one deploying daily with a high failure rate.
From commit to running in production. Measuring from ticket creation includes prioritisation decisions, which are a different problem and obscure the delivery signal.
No. They measure the delivery system, not individuals. Using them for appraisal reliably produces gaming and destroys their diagnostic value.
