The network team has a reputation problem.

We’re seen as the bottleneck, the department that’s allergic to innovation, the folks who turn every simple request into a three-week ordeal involving request forms, review committees, and change windows scheduled for sometime in the next geological era.

But here’s what I know from 25 years of working in infrastructure management: Our tools—or rather, a lack of tools—has been the biggest part of the problem.

Our developer colleagues have spent the last decade building an entire ecosystem of tools that let them innovate at breakneck speed without breaking everything.

It’s time we had the same advantage.

. . . . .

The great mindset myth

Developers are tasked by the business with innovating at speed.

For devs, embracing a “fail fast” approach makes some sense: Experiment in a lot of different directions at once to see what sticks. Drop the things that don’t work and go further on the things that do.

In contrast, infrastructure engineers are tasked with keeping things stable.

For network engineers, a “fail fast” style is nothing but a surefire path to a pink slip. When a single misstep can take down an entire network, grinding company operations to a halt, infrastructure is the last place you want to “try lots of things to see what works”.

The problem comes when the business asks the infrastructure team to keep things stable and also move quickly. With the tools that have traditionally been available to infrastructure engineers, staying steady and moving fast are goals that are at odds.

As infrastructure engineers, we understand better than anyone the risks of a rushed change to the network. We also know that the fallout from any outage falls entirely on our shoulders. So it’s no wonder we’ve tended to pump the brakes when it comes to trying something different.

But as a result of this natural (and perfectly appropriate) caution, the network team has developed a reputation as being slow. Resistant to change. Difficult to work with.

There seems to be a general perception that the mindset of the network team is what’s at fault. That we’re driven by an innate stubbornness, an unwillingness to adapt, or a need to protect our territory.

That perception is false. We’re not obstinate cranks (at least, not any crankier than other teams 😉). We don’t hate change just because it’s change. Quite the contrary.

My experience has always been that infrastructure engineers are enormously curious human beings, open to new ideas and new technologies. We’re generally collaborative. And we would love to be more agile in evolving and adapting the network—if there was a realistic way to do so without incurring massive risk.

. . . . .

A (very) brief history of infrastructure change control

Early change control for the network relied on organizational knowledge and engineer-to-engineer coordination. (I say “early” because this is how infrastructure teams have operated since time began, but in many cases, it’s how teams still operate.)

Configurations lived in spreadsheets or backup files. Rollbacks were handwritten scripts or perhaps vendor-specific playbooks. Most changes lived in ticket comments or Notepad++.

The CAB (Change Advisory Board) was born to make infrastructure changes visible, reviewable, and shared. It was a way to formalize change requests, and put them before a room full of people who would meet regularly to read and debate the changes before they went live. CABs are essentially version control by committee.

All of these manual change processes are effective for managing risk but extraordinarily time-consuming and hard to scale. It’s the trade-off we’ve been forced to make for a long time now.

But while our eyes have been falling out of our heads reading 50-page change docs, other parts of the org have been moving on.

. . . . .

When other teams got better tools

In 2009, a Belgian consultant named Patrick Debois championed the concept of DevOps, an agile work method to connect siloed teams. Since then, the DevOps movement has coalesced into a mature set of operational practices.

Today, developers can quickly and easily branch, propose, review, and merge code changes, catch mistakes with testing, and enforce standards automatically. These agile workflows are made possible by an entire universe of supporting tools and technologies.

The tools are what gives DevOps its true power. In fact, many DevOps concepts are automated or software-enabled versions of the change management practices we’ve been using in infrastructure all along.

So now we come to the crux of the matter: Developer and infrastructure teams aren’t mismatched in terms of mindset: They’re both open to moving quickly and adapting to change. But they are hugely mismatched in the tooling available to support that mindset.

DevOps tooling made change review fast and repeatable for code—but not for infrastructure data. Infrastructure data doesn’t fit neatly into the same workflows and toolchains as software code does, as much as we might want it to.

And despite being a methodology for primarily one type of team, DevOps set new expectations for the speed of change across the entire business. Compared to software devs, the network team looks like a recalcitrant slacker sibling: “You’re still so slow! Why can’t you be more like your brother, DevOps.”

Hey mom and dad, we’d love to be more like DevOps! It’s not our attitude that’s holding us back. We need different tools if we’re going to realistically move at DevOps speed.

. . . . .

The infrastructure tooling revolution we’ve been waiting for

We’re now firmly in the era of automation and AI, where networks have become so large and complex that managing them manually is nearly impossible. The old ways of tracking changes in spreadsheets and validating them through committee meetings simply can’t scale to meet modern demands.

The good news is that infrastructure tooling is finally catching up to the specific realities of what we do.

Unlike software code, infrastructure management needs structured, interconnected data: devices, interfaces, policies, and all the complex relationships between them. We need tools that understand these relationships, can validate dependencies, and can track changes to schema over time.

What we need is true version control for infrastructure. Not just Git with YAML files, but purpose-built systems that treat infrastructure data as the structured, queryable, interdependent information it actually is.

That means version control that starts with a database foundation, then adds the collaborative workflows that have made DevOps so successful: branching for safe experimentation, peer review for catching issues early, and automated testing to enforce standards before changes go live.

When infrastructure teams have access to these kinds of tools—ones that match both our risk tolerance and our need for speed—we can finally move with the agility the business has been demanding of us without sacrificing the stability they depend on.

My prediction: The perception that infrastructure teams are inherently slow will fade when we’re no longer constrained by a lack of relevant tools. We are not the bottleneck. We never were. We just needed better equipment for the job.

Finally, we’re starting to get it.