This article is based on a piece originally published on InfoQ, drawing on real-world DevOps coaching engagements. Attribution is preserved where possible.
The Core Premise Everyone Keeps Forgetting
The founding idea behind DevOps was straightforward: development and operations teams would collaborate closely so that software could be delivered faster, more reliably, and with less pain for everyone involved. Both sides had legitimate grievances. Developers felt that Operations was a bottleneck. Operations felt that developers threw unrunnable artifacts over the wall and walked away. The answer was to close that gap — not to pick a winner.
A decade later, a troubling pattern persists: organisations announce a “DevOps transformation” and then proceed to execute it almost entirely without the Ops people. Tools get chosen, pipelines get built, and culture decks get written — all while the engineers who actually run production systems are left out of the room. This article examines why that happens, what the consequences are, and what real collaboration looks like based on observed field experience.
How DevOps Started: Innovators Embraced Real Collaboration
The early DevOps community — visible at events like DevOpsDays starting around 2009 — was split roughly in half. One group came from an operations background and was exhausted by late-night outages caused by untested deployments. The other came from development and was frustrated by slow, opaque release processes that killed momentum.
What united them was the recognition that their problems were mirror images of each other. Ops could not get deployable, operable artifacts unless developers understood production constraints. Developers could not get the reliable platforms and fast feedback they needed unless Ops understood delivery pipelines. The practical outcome was a set of shared practices that are now mainstream:
- Infrastructure as Code (IaC) — managing servers and environments with version-controlled scripts rather than manual changes.
- Build and deployment automation — removing human hand-offs from repeatable steps.
- Shared monitoring and metrics — giving both Dev and Ops visibility into the same signals.
- Cross-functional teams — breaking down the org-chart silos that caused the original problem.
When these practices were adopted together, software delivery became significantly smoother. That is what the early practitioners demonstrated, and it is what larger organisations tried to copy.
Early Adopters: Change the Way of Working First
As success stories spread, larger organisations began their own transformations. One documented engagement involved a 150-person SaaS platform company that had grown rapidly and lost control of both its infrastructure and its deployment process. Finger-pointing was endemic. Deployments were unreliable. The platform was unstable.
The deliberate first step was not to hand developers a new pipeline tool. It was to teach the Operations team infrastructure-as-code and continuous delivery fundamentals. The rationale: if Ops people understand how CI/CD works — what an artifact looks like, what a deployment stage does, how developer tooling is structured — they can become genuine partners in building those pipelines rather than passive recipients of whatever developers produce.
The result was a shared language. Once Operations used the same tools and understood the same concepts as developers, conversations changed character. Misunderstandings that had previously required escalation were resolved in daily stand-ups. The gap narrowed substantially — not because of a new tool, but because of a deliberate investment in shared understanding.
The “Operations” Definition Problem
A recurring obstacle in larger transformations is that the word “Operations” is overloaded. In one large-scale engagement, the organisation defined DevOps as combining software developers with people who “operated” the application from a business perspective — for example, staff who added products to a catalogue. Putting those two groups together was called DevOps. Nobody was responsible for the deeply technical operational work: production stability, infrastructure reliability, security patching, capacity planning.
It took eighteen months to locate a single engineer with genuine infrastructure expertise. That person was firefighting production incidents full-time, had been excluded from transformation discussions entirely, worked in a different building under a different legal entity, and was close to leaving the organisation out of frustration. Yet the organisation was publicly claiming to “do DevOps.”
The intervention in that case drew on a pattern recognisable to anyone who has read The Phoenix Project: identify the individuals who are critical bottlenecks and temporarily remove them from the interrupt queue so they can build durable, automated solutions. Those engineers were taken offsite for several months to rebuild key infrastructure components using IaC and Scrum. When they returned, they brought new working methods with them — including operations veterans who became advocates for infrastructure-as-code over manual production hotfixes.
Before embarking on a DevOps transformation, organisations need to explicitly define what “Operations” means — from both a business and a technical perspective. Conflating the two is a common and expensive mistake.
When Tooling Becomes a Substitute for Collaboration
A more recent engagement at a large financial institution illustrates how badly a transformation can go when the organisational problem is treated as a tooling problem. In this case, DevOps coaches reported that they were explicitly prohibited from speaking to the Operations team, because Operations was run by a separate outsourced company not included in the transformation scope.
The patch solution was to create a new “DevOps team” positioned between Development and Operations. This team had no deep development experience, no deep operational experience, and no access to production environments. Their mandate was to build a continuous delivery pipeline that could deploy as far as a test environment; from there, the outsourced Operations team would take over and deploy manually, via tickets.
The predictable outcomes:
- The tooling stack went largely unused because it did not fit how developers actually worked.
- Manual deployment tickets to Operations remained, meaning the original bottleneck was never removed.
- Key people left — including local senior management who recognised the transformation could not succeed under these constraints.
The lesson is not that tooling is unimportant. It is that tooling chosen and operated in isolation by a subset of the teams involved will widen the gap between those teams, not close it.
“Works in My Tool, Ops Problem Now”
There is a broader tooling anti-pattern worth naming directly. A decade ago, the DevOps community fought against the attitude of “works on my machine, Ops problem now” — the habit of developers shipping an artifact without regard for how it would actually run in production. That battle was partially won. But a new version of the same problem has emerged: “works in my tool, Ops problem now.”
The dynamic works like this: a development team or a vendor adopts a new platform or service. The tool is genuinely easy to use for developers. It abstracts away infrastructure complexity. The problem is that someone still has to manage that complexity — monitoring, security patching, backups, scaling, networking, compliance. If the Operations team was not involved in evaluating or selecting the tool, they now inherit responsibility for operational concerns they had no input in designing.
The result is a return to the “Dev vs. Ops” dynamic: developers and management view Operations as a blocker; Operations is overwhelmed by non-functional requirements they cannot meet at the speed being demanded. This is sometimes called “Cloud Naive” — mistaking the ease of provisioning resources for the absence of operational responsibility.
Containers are a concrete example worth examining. Container technology brought real benefits for consistency between development and production environments. However, in many organisations the adoption of containers also created a new divide: developers worked in containers they controlled; operations teams were handed container orchestration platforms to run without having been part of the conversation about how applications were containerised or what operational requirements they had.
What Genuine Ops Inclusion Looks Like
Including Operations in a DevOps transformation is not a soft, cultural nicety. It has concrete, practical implications:
- Define “Operations” explicitly. Before the transformation begins, identify who is responsible for production stability, infrastructure, security, and reliability. Make sure those people have a seat at the table — even if they sit in a different building, report to a different manager, or work for a third party.
- Share the toolchain. When Ops engineers use the same source control, the same CI pipelines, and the same observability tools as developers, a common language and shared mental model emerge. This is not about forcing Ops to code; it is about creating enough overlap that both groups can reason about the same system.
- Include Ops in tool selection. Any platform, framework, or service that will run in production should be evaluated with input from the people who will run it. Non-functional requirements — reliability, observability, security posture, upgrade path — are as important as developer ergonomics.
- Measure what matters to both sides. Deployment frequency and lead time are important. So are mean time to recovery (MTTR), change failure rate, and on-call burden. A healthy DevOps culture tracks both.
- Protect operational expertise from constant interrupt work. Engineers with deep operational knowledge are frequently too busy fighting fires to contribute to transformation efforts. Making space for them — deliberately, as an organisational decision — is often the unlock that makes change possible.
Conclusion: Ten Years On, the Basics Still Matter
The DevOps movement has produced genuine advances: infrastructure as code is standard practice, CI/CD pipelines are expected rather than exceptional, and cross-functional teams are no longer a radical idea. But the foundational premise — that Dev and Ops collaborate as equals — is still routinely violated in practice.
Organisations claim DevOps transformations while excluding the people who run their production systems. They adopt tools that simplify developer workflows while exporting operational complexity to teams with no voice in the decision. They define “Operations” so loosely that no one is accountable for the technical work of keeping systems alive.
If your DevOps transformation does not include the people responsible for production, it is not a DevOps transformation. It is a developer productivity initiative with a misleading name — and it will eventually run into the same wall that DevOps was invented to demolish.
The Ops in DevOps is not optional. It never was.