After forty-odd network automation engagements, the pattern is consistent enough to name. Every team moves through the same four stages, and the stall point is almost always the same one.
The four stages
- Stage 1 — Console jockeys: everything by hand, knowledge in heads, change velocity measured in weeks.
- Stage 2 — Hero scripts: one or two engineers write Python that only they understand. Faster, but fragile and unauditable.
- Stage 3 — Source of truth: the network is modelled (NetBox or equivalent), configs render from templates, Git holds history.
- Stage 4 — Closed loop: intended state is continuously compared against actual state; drift triggers remediation or alerting.
Why stage two is sticky
Stage two feels like success — tasks that took an hour take minutes, and the scripting engineers are visibly more productive. The problem is structural: the automation is an extension of individuals rather than a property of the system. When the script author is on leave, the team regresses to stage one. When the script author leaves, the scripts become hazardous artifacts nobody dares run or delete.
Teams stall here because the jump to stage three has a cost that stage two never had: you have to agree on how the network is modelled. That is not a technical conversation. Naming conventions, site definitions, what counts as a device role — these are political questions, and script-writing was a way of avoiding them.
Crossing the gap
What works is starting with one workflow that hurts everyone — usually VLAN provisioning or firewall rules — and modelling only what that workflow needs. Do not attempt to model the whole network before automating anything; the empty-NetBox-death-march has killed more automation programmes than any technical failure.
Populate the model from the network (discovery), not from spreadsheets. Render one config type from it. Deploy through a pipeline with a dry run. When that single workflow is boring and reliable, the second one is an argument nobody needs to have.