This article is based on reporting originally published by CIO Dive, drawing on interviews with practitioners and executives from Puppet, XebiaLabs, DORA, the College Board, and ISG.
The Gap Between DevOps Ideology and Enterprise Reality
Enterprise technology has a long history of reaching for the easy answer. Business stakeholders demand more than technologists consider reasonable, while ageing backend systems leave IT perpetually starved of resources, funding, and headcount. Nowhere is this tension more visible than in the gap between development and operations teams.
The traditional model is straightforward in its dysfunction: developers write software to meet business requirements, then hand it off to operations for deployment and maintenance. The two sides rarely share accountability, and when something breaks in production the blame travels in one direction while the pain travels in the other.
DevOps emerged as a cultural antidote to that dysfunction. By aligning development and operations around shared ownership of a product—from code commit to production incident—teams could move faster, break less, and recover more quickly when things did go wrong. The idea caught fire, propelled in part by books like The Phoenix Project and early adoption at web-scale companies such as Google, Twitter, and Facebook.
But somewhere between grassroots movement and enterprise mainstream, the essence of DevOps got diluted.
Tooling Without Culture: The Core Problem
“The thing I’m seeing over and over again is [companies are] adopting the tooling but not the process changes or the cultural changes” of DevOps, said Nigel Kersten, VP of Ecosystem Engineering at Puppet, in an interview with CIO Dive.
This pattern is understandable in context. When a methodology goes mainstream, vendors rush to serve it, executives mandate it, and organizations reach for the most tangible artefact they can buy or install. Tools are concrete. Culture is not. So tools win—at least in the short term.
“DevOps has been bastardized now from what it started as,” said T.J. Randall, VP of Customer Success at XebiaLabs, in an interview with CIO Dive. The original concept centered on closing the gap between two sides of the enterprise puzzle—development and operations—by encouraging collaboration, shared tooling, and mutual accountability.
Early DevOps practitioners were willing to experiment and iterate, treating failure as information. Today, Randall says, most customers arrive with a single request: “Just tell us what the right way to do this is.” They want a template. They want certainty. And in reaching for certainty, they skip the hard cultural work that makes DevOps valuable.
Jez Humble, co-founder and CTO of DevOps Research and Assessment (DORA), put it bluntly in correspondence with CIO Dive: “You can’t just buy tools or implement methodologies; you have to do the hard work of process improvement and capability development and learn what will work for your organization.”
Vendors to the Rescue—and to the Problem
A sprawling vendor ecosystem has grown up around DevOps, covering virtually every layer of the delivery stack:
- Cloud platforms (AWS, Microsoft Azure, Google Cloud) have embedded DevOps capabilities—pipelines, registries, monitoring—directly into their services.
- Collaboration tools (Atlassian, Slack) streamline communication between development and operations teams.
- CI/CD and automation vendors (Puppet, XebiaLabs, and many others) target the continuous integration, delivery, and deployment pipeline.
- Observability and analytics platforms (Splunk, Sumo Logic) provide visibility into production performance.
These tools are genuinely useful—when deployed within an organisation that has already done the cultural groundwork. The risk is that buying the tools becomes a substitute for doing that work.
Kersten pointed to a familiar pattern: “A lot of people rebadged existing software development tools—and often existing tools that were called ‘Agile’ five years earlier—and they just threw DevOps on the title.” The result is a market full of products claiming DevOps alignment while delivering little more than a renamed feature set.
Once commercialisation took hold, early DevOps advocates began to disengage. “We saw a lot of people who weren’t interested in the commercial side of DevOps start to back away somewhat in disgust,” Kersten noted.
What “DevOps Department” Actually Signals
One of the clearest warning signs of DevOps being adopted in form rather than substance is the creation of a dedicated “DevOps department” or the renaming of an existing operations team to DevOps.
“If you are creating a DevOps department, you might not be practicing DevOps,” said Jeff Olson, VP and Chief Data Officer at the College Board. “It’s possible to embrace the trapping of something without embracing the essence of it.”
Olson’s framing is instructive: the essence of DevOps is that the teams who develop software also operate it. Any organisational separation between those who write the code and those who run it creates what he calls a “moral hazard.” Developers who never experience a 2 a.m. production alert have less incentive to write operationally robust code. The accountability loop is broken before it begins.
The College Board—responsible for running the SAT and Advanced Placement exams—worked through this directly when migrating monolithic applications to the cloud. Rather than mandating a top-down transformation, the organisation stood up early “beachhead” teams charged with embodying core principles, including DevOps ownership. Each team’s success built organisational confidence and helped spread practices more broadly.
Top-Down Mandates vs. Grassroots Reality
Enterprise digital transformation initiatives have given DevOps a new source of momentum: executive sponsorship. But leadership-driven adoption carries its own distortions.
Executives who mandate DevOps often receive “filtered and sanitised” progress reports, leaving them unaware of the bottlenecks and broken processes stalling real adoption. This observation appeared in the 2018 State of DevOps report from Puppet and Splunk, which surveyed roughly 3,000 respondents.
That same report found that among companies at a medium level of DevOps maturity—which represented approximately 80% of respondents—only one-third reported a strong DevOps culture within a single team, with even fewer achieving that culture across multiple departments or the broader organisation. Among high-maturity organisations, only 19% had applied DevOps practices across multiple departments.
Grassroots adoption tells a different story. Kersten described the typical pattern: “pockets of success where individuals or teams have worked out how to adopt these practices and within their own sphere of influence and domain, they’ve been able to achieve really great things.” The problem is that these successes rarely spread organically. Every team sees its challenges as unique, and watching a peer team succeed is as likely to produce resentment as inspiration.
The Brownfield Problem: You’re Never Starting from Zero
DevOps is easiest to describe—and hardest to implement—in the context of a greenfield project, where teams can build architecture, tooling, and culture from scratch. But the majority of enterprise DevOps efforts today are brownfield: they happen inside organisations with decades of accumulated technical debt, organisational inertia, and entrenched process.
With DevOps, you’re “never ever starting from zero,” said Prashant Kelker, Partner and Lead for Digital Strategy and Solutions, EMEA at ISG. His view on the cultural change rhetoric is pointed: “Everybody says culture eats DevOps strategy for breakfast. I think architecture will eat strategy for breakfast. You simply can’t undo 30 years of legacy.”
According to Kersten, the first wave of DevOps adoption had a natural advantage: it was driven by web-scale companies—where engineering and operations staff often shared development skills—and by small startups building greenfield systems. Mainstream enterprise adoption lacks both of those structural advantages.
What Elite Performance Actually Looks Like
Despite the difficulties, the performance gap between organisations that have genuinely adopted DevOps and those that have not is stark. Research from DORA quantified software delivery performance across adopter maturity levels. The findings, as reported by CIO Dive, are summarised below.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On demand (multiple per day) | Between once per hour and once per day | Between once per week and once per month | Between once per week and once per month |
| Lead time (code commit to production) | Less than 1 hour | Between 1 day and 1 week | Between 1 week and 1 month | Between 1 month and 6 months |
The gap between elite and low performers is not incremental—it is measured in months versus minutes. That performance difference is the reason organisations continue to chase DevOps adoption even as implementation proves difficult.
Getting DevOps Right: What Genuine Adoption Requires
The practitioners quoted throughout this article converge on a consistent set of principles for organisations serious about DevOps transformation:
- Treat tools as enablers, not solutions. CI/CD pipelines, monitoring platforms, and collaboration software are necessary but not sufficient. They accelerate cultural change; they do not replace it.
- Keep development and operational accountability together. Organisational structures that separate who writes code from who runs it undermine the core value proposition of DevOps.
- Avoid naming DevOps departments. A dedicated DevOps team is often a sign that DevOps has been siloed rather than embedded across engineering.
- Expect iteration, not prescription. There is no universal DevOps template. Organisations must experiment, measure outcomes, and adapt. Randall’s customers who ask for a roadmap to follow are skipping the learning process that makes the roadmap meaningful.
- Engage stakeholders beyond engineering. If developers are the only drivers of a DevOps initiative, Randall warned, the effort tends to become 99% tools-focused, with the rest of the organisation left to figure out its own role.
- Make C-suite visibility accurate. Executives who only see sanitised progress reports cannot make informed decisions about where transformation is genuinely stalling.
The Risk of DevOps Becoming Another Tired Acronym
The trajectory of DevOps mirrors earlier enterprise methodology waves—Agile, ITIL, Lean—where genuine insight was packaged, commoditised, and gradually drained of meaning. The risk is not that DevOps fails technically. The risk is that enough organisations adopt the label without the substance that the term stops being useful as a signal of actual capability.
For teams that do the hard cultural work—breaking down organisational silos, tying developers to production accountability, iterating on process rather than just tooling—the rewards remain substantial. The DORA performance data makes that case clearly.
The question for any organisation embarking on DevOps is not which tools to buy. It is whether leadership is willing to accept that the hard part—process improvement, cultural change, and shared accountability—cannot be purchased.