Part 1: The Roles and Structure

In my last piece, I argued that the biggest barrier to NetDevOps adoption isn’t technical—it’s people. The 2025 State of Network Automation Survey backed that up pretty clearly: 44% of automation barriers are people problems. Only 10% are technical. The tools work. The humans are still figuring it out.

That article focused on the why of the people problem. This one is about the what. Specifically: what does a modern network team actually look like in 2026? Because the team structures that got us here—the ones built around CLI expertise, ticket queues, and siloed domains—aren’t going to get us where we need to go.

The answer isn’t to blow everything up and start over. It’s to evolve what you have. But evolution requires understanding what you’re evolving toward.

The Old Model Is Breaking

Let’s be honest about what “traditional” network team structure looks like. You’ve got a group of network engineers, usually organized by domain—campus, data center, WAN, security. Each domain has its own tools, its own tribal knowledge, and its own way of doing things. Changes go through a ticket system. Someone copies a config from a notepad, pastes it into a terminal, and hopes for the best. Documentation gets updated if there’s time (there’s never time).

This model worked when networks changed slowly and the biggest risk was a fat-fingered subnet mask. It doesn’t work when you’re managing hybrid cloud environments, supporting microservices architectures, and getting asked to provision infrastructure at the speed of a CI/CD pipeline.

The NetworkWorld article I referenced previously cites Intel’s Greg Botts describing 13 engineers managing 5,500 devices. You can’t do that with CLI and tickets. But here’s what’s less obvious: you also can’t do that by just giving those 13 engineers Ansible playbooks and telling them to automate. The team itself needs to change shape.

Nobody Is a Unicorn. Everybody Is Evolving.

I wrote last time about the unicorn hire—the person who’s simultaneously an expert network engineer, software developer, and DevOps practitioner. These people absolutely exist. We have a whole herd of them at Network to Code. But you don’t need a herd. You don’t even need one to get started. What you need is the right skills distributed across your team, and leadership that knows how to blend those strengths together.

The automation survey data is instructive here. 92% of respondents said network engineers with automation skills are the ones building automation. Not software developers brought in from outside (44%). Not dedicated DevOps teams (32%). The people doing this work are network engineers who learned new tricks.

But “network engineer who learned some Python” isn’t a team structure. It’s a starting point. The organizations I see succeeding in 2026 are building something more intentional.

The Emerging Team Model

Here’s what modern network teams are actually converging on. It’s not one-size-fits-all, but there are clear patterns emerging across the organizations I work with and the data we’re seeing in the industry.

The Network Platform Team. This is the biggest structural shift happening right now. Gartner estimates that 80% of large software engineering organizations will have platform teams by 2026, and that thinking is bleeding into network operations. The idea is straightforward: instead of every network engineer reinventing the wheel on automation, you build a small team that creates the tools, pipelines, and self-service interfaces that everyone else consumes. Think of it as the team that builds the automation factory, not the team that runs every individual automation.

This maps directly to what I described in my last article about intent-driven operations. The platform team owns the source of truth, the CI/CD pipelines, the testing frameworks, and the golden configs. They make it so that a network engineer who needs to provision a new VLAN can do it through a standardized workflow instead of SSH’ing into a switch.

According to theCUBE Research, more than 60% of enterprises anchor their NetDevOps initiatives within traditional infrastructure teams rather than application or platform engineering groups. That tells me the network platform team is still early—most organizations haven’t separated the “build the platform” work from the “operate the network” work yet. The ones that do are seeing real results.

The Network Operations Engineers. These are your domain experts—the people who understand BGP, spanning tree, and why that one legacy router in the corner has been running the same firmware since 2017. The role isn’t going away. It’s changing. Instead of spending 80% of their time on reactive troubleshooting and manual changes, these engineers increasingly spend their time on design, validation, and reviewing automated changes.

TheCUBE’s research backs this up: high-performing infrastructure teams spend more than 40% more time on design, testing, and verification than on reactive troubleshooting. That’s a meaningful shift in what the job actually looks like day to day.

The key skill evolution here isn’t “learn Python.” It’s “learn to work in code review.” It’s understanding Git workflows, reading YAML, and being able to validate that an automated change will do what it’s supposed to do before it hits production. As Bob Laliberte from theCUBE puts it, NetDevOps enhances networking expertise rather than replacing it. The deep protocol knowledge still matters. It just gets applied differently.

The Data Steward Role. This one is less recognized but arguably the most important. I made the case last time that the road to automation—and the road to AI—runs through your data. Organizations with a clearly defined source of truth are nearly three times more likely to achieve consistent automation outcomes. But only about 44% of respondents in the automation survey are using Nautobot or NetBox.

Someone needs to own the data. Not as a side job, not as a “when I get to it” task. As a real, recognized responsibility. The data steward is responsible for the accuracy and completeness of your network source of truth. They define the data models. They enforce the standards. They’re the reason your automation actually works consistently instead of breaking every time someone discovers a device that doesn’t match the template.

EMA’s Shamus McGillicuddy notes that organizations often spend a year or two just establishing their network source of truth. That investment in data infrastructure is foundational, and it needs dedicated ownership.

Structure is only half the equation. In Part 2, I’ll cover the collaboration models, skills strategies, and practical transition steps that turn this team model into something that actually works—including where AI fits and where it doesn’t.

Learn More Here.

Guardrail Launches Traffic Light for AI Code Security