A development manager from a large enterprise organization once described how his team had built a DevOps maturity model based on CMMI. He explained their current maturity level and laid out a three-year roadmap to reach ‘full maturity.’ The plan had already been presented to executive leadership, which had approved the creation of a new ‘DevOps team’ to drive the effort forward.
This story is far from unique. As enterprise organizations move beyond early experimentation and try to scale DevOps adoption, many are turning to formal maturity models to gauge their progress and benchmark themselves against peers. The impulse is understandable. The consequences, however, can be quietly damaging—and we have seen this pattern play out before.
The Danger of Maturity Models
Organizations that adopt maturity frameworks are usually well-intentioned. But once the conversation shifts to maturity scores, benchmarks, and peer comparisons, it tends to follow a predictable and unproductive arc.
Maturity assessments typically serve two masters: they reassure an organization that it is not doing ‘too badly,’ and they identify gaps that can be addressed through additional consulting engagements or technology purchases. The client feels validated. The consultant finds their next project. And the organization’s actual operational posture rarely improves in any meaningful way.
Enterprise executives tend to embrace these assessments because they provide political cover. Being able to show leadership that you are monitoring your current state, comparing it against a framework, and funding improvement initiatives looks like responsible management. In practice, it is often a performance—a dance that signals action without producing transformation.
The Risks Inherent in ‘Doing DevOps’
The rise of DevOps maturity models has been predictable. Consulting firms and technology vendors produce them because DevOps, at its core, is a cultural transformation—not a traditional IT project with clear deliverables and measurable milestones. That ambiguity creates demand for external frameworks that help executives explain what they are doing and why it is worth the investment.
The same pressure that drives demand for maturity models also drives the creation of structural artefacts like dedicated DevOps teams and new job titles such as ‘DevOps Engineer.’ These structures communicate to the organization that leadership is taking DevOps seriously. But they also fundamentally misunderstand what DevOps is.
DevOps is not a department. Creating a siloed DevOps team does not eliminate silos—it adds a new one. If the goal is to break down the wall between development and operations and foster a culture of shared ownership and continuous improvement, standing up a separate team labelled ‘DevOps’ moves the organisation in exactly the wrong direction. The structure itself becomes an obstacle to the cultural shift it was meant to accelerate.
At its core, DevOps is a cultural transformation—a new way of working and collaborating—that brings the organisation together to deliver better services more efficiently, rapidly, and reliably.
Adopting DevOps principles in narrow pockets of an organisation can make sense during early experimentation. But for DevOps to be genuinely effective, those principles must be applied holistically across the entire enterprise—not delegated to a single team.
Don’t Confuse DevOps with Continuous Delivery
A significant source of confusion is the conflation of DevOps with Continuous Delivery (CD). Many organisations treat the two as synonymous, viewing DevOps primarily as a deployment automation strategy and applying it on an application-by-application basis. This is a category error.
Continuous Delivery is a structured engineering practice: developers continuously integrate code throughout the development lifecycle and, using high degrees of automation, rapidly test and deploy that code into production. CD is powerful. It can dramatically reduce time-to-market, improve software quality, and increase organisational agility. For customer-facing, business-critical applications, it is often essential.
But CD is not universally applicable. Many enterprise applications are critical to operations without being sources of competitive differentiation. They do not demand the same rate of change, and the investment required to build and maintain a full CD pipeline may not be justified. CD principles should therefore be applied selectively, based on the characteristics of each application.
DevOps is different. It is not a methodology to be applied to individual applications. It is an overarching philosophy—a new operating model for how IT works, collaborates, and delivers value. The ‘dev’ and ‘ops’ in the name create a misleadingly narrow impression of its scope. In practice, DevOps should govern the entire IT organisation, and as enterprises become increasingly software-defined, it should extend beyond IT entirely.
| Dimension | Continuous Delivery | DevOps |
|---|---|---|
| Scope | Application-level practice | Organisation-wide philosophy |
| Focus | Deployment pipeline automation | Culture, collaboration, and shared ownership |
| Application | Selective, based on application needs | Holistic, applied across the entire enterprise |
| Outcome | Faster, more reliable releases | Integrated, adaptive IT operating model |
What DevOps Pioneers Actually Talk About
There is one reliable way to distinguish genuine DevOps practitioners from organisations performing DevOps: pioneers never talk about maturity.
Consider the contrast described at a conference where the enterprise application manager spoke at length about his maturity model—and a founder of the DevOps movement at Netflix spoke in the same room. The Netflix practitioner never used the word ‘maturity.’ Instead, he talked about business objectives. He discussed continuous improvement of deployment processes. He described efforts to make systems and development workflows more resilient. He mentioned specific tools being evaluated to support those goals.
The difference in framing is not cosmetic. It reflects a fundamentally different relationship with the work. One approach asks, ‘What level are we at?’ The other asks, ‘What are we trying to achieve, and how do we get better at it?’
The second question is the right one. It keeps the focus on outcomes rather than on the performance of improvement. It resists the temptation to treat DevOps as a destination rather than an ongoing practice.
How Enterprises Can Avoid the Trap
None of this means that enterprise organisations are wrong to want visibility into their DevOps progress. The political pressures that drive executives toward maturity models and dedicated DevOps teams are real. Justifying resource allocation and demonstrating progress to leadership are legitimate needs.
The problem is not the desire for accountability—it is the mechanism used to satisfy it. Maturity scores and organisational structures are proxies for progress. They are easy to produce and easy to present, but they measure inputs and activities rather than outcomes.
A more productive approach focuses on the following:
- Business outcomes over maturity scores. Define what success looks like in terms of deployment frequency, lead time for changes, mean time to recovery, and change failure rate—metrics that reflect real operational improvement rather than framework compliance.
- Cultural change over structural change. Resist the urge to solve a cultural problem by reorganising the org chart. Embedding DevOps principles into existing teams is harder to communicate upward, but it is more likely to produce lasting change.
- Continuous improvement over milestone achievement. Treat DevOps as an ongoing practice of learning and adaptation. There is no ‘full maturity’ to reach—only the next improvement to make.
- Holistic adoption over isolated pilots. Pilot programmes have value, but the goal should always be to spread principles across the entire organisation, not to preserve a DevOps team as a permanent island of good practice.
The Bottom Line
Maturity models and dedicated DevOps teams are understandable responses to the political pressures of enterprise IT. But they carry a real risk: they allow organisations to feel like they are transforming without actually doing the hard work of transformation. DevOps done well is not a level to achieve—it is a way of operating. The moment an organisation starts asking ‘are we mature yet?’ it may already be losing sight of the question that matters: ‘are we getting better?’
This article draws on analysis originally published at news.sys-con.com.