DevOps Is Not a Tool, It Is a Culture Problem

A few years back, a large insurance company I was reading about spent somewhere in the range of eight figures on a DevOps transformation. They bought the toolchain: containerization, Kubernetes, a CI/CD platform, infrastructure as code, observability dashboards. They hired a DevOps consulting firm. They ran the workshops. And then, at the end of it, development was still writing tickets to operations, operations was still manually reviewing every deployment, and the release cycle was still monthly. The tools were there. DevOps was not.

I keep thinking about that pattern when I read the DevOps Research and Assessment work. DORA has been running large-scale surveys of software delivery professionals since the mid-2010s, publishing findings in their annual "State of DevOps" reports. What they consistently find is not that elite-performing organizations use better tools. What they find is that elite performers deploy code far more frequently, recover from failures much faster, and have lower change failure rates. The differences between elite and low performers on these dimensions are large, sometimes orders of magnitude across deployment frequency and recovery time. And the factors that predict which group an organization lands in are not primarily technical.

The four metrics DORA uses to measure software delivery performance are deployment frequency, lead time for changes, mean time to restore, and change failure rate. These are outcome measures. They describe what is happening, not why. The "why" shows up when DORA breaks down the practices that distinguish high performers: trunk-based development, automated testing, continuous integration, deployment automation, and, notably, organizational culture. They specifically find that high-performing organizations tend to have cultures characterized by psychological safety, information sharing, and cross-functional collaboration. Low performers tend to have blame cultures, siloed decision-making, and adversarial relationships between development and operations.

That last part is the uncomfortable part. You can buy a CI/CD platform in an afternoon. You cannot buy psychological safety or cross-functional trust. Those things require changing incentive structures, management behavior, and the organizational history that created the adversarial relationship in the first place.

The dev-ops divide is old. It comes out of the waterfall era, when development and operations were genuinely separate functions with genuinely separate concerns. Development's job was to build new features. Operations' job was to keep the lights on. New features are the enemy of stability, so the two teams had structurally opposed incentives from the start. Development teams were rewarded for shipping. Operations teams were rewarded for not breaking things. When something went wrong in production, the blame game was automatic because the incentive structures pointed at each other.

DevOps, the philosophy rather than the toolchain, claims you can have both frequent deployment and high stability. The evidence from DORA suggests this is true for organizations that actually change how the two functions relate to each other. Elite performers have resolved or dissolved the dev-ops adversarial split, usually by forming cross-functional teams that own the full lifecycle of a service, from development through deployment through production support. The team that writes the code is also on call when it breaks. That incentive alignment changes behavior without any particular tool being necessary. But the incentive realignment requires management to reorganize, which requires executives to have an opinion about team structures, which requires someone with authority to actually care.

That is a management problem, and most DevOps tool vendors cannot sell management. They can sell Kubernetes. They can sell monitoring. So the story that gets told in sales cycles is about tools, and organizations buy tools expecting transformation and get expensive infrastructure operated by the same siloed teams that had nothing to work with before.

This connects to something I keep coming back to in the IS literature on why the same technology can succeed in one department and fail in another. The technology arrives with a certain spirit, to use DeSanctis and Poole's language, and what actually happens depends on how the people in the organization appropriate it. A CI/CD pipeline deployed by a team with no authority to change deployment decisions is just a fancy build system. The same pipeline, deployed by a cross-functional team with production ownership and on-call responsibility, becomes the foundation for genuine continuous delivery. Same tool. Completely different organizational context.

The cultural factors DORA identifies are not soft. They are mechanistic. When developers know that a bug they push will wake them up at 2 a.m., they write better tests. When operations engineers participate in feature planning, they design infrastructure that can handle the deployment patterns developers intend. When post-incident reviews look for process failures rather than human scapegoats, the information from each failure actually gets incorporated into the next release. The psychological safety and low-blame culture that DORA reports as predictive of high performance are not end states in themselves. They are the conditions that allow these improvement mechanisms to function.

The hardest version of this problem shows up in large enterprises, where the DevOps transformation is funded as a technology initiative. A CTO gets a budget, hires a platform engineering team, stands up the toolchain, and then waits for development and operations teams to adopt it. Adoption is slow, because the incentive structures have not changed. Development teams do not want their deployment process changed by a platform team they had no input with. Operations teams do not want to give up the manual review gates that give them control over what goes to production. The platform sits there, technically available, practically unused, because the organizational pre-conditions for adoption do not exist.

I have a related post on agile at enterprise scale that covers the same pattern from a different angle. Agile, like DevOps, was designed for small co-located teams with aligned incentives. Scaling either to large enterprises without changing the underlying governance structure produces something that uses the language of the original but none of the organizational conditions that made it work. SAFe looks like agile. Enterprise "DevOps" looks like DevOps. Neither is the thing it claims to be unless the incentive structures and team topologies actually change.

My read is that the DORA findings are useful precisely because they refuse to let organizations off the hook. They do not say "install these tools and measure this metric." They say "high performance is associated with practices that require cultural change, and cultural change requires management will." That is a harder sell than a platform license, and it is why so many DevOps transformations stall at the toolchain.