Part 2: Collaboration, Skills, and Making the Transition
In Part 1, I laid out what modern network teams are converging on: a platform team that builds the automation factory, operations engineers shifting from reactive troubleshooting to design and validation, and a data steward role that gives your source of truth dedicated ownership.
But structure alone doesn’t get you anywhere. The difference between a modern team and a reorganized-but-still-broken team comes down to how people actually work together.
Collaboration Models That Actually Work
Remember the 52% misalignment figure from EMA’s research? More than half of organizations report a gap between management expectations and automation reality. Nearly half have no formal measurement of automation success. That’s not a technology problem. It’s a collaboration problem. Here’s what I’m seeing work:
Pair, don’t hand off. When a platform engineer builds a new automation workflow, they build it with an operations engineer, not for them. Pipeline expertise meets domain knowledge. Both learn from the other. Hand-off culture produces automation that misses edge cases and engineers who don’t trust tools they didn’t help build.
Code review as a collaboration surface. This is the biggest cultural shift in modern network teams. Changes stop happening in real time on live devices and start happening in Git—reviewed, tested, then deployed. That review process is where knowledge transfer happens. A senior network engineer catches the thing a developer wouldn’t know. A platform engineer spots where a change could be templatized. The pull request becomes the collaboration point.
Shared ownership of outcomes. In the old model, the network team owned uptime and the development team owned velocity—goals often in direct conflict. Modern teams are increasingly accountable for both. Platform teams measure themselves on adoption and reliability. Operations engineers measure themselves on mean time to resolution and the ratio of automated-to-manual changes. When everyone owns both speed and stability, the finger-pointing stops.
The Skills Gap Is Real—But It’s Not What You Think
The 2025 State of Network Automation Survey shows a 30-point gap between networking proficiency (74% self-rate as highly skilled) and automation proficiency (44%). That’s significant. But what does that gap actually mean for team building?
It doesn’t mean you need everyone at a 10 in both categories. It means you need enough overlap that people can collaborate. A network engineer doesn’t need to write production Python. They need to read a Jinja2 template, understand a YAML data model, and review changes in Git. A platform engineer doesn’t need a CCIE. They need to understand why BGP convergence time matters and what happens when you push a bad ACL.
But the real skills gap—the one nobody talks about—is communication. Translating between the language of networking and the language of software development. Writing documentation that someone outside your domain can actually understand. The Packet Pushers Tech Salary Survey shows automation expertise correlates with a 31% compensation increase, but I’d bet the people earning those premiums aren’t just good at Python. They’re the ones who can bridge the gap between teams.
Where AI Fits (And Where It Doesn’t)
I wrote in my previous article that the road to AI runs through automation, not around it. I stand by that. But there’s a team implication that’s becoming clearer every day.
Only 3% of organizations have deployed AI/LLM in network operations. 45% have no plans to. Right now, AI’s biggest contribution isn’t replacing anyone’s job—it’s augmenting the platform team. AI-assisted drift detection for data stewards. Conversational telemetry queries for operations engineers. And increasingly: natural language interfaces on top of self-service automation.
That last one deserves more attention, because it reframes the entire skills conversation. When you put a natural language interface on top of your automation platform, the bottleneck isn’t coding ability anymore. It’s domain knowledge. The engineer who deeply understands what a valid BGP configuration looks like, who knows why you can’t just redistribute OSPF into BGP without a route map, who understands what “core isolation during a maintenance window” actually means—that person can now describe the desired outcome clearly enough for AI to generate useful automation. They don’t need to write the Python. They need to ask the right questions.
This flips the traditional assumption that you need to learn to code before you can automate. AI opens a door where the ability to precisely describe what you want—to articulate intent in domain-specific terms—becomes the critical skill. Your experienced network engineers already have it. They’ve been describing complex network behavior to each other for years. Now they can describe it to a tool that acts on it.
But AI doesn’t remove the need for guardrails. You still need the platform team validating and testing AI-generated changes before they hit production. You still need the data steward keeping the source of truth accurate. And you still need operations engineers who can look at an AI-generated config and know whether it’s right. Domain expertise doesn’t get replaced by AI. It becomes the multiplier that makes AI useful.
Making the Transition
If you’re thinking “I have six network engineers and nobody has time to learn new things because we’re drowning in tickets”—I hear you. Here’s how the transition actually works:
Start with one person, not a reorganization. Identify the engineer who’s already most curious about automation. Give them dedicated time—even 20% of their week—to build the first piece of your platform. A source of truth. A single automated workflow. Something real, not a lab proof of concept.
Let the work create the roles. Don’t rename anyone’s title on day one. Let the platform work grow until it obviously needs dedicated ownership. Successful organizations don’t hire a “Head of Network Automation” into a vacuum. They grow one out of demonstrated need.
Measure what matters. Nearly half of organizations have no formal measurement of automation success. Track manual vs. automated changes. Track mean time to provision. Track incidents caused by drift. The numbers make the case for you.
Invest in collaboration skills, not just technical training. Git workflows. Code review practices. Internal documentation standards. A culture where asking for help is normal. The 44% of automation barriers that are people problems? This is where they get solved.
The Bottom Line
The modern network team in 2026 isn’t defined by an org chart. It’s defined by principles: distributed skills and strong leadership over dependence on unicorn hires, platform thinking over one-off automation, data as a first-class concern, and collaboration that breaks down silos between network knowledge and software practices.
Broadcom’s Jeremy Rossbach was right that 2026 is the year network operations gets defined by data, automation, and intelligence. But I’d frame it differently: 2026 is the year network teams get defined by how well they collaborate across disciplines, not by any individual’s mastery of all of them.
The good news is the same thing I said in my first article in this series: you already have the people you need. They just need the structure, the permission, and the support to evolve.
To learn more about modern network teams and the strategies driving network transformation, visit the Network to Code website here.
Related News:
