Speed and Stability

Speed and Stability

We’ve all heard customers complain when a release takes longer than expected. We’re busy polishing every edge case, double-checking functionality—and yet, delays frustrate stakeholders. On the flip side, when we move too fast, we fear breaking production. It feels like we’re constantly balancing between speed and stability.

This post is a continuation of my earlier piece, Measure What Truly Matters. If you haven’t read it yet, I highly recommend starting there.

Speed vs. Stability: A False Tradeoff

In software engineering, there’s a common belief that speed and stability are opposing forces. That to move faster, you have to compromise on quality—or that to ensure stability, you must slow down. But the State of DevOps report shows that this is a false tradeoff. In fact, with the right engineering practices and fast feedback loops, teams can achieve both speed and stability.

This isn’t just an opinion. The State of DevOps report is based on empirical research, offering a global, data-driven view of how software teams operate.

The Four Key Metrics of Delivery Performance

The book Accelerate identifies four key metrics that help teams measure software delivery performance. These are:

• Delivery Lead Time
• Deployment Frequency
• Time to Restore Service
• Change Failure Rate

These metrics are split across two dimensions: Speed (Lead Time and Deployment Frequency) and Stability (Time to Restore Service and Change Failure Rate).

Delivery Lead Time

Lead Time refers to the time it takes from a customer request to that request being delivered in production. It includes design, development, testing, and deployment. Lower lead time is better—it enables faster feedback, iteration, and innovation.

Deployment Frequency

This measures how often your team delivers changes to production. A higher deployment frequency is a sign of healthy, incremental delivery. It reduces risk, increases efficiency, accelerates feedback, and helps prevent bottlenecks.

Time to Restore Service

No system is perfect. Outages and failures happen. What matters is how quickly we can recover. This metric tracks the time it takes to restore service after an incident. Lower is better—it reflects resilience, preparedness, and a focus on minimizing user impact.

Change Failure Rate

This is the percentage of deployments that result in a failure—whether it’s a rollback, a hotfix, or a service disruption. A lower failure rate shows that changes are being delivered reliably without sacrificing system stability.

Context Matters

It’s important to remember that these metrics are contextual. A “high performer” in one industry or team structure might look very different in another. These measures aren't meant for direct comparison between teams, but rather to help teams evaluate their own progress over time.

For example, if your team adopts continuous delivery, you might expect improvements in lead time and deployment frequency. Tracking these metrics helps you see whether that’s actually happening.

Use Metrics as a Tool, Not a Weapon

Measuring delivery performance is hard. It requires effort, intention, and trust. These metrics work best in organizations that foster a learning culture—where data is used to identify bottlenecks and drive improvement, not to assign blame.

When metrics are used in fear-based environments, they often produce misleading data. People game the numbers, hide failures, or optimize for the wrong outcomes.

In the right environment, though, these four metrics can help you move faster and more safely—at the same time.