Most technology organizations do not have a delivery problem. They have a measurement problem.
They run standups, maintain project boards, staff change advisory boards, and hold quarterly planning sessions.
They even hire some bespoke hipsters in flannel, cosplaying as SREs, complete with matching John Lennon eyeglasses.
Everyone can explain why the current delay is exceptional, why the latest incident was unusual, and why the next release will be cleaner. Then a deployment causes an outage. A migration collapses under production conditions. A security patch sits unresolved for weeks. And it becomes clear that no one actually knew how fast they could ship, how often changes failed, or how long recovery took.
That’s where DORA metrics matter.
DORA stands for DevOps Research and Assessment, a multi-year research program that studied thousands of software organizations to identify what separates high-performing teams from struggling ones. The findings were published in the book Accelerate, and the conclusion was unambiguous: organizations that perform well on these metrics ship faster, break less, and recover more quickly, and that performance correlates directly with profitability, customer satisfaction, and competitive positioning.
The four metrics are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore (MTTR). Together they answer one question most executives assume someone already knows: can this organization change its own systems without creating unacceptable operational risk?
In too many organizations, the honest answer is that no one knows.
But But But “We Have a Process”
Most teams believe they are mature because they have ceremonies and controls. Release windows. Approval workflows. Incident review calls. Dashboards that measure system health, which is not the same thing as delivery capability.
A change process can exist without measuring whether changes are getting safer. A release calendar can exist without knowing whether lead time is improving. A governance forum can exist without ever answering whether teams are becoming more resilient or simply more articulate at explaining failure after the fact.
DORA metrics force an organization to stop confusing activity with capability. They create a shared language between engineering, operations, risk, security, and leadership. Without that shared language, the organization manages delivery through status updates, anecdotes, and after-the-fact explanations. That holds when conditions are calm. It does not hold when a deployment fails in front of real customers.
What Each Metric Means and Why It Matters
Deployment Frequency measures how often the organization successfully releases working software to production. Not commits made or sprints completed. How often functioning software actually reaches users.
Business value: High deployment frequency means shipping in small, controlled increments rather than large, risky batches where errors are harder to isolate and rollback is more expensive.
Consequence of not knowing it: the organization may be batching enormous amounts of change into rare, high-stakes release events without realizing it. When one of those releases fails, the blast radius and the recovery cost are proportionally larger.
Lead Time for Changes measures how long it takes a code change to travel from a developer’s commit to running in production.
Business value: short lead time means the organization can act quickly on a critical security patch, a regulatory fix, or a production incident. It is a direct measure of how much friction exists between decision and execution.
Consequence of not knowing it: a team may believe patches are being applied promptly while the actual time from identification to verified deployment is measured in weeks. That gap is active exposure time, and in a regulated environment it is also potential liability.
Change Failure Rate measures what percentage of deployments result in degraded production service, an emergency hotfix, a rollback, or unplanned remediation.
Business value: this metric cuts through release-volume vanity. A team can deploy frequently and still be reckless. A team can deploy rarely and still fail at an unacceptable rate. Change Failure Rate shows what is actually happening in production.
Consequence of not knowing it: the organization may have no idea whether its own releases are a primary source of the customer disruption it is simultaneously trying to resolve. That is not a hypothetical. It is a common pattern in organizations where delivery and operations are siloed.
Mean Time to Restore (MTTR) measures how long it takes the organization to recover from a production failure. Not how long it takes to open a war room. How long it takes customers to have working service again.
Business value: fast MTTR reflects investments in monitoring, rollback design, documented runbooks, and practiced restoration. It reflects whether recovery is an engineered capability or an improvised scramble.
Consequence of not knowing it: when a failure occurs, the organization discovers its recovery capability in real time, under full operational pressure, with no rehearsal. That is the worst possible time to find out that recovery depends on one person who understands the affected system and happens to be reachable.
Four Cases Where the Absence of These Metrics Had Consequences
Knight Capital: Delivery Discipline as Market Risk
On August 1, 2012, Knight Capital Group deployed a software update to its automated equity trading system. Within 45 minutes of market open, the system sent more than 4 million unintended orders, accumulated billions in unwanted equity positions, and produced a loss exceeding $460 million. The firm was acquired shortly afterward. The SEC, the Securities and Exchange Commission, which regulates U.S. securities markets, charged Knight with market access violations and assessed a $12 million penalty.
The SEC documented that Knight’s systems generated 97 automated error emails before market open flagging the problem. The firm did not act on them. The signals existed. The operational infrastructure to convert those signals into control did not.
A team tracking Change Failure Rate and MTTR would have demanded answers before that deployment reached production: Is the rollout verified across every relevant server? What is the recovery time objective for a failed deployment in a live trading environment? Are our alerts owned and rehearsed? In a high-velocity financial environment, software delivery is not a back-office concern. It is market risk.
TSB Bank: When Transformation Outruns Operational Readiness
In 2018, TSB Bank attempted to migrate approximately 1.3 billion customer records to a new platform operated by its parent company. The migration failed. Customers were locked out of accounts. Some gained unintended visibility into other customers’ information. Core banking services were disrupted for weeks. In December 2022, the FCA, the Financial Conduct Authority, the United Kingdom’s primary financial services regulator, fined TSB £48.65 million for operational resilience failings, finding that TSB had failed to adequately organize and control the migration and had failed to manage risks from its outsourcing arrangements. The bank’s chief executive resigned. Total costs exceeded 300 million pounds.
Executive confidence was high. Vendor confidence was high. Program confidence was high. None of that was the same as demonstrated delivery capability.
The governing question before a migration of that scale is not whether the project plan looks complete. It is: what does our Change Failure Rate look like under realistic production load, and what is our MTTR when a migration step fails? An organization that cannot answer those questions has confused planning with readiness.
Equifax: When Lead Time for Changes Becomes Security Exposure
In 2017, Equifax failed to patch a critical vulnerability affecting a system handling consumer credit data. The FTC, the Federal Trade Commission, which enforces consumer protection law in the United States, alleged that Equifax did not remediate after being alerted in March 2017, despite its own security team ordering a patch within 48 hours, and that Equifax failed to verify whether the order had been carried out. Equifax later settled with the FTC, the CFPB (the Consumer Financial Protection Bureau, which supervises financial products and services), and state regulators for at least $575 million.
For security remediation, Lead Time for Changes is exposure time. Every day a critical patch sits in a backlog is a day the risk remains exploitable. Equifax’s failure was not that a vulnerability existed. The failure was that the organization could not translate a known risk into a verified production change and had no instrumentation to confirm the remediation had been executed. Security teams can identify risk precisely. The delivery system determines how quickly that risk is actually reduced. If the delivery system is opaque and unverified, the security program is partially performative regardless of how sophisticated its detection capabilities are. You cannot secure what you cannot reliably change.
Meta’s 2021 Outage: Recovery Must Be Engineered, Not Improvised
On October 4, 2021, Facebook, Instagram, and WhatsApp all went offline for approximately six hours. Meta explained that a configuration change to backbone routers severed communication between data centers, creating a cascade that brought services down. Restoration was further complicated because internal recovery tools were hosted on the same affected infrastructure.
Cloudflare’s public analysis noted the failure presented as BGP (Border Gateway Protocol, the system governing how internet networks route traffic) and DNS (Domain Name System, the directory that translates web addresses into server locations) failure simultaneously, extending the cascading effect well beyond the initial error.
Meta is among the most technically capable organizations in the world, which is precisely the point. Even technically elite organizations experience cascading failure from configuration changes in complex systems. What separates organizations in those moments is whether recovery is engineered and practiced, or assembled under pressure while customers wait. An organization that does not track MTTR has no baseline to improve against, no rehearsed playbook to execute, and no visibility into whether its recovery capability is strengthening or eroding.
Why This Is Especially Dangerous Across Industries
A banking or fintech organization is not simply running software. It is running trust infrastructure. Payments must process. Authentication must work. Fraud controls must function. Regulatory obligations do not pause because a deployment went sideways. A leadership team that cannot articulate these four metrics is not facing a vocabulary gap. It is operating with a measurement gap that carries direct consequences for customers, regulators, and its own risk posture.
But the stakes are not unique to financial services. They exist in any organization where software failure has a direct, visible, and time-sensitive impact on the people it serves.
Consider the live sports and entertainment industry. An organization producing hundreds of live events annually across dozens of countries, managing concurrent ticketing surges, pay-per-view broadcasts, and high-volume checkout flows at the moment of peak global demand, depends on infrastructure that cannot fail during the moments that matter most. When a championship ticket sale opens, tens of thousands of transactions hit a single checkout flow within minutes. When a broadcast goes live, every latency spike is visible to a global audience. The revenue window is defined by the clock on the broadcast, not by the readiness of the deployment pipeline.
In that context, every metric has a direct operational translation. Deployment Frequency determines whether engineering can push fixes in the compressed window before a major event. Lead Time for Changes determines how quickly a critical payment fix or security patch reaches production. Change Failure Rate determines whether event-day deployments are a calculated risk or a recurring source of fan-facing disruption. And MTTR determines whether recovery from a live-event failure is a practiced sixty-second rollback or a multi-hour war room improvising under pressure.
The same logic applies in healthcare, where a failed deployment affecting clinical workflow carries consequences well beyond operational inconvenience. It applies in e-commerce, where a degraded checkout during peak demand produces losses that cannot be recovered. It applies in logistics, where a platform outage ripples into supply chain disruption. In any environment where software changes must be controlled, auditable, and recoverable, the absence of delivery measurement is not a maturity gap. It is an operational risk with a predictable cost.
The industry does not change that conclusion. It only changes the story of how the consequences arrive.
If your team cannot explain these metrics, it probably cannot explain its own delivery system. And if it cannot explain its delivery system, it cannot credibly claim to control the operational risk that comes with changing software in a customer-facing environment.
It’s time to send your SREs back to Spirit Halloween for a costume change.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn