Too often I find myself in a world where I’m adding a small feature or bugfix and I struggle to get through the defined change process. In order to propagate my changes, I have to file a change request at the Change Advisory Board (CAB). This process usually takes several days to even weeks. When everything is approved, the actual change itself takes less than an hour to deploy — and often introduces no risk at all. The overhead feels disproportionate, and worse, it creates friction that discourages frequent, safe changes. In a time where agility and reliability should go hand in hand, this model starts to feel more like a barrier than a safeguard. Surely this can be done differently right? But first let’s give a bit of background to how this all started.
Traditional change management is designed for fear
The traditional ITIL-style change management model was designed around risk prevention in an era where changes were infrequent, high-stakes events. While the intent was to protect stability, the result has often been a bloated, fear-driven process. CABs routinely approve changes they don’t fully understand, relying on manual documentation that’s often outdated before it’s reviewed. Arbitrary change windows add further delay, slowing down value delivery without improving safety. Worse, these processes foster a false sense of control. In reality, most outages aren’t caused by reckless engineers bypassing procedure — they’re caused by the illusion that bureaucracy guarantees safety, when in fact it often obscures real risk.
The hidden risks of the “safe” way
Ironically, the traditional approach to “safe” change management often introduces new and more dangerous risks. When approvals take days, feedback is delayed, and issues only surface long after the change was rubber-stamped. Faced with slow or burdensome processes, engineers naturally start to find ways around them, bypassing controls entirely. Even worse, teams often resort to batching multiple changes into a single deployment just to justify the overhead of CAB approval — increasing blast radius and complexity. When something does go wrong, the failure is rarely traced back to the change process itself. Instead of learning from systemic flaws, change requesters often get punished by a even more stricter process with additional controls that created the risk in the first place.
What we can do about it
The traditional change process is there for a reason. It’s all about managing risk and decreasing the change of changes resulting in service affecting impact to customers (either internal or external). That demand of risk management is not something that changes now. It’s just about defining a process that aligns with the new way of working around SRE, cloud-native and whatever practice you can name here more. They all represent team autonomy, a high velocity of changes and automation to support this. So what is my view on how to shape this new change management process?
Start Where It Hurts Most
Don’t boil the ocean. It will never work out. Start with a team that has high autonomy, high velocity changes and has the knowledge and experience to build automation to support redefining the change process. Then identify a single painful, high-friction change process — maybe a weekly patch rollout or config update that always gets stuck in approval loops. Redesign it with automation, observability, and policy-as-code. Once this redefined process pays of, use it as an accelerator to expend this to more processes and next even more teams.
Define Standard Changes
Start by creating a catalog of low-risk, pre-approved changes. These “standard changes” are repeatable, well-understood, and safe by design. Formalizing them is your entry point to agility — you reduce friction for the common, boring changes while keeping control over the risky ones. It’s the first step toward shifting trust from process to evidence.
Use Data, Not Gut Feeling
Move away from subjective risk assessments and start using change metrics as your compass. Track change failure rate, lead time, rollback frequency, and error budget impact. These metrics give you the leverage to challenge legacy controls and design smarter policies — grounded in reality, not assumptions.
Automate Low-Risk Reviews
Not every change needs human eyes. Implement automated approvals for changes that meet defined criteria — like small diff size, recent success rate, or non-critical components. Use tags, annotations, or even machine learning models to score risk. Let automation handle the safe 80%, so humans can focus on the complex 20%.
Treat Git as Your CAB
In a GitOps model, every pull request is a complete change record: who approved it, what changed, when it changed, and why. This is richer, faster, and more auditable than any traditional CAB. You don’t need a meeting to discuss change when the evidence is already versioned and observable.
Wrapping up
Change management isn’t the enemy — outdated change management is. The goal has never changed: protect customer impact by managing risk. But the environment has. Modern systems move faster, are built by autonomous teams, and are expected to deliver value continuously. Clinging to slow, manual approval cycles and abstract CAB reviews doesn’t increase safety — it undermines it.
By embracing automation, treating Git as our source of truth, and letting real data guide risk decisions, we can evolve change management from a bottleneck into an enabler of reliability and speed. It starts small: with one team, one process, and one well-defined change. But the payoff is big: faster deployments, fewer incidents, and a culture of trust reinforced by systems, not just signatures.
The sooner we accept that the process needs to change too, the closer we get to truly reliable, scalable, and efficient delivery.