This article draws on reporting from CIO Dive and findings from the 2019 DORA (DevOps Research and Assessment) State of DevOps report.
The Uncomfortable Truth: There Is No DevOps Playbook
Every engineering leader wants a step-by-step maturity model — a clear, prescriptive path from “no DevOps” to “elite performer.” According to Nicole Forsgren, then lead of DevOps Research and Assessment (DORA) and head of research and strategy at Google Cloud, that model does not exist and cannot be made to work.
“Everyone wants a maturity model,” Forsgren told CIO Dive. “They want this easy, prescriptive path telling them exactly where it should go, and what we’ve seen is that that doesn’t work because no two organizations look alike, no two teams in an organization look alike.”
This is not pessimism — it is an evidence-based finding drawn from six years of research and data from more than 31,000 professionals across sectors. The research identified what works and what does not when organizations develop and deploy software at scale. The conclusion: strategy must be designed around your specific constraints, not borrowed wholesale from another company’s journey.
Start With a Constraints-Based Approach
The practical starting point for any DevOps initiative is identifying your organization’s single biggest bottleneck and attacking it first. Forsgren’s guidance is deliberately simple: “When it’s no longer your problem, do your next problem.”
This constraints-based thinking — influenced by the Theory of Constraints — prevents organizations from spreading effort too thinly across many improvement areas simultaneously. Fixing your second-biggest problem before your biggest problem yields little measurable improvement. Once the primary constraint is resolved, the next constraint naturally rises to prominence and becomes the next target.
Applying this to DevOps adoption in practice means asking:
- Where does work slow down most visibly — planning, build, test, deployment, or incident response?
- Which team or process creates the longest wait time for others?
- What failure mode causes the most disruption to end users or the business?
Answering these questions honestly gives leadership a defensible, data-driven place to begin investment.
What the DORA Research Found: Common Threads of Success
Although no two DevOps strategies are identical, DORA’s research identified consistent patterns among the highest-performing organizations:
- Community structures matter. High performers scale DevOps by building communities of practice at both the management and individual contributor level, not by mandating process changes from a central team.
- Large-scale change comes from management. Grassroots momentum can spark interest, but durable, organization-wide change requires leadership involvement — particularly at the middle management layer.
- Speed, stability, and availability are the key levers. Software delivery performance across these three dimensions is the clearest indicator of an organization’s overall technology transformation progress.
- Cloud adoption improves delivery performance. Organizations that leverage cloud infrastructure demonstrate stronger software delivery performance and operational availability than those relying primarily on on-premises infrastructure.
The Performance Gap: Elite vs. Low Performers
The 2019 DORA State of DevOps report categorized organizations into four software delivery and operational (SDO) performance tiers: elite, high, medium, and low. The data revealed a striking and widening gap between the top and bottom tiers.
- In 2019, 20% of organizations qualified as elite performers, up sharply from 7% the previous year.
- Medium performers grew from 37% to 44%, indicating the field is maturing overall.
- The proportion of low performers continued to shrink.
Despite the positive trend, the chasm between elite and low performers remains stark:
- Elite performers deploy code 208 times more frequently than low performers. In concrete terms, elite performers deploy on demand — multiple times per day. Organizations such as Amazon, Google, and Netflix deploy thousands of times per day, according to DORA. Low performers deploy once a month or as infrequently as once every six months.
- Elite performers recover from incidents 2,604 times faster than low performers, a difference that has profound implications for customer experience and business continuity.
For large enterprises — organizations with 5,000 or more employees — these gaps are especially difficult to close. DORA’s 2019 data showed that enterprises generally score lower on SDO performance than smaller organizations, largely because legacy processes, entrenched controls, and aging infrastructure create inertia that slows adoption.
Effective Evangelism: Who Actually Drives DevOps Adoption
The DevOps movement, approaching its second decade, has matured beyond grassroots enthusiasm. Early adoption often started at the team level, with developers and system administrators demonstrating the value of automation and continuous integration until the C-suite noticed. That model still exists, but it is no longer the dominant driver of success.
Forsgren is direct on what only leadership can do: “Only leaders can change your process. That’s a bureaucracy thing.”
The 2019 research elevated the role of middle management in particular. Alanna Brown, senior director of developer relations and lead researcher of the Puppet State of DevOps report, explained the dynamic to CIO Dive: “The middle management layer is critically important in the DevOps evolution as they can translate both the business needs and the on-the-ground needs to make it happen across those teams.”
Middle managers serve as the connective tissue between executive vision and engineering execution. They prevent siloed knowledge, align priorities, and carry context in both directions. Without this layer functioning effectively, DevOps initiatives tend to fragment — teams optimize locally without contributing to organization-wide improvement.
Dividing Responsibilities: Teams vs. Leadership
A healthy DevOps organization separates concerns appropriately between individual contributors and management, rather than asking either group to do everything.
What individual contributors and teams should own:
- Deploying automation within their scope
- Implementing and improving continuous integration pipelines
- Automating test suites and quality gates
- Iterating on local delivery processes
What leaders and managers should own:
- Setting and enforcing organization-wide processes and standards
- Removing structural blockers that individuals cannot resolve
- Sponsoring cloud adoption and infrastructure investment
- Coordinating disaster recovery testing across teams
As Forsgren put it, leaders and VPs “should probably not be putting their hands on code” — but they must actively create the conditions in which good engineering practices can spread and take root.
Building Community to Sustain DevOps at Scale
Once the right leadership structure is in place, sustainable scaling depends on community — not mandates. DORA’s research found that the highest-performing organizations build communities of practice that survive reorganizations and major product changes. A DevOps transformation anchored only to a particular team, tool, or champion is fragile. A community of practitioners who share knowledge, set standards, and support each other is durable.
Practical steps toward building that community include:
- Creating internal guilds or working groups around reliability, CI/CD, and security
- Establishing shared metrics and definitions of “done” across teams
- Making internal case studies and post-mortems widely available
- Recognizing and amplifying teams that demonstrate elite practices
Key Takeaways
- There is no universal DevOps maturity model. Strategy must be tailored to each organization’s specific constraints.
- Start by identifying and addressing your single largest bottleneck before moving to the next.
- DORA research consistently links software delivery speed, stability, and availability to overall organizational performance.
- Middle management is a critical, often overlooked, driver of DevOps adoption at scale.
- The gap between elite and low software delivery performers is large and consequential — but the proportion of elite performers is growing.
- Community structures, not top-down mandates, sustain DevOps transformation over time.