Your Network Is Not a Toilet: Stop Flushing Infrastructure Expertise

Before diving into the messy state of how network engineering is perceived today, let me start by giving credit where it’s absolutely due.

Sometime back in 2023 or early 2024, after I had been regularly writing about the craft of network engineering, the protocols, the architectures, the hard lessons, I started noticing people tagging me with the hashtag #MakeNetworkEngineeringCoolAgain.

At first, I didn’t even know what it was or where it came from. It felt like a meme. However, after some digging, I realized that someone else was already out there, not just promoting the discipline, but doing it with clarity, charisma, and consistency. That person is Alexis Bertholf.

Let me be clear: Alexis is one of the brightest and most thoughtful content creators I’ve ever seen in the network engineering space. She's sharp, deeply technical, and somehow manages to turn complex infrastructure topics into content that’s approachable, energizing, and often even fun. She doesn't just know her stuff; she brings community along with her, which is a rare and powerful skill in our field.

So, before we go any further: Alexis, consider this a big, public shout-out. You’re a rock star. You’ve done more to lift up the visibility of network engineering than most of us ever could.

Despite that movement, and the work of people like Alexis, something has continued to bother me.

You scroll through social media, and it's flooded with talk of AI, cybersecurity, software development, productivity hacks, and now even “vibe coding”. Meanwhile, posts about network engineering are… rare. Almost invisible.

This isn’t just an algorithmic trend or a branding issue.
This is a warning sign.
It signals that a critical layer of our digital world is being culturally ignored, and that we may be heading straight toward a talent collapse in one of the most foundational engineering disciplines of the Internet.

This article is my take on what’s happening.

I’ll walk you through the myths we’ve normalized, the consequences that are already showing up, and the urgency of fixing our cultural perception of what infrastructure engineers actually do, and why their role must be reclaimed.

You don’t have to agree with me. You might even disagree strongly. That’s okay.

But if you're willing to sit with the discomfort of what this might mean for the future of our systems, then let’s move on.

Because your network is not a toilet.
And we’re running out of people who know how to fix the pipes.

There’s a phrase I’ve heard too many times in meetings, tech talks, and hallway conversations:

“Don’t worry, it’s just the plumbing.”

They’re talking about the network.
The assumption being: once it’s installed, it quietly does its job, like a set of buried water pipes. Unseen, unquestioned, and uncelebrated.

And with that one dismissive metaphor, a foundational layer of our digital world is reduced to something mundane, something beneath strategic consideration. This perception isn’t just inaccurate, it’s perilous.

As someone who’s spent decades architecting complex, hyperscale network infrastructures, I’ve witnessed firsthand how critical this layer is. I’ve also watched, frustrated, at times heartbroken, as infrastructure engineers are treated as utility workers in a world obsessed with abstraction. While software engineers push shiny front-end features and DevOps teams champion pipelines and CI/CD agility, the engineers who make global connectivity possible are often left out of the conversation entirely. And worse: they’re left out of the vision.

But let’s be clear. And don't get me wrong; facts are facts, and you can't disagree with the following:

There is no cloud without a network.
There is no edge without a backbone.
There is no service, system, or software that operates without reliable, performant, and secure connectivity underneath.

And yet, networking is increasingly being neglected in engineering education, in strategic planning, and even in career development. Fewer people are learning how to design routing policies. Fewer still are trained in traffic engineering, failover topologies, or network observability. In an era of global systems and microsecond latencies, we're producing professionals who treat connectivity as a checkbox, something a vendor or platform will “just handle.”

This isn’t a minor cultural shift. It’s a strategic blindspot.

The more we abstract the network into a commodity, the more we ignore its impact on resilience, security, latency, compliance, and cost. And as the generation of engineers who built the Internet begins to retire, we’re facing a stark future: fewer qualified professionals, more brittle systems, and a talent pipeline that’s drying up before we realize it.

This article is a response and a call to action.

We’ll examine how and why network engineering came to be seen as “just plumbing,” confront the myths that fuel this perception, and explore what happens when we lose the engineers who know how to build and fix what lies underneath. Most importantly, we’ll chart a path forward for bringing visibility, respect, and opportunity back to one of the most vital disciplines in modern computing.

Because networks are far more than just wires: they’re intent, architecture, and strategy. And they deserve to be treated and taught as such.

It’s a narrative that’s become increasingly popular in the age of cloud consoles, Terraform scripts, and drag-and-drop network builders:

“Networking isn’t hard anymore.”
“Everything’s automated.”
“If you can spin up a VPC and set some security groups, you’re good.”

This belief is not only widespread, it’s being reinforced by cloud marketing itself.

Providers promise simplicity. Diagrams show clean icons connected by friendly arrows. And for many engineers early in their careers, their first “network” is virtualized: it lives in AWS, GCP, or Azure, tucked neatly behind an API and a dashboard. They’ve never touched a router. Never debugged a BGP flap. Never felt the urgency of a live outage rippling through a regional Internet Exchange.

It’s no wonder that deep networking knowledge is being sidelined.

But here’s the problem: Abstraction does not equal elimination.

The protocols haven’t changed. The complexity hasn’t disappeared. It’s been hidden beneath a glossy interface that doesn’t reveal the underlying architecture. And when something breaks, and it always breaks, that complexity comes roaring back. The logs stop making sense. The metrics point nowhere. The abstraction collapses.

Consider this:

These are not hypothetical scenarios. They’re real-world, daily challenges in distributed systems. And they can’t be solved by clicking buttons.

They require engineers who understand:

In other words, they require network engineers.

And here’s one of the problems we've started to see nowadays: those engineers are becoming harder to find. According to recent industry reports, 74% of global CIOs believe that the shortage of skilled infrastructure professionals, especially network engineers, is one of the greatest threats to their organization's long-term resilience. You’ll find the links to those claims further below.

This isn’t just a hiring challenge but a pipeline collapse. Fewer people are entering the field. Fewer training programs focus on the fundamentals of networking. Fewer young engineers are exposed to the underlying mechanics that support cloud-native design. Instead, they’re told that networking is “legacy.” That it’s “low-level.” That it’s “just plumbing.”

But when your service fails, and your cloud provider tells you, “It’s a routing issue outside our scope,” what then?

In those moments, you realize:
Clicking around the cloud was never enough.
You needed to understand how the cloud connects to itself and everything else.

So, to those who argue that “nobody needs to learn networking anymore,” here’s a thought:

Nobody needed to learn math either, until the calculator broke.

There’s a new crown jewel in modern engineering culture: the platform team.

Built on the promise of internal developer platforms (IDPs), self-service automation, golden paths, and paved roads, platform engineering is meant to abstract away the complexity of infrastructure, security, compliance, and deployment. It’s DevOps, evolved. And it’s realm, done well, platform engineering delivers incredible velocity and consistency across organizations.

However, in the rush to elevate platform roles, there has been a quiet dismissal of the disciplines they rest upon, none more overlooked than network engineering.

“Ops is legacy.”
“Infra is solved.”
“Networking? That’s a concern for vendors.”

These narratives are seductive, as they simplify budgets and consolidate teams. They make complexity someone else’s problem. But they also mask a dangerous truth: every platform depends on infrastructure, and when it fails, or is misconfigured, it brings down everything with it.

Let’s be clear: platform engineering doesn’t replace network expertise. It consumes it. Beneath every internal API gateway, every service mesh, every build pipeline, and deployment orchestrator lies real connectivity. If that connectivity isn’t designed by someone who understands latency domains, routing convergence, east-west segmentation, and failure scenarios, the entire platform is built on guesswork.

When you centralize all service traffic behind an ingress controller, have you modeled for Layer 3 isolation? Do you understand what happens when BGP re-convergence meets pod churn? Or when your egress traffic to a third-party API now takes a trans-Pacific detour because someone removed a preferred route in your cloud backbone?

Platform teams may own the interface. But when the data plane collapses, it’s not the YAML that saves you, it’s the engineer who understands how packets actually flow.

And the irony? The best platform engineers already know this.

They’re the ones embedding SREs with infrastructure backgrounds. They’re the ones who understand that you can’t build reliable internal platforms if you don’t observe, model, and test the network underneath. They know that infrastructure as code doesn’t magically eliminate the need for physical infrastructure. The hardware still exists. The routing tables still matter.

However, platform teams are often being stood up without that integration. They’re expected to move quickly with templates and blueprints, while network teams, if they still exist, are marginalized as blockers, relics, or worse, cost centers.

This creates two problems:

Here’s the deeper insight:
Platform engineering isn’t a replacement for infrastructure expertise. It’s a layered composition. And when network engineering is missing from the platform team, it’s like building a high-performance engine without checking the fuel lines.

So let’s stop pretending that platform engineering is a new world. It’s a higher vantage point on a very real, very physical one. And the quality of what you build still depends on what you’ve built it upon.

It’s easy to assume that critical technical skills will always be around.
After all, hasn’t networking been part of IT forever? Surely there will always be network engineers. Right?

That assumption is quietly setting us up for a crisis.

Across the industry, the signs are clear and deeply troubling. A significant portion of experienced network engineers are nearing retirement age, and the pipeline of new talent entering the field simply isn’t keeping pace.

In one recent study, over 25% of U.S. network engineers said they expected to retire within five years. Another survey of global CIOs found that 74% see talent shortages in network and infrastructure roles as a major threat to their long-term digital resilience. This isn’t just anecdotal: it’s backed by consistent data across enterprise, telecom, and cloud providers. Some examples:

And the problem is more than just numbers; it’s depth.

The engineers nearing retirement aren’t just line workers. They are the ones who:

These aren’t just skills. They’re institutional memory. They’re operational wisdom, accumulated through decades of hard-earned experience in systems where the cost of failure is measured in millions or lives.

And yet, there is no coherent plan in most organizations for transferring that knowledge. No structured mentoring programs. No apprenticeships. No long-term succession strategy. Younger engineers are being routed into platform roles, DevOps, or cloud-specialist positions that rarely touch L3 protocols or physical topologies. They are trained to deploy, but not to understand. To monitor, but not to diagnose.

So what happens when the experts retire, and nobody is ready to step in?

You get fragile networks covered by superficial automation.
You get architecture based on convention, not careful design.
You face outages that no one can explain, and the only solution is to reboot.

The deeper irony is this: the demand for network engineering is actually rising, not falling.

But while the complexity of the job increases, the number of qualified professionals is shrinking. The knowledge gap is widening. And the impact is beginning to show in the form of longer MTTR, growing reliance on external consultants, and catastrophic outages that should’ve been predictable.

This is an accelerating fracture.

We can’t afford to ignore the retirement wave. We need to act. That means:

Because once this layer of expertise is gone, it won’t be easily replaced.

Let’s talk about respect.

In most societies, when an electrician restores power after an outage or when a plumber fixes a ruptured pipe in the dead of night, they’re treated with appreciation, even reverence. They are considered vital. Essential. The kind of professionals you don’t think about until you desperately need them… and then you realize how indispensable they are.

Now compare that to how we treat network engineers.

Despite keeping hospitals online, stock markets running, banks synced, planes flying, and entire nations connected, network engineers are often invisible. Not just operationally, but culturally.

There’s no “thank you” when the routing works flawlessly across five global cloud regions.

No recognition when a team rebuilds an MPLS backbone under live traffic.
No applause when an engineer stays up all night mitigating a DDoS attack to protect customer trust.

Why?

Because most people, even within IT, don’t see the network.
And what you don’t see, you don’t value.

But make no mistake: network engineers are the digital world’s emergency responders, electricians, and structural architects, all rolled into one. They build and maintain the invisible foundation upon which the rest of modern computing operates. Yet they often get treated as a background cost center, or worse, as “legacy tech” practitioners in a world obsessed with abstraction and velocity.

Here’s the uncomfortable truth:
If a backend service goes down, it’s an incident.
If the network goes down, it’s a headline.

We’ve seen this time and again:

In each case, the problem wasn’t “just plumbing.”
It was critical infrastructure failure, on par with losing power, water, or transportation.

And yet, when budgets are cut, network teams are often the first to lose headcount. When headcount is approved, it's DevOps or platform hires that take precedence. And when the spotlight is on, it’s the product team that gets the praise, even when it was the network that saved the day under the hood.

This has a chilling effect on the talent pipeline.

Why would a student entering the tech world today choose network engineering when:

Meanwhile, other infrastructure roles, such as cloud architects or platform engineers, are increasingly valued, which is fine. But we cannot allow visibility to dictate value. Not when the consequences are so high.

If society can respect and reward those who fix our lights and water, it should absolutely respect those who keep the world’s digital arteries flowing.

That respect starts with us. Inside the industry. Inside our teams.

Because network engineers don’t just fix problems: they prevent them.
And they don’t just plug things in, either: they design the modern world’s circulatory system.

You might think the undervaluing of network engineering is just a cultural issue. A matter of optics. A problem of internal politics or misunderstood job roles.

But it’s so much bigger than that.

The steady erosion of respect, investment, and training in network infrastructure isn’t just hurting careers; it’s putting entire digital ecosystems at risk. This is not theory. It’s not a thought experiment. It’s happening now, and it’s happening everywhere.

On the surface, modern systems appear resilient. Cloud dashboards show green lights, CI pipelines move quickly, and failover procedures are documented in runbooks. But dig a little deeper, and the story changes.

Behind every Kubernetes cluster is an IP routing fabric.
Behind every edge function is a global anycast network.
Behind every real-time experience is a path carefully tuned for latency, loss, and jitter.

Still, many teams today don't really grasp what’s going on between the service mesh and the network. They rely on the defaults, the platforms, and the assumption that “the network will just work.”

But resilience doesn’t come from trust. It comes from design.
And you can’t design for what you don’t understand.

This leads to a dangerous pattern:

It always is, until you hire someone who knows better.

We talk about Zero Trust. We talk about segmentation. We deploy SASE platforms, ZTNA brokers, and encrypted overlays. But too often, these are implemented without understanding the topology, traffic flows, or failure paths they sit on.

When network engineering is left out of the security conversation, you get:

Security isn’t a box to check. It’s a property of a well-engineered system, and that system starts with the network.

Studies show that over 85% of IT teams experience between one and four outages per quarter, and the average cost of a major cloud outage exceeds $300,000 per hour. Yet most teams lack the depth of expertise to diagnose network-related issues quickly, let alone prevent them.

Why?

Because the people who could once trace a fault through three layers of transit, including MPLS labels, route reflectors, and cloud NAT, are retiring or have been reorganized out of relevance.

So instead, teams reboot the process. They rerun Terraform and wait for the cloud provider to respond.

Meanwhile, customers churn. Revenue pauses. Engineers burn out.

When networking is viewed as a utility, something passive, something invisible, leadership often overlooks the importance of investing in it. And that has strategic consequences.

In each case, the companies that embed networking expertise into their strategic planning win. The ones who don’t? They learn the hard way, at scale and a cost.

Perhaps the most alarming consequence of all: we’re not just facing a shortage of network engineers today, we’re creating a vacuum for tomorrow.

Every year we allow the discipline to be sidelined, we lose:

We are watching the slow erosion of an essential craft, and we are not replacing it fast enough.

So what happens when nobody knows how the network really works anymore?

You don’t just get outages.

You get an Internet that’s slower, riskier, harder to debug, and less resilient.
You get systems that look modern on the outside but are rotting underneath.
You get a digital world that’s running on borrowed time and borrowed talent.

Unless we change course, this is where we’re headed.

We’ve come this far without blinking. We’ve built billion-dollar platforms, global cloud systems, and digital economies that depend entirely on connectivity, and yet, we’ve forgotten to celebrate, nurture, and sustain the very people who make that connectivity possible.

It’s time to stop treating network engineering like background noise.
It’s time to stop calling it “plumbing.”
And it’s time to start building a future where infrastructure engineers are seen not as legacy specialists, but as strategic architects.

Because that’s exactly what they are.

So what do we do about it?

Language matters. The words we use shape how others see us and how we see ourselves.

If we describe networking as “pipes and wires,” we reduce a high-stakes engineering discipline to something passive, static, and dull. In reality, the work of network engineers involves systems thinking, risk modeling, performance optimization, security strategy, and business continuity planning.

We must address it accordingly, in conversations with leadership, product teams, and peers. Let’s reframe networking as a force multiplier, not a sunk cost.

The next generation of engineers won’t learn deep networking through osmosis. We must teach it deliberately, strategically, and with patience.

The legacy of today’s experts must become the foundation of tomorrow’s resilience.

Even if someone doesn’t specialize in infrastructure, they need to understand its shape and behavior.

Every engineer working in cloud-native, distributed systems, or edge computing should grasp the fundamentals of:

Think of it as infra fluency, just like we expect application developers to understand memory management, concurrency, or test coverage.

The network is everyone’s responsibility, especially when everyone is shipping software that depends on it.

We don’t just need more network engineers; we need to inspire them.

Because for every engineer who burns out in silence, there’s a potential mentee who never even realized this was a career worth pursuing.

This goes beyond just respect: It’s about survival.

Suppose we continue to lose senior engineers and fail to cultivate new ones. In that case, we will first feel the impact in subtle degradations, then in major outages, and ultimately in crises where we no longer have the skills to understand, let alone fix.

But if we act now, if we revalue the discipline, rebuild the pipeline, and reframe the narrative, we can turn the tide. We can build networks that are not only functional but also resilient, secure, performant, and worthy of pride.

From “Just the Network” to "Just in Time."

Next time you hear someone dismiss the network as "just plumbing," take a moment to think about it. Ask them what happens when that plumbing fails, and every service comes to a standstill, leaving people unable to access what matters most.

Then share this with them:

The network isn’t just a background element.
It’s the backbone.
It’s not a cost, but a capacity.
It’s not a legacy, but a lever for growth.

And the people who design, build, and protect it?

They’re not just support staff.
They’re the true architects.

Let me know if this article brings anything to mind! I'd love to hear your thoughts.

Until our next edition!

Leonardo Furtado