Your Network Automation Problem Is an Interface Problem

Organizations come at network automation from two starting points, and this post is for both. Some already have three or four automation projects, and yet the network is still operated by hand. Others have no automation at all and want a credible way to start. Both groups tend to reach for the same structural question first: should automation be a separate team, or live inside the network team?

It’s the right instinct pointed at the wrong target, for two reasons. First, that’s a bundle of five or six decisions wearing a trench coat, and team structure is only the most visible of them. Second, we’ve watched both structures succeed and both fail, sometimes inside the same company. The org chart never separated the successes from the failures. The seams did. Between teams, between skill sets, between the technical work and the business paying for it: were those boundaries explicit, or assumed?

This post won’t tell you which structure to pick. We don’t know your organization’s problem statement, and anyone who prescribes a model without knowing it wants to sell you their favorite answer. What we can give you is the set of spectra, decisions, and questions we use to help organizations choose for themselves.

First, locate your people on two spectra

Before any structural conversation, you need an unsentimental map of the skills you have. Most organizations skip this, because everyone involved has an incentive to round themselves up. The map has two axes.

The software axis runs, roughly, through these markers. At one end: engineers who work purely on the command line. Next: engineers with Bash scripts accumulated over the years, living in home directories and running when their author runs them. Next: engineers who’ve taken a course (Kirk Byers’ Python for Network Engineers is the classic on-ramp, and a good one) and can write Python that works. Then a wide gap, and it’s the gap that matters. On the far side of it are people who practice software engineering as a discipline, for whom version control is a reflex and tests and code review are routine. Beyond that lies distributed systems and SRE-style operations. What happens when this runs against 4,000 devices and 3% of them time out?

Our direct and repeated observation is that most organizations have people at markers one through three and believe they have people at marker five. A completed Python course is worth celebrating. Designing a system that fails safely at scale is a different capability, and treating the two as interchangeable is how organizations end up with automation that is itself unmaintainable: scripts nobody dares edit because their author changed roles two years ago. None of this criticizes the engineers. It criticizes plans that pretend the gap isn’t there.

The networking axis deserves the same honesty. Here’s a composite portrait drawn from organizations we’ve worked with, no single client, every element real. Architects whose role has drifted into senior escalation, whose diagrams describe a network that stopped existing two refreshes ago. Engineers who are superb in one specific mode: log into the device, read the state, diagnose, fix. One device at a time, never a fleet. And alongside them, recently hired infrastructure-as-code specialists writing Terraform for systems nobody has fully mapped. What exactly are you automating, if no one can describe it?

Skill applied to ambiguity doesn’t resolve the ambiguity. It encodes it.

If that portrait feels familiar, you’re in the majority, and the point isn’t blame. You can’t design a structure for a team you haven’t located.

You’re making a set of decisions

With the map in hand, notice how many separate dials you’re setting. Team structure (separate, integrated, or a platform group with product teams on top) is one dial with unusually broad influence over the others. But it decides none of them by itself. You are also deciding:

• The skills mix: build by training your engineers up the software axis, or buy by hiring developers and teaching them networking. Most end up with a blend and still have to pick the ratio and the timeline.
• Who owns the platform: the pipelines and test harnesses and deployment machinery that everything else stands on.
• Who owns the data: the source of truth and the definitions inside it (more on this below).
• Sequencing: what gets automated first, and whether an organization starting from zero should begin before the other dials are settled. Our answer is yes. A small real automation teaches you more than a quarter of planning. Just know that the other decisions charge interest whether you make them deliberately or not.
• The funding story: what the business believes it’s buying, which turns out to be the decision that governs all the others.

Each dial has a spectrum of reasonable settings. The failure pattern is setting one dial deliberately and letting the other five default.

The force working against every one of these decisions has a name

Alex Komoroske (Google, then Stripe) wrote the best treatment we know of the force that stalls these programs: Coordination Headwind: How Organizations Are Like Slime Molds. Compressed, his argument is that as organizations grow, getting anything done requires agreement from more parties with their own priorities and hidden constraints. No villain is required. Everyone can be competent and collaborative and progress still stalls, because the odds of a stall compound with every extra team whose sign-off a change needs.

Network automation is unusually exposed to this. A single automated change can reach into design’s standards, engineering’s build, operations’ runbooks, security’s policy, and an automation team’s codebase. Five parties, one change. Under those conditions the manual process (one senior engineer, one change window, one approval) is faster, and everyone knows it. Nobody rejects the automation. They route around it.

Hold onto that as the test for every dial: does this setting reduce the number of parties who must agree before a change goes live, or add one?

Whatever you decide, write the contracts between the teams

Software engineering has a concept worth borrowing, design by contract. Every component states what it requires and what it promises. It also states what happens when the promise breaks. The idea transfers almost perfectly to teams. The standard cargo container is the model. Its genius wasn’t the box but the interface, which let every carrier handle the cargo without knowing what was inside. Ports got faster because the seams stopped requiring negotiation.

Your teams need the same treatment. For every seam in whatever structure you choose, someone should be able to answer, in writing:

• What does this team promise the other? (“The platform group guarantees the pipeline validates config against standards before push.”)
• What does it require in return? (“The network team guarantees device data in the source of truth is accurate before invoking the pipeline.”)
• What can each side change without asking? This one question, answered candidly, predicts your coordination headwind better than any org chart.
• What happens when the contract breaks? Who gets paged, who fixes it, and who decides whether the contract itself was wrong.

Notice what this does to the structure debate. A separate team with explicit contracts behaves like a well-run vendor. An integrated team with explicit contracts avoids the trap where everything is everyone’s job and so no one’s. The structure becomes revisable, because the contracts, not the reporting lines, are what people work against.

Your data is an interface too, and it’s often the broken one

The contracts so far are between people. There’s a quieter contract underneath them, between systems, and in our experience it’s where automation programs bleed out: data quality, the source of truth, and, less discussed, the organization’s taxonomy (its agreed names and categories for things) and ontology (how those things relate to each other).

Ask three teams in the same company what a “site” is and you’ll often get three answers. One team means a building. Another means a billing entity. The third means a routing domain. Is a firewall a device role, a service, or a security-team asset? Does “decommissioned” mean powered off, or removed from monitoring, or deleted from inventory? Humans absorb these ambiguities without noticing and resolve them in hallway conversations. Code needs one answer. When the organization has three, the automation either guesses or asks, and both destroy the trust the program depends on. Our read, stated plainly: most “automation bugs” we’re called in to look at are not code failures. They’re the organization’s unresolved disagreements about nouns, surfaced by the first system rigid enough to notice them.

That is why “build a source of truth first” is right but incomplete. A source of truth built on an ambiguous taxonomy centralizes the ambiguity. Agree on the nouns and their relationships first. Encode that agreement. Then populate it, and treat the schema itself as a contract with an owner and a change process. Hiring tool specialists before this exists inverts the work. They end up automating the ambiguity instead of the network.

Bring the business into the room, or fear will fill the vacuum

Everything so far is a technical-organization conversation. It fails without a parallel conversation with the business, which is the part most technically led programs skip. That conversation has two directions. Upward, leadership needs to understand what this program buys in its own units. Faster delivery of new sites. Fewer outage-hours. Audit evidence in minutes instead of weeks. If the funding story is vague, the program gets funded like a hobby and cut like one. Downward matters even more and is done even less. Every person on the team needs to understand that same story, for a reason we’ve observed across nearly every transition we’ve supported. When engineers don’t know what the automation program is for, they fill the gap with the obvious inference: it’s for replacing them. People who believe that don’t sabotage openly. They cooperate slowly and share knowledge selectively. The manual process stays alive as a hedge. No org structure survives that, because every contract in this post depends on good faith at the seams.

The honest story is also the true one, in every organization we’ve seen. The traditional network engineers hold irreplaceable knowledge, and the automation is worthless without what’s in their heads. The software developers hold practices the program can’t deliver without. People who combine both are rare enough that you should plan to grow them rather than find them. What every organization can build immediately is the shared understanding: everyone from the CFO to the newest engineer able to state what the program achieves and what their own work contributes. That shared picture is a prerequisite.

Leaders should describe the destination, not the route

One more principle, aimed at whoever sponsors this program. The leader’s job is outcomes and vision. “Every standard site change goes live same-day without a maintenance window.” “A new region comes up in a week instead of a quarter.” The leader’s job is not to specify the tooling or the team boundaries or the automation sequence. The leader is seldom the expert. Prescription from a non-expert is how organizations end up committed to last decade’s answer, delivered confidently.

There’s a subtler version of this trap. Suppose you hire the unicorn: thirty years of networking plus strong software engineering. Deep expertise in the state of the art is still a different skill from knowing how to move this organization toward it: which team goes first, which fight is worth having now. That skill is organizational and it’s the rarer one. Assuming your best technologist is automatically your transformation driver sets that person up to fail. Leaders who hold the outcome steady, and who staff the route as its own problem, get both.

Questions to take to your own whiteboard

We promised principles rather than prescriptions, so here are the questions we’d put to your leadership team. Take them in any order. Each opens a different door.

1. Plot your ten most senior network people on the two axes, candidly. How many are past the software-engineering gap? Not “knows Python,” but tests, review, and failure-at-scale. The answer sets your build-versus-buy ratio.
2. Take your last ten routine network changes. How many teams had to agree to each? That number is your measured coordination headwind, and every dial you set should be judged by whether it goes down.
3. For each seam in your current structure: what can each side change without asking the other? If nobody can answer, your contracts are implicit, and implicit contracts get renegotiated during every incident.
4. Could three teams define “site,” “device role,” and “decommissioned” identically, in writing, today? If not, that’s earlier in your sequence than any workflow or any hire.
5. Can the most junior engineer on the team state what the business gains from this program? If not, assume fear is filling that vacuum right now.
6. For the next automation role you fill: what three outcomes must this person have produced by month twelve? (Geoff Smart and Randy Street’s Who is the standard reference for this scorecard method.) If you can’t write the outcomes, you’re not ready to hire.
7. Is your sponsor describing destinations or prescribing routes? One of these scales. The other becomes the program’s ceiling.

Answer all seven crisply and you don’t need us, you need six months of execution. Most organizations can answer three or four. The unanswerable ones point at where the real work is. They’re also available as a one-page handout for your next leadership meeting.

What would change our mind

If your network is small enough that three engineers hold the whole thing in their heads, most of this is premature. A shared repository of scripts plus good habits beats any amount of contract-writing at that size. If your organization already runs a strong internal platform culture on the software side, extending that platform to the network may beat anything network-specific built fresh. And nobody starting from zero should let this post become a reason to delay a first small automation. Planning forever is a risk too.

The hard part, the part no post can do, is working these questions against your organization’s specific history. Which seams are politically safe to formalize first. Whether your most senior engineer becomes the program’s credibility anchor or its most effective opponent. How to grow the hybrid people you probably can’t hire. That’s judgment work, and it’s where we spend most of our time with clients. If you’re taking these questions to your own whiteboard and want a second set of eyes on the answers, we’re easy to find.