After my recent article on why NetDevOps is stuck on the wrong problem, I got a response that I think captures the single most expensive misconception in network automation today:
“A network engineer isn’t going to be able to build complex software… for networks that are critical and large enough, you see devs building the automation, not just a network engineer who can do Python scripts and Ansible.”
When I pressed on what that looks like in practice, the answer was revealing: those dev teams are building provisioning pipelines, auto-remediation systems, configuration management, and operational workflows.
I don’t disagree with the observation. I disagree with the conclusion. Because somewhere along the way, our industry decided that the right response to “network engineers need better tools” was “go hire a software engineering team to build them.”
That decision is costing companies millions and burning years to arrive at what already exists.
The Network Provisioning Anomaly
Nobody builds their own monitoring stack from scratch. That would be insane. Teams aren’t building Kafka or Grafana or Prometheus. Those are solved problems with mature platforms behind them. But when the conversation shifts to network provisioning, configuration management, or automated remediation, suddenly the assumption flips to build. The justification? The work is too complex for network engineers.
There’s a fair distinction: monitoring is read-only. A provisioning platform that pushes config across thousands of production devices carries real risk. But that risk argument actually cuts against building in-house, not for it. The teams I’ve seen build internally almost always underinvest in guardrails because the backlog pressure is relentless. The dry-run validation and rollback capabilities that keep a bad change from taking down a region don’t get built when the team is sprinting to deliver the next feature request. A platform hardened across dozens of production deployments will handle that better than something your team built last quarter.
The “complex software” layer for network provisioning, data modeling, config management, and operational workflows has been built. It’s in use at some of the largest networks in the world. The question isn’t whether network engineers can build it. The question is why anyone is still asking them to.
The In-House Build Trap: Trading Vendor Lock-In For Engineer Lock-In
When an organization decides to build their network automation platform in-house, they typically hire two or three developers with Python experience, someone with a Django background for the API layer, and someone else for pipeline orchestration. Smart, capable engineers who have never had to think about why the same BGP policy behaves differently on IOS-XR and JunOS, or why your OSPF adjacency is flapping on a link that looks clean at layer two.
So you pair them with network engineers who understand the domain. Those network engineers spend half their time translating requirements into terms the developers can work with, and the other half reviewing code to make sure the automation logic actually reflects how the network operates. The developers are building software. The network engineers are becoming full-time product managers for an internal tool. Nobody is doing the work they were hired to do.
Eighteen months in, you have a provisioning pipeline that handles your greenfield deployments cleanly. Then you hit the wall. Brownfield migrations are still manual because the data model assumes structured naming conventions, but half your data center VLANs were named by an engineer who left four years ago using a scheme nobody documented. The auto-remediation engine covers a handful of failure scenarios, but edge cases require constant refactoring. Every new vendor introduction means extending the data model, updating integrations, and regression testing everything. What has been built is software maintenance.
You haven’t built a product. You’ve built a liability that requires continuous engineering investment just to maintain, and that becomes a bottleneck every time the network team needs a capability the dev team hasn’t gotten to yet.
And here’s the irony: the whole reason you built in-house was to avoid being dependent on a vendor. Instead, you’ve made yourself dependent on individuals. The lock-in problem you thought you were avoiding? You didn’t avoid it. You just traded vendor lock-in for something worse: lock-in to the two or three engineers who understand the codebase, their architectural decisions, and their continued employment at your company. Production networks require production-grade tools. When the conversation moves to the leadership level, the questions get uncomfortable fast. Who supports this if the team turns over? What’s the SLA? Who’s accountable when it breaks during a change window? “We built it and we maintain it” sounds like ownership until someone asks what happens when the people who built it leave.
Basing Decisions on a False Binary
The original counterargument rests on a binary: you’re either a network engineer who does Python scripts and Ansible, or you’re a software engineer who builds real systems. That binary is false, and it’s actively harmful to people making career decisions in this industry.
The 2025 State of Network Automation Survey from the Network Automation Forum found that 92% of organizations reported that automation is built by network engineers with automation skills. Not software developers. Not DevOps teams. Network engineers who learned to work with the tools and platforms available to them. That number spans organizations of all sizes, and the work ranges from simple playbooks to production provisioning. But the pattern is consistent: the people closest to the network are the ones building the automation. That’s not a workaround. That’s the model. And the orgs getting this right aren’t asking network engineers to do automation on top of their day job. They’re treating automation as the job and giving people the space and the platforms to do it properly.
Those network engineers aren’t building provisioning platforms from scratch. But what they are doing is far more than “just scripts.” They’re defining data models, writing jobs that encode their operational knowledge, building integrations between systems. And they’re doing it on top of platforms that handle the hard computer science problems so they can focus on the hard network problems.
Building a data model that accurately represents a multi-vendor, multi-region network is hard. Add overlapping VRFs, route leaking policies that differ per region because three different engineers configured them over five years, and brownfield infrastructure nobody fully documented, and “hard” starts to feel like an understatement. It’s just a different kind of hard than building a distributed message queue. And it’s the kind of hard that network engineers are uniquely qualified for.
The Platform Layer Changes the Math
When someone says you need experienced developers to build provisioning pipelines and auto-remediation systems, they’re describing real capabilities that real networks need. The leap in logic is going from “we need these capabilities” to “we need to build these capabilities.”
Now, network engineers are right to be skeptical of platforms. Anyone who’s been forced to use an automation tool designed by someone who clearly never had to troubleshoot a production outage at 2 AM knows the feeling. Workflows that don’t match how you actually operate. Data models that treat a network as a bag of IP addresses and hostnames. That frustration is rational, and so is the impulse to build your own. But the answer isn’t to start from scratch. It’s to pick a platform built by people who have lived through the problem. One you can actually extend yourself: custom jobs, plugins, open APIs. And when the platform doesn’t cover your use case, the ability to contribute back instead of filing a feature request into the void. Build-vs-buy only works if the thing you buy was actually designed to be extended by the people using it.
Platforms purpose-built for network automation, including Nautobot, already provide the provisioning, data modeling, job orchestration, and config management capabilities that internal teams spend years trying to build. Nautobot isn’t alone in this space. The broader point is that the platform layer for network automation exists now. Building your own isn’t required anymore, and doing so is expensive.
The network engineer’s role isn’t to rebuild that stack. It’s to bring the one thing no platform vendor can ship in a box: knowledge of your network. Your topology. Your operational policies. That’s what makes automation safe, and no developer you hire is walking in the door with it.
A platform doesn’t eliminate custom work. The hardest part of automation at scale is often the integration layer: connecting your IPAM to your CMDB to your change management system to three vendor APIs with different authentication models. That glue always requires engineering effort. And yes, migrating brownfield environments to any platform is hard, but compare that one-time cost against maintaining a custom platform indefinitely. The question is whether your engineers spend their time on integration work that delivers direct operational value, or on rebuilding foundational plumbing someone else has already built and battle-tested. Which, come to think of it, is kind of where we started.
The real question isn’t whether network engineers can build complex software. It’s why we keep forcing them to.
Network engineers have the knowledge. Platforms have engineering. Stop making one do the other’s job and you might actually get somewhere.
