- The Routing Intent by Leonardo Furtado
- Posts
- Change Control Without Proper Automation Is Just Delayed Risk
Change Control Without Proper Automation Is Just Delayed Risk
Modern Change Control Without Automation Is Just Slow-Motion Failure, and Here’s How to Fix It.

In many organizations, from global enterprises to service providers, the change control process serves as the crucial guardian of network stability and operational continuity.
It represents a formalized framework meticulously designed to minimize potential risks, enforce rigorous operational discipline across teams, and maintain the integrity and safety of mission-critical production systems.
Through careful oversight and standardized procedures, this process acts as a protective barrier between proposed changes and the live environment.
But here’s the uncomfortable truth that seasoned engineers know all too well:
Without automation and system-driven consistency, change control isn’t risk mitigation. It’s just risk postponement.
Let’s unpack this.
Find out why 1M+ professionals read Superhuman AI daily.
In 2 years you will be working for AI
Or an AI will be working for you
Here's how you can future-proof yourself:
Join the Superhuman AI newsletter – read by 1M+ people at top companies
Master AI tools, tutorials, and news in just 3 minutes a day
Become 10X more productive using AI
Join 1,000,000+ pros at companies like Google, Meta, and Amazon that are using AI to get ahead.
The Reality of Manual Change Control: Bureaucracy Over Efficiency
In many traditional enterprise environments, change approval processes are carefully structured into distinct tiers, each corresponding to a specific impact level.
This hierarchical approach to change management ensures that modifications to the infrastructure receive appropriate scrutiny and oversight based on their potential risk and business impact.
The typical framework for these approval processes manifests as a comprehensive tiered structure that looks like this:
Impact 3 (Low-Risk)
Minor changes, config tweaks on non-critical paths
⏱ Up to 1 week for approval
🧍 1 peer review required
Impact 2 (Medium-Risk)
Routing changes, ACL updates, device upgrades
⏱ 1–2 weeks for approval
👥 2 peer reviews required
Impact 1 (High-Risk)
Changes on core systems, critical infrastructure
⏱ 2–3 weeks for approval
👥 3 peer reviews, plus senior sign-off
Every change needs:
An implementation plan with pre-checks, execution steps, rollback scenarios, and post-checks.
CMDB validation: Ensure devices involved aren’t under conflicting maintenance.
CAB meeting slot for discussion and formal sign-off.
Revisions, questions, concerns, rescheduling...
On paper, this seems robust. But in practice?
Let’s say you’re planning a simple OSPF adjacency modification on a pair of redundant routers in a distribution layer. The change might take 2 hours max but you'll burn through:
7+ hours of planning and meetings
1–2 weeks of delay before approval
Risk of context loss by the time of execution
And after all that...
❌ The change might still fail.
⚠️ It might still cause an outage.
💥 It might still trigger a rollback while service impacts frustrate customers.
Why Do Well-Reviewed Changes Still Break Things?
This is the heart of the issue. If we’re being so “thorough,” why do problems persist?
Because humans don’t scale, and variability kills reliability.
Processes Are Interpreted Differently
Two engineers might read the same peer review checklist but interpret it in slightly different ways. A config snippet might be copied manually. A rollback step might be missed.
What’s Documented Isn’t Always What’s Done
Engineers often adjust procedures in real time. Maybe a pre-check fails, and a workaround is applied. These deviations rarely make it back to the source of truth.
Every Change Is a Snowflake
Without automation, no two implementations are ever identical, even if they claim to follow the same process. You lose predictability, and with it, resilience.
Postmortem Fatigue
After enough change failures, teams get cynical. The CAB becomes a formality. Documentation is written to pass checks, not to deliver precision. You get rubber-stamped changes.
The Solution: Systematic, Automated, Declarative Change
To move beyond this broken cycle, organizations need a shift in mindset.
Stop thinking of change control as paperwork. Start thinking of it as code validation.

Subscribe to our premium content to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content. No fluff. No marketing slides. Just real engineering, deep insights, and the career momentum you’ve been looking for.
Already a paying subscriber? Sign In.
A subscription gets you:
- • ✅ Exclusive career tools and job prep guidance
- • ✅ Unfiltered breakdowns of protocols, automation, and architecture
- • ✅ Real-world lab scenarios and how to solve them
- • ✅ Hands-on deep dives with annotated configs and diagrams
- • ✅ Priority AMA access — ask me anything