While it is true that network engineers are taking on NetDevOps roles to advance stalled automation efforts, the barrier to NetDevOps isn’t technical; it’s people.
The 44% Problem
The 2025 State of Network Automation Survey from the Network Automation Forum, which gathered responses from 681 network professionals across 58 countries, paints a clearer picture. When asked about barriers to automation, only 10% cited technical challenges. Meanwhile, 44% pointed to people problems: Skills gaps, organizational dysfunction, cultural resistance and yes, sometimes, just personalities that don’t mesh.
Let that sink in: The tools work. Python is mature. Ansible is everywhere. Source-of-truth platforms are production-ready. The tech isn’t the bottleneck — people are — and this aligns with something else the recent NetDevOps article touched on: Nearly half the organizations have no formal measurement of automation success. You can’t fund what you can’t prove, and you can’t prove what you don’t measure.
This is the real challenge in NetDevOps adoption. It’s not about writing better Python. It’s about organizational change management. It’s about communication. It’s about building trust between teams that have historically operated in silos.
You Don’t Need Unicorns — You Need Evolution
Here’s where I want to push back on the industry narrative a bit.
There’s this persistent idea that NetDevOps requires mythical unicorn hires, people who are simultaneously expert network engineers and expert software developers and expert DevOps practitioners. These people exist. I’ve met a few. But building your automation strategy around finding them is a losing game.
Research from theCUBE shows that organizations prioritizing internal upskilling outperform those relying on net-new hires. But I want to amplify this point: You already have the people you need. They just need to evolve.
When I was at Dell EMC, I transitioned from principal network engineer to consultant software developer, because automation became necessary and I kept pulling on that thread. One script at a time. One playbook at a time.
That’s the path for most of us. You don’t wake up one day as a NetDevOps architect. You evolve into one.
The automation survey data backs this up. When asked who builds automation in their organizations, 92% said “network engineers with automation skills.” Not software developers (44%), not DevOps teams (32%) — network engineers who learned new tricks.
So how do you create the conditions for that evolution? Here are a few patterns I’ve seen work:
Permit people to learn on the job. Automation skills don’t come from weekend certification cramming. They come from solving real problems with new tools. That means accepting that the first few automation projects will take longer than doing manual work, and that’s okay.
Pair, don’t silo. When you do have someone with stronger automation skills, don’t make them the automation person. Pair them with network engineers on real projects. Transfer skills through collaboration, not documentation.
Celebrate the small wins. The engineer who writes their first working Python script to pull interface stats has taken a bigger step than it looks. Recognize it. That momentum compounds.
The Data Foundation
Traditional network operations treat documentation as an afterthought, something you update after you make changes (if you remember). NetDevOps flips this. You make changes in the data first, then push those changes to the network through automation.
Intel’s Greg Botts (a Network to Code customer) puts it perfectly: “Start with your data, and everything falls out of that. Network config is a byproduct of the data.”
This is a mindset shift that trips up a lot of organizations.
EMA’s McGillicuddy notes that organizations often spend a year or two just establishing their network source of truth. That sounds like a long time, but it’s foundational work. You’re consolidating information that lives in 10 different silos, cleaning up years of accumulated drift and building the authoritative data layer that makes everything else possible.
Organizations with a clearly defined source of truth are nearly three times more likely to achieve consistent automation outcomes. Yet 56% are still flying without one — and if you’re trying to do NetDevOps without a source of truth, you’re building on sand.
From Documentation to Operations
Here’s where intent-driven methodology changes everything.
Without NetDevOps, without an intent-driven approach, your network data is just documentation. It’s a record of what you did, updated after the fact (if you remember) and its only purpose is to help the next person understand what’s out there. It’s passive. It describes the past.
With an intent-driven approach, data becomes operational. Your source of truth doesn’t just document what the network looks like; it defines what the network should look like. Data becomes the way you operate the network. You change the data, and automation makes reality match.
This flips everything. Documentation stops being a chore you do after the work is done. It becomes a natural byproduct of doing the work itself. You don’t update the spreadsheet after you make a change; you make the change by updating the source of truth. The documentation is the operation.
That’s a profound shift, and that’s why organizations that embrace it see such dramatic improvements. The act of automating forces you to clean up your data, and clean data makes better automation possible. But more than that: Data finally has a real purpose. It’s not busywork. It’s how you run the network.
AI Can Help Today, if You’re Ready
AI can help you today. Natural language queries against network data, configuration analysis, optimization recommendations, and even generating automation code, all of this works right now. The problem isn’t the AI. The problem is that most teams aren’t ready to use it effectively.
Think about how we approach Python in network automation. We don’t just write scripts and push them to production. We have linting. We have a code review. We have testing frameworks and CI/CD pipelines. We build structure around how we use Python so that it’s safe, repeatable and maintainable.
AI needs the same kind of structure. The good news is that the industry is starting to define it — frameworks such as the NIST AI Risk Management Framework and ISO 42001 for AI management systems, plus LLM testing tools such as DeepEval that bring automated validation to AI outputs. However, most organizations haven’t built these guardrails yet.
The automation survey shows that 45% of network professionals have no current plans to use AI/LLM in network operations. Only 3% have actually deployed it. I don’t think that’s because AI doesn’t work; it’s because experienced network engineers are appropriately cautious. They’ve seen what happens when you push untested changes to production. They’re waiting for the guardrails.
The Road to AI Runs Through Automation
Here’s the thing: AI is only as good as the data you feed it. If your network data is scattered across spreadsheets, tribal knowledge and half-updated CMDBs, AI will confidently give you wrong answers.
This is why the road to AI in NetDevOps runs through automation, not around it. Think of it as a flywheel:
First, you build your data foundation. You establish a source of truth and create authoritative records of what your network should look like.
Then, automation starts improving that data. Every automated change gets logged. Every drift gets detected. The act of operating the network through data makes your data better.
Finally, with solid data and mature automation practices, AI has something real to work with. It can query accurate inventory. It can analyze consistent configurations. It can learn from a history of well-documented changes. The foundation you built for automation becomes the foundation AI needs to be useful.
Skip the early steps and you’re asking AI to make sense of chaos. That’s not a technology problem; it’s a sequencing problem.
As Intel’s Botts says, “AI is going to enable us to uplevel our workforce. It’s not going to take these jobs away; it’s going to help us do our jobs better.” But better assumes you’ve done the work to be ready for it.
The Bottom Line
NetDevOps is real. It’s happening — and the organizations that figure it out will operate more efficiently, respond faster and frankly, be better places to work.
But let’s be honest about what figuring it out actually requires. It’s not about finding the perfect hire or buying the perfect tool. It’s about evolving your team, fixing your data and doing the hard organizational work that nobody wants to talk about.
2026 is a turning point. It will be defined by the people who do the work — and most of those people are already on your team. They just need the opportunity to evolve.