This article summarises findings from the 2019 State of DevOps Report, originally discussed on DZone. All metrics and category definitions referenced below are drawn from that report.
DevOps Is a Continuous Journey, Not a Destination
Since the term “DevOps” was coined in 2009, the discipline has evolved rapidly. By 2019, organisations of every size — from early-stage startups to large enterprises — were deep in their own DevOps stories. Some were just beginning; others had reached a mature, high-performing state. What distinguishes DevOps from most technology initiatives is that there is no finish line: the goal is perpetual improvement.
As businesses become increasingly software-driven, DevOps is no longer just a concern for engineers and technology leaders. Business stakeholders are actively interested in DevOps concepts because they recognise the direct connection between software delivery performance and business outcomes.
The 2019 State of DevOps Report: Why It Matters
The 2019 State of DevOps Report is one of the most widely cited annual resources for understanding how DevOps practices shape software delivery across industries. It summarises trends, identifies challenges, and — crucially — maps out the specific capabilities that help teams improve their delivery performance and ultimately reach elite status.
One notable shift in the 2019 edition: the report reframes “IT Performance” as Software Delivery Performance. This change cleanly separates software delivery work from IT help-desk and other support functions, giving practitioners a more precise vocabulary for measuring what matters.
Five SDO Performance Metrics: Measuring What Matters
A key contribution of the 2019 report is the introduction of five Software Delivery and Operational (SDO) performance metrics. These metrics focus on system-level outcomes rather than individual team or function-level activity, helping organisations avoid the classic trap of local optimisations that harm overall delivery flow.
The five SDO metrics encompass four core software delivery measures plus an operational stability dimension:
- Deployment Frequency — How often does your organisation deploy code to production for its primary application or service?
- Lead Time for Changes — How long does it take to go from a code commit to that code running successfully in production?
- Time to Restore Service — When a service incident occurs (unplanned outage or service impairment), how long does it generally take to restore service?
- Change Failure Rate — What percentage of changes result in degraded service or require remediation (hot-fix, rollback, patch, fix-forward)?
- Availability / Reliability (operational metric) — Does the service meet its availability targets? (Added to complete the delivery-to-operations cycle.)
By combining delivery speed metrics with operational stability metrics, the SDO framework discourages teams from optimising purely for speed at the expense of reliability — or vice versa.
Four Performance Tiers: Elite, High, Medium, and Low
The report uses the four core delivery metrics to rank organisations into four performance buckets:
- Elite — Multiple deployments per day; lead time of less than one hour; time to restore under one hour; change failure rate of 0–15%.
- High — Between once per day and once per week; lead time of one day to one week; restore time less than one day; change failure rate of 0–15%.
- Medium — Between once per week and once per month; lead time of one week to one month; restore time less than one day; change failure rate of 0–15%.
- Low — Between once per month and once every six months; lead time of one to six months; restore time between one day and one week; change failure rate of 46–60%.
Note: The exact threshold values above are drawn from the report’s published summary data. Readers should consult the full 2019 State of DevOps Report for precise figures and methodology details.
The J-Curve of Transformation
One of the most practically useful concepts in the 2019 report is the J-Curve of Transformation. The J-Curve describes how organisations typically progress — and sometimes regress — on their DevOps journey:
- Automation lifts low performers — Initial investment in automation (CI/CD pipelines, infrastructure as code, automated testing) moves teams from low to medium performance relatively quickly.
- Progress stalls in the middle — As codebases grow, test requirements multiply, technical debt accumulates, and system complexity increases. These pressures can push teams back toward manual controls, causing a visible dip — the bottom of the J.
- Relentless improvement drives the climb — Teams that continue investing in technical practices, learning culture, and continuous improvement work their way up to high or elite performance.
A critical insight from the J-Curve: automation is not a silver bullet. Automating a flawed process does not fix it — it produces wrong outcomes faster. Before automating, teams need to examine and improve the underlying process.
Engines and Anchors: Visualising the Path to Elite Performance
A useful mental model for understanding what drives teams toward elite performance — and what holds them back — is the Sailboat (or Speedboat) Retrospective format, which categorises factors as either engines (things that propel you forward) or anchors (things that slow you down).
| Engines (Catalysts) | Anchors (Blockers) |
|---|---|
| Continuous integration and delivery automation | Accumulated technical debt |
| Strong automated test coverage | Inadequate or poorly defined test requirements |
| Continuous improvement culture | Increasing system complexity without corresponding investment |
| Cross-functional collaboration | Siloed teams and manual handoffs |
| Leadership sponsorship and psychological safety | Lack of organisational support for improvement work |
Reaching elite performance requires more than tools. Persistence, perseverance, and genuine organisational commitment — at team, leadership, and executive sponsor levels — are necessary to break through from medium performance to high or elite.
The Rise of Elite Performers
One of the headline findings of the 2019 report is encouraging: the proportion of elite performers had almost tripled compared to earlier surveys, while the proportion of low performers declined. Medium performers also increased in proportion, suggesting that the overall population is shifting upward.
However, the report is careful to note that movement between tiers is not unidirectional. Teams that achieve high performance can drop back to medium — or even low — when they face a surge in complexity, a large acquisition, or a significant architectural overhaul. Maintaining elite performance requires sustained investment and discipline, not a one-time transformation effort.
A Missing Metric Worth Considering: Team Engagement
While the five SDO metrics cover the technical and operational dimensions of delivery, one dimension the report does not formally measure is team engagement — how satisfied, motivated, and psychologically safe teams feel. There is a strong argument that team engagement is a leading indicator of delivery performance: engaged teams are more likely to invest in improvement, surface problems early, and sustain high performance over time. Practitioners building their own measurement frameworks may want to supplement SDO metrics with team health or engagement surveys.
Key Takeaways for DevOps Practitioners
- Measure software delivery using system-level outcomes (the four SDO delivery metrics plus operational stability), not local team metrics that create perverse incentives.
- Understand where your team sits across the four performance tiers and identify concrete capabilities to move up.
- Expect a J-Curve: early automation gains may plateau as complexity grows. Plan for the dip and invest in addressing root causes rather than applying more automation to broken processes.
- Treat elite performance as a sustained practice, not a project milestone — teams can and do regress under pressure.
- Complement technical metrics with qualitative signals such as team engagement and psychological safety.