This article is based on reporting originally published at cloudcomputing-news.net covering the DORA Accelerate State of DevOps 2019 report, produced in partnership with Google Cloud.
Overview: Six Years of DevOps Research, One Clear Trend
The DORA (DevOps Research and Assessment) Accelerate State of DevOps 2019 report represents one of the most comprehensive longitudinal studies in the industry. Drawing on more than 31,000 survey responses gathered across six years of research, and produced in collaboration with Google Cloud, the report tracks how DevOps adoption and performance have evolved — and what separates elite performers from the rest of the field.
Two themes dominate the 2019 findings: the growing performance gap between top-tier DevOps teams and their peers, and the outsized role that cloud computing plays in enabling that performance. A third finding challenges a long-standing industry assumption — that heavyweight change approval processes improve stability.
Elite Performers Are Growing — and They’re Cloud Specialists
According to the 2019 report, the proportion of highest-performing DevOps teams has nearly tripled compared with earlier editions of the study, now representing approximately 20% of all respondents. This cohort continues to widen its lead over low and medium performers across key software delivery metrics including deployment frequency, lead time for changes, mean time to restore, and change failure rate.
Critically, cloud usage emerges as a strong differentiator. The report found that elite performers were 24 times more likely than low performers to be genuine cloud specialists. The study defined cloud specialisation using the five essential characteristics outlined in the NIST definition of cloud computing:
- On-demand self-service — teams can provision compute resources without requiring human interaction from the provider.
- Broad network access — capabilities are available over the network and accessible via standard mechanisms.
- Resource pooling — provider resources serve multiple consumers using a multi-tenant model.
- Rapid elasticity — capabilities can be scaled up or down quickly to meet demand.
- Measured service — resource usage is monitored, controlled, and reported transparently.
Organisations that operated across all five of these dimensions were far more likely to be classified as elite performers, suggesting that superficial cloud adoption — lifting and shifting workloads without embracing cloud-native operating models — does not deliver the same performance benefits.
The Problem with Heavyweight Change Approval Processes
One of the more provocative findings in the 2019 report concerns change management. For years, formal Change Approval Boards (CABs) and heavyweight approval workflows have been standard practice in ITSM-aligned organisations. The intuition behind them is understandable: if software releases are causing incidents, slow things down and add more gates.
The DORA data challenges this assumption directly. The report found that formal change approval processes — particularly those requiring sign-off from an external Change Approval Board — were associated with worse software delivery performance, not better. As the report states:
“Heavyweight change approval processes negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout.”
The research investigated a specific hypothesis: that requiring fewer, more formally approved releases would be associated with lower change failure rates. The data did not support it. Adding process gates in response to production incidents is, in the report’s framing, a red herring — one that slows delivery without improving reliability.
The Alternative: Shift Left, Automate, and Peer Review
Rather than relying on external approval boards, the report recommends moving quality and risk assessment earlier in the development lifecycle — a principle commonly described as “shifting left.” The report’s recommended approach combines human judgement with automation:
“Organisations should shift left to peer review-based approval during the development process. In addition to peer review, automation can be leveraged to detect, prevent, and correct bad changes much earlier in the delivery lifecycle. Techniques such as continuous testing, continuous integration, and comprehensive monitoring and observability provide early and automated detection, visibility, and fast feedback.”
In practical terms, this means replacing after-the-fact approval gates with engineering practices built into the development workflow:
- Peer code review — changes are reviewed by fellow engineers before merging, embedding risk assessment into the team’s normal workflow.
- Continuous integration (CI) — automated builds and tests run on every commit, catching integration problems early.
- Continuous testing — automated test suites cover unit, integration, and acceptance scenarios, reducing reliance on manual QA gates.
- Monitoring and observability — production telemetry enables fast detection and rollback when issues do reach production, reducing mean time to restore.
This approach does not eliminate process — it relocates it to where it is most effective and least disruptive to delivery flow.
Transformation Strategy: Why “Big Bang” Rarely Works
The 2019 report also addresses how organisations should approach DevOps transformation itself. The data suggests that incremental, sustained improvement consistently outperforms large-scale, all-at-once transformations — sometimes called a “big bang” strategy.
“One thing is clear: a DevOps transformation is not a passive phenomenon. No profiles report strong use of a ‘big bang’ strategy — though low performers use this the most often — and that’s probably for the best.”
The report elaborates on why big-bang approaches tend to struggle:
“In our experience, this is an incredibly difficult model to execute and should only be attempted in the most dire of situations, when a ‘full reset’ is needed. In the ‘big bang’, everyone needs to be on board for the long haul, with resources dedicated for a multi-year journey. This may explain why this method is seen most often among our low performers.”
The implication for engineering leaders is significant: organisations that attempt to transform everything at once — tooling, culture, process, and organisational structure simultaneously — face higher execution risk and tend to see worse outcomes than those who pursue targeted, iterative improvement.
Key Takeaways for DevOps and Platform Engineers
- Cloud specialisation matters. Adopting the full NIST model of cloud computing — not just migrating workloads — correlates strongly with elite DevOps performance.
- Change Approval Boards slow you down without improving stability. The data does not support the assumption that fewer, more formally approved releases reduce change failure rates.
- Shift quality left. Peer review, CI, continuous testing, and observability are more effective risk controls than external approval gates.
- Iterate, don’t reset. Incremental DevOps transformation outperforms big-bang approaches in the DORA dataset. Sustained, focused improvement is the pattern associated with elite performance.
The DORA Accelerate State of DevOps reports are published annually. For the full methodology and findings, refer to the official DORA research publications available through Google Cloud.