In tech, some ideas stick around simply because “that’s how we’ve always done it.” But every now and then, it’s worth questioning whether long-standing practices are still earning their place.
Reality Bytes is a series where our specialists share their most honest, sometimes uncomfortable views (we’ve called hot takes) on modern IT the ones that challenge convention, spark debate, and push organisations to think differently about risk, resilience, and progress.
This time, we’re tackling a sacred cow.
By Chris Read, Workspace Principal Engineer, Inde
Personal hot take: There is a perfect cheese match for every food that exists, even chocolate.
Professional hot take: You don’t need change control.
Audience survey results*: 50% Agree, 50% Disagree
*Inde survey of 46 IT professionals at Reality Bytes event
Before anyone reaches for the pitchforks, let me be clear: change control exists for a reason.
Traditionally, change control was introduced to reduce risk, to prevent outages, catch unintended impacts, and provide auditability in complex IT environments. Frameworks like ITIL formalised this through Change Advisory Board (CAB) or Technical Advisory Board (TAB), where proposed changes are reviewed, debated, and approved before they happen. That made sense in a world of fragile systems, manual deployments, and limited visibility.
The problem isn’t the intent. It’s what change control has become.
For many technology teams, the CAB meeting has become a weekly ritual. In theory, these sessions provide oversight, reduce operational risk, and ensure alignment across the organisation. In practice, they often devolve into hours long queues of engineers waiting for approval from people who may not understand the context, the workload, or the technical details, yet still hold the power to block progress. Long queues of engineers waiting for approval from people who may not understand the context, the workload, or the technical details, yet still hold the power to block progress.‑long queues of engineers waiting for approval from people who may not understand the context, the workload, or the technical
After years of sitting in these meetings, sometimes as the first agenda item, sometimes as the eleventh, I’ve noticed a common pattern: the people doing the work wait, while those reviewing it wield veto power with minimal accountability for the time and cost involved. And often, the outcome is a “no,” not because the change is risky, but because the reviewer is uncomfortable, misinformed, or simply prefers to maintain tight manual control over processes that should never have been manual in the first place.
It doesn’t have to be this way.
One moment sticks with me more than most. Before a particularly full CAB session, I checked the attendee list. Out of curiosity, and a little frustration, I added up the hourly billable rate for every engineer, consultant, and specialist who had been required to attend.
The hourly rate for that meeting was over $2,000. Executives rarely see this cost directly because it hides inside salary budgets, utilisation reports, and delivery delays. But any engineer who has spent 90 minutes waiting to get a two-minute change approval has felt this pain.
Before a single change had been reviewed, the organisation was already spending thousands simply having experts sit on mute, waiting for their turn. In another business unit, this cost ran even higher because senior architects and external contractors were mandated attendees, whether or not their expertise was needed.
At the time I was struck by one thought: This is not governance, this is waste.
Micromanagement often fills the gap where automation and observability are missing.
When there are no guardrails, people become the guardrail. When there’s no automated rollback, someone in leadership insists on personally checking everything.
When deployment pipelines are inconsistent or poorly documented, committees form to compensate. These controls aren’t malicious; they’re a response to uncertainty. But they’re also a bottleneck — one that scales badly as teams grow or workloads increase.
Leaders frequently underestimate how much friction this creates:
Governance should rely on systems, not meetings.
Many high maturity IT teams are moving away from lengthy CAB processes. Instead, they keep it short, calling out the risk, agreeing a date and time for deployment, and simply rely on their tools to do the heavy lifting. Tools such as: ‑maturity IT teams have already moved away from lengthy CAB processes. Instead, they keep it short, calling out the risk, agreeing a date and time for deployment, and simply rely on their tools to do the heavy lifting.
A pipeline that takes a snapshot or backup before deployment eliminates one of the most common objections in CAB discussions:
“But what if something goes wrong?” Snapshots make rollback predictable, fast, and verifiable.
Modern CI/CD tooling allows:
These systems are objective, repeatable, and impossible to intimidate.
If a deployment fails health checks or impacts performance, the pipeline can roll back automatically, often in seconds. No meeting can react that fast. No human can be that consistent.
This removes the compliance justification for sticking with weekly CAB sessions.
What this really points to is not that change control is wrong, but that it’s out of step with how modern systems operate. The opportunity here is balance.
Modern IT environments need both speed and stability. Governance still matters, but it doesn’t have to come at the expense of momentum. The point of removing CAB meetings isn’t to remove governance — it’s to improve it.
Automated change management:
If your organisation is still using weekly CAB/TAB meetings to control change, you’re likely paying more for worse outcomes.
The real question isn’t: “Do we trust engineers enough to automate?” It’s: “Do we trust engineers enough that we shouldn’t waste their time?”
Executives who shift from meeting driven change control to system driven change control see immediate benefits:
And perhaps best of all: Your people spend their time building value, not waiting in line for approval.
If organisations want to move faster, deliver safer, and remain competitive, this shift isn’t optional. Engineering cultures that cling to manual review boards will fall behind the ones that invest in automation, observability, and trust.
Because nothing kills innovation faster than three hours spent waiting for someone else’s permission.