Change quality is a system, not an approval process

When change goes wrong, the reflex is almost always the same.

We add another check, tighten the form, escalate the approvals...

It all feels like the responsible move and it looks like control externally.

But most of the time, it will simply not fix the underlying problem.

I’ve seen so man environments over the years with all the key metrics hit..

• super rigorous change processes
• multiple senior approval layers
• immaculate paperwork

…and still experience repeated, avoidable failures.

That’s because change quality doesn’t come from permission.

It comes from confidence, and confidence is a system property.

The illusion of control

Approval processes exist for a reason. I’m absolutely not anti‑governance.

But I’ve seen businesses quietly drift into believing that...

"If enough people approve something, it must be safe."

That is a comforting idea but a really dangerous one.

In one environment years ago, changes were thoroughly reviewed and signed off, yet serious failures continued with almost zero improvement. Post‑incident reviews consistently pointed to the same themes...

• changes were tested, but not in representative conditions
• dependencies were understood in theory, not in practice
• recovery paths existed, but hadn’t been exercised

The process was working exactly as designed.

But the system the process worked within wasn’t.

 Where does quality actually come from?

High quality change isn’t the absence of risk.

It’s the presence of confidence.

And confidence comes from a few simple and predictable places...

 1. Environments that tell the truth

I’ve seen teams do everything “right” and still get caught out because the environment lied to them.

Tests passed but only because the test environment was lacking real load, real data shape, and real integration points.

When production behaves differently from testing environments, approval becomes irrelevant.

Teams with strong change outcomes almost always have environments that...

• fail in similar ways to production
• surface constraints early
• allow safe experimentation

That doesn’t mean perfect replicas, it means honest ones.

 2. Patterns beat permissions

Another common failure mode I see is novelty.

• One off solutions.
• Special cases.
• “Just this once” changes.

Every exception increases cognitive load and erodes predictability.

Often the highest‑risk changes aren't the complex ones, they are the unique ones. Changes that didn’t follow established patterns, even when approved, were far more likely to cause issues.

Teams with good change quality rely less on approval and more on simple but important metrics...

• known patterns
• standard deployment paths
• familiar rollback mechanisms

When the path is familiar, people spot deviations instinctively.

3. Recovery confidence matters more than prevention confidence

I’ve been in change discussions where all the energy went into proving a change wouldn’t fail.

But very little went into what would happen if it did.

That imbalance shows up clearly during incidents.

Teams that recover well usually demonstrate the following...

• know exactly how to undo a change
• have rehearsed the recovery
• aren’t emotionally attached to being “right”

I've seen this go so well where a change caused wide scale unexpected impact, but the team recovered quickly because rollback was treated as a normal and practised operational action and not an admission of failure.

That mindset dramatically lowers risk.

Why adding more approvals often makes things worse

There’s a subtle cost to heavy approval models that doesn’t show up on dashboards.

When approvals multiply you see

• accountability blur
• ownership diffuses
• people can assume someone else has checked the important thing

I’ve seen teams become less careful, not more, because responsibility felt shared instead of owned.

High‑performing teams behave differently. They assume...

“If this goes wrong, it’s on us — so let’s design it properly.”

That sense of ownership doesn’t come from process. It comes from clarity.

Change quality improves when systems do the heavy lifting

The most reliable environments I’ve worked in didn’t rely on exceptional people or heroics.

Simply, they relied on systems that...

• made the right thing the easy thing
• constrained dangerous paths
• surfaced risk early

When that’s in place, approvals become a sanity check and not the primary safety mechanism.

Bringing it together

If change quality is poor, resist the urge to immediately add controls.

Instead, ask yourself...

• does our environment reflect reality?
• are we repeating patterns or inventing new ones?
• do teams know exactly how to recover?
• is ownership clear, or diluted?

Most of the time, improving change quality means designing better systems, not tightening gates.

Closing thought

Good change management doesn’t eliminate risk.

It makes risk visible, manageable, and recoverable.

When change quality improves, it’s usually because

• environments became more honest
• patterns became clearer
• recovery became normalised

That’s not process optimisation.

That’s operational design.

Design for confidence.

Normalise recovery.

Operate with intent.