Reality Bytes: You don't need change control

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.

You don't need change control

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.

When governance becomes gridlock: Why automating change workflows beats endless CAB meetings

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.

For example:

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.

Control vs Confidence: The real problem behind these bottlenecks

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:

• Changes get delayed because the CAB is over‑loaded.
• Teams batch changes into risky “big bang” releases instead of safe, incremental deployments.
• Innovation slows because engineers avoid proposing improvements that will get stuck in approval loops.
• Audit trails depend on meeting minutes rather than automated evidence.

Governance should rely on systems, not meetings.

Automated pipelines: Your best CAB member is a robot

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.

1. Automated snapshots and pre change backups

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.

2. Automation‑driven deployment 

Modern CI/CD tooling allows:

• Mandatory peer review
• Automated testing
• Security scanning
• Consistency across environments
• Approval policies enforced through infrastructure, not people

These systems are objective, repeatable, and impossible to intimidate.

3. Automatic rollback

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.

4. Built in audit trails

• Every action is logged.
• Every approver is recorded.
• Every change is traceable.

This removes the compliance justification for sticking with weekly CAB sessions.

Balance is better

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:

• Reduces operational risk (because pipelines catch errors earlier than humans do)
• Accelerates delivery (engineers stop waiting for meetings)
• Improves morale (less red tape, more meaningful work)
• Lowers cost (no more expensive meeting bottlenecks)‑thousand‑dollar meeting bottlenecks)
• Strengthens compliance (audit happens continuously, not manually)
• Supports scalability (governance grows with automation, not headcount)

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?”

Bring governance into the era of automation

Executives who shift from meeting driven change control to system driven change control see immediate benefits:

• Faster releases
• Fewer incidents
• Less friction between teams
• Greater engineering confidence
• Better customer outcomes
• A culture of accountability built into pipelines instead of meetings

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.