The Four Accelerate Metrics
Introduction#
Software teams inherit metrics from their organizations, their tools, and their history. Story points, velocity, utilization rates, code coverage percentages. These measurements provide comfort because they generate concrete numbers and trends you can show in reports. The challenge is that they often measure activity rather than outcomes, tracking how busy you are rather than how effectively you’re delivering value to customers.
The four Accelerate metrics offer a different lens. They measure capabilities that directly affect your ability to respond to customer needs: how quickly you can get changes into production, how often you deploy, how fast you recover from failures, and how often those deployments cause problems. These metrics reflect the delivery system itself rather than the people operating within it.
You don’t need to implement complex measurement systems or hire consultants to start using these metrics. Most teams already have the data they need buried in their version control systems, deployment pipelines, and incident management tools. Understanding what these metrics measure and why they matter is the first step toward improving how your team delivers software.
Lead Time#
Lead time measures the duration from when a developer commits code to when that code runs in production. This metric captures the efficiency of your entire delivery pipeline, from the moment work is complete to when customers can use it.
Lead time is sometimes confused with cycle time or total task duration. Cycle time measures how long work takes from when you start it until you finish it. Lead time specifically measures the gap between code completion and production deployment. Features might be completed quickly but then wait days or weeks for deployment windows, code freezes, or approval processes. Lead time makes this waiting visible.
Short lead times create competitive advantages that compound over time. When you can deploy a bug fix in minutes instead of days, customer satisfaction improves because problems get resolved quickly. When you can ship a new feature the same day a customer requests it, you create experiences that competitors with week-long deployment cycles simply cannot match. When you can test market hypotheses through rapid experimentation, you learn faster than organizations that need weeks to see results.
Control theory and the Nyquist Shannon sampling theorem, which I explore in Shorter Feedback Cycles, explain why lead time matters so much. Every day between committing code and seeing it in production is a day you cannot learn whether that code solves the actual problem. If your lead time is two weeks, you wait two weeks to discover that your brilliant solution misunderstood the requirement. If your lead time is two hours, you course correct the same day. The team with shorter lead time learns faster, adapts faster, and ultimately delivers better solutions.
Long lead times also encourage batching, which increases risk. When deployments are expensive or time-consuming, teams naturally batch multiple changes together. Each deployment becomes a high-stakes event containing dozens or hundreds of changes. If something breaks, isolating the problematic change becomes detective work. Short lead times enable small, frequent deployments where each change is isolated and easy to validate or roll back.
Organizations with lead times measured in hours can respond to customer needs and production issues the same day they’re discovered. Organizations with lead times measured in weeks accumulate completed work waiting for the next deployment window. This difference reflects the constraints and capabilities of the entire delivery system, not the skill or effort of individual developers.
Deployment Frequency#
Deployment frequency measures how often your team releases changes to production. This metric reveals your organization’s capability to deliver value continuously rather than in large, risky batches.
High deployment frequency doesn’t mean deploying for the sake of deploying. It means your delivery system is reliable and automated enough that deploying feels routine rather than exceptional. When deployment is routine, you deploy whenever there’s value to deliver rather than waiting for scheduled windows or management approval.
The relationship between deployment frequency and quality surprises people. Conventional wisdom suggests that deploying more often increases risk because each deployment is an opportunity for something to go wrong. The data shows the opposite. Teams that deploy multiple times per day have fewer production incidents than teams that deploy monthly or quarterly.
This counterintuitive result makes sense when you consider what enables frequent deployment. To deploy confidently multiple times per day, you need automated testing that catches problems before production. You need deployment automation that eliminates manual error. You need monitoring that detects issues immediately. You need architecture that isolates changes and enables safe rollback. All of these capabilities that enable frequent deployment also improve quality.
Infrequent deployment creates its own problems. When you deploy monthly, each deployment contains a month of changes. Testing becomes exponentially more complex because you’re validating interactions between dozens of changes rather than a single change. When something goes wrong, isolating the problematic change requires analyzing a month of work. When you need to roll back, you’re rolling back a month of progress instead of a single feature.
Deployment frequency also affects team dynamics and culture. When deployment happens infrequently, it often requires coordination across multiple teams, specialized deployment engineers, and sometimes weekend work. When deployment happens frequently, it becomes something any developer can trigger during normal working hours. This shift reduces bottlenecks and enables teams to take ownership of their entire delivery pipeline.
The psychological impact matters too. When deployment is rare and risky, conservation makes sense. Refactoring might destabilize the deployment. Small bug fixes add complexity to an already complex release. When deployment is frequent and safe, these trade-offs change. The cost of deploying a one-line fix becomes negligible, so problems get fixed immediately rather than deferred.
The difference between teams that deploy multiple times per day and teams that deploy monthly usually isn’t skill or funding. It’s investment in automation and de-risking the deployment process to the point where deploying becomes routine rather than exceptional.
Mean Time to Restore#
Mean time to restore measures how long it takes to recover from a production failure. This metric captures your organization’s resilience and ability to respond when things go wrong. In production systems, things will go wrong. The question is how quickly you can restore service.
MTTR reveals whether your team has the capabilities needed to respond to incidents effectively. Short MTTR requires good monitoring so you detect problems quickly. It requires clear ownership so someone responds immediately rather than waiting for escalation. It requires deployment automation so you can roll back or deploy fixes without manual procedures. It requires architecture that enables isolating and fixing problems without full system restarts.
Organizations often focus heavily on preventing failures, which is valuable and necessary. Prevention alone isn’t sufficient, though. Complex systems inevitably encounter scenarios that testing didn’t cover, edge cases that requirements didn’t anticipate, and environmental conditions that staging didn’t replicate. When prevention fails, recovery speed determines customer impact.
Strong MTTR performance comes from recovery capabilities, not absence of incidents. When teams detect problems within minutes through automated monitoring, have engineers available who understand the system, can deploy fixes or rollbacks within minutes through automated pipelines, and validate changes through automated tests, they can restore service before many customers notice the problem. When problems are discovered through customer complaints, require escalation to find someone who can investigate, need manual deployment procedures coordinating across teams, and depend on manual testing for validation, recovery takes hours or days.
MTTR also measures your deployment capabilities under pressure. When teams can deploy fixes quickly during incidents, it’s because deployment is automated to the point where it works reliably even when people are stressed. When deployment during incidents is difficult, it’s often because manual deployment processes that work fine during planned deployments become unreliable when someone needs to execute them under time pressure at 2 AM.
The relationship between deployment frequency and MTTR is strong. Teams that deploy frequently have the automation and confidence to deploy fixes quickly during incidents. Teams that deploy infrequently struggle to deploy during incidents because deployment isn’t a routine operation. When deployment happens monthly, deploying an emergency hotfix means executing a rarely-used procedure under time pressure. When deployment happens hourly, deploying a fix is exactly the same procedure you used an hour ago.
Improving MTTR often reveals organizational bottlenecks that aren’t visible during normal operations. If restoring service requires specific people, you’ve identified a knowledge-sharing problem. If restoring service requires management approval, you’ve identified a trust problem. If restoring service requires coordinating across multiple teams, you’ve identified an architecture problem. MTTR measures the outcome, but improving it requires addressing root causes in your organization and systems.
Change Fail Percentage#
Change fail percentage measures how often deployments cause production failures that require remediation. This metric captures the quality and reliability of your delivery process. It answers a fundamental question: when you deploy changes, how often do those changes create problems?
This metric balances the pressure to deploy frequently with the need to maintain system stability. Organizations that optimize purely for deployment speed without considering failure rates end up deploying broken code rapidly. Organizations that optimize purely for preventing failures end up deploying so rarely that they cannot respond to customer needs. Change fail percentage helps you find the balance.
Low change fail percentage indicates that your quality processes work. You have effective testing that catches problems before production. You have good requirements that ensure the right thing gets built. You have architecture that isolates changes so they fail safely. You have deployment automation that handles the mechanics correctly. When these capabilities are strong, most deployments succeed without incident.
High change fail percentage signals opportunities for improvement in your development or deployment process. Frequent production failures after deployment suggest gaps in testing coverage, differences between staging and production environments, errors introduced during deployment itself, or insufficient review processes. The metric doesn’t diagnose which specific gap you’re facing, but it makes the pattern visible so you can investigate.
The definition of failure matters when measuring this metric. A failure is any deployment that requires immediate remediation, whether through rollback, hotfix, or configuration change. A deployment that works correctly but doesn’t achieve the desired business outcome isn’t a failure for this metric. A deployment that causes customer-visible errors or service degradation is a failure. The distinction is between technical failures that break the system and product decisions that don’t achieve goals.
Change fail percentage interacts with deployment frequency in important ways. If you deploy once per month and 50% of deployments fail, you have catastrophic quality problems. If you deploy ten times per day and 5% of deployments fail, you might have reasonable quality with effective detection and recovery. The same percentage means different things depending on deployment patterns.
The temptation exists to define failure narrowly to exclude certain incidents. This undermines the value of measurement. The goal isn’t achieving impressive numbers through careful definitions. The goal is honestly measuring how often deployments cause problems so you can identify and address root causes in your delivery process.
Improving change fail percentage often requires addressing multiple areas simultaneously. Better automated testing catches more problems before deployment. Better staging environments that mirror production reveal issues during development. Better monitoring detects problems quickly so they can be remediated before they affect many customers. Better deployment automation reduces the mechanical errors that occur during manual deployments. Better architecture isolates changes so failures affect fewer users.
Organizations that maintain change fail percentages around 15% or lower while deploying frequently have typically invested in testing, automation, and monitoring infrastructure. When change fail percentages exceed 50%, a common response is deploying less frequently to reduce risk. This creates a challenging cycle where infrequent deployment makes each deployment carry more changes and therefore more risk, which reinforces the need to deploy carefully and infrequently.
Using These Metrics#
These four metrics work together to paint a complete picture of software delivery performance. Optimizing one metric while ignoring the others creates dysfunctional outcomes. Deploying frequently with high change fail percentage means shipping broken code quickly. Deploying rarely with low change fail percentage means delivering value slowly. Fast MTTR with long lead time means you can fix production quickly but can’t ship new features. Short lead time with slow MTTR means you ship fast but can’t respond to problems.
Start measuring these metrics with simple tools before building sophisticated dashboards. Lead time comes from comparing commit timestamps to deployment timestamps. Deployment frequency comes from counting deployments per day or week. MTTR comes from incident management systems or deployment logs. Change fail percentage comes from correlating deployments with incidents. Most teams already have this data scattered across their tools.
Use these metrics to drive improvement conversations rather than judge individuals. If lead time is long, discuss what slows down the path to production. If deployment frequency is low, explore what makes deployment difficult or risky. If MTTR is high, investigate what makes responding to incidents complicated. If change fail percentage is high, examine what quality processes are missing or ineffective.
Improving these metrics involves common investments regardless of your starting point. Automation makes deployment reliable and fast. Monitoring detects problems quickly. Architecture that isolates changes enables safe rollback. Practices that ensure quality before deployment reduce failure rates. Culture that values rapid feedback and continuous improvement sustains progress over time.
You don’t need to achieve perfect scores on all four metrics to benefit from measuring them. Simply making these metrics visible often reveals opportunities for improvement that were previously hidden. Discovering your lead time is two weeks when you assumed it was days gives you a clear target for improvement. Learning your change fail percentage is 40% helps connect deployment patterns to customer experience.
These metrics represent capabilities that compound over time. Small improvements in lead time enable more frequent deployment. More frequent deployment drives better automation. Better automation improves change fail percentage. Lower change fail percentage builds confidence to deploy more frequently. The organizations that invest in these capabilities create advantages that competitors struggle to replicate because the capabilities reinforce each other.