The DevOps operating model is fundamentally a partnership. Like any productive partnership, it requires both sides to move toward a shared solution rather than defending entrenched positions. For many organisations, the biggest obstacle is not tooling or architecture — it is the cultural gap between development teams that embrace change and operations teams that are wired to control it.
Why Operations Teams Resist Change
Operations professionals have spent years dealing with the consequences of bad releases. A single botched deployment that causes an outage at 2 a.m. leaves a lasting impression, while hundreds of smooth deployments quietly fade from memory. This asymmetry shapes how ops teams think: caution becomes a reflex, and change becomes something to be managed carefully rather than accelerated.
That caution is not irrational. Ops teams are accountable for uptime, performance, and customer experience. When something breaks, they are the ones who fix it. Understanding this perspective is the starting point for any meaningful DevOps conversation.
The ITIL Problem
Operations teams often work within frameworks such as ITIL (IT Infrastructure Library), which define rigorous change management processes. These processes were designed to reduce risk, and they do — but they also introduce significant overhead. A straightforward configuration change can trigger a chain of approvals, documentation requirements, and review meetings that take far longer than the change itself.
In a DevOps environment where the goal is frequent, incremental delivery, a heavyweight change process becomes a structural bottleneck. This does not mean ITIL is wrong or that all its controls should be discarded. It means organisations need to honestly assess which steps add real risk protection and which add bureaucratic friction without meaningful safety benefit.
Controlled Change: Finding the Middle Ground
Embracing the DevOps operating model does not require ops teams to abandon all change control. It requires them to adopt a pace and process that aligns with the delivery cadence development teams need, while still fulfilling their gatekeeping responsibilities.
There are practical steps that help both sides find that balance:
- Establish a shared change schedule. Operations and development teams can collaboratively define deployment windows, freeze periods, and escalation paths. A predictable schedule reduces surprise on both sides.
- Categorise changes by risk. Not every change deserves the same level of scrutiny. Routine, low-risk changes can move through a lightweight approval path, while high-impact changes retain full review cycles.
- Automate compliance evidence. Many ITIL requirements exist to produce an audit trail. CI/CD pipelines, infrastructure-as-code repositories, and automated test results can generate that evidence automatically, replacing manual documentation steps without removing accountability.
- Streamline, do not eliminate. The goal is to reduce steps that add overhead without adding safety — not to remove oversight entirely. Change management exists for good reasons; it just needs to evolve.
Getting Management On Board
Managers who championed ITIL as a risk control mechanism may resist any proposal to simplify it. Their concern is legitimate: they are responsible for the stability of systems that the business depends on, and they have seen what happens when change processes erode.
The most effective approach is to frame the conversation in terms management already cares about: speed to market, cost of delayed releases, and competitive risk. When a change management process costs more in engineering hours than the changes it governs, that is a business problem, not just a technical inconvenience. Presenting that argument with real data from your own environment — cycle time, lead time, change failure rate — gives management something concrete to evaluate.
These conversations are rarely easy. Expect to give ground. The objective is not to win the argument but to reach a workable compromise that lets DevOps practices take hold while preserving the controls that genuinely matter.
Taking the Good with the Bad
The shift toward a DevOps operating model will feel uncomfortable for operations teams at first. More frequent changes mean more exposure to potential issues, at least until automated testing and deployment pipelines mature enough to catch problems before they reach production. That maturity takes time to build.
At the same time, the move creates a genuine opportunity for ops teams to shed the most tedious parts of their work. Repetitive, manual change documentation is not valuable work — it is compliance theatre that consumes time engineers could spend on reliability improvements, capacity planning, and automation. A well-implemented DevOps model returns that time.
It is worth asking honestly: how many organisations ever had a truly rigorous ITIL process to begin with? In many cases, the paperwork existed but the discipline behind it was inconsistent. If that is true in your organisation, streamlining the process may not represent as great a risk as it first appears.
The Path Forward
There is no universal blueprint for a DevOps operating model. What works depends on your application portfolio, your release cadence, your customer expectations, and the maturity of your existing processes. The journey looks different for a team shipping a consumer SaaS product every day than for a team managing enterprise infrastructure with quarterly release cycles.
What is consistent across every successful DevOps transition is this: development and operations teams must understand each other’s priorities and constraints, and management must be an active participant in shaping the new model rather than an obstacle to it. When all groups are genuinely invested in making the partnership work, the result is a delivery capability that serves the business better than either side could achieve independently.
Embracing change does not mean abandoning discipline. It means replacing outdated discipline with something that fits the way modern software is built and delivered.