Why would you automate a network, and what would you automate first?
Show the answer
Say this first
Automation gives me consistency, speed and a record of every change. The same template produces the same config on 500 switches, a change that took a week of SSH sessions takes minutes, and every change is reviewed in Git before it runs. I start with read-only work (config backups, inventory, compliance checks), then move to small, repetitive, low-risk changes such as VLANs, NTP, SNMP and interface descriptions.
Go deeper
What it fixes
- Human error. Typing the same 40 lines on 200 devices guarantees a typo somewhere. A template does not get tired.
- Drift. Hand-made changes slowly make every device a little different. Automation lets you compare every device against one intended state.
- Speed and scale. The team stops being the bottleneck for routine requests.
- Audit and compliance. Changes are in Git with an author, a reviewer and a ticket number.
- Faster troubleshooting. A script collects
showoutput from 300 devices in a minute during an incident.
A sensible order
- Read-only. Nightly backups, inventory, "which devices still run this old image", compliance reports. Nothing can break, and the team learns the tools.
- Standard config. NTP, syslog, SNMP, AAA, banners. Low risk, high repetition.
- Service requests. VLANs, port configuration, ACL entries, driven from a source of truth.
- Full provisioning and closed loop. Day 0 builds from templates, then continuous checks that the network still matches intent.
What I would say about risk
Automation also multiplies mistakes. A bad template reaches every device as fast as a good one. So the process matters as much as the tool: peer review, a dry run with a diff, a canary device first, and a rollback plan.
They will ask next
When is automation not worth it?
A task done twice a year on two devices, where writing and testing the code costs more than doing it by hand. I still document it as a runbook. If it starts to repeat or grow, it moves to the backlog.
How do you get a team of CLI engineers to adopt it?
Start with something that saves them time on day one, like a backup or a show-command collector. Keep it in a shared Git repo, pair on the first changes, and never make automation the only way to fix an outage at 3 a.m. until people trust it.
Traps
- Saying automation means fewer engineers. Interviewers want to hear that it moves engineers to higher-value work.
- Starting with large config pushes. Read-only wins come first and build trust.