I spent a lot of my career trying to become a better network engineer.
For a long time, I had a fairly recognizable idea of what that meant. Learn routing protocols. Understand switching. Get certifications. Become better at troubleshooting. Design larger networks. Learn enough of the vendor platforms in front of me that I could solve increasingly difficult problems.
None of that was wrong.
I still think network engineers should understand routing, switching, packet flow, ports, addressing, and the other fundamentals that make networks work. What changed for me was the boundary around that knowledge.
At some point, being a better network engineer started requiring me to understand a just about everything around the network.
Cloud was probably one of the first things that made this obvious. Applications started moving into environments where the constructs, operating models, and interfaces looked different from the networks I had spent years learning. That helped ruin the idea that a certification path from a single networking vendor could carry me through an entire career.
The networking itself did not suddenly become unrecognizable.
There was still TCP/IP. There was still routing. There were still addresses, ports, segmentation, policy, and dependencies. Cloud platforms added capabilities and abstractions that I needed to learn, but understanding networking generally made those abstractions easier to reason about.
I have found versions of that same thing almost everywhere since.
The network keeps showing up in other domains
Observability is a good example.
A network engineer can treat Syslog, flow data, DNS logs, metrics, and other telemetry as something that gets sent to an observability platform and let another team worry about the rest.
Sometimes that is an appropriate ownership boundary.
It is still useful to understand what happens after the telemetry leaves the device.
How much data are we generating? Where is it being collected? Are we shipping large volumes of logs across the WAN? Should some of that processing happen locally? Which signals actually matter? How long do we need to retain them? What does the observability team need from networking, and what can their platform tell us about whether the network is behaving correctly?
Those questions start to look less like pure network design and more like solution design.
Security and segmentation have pushed me in the same direction.
If I am trying to reduce blast radius, a firewall may be the right answer. It may also make more sense to enforce something on a host, with a cloud security group, through an identity-aware control, or using a capability native to the compute platform.
Knowing more about those domains makes it easier to ask which control is appropriate instead of automatically reaching for the tool my team happens to own.
That can be uncomfortable in organizations built around strong domain boundaries. I have heard variations of, “I don’t want to depend on another team for a service I provide.”
I understand the instinct. Dependencies create operational and accountability questions.
But almost every useful technology system depends on something another team operates. Learning more about that domain can make the dependency less mysterious. It can also help determine whether the dependency is actually a bad design or simply part of building a larger system.
Troubleshooting already taught us some of this
This may be one reason I think people with networking backgrounds can do particularly well when they start learning adjacent disciplines.
I don’t mean that network engineers are inherently better technologists than people who came from compute, security, applications, or another specialty. Plenty of people in those domains know things I do not.
Networking just puts you in an interesting position.
When an application can’t connect, the answer might be routing. It might also be DNS, a host firewall, a cloud security group, NAT, a load balancer, an application binding to the wrong interface, or some behavior inside Kubernetes.
The Linux engineer may understand the host much more deeply than I do. The Kubernetes engineer may know every edge case of the platform. The cloud engineer may know exactly how that provider implements a particular service.
I may still know enough to ask the questions that gets us closer to the boundary where the problem exists.
That is a useful place to operate.
Sometimes I know the answer and can guide someone toward it. Other times I know enough to ask a specialist to check something I cannot validate myself. Ideally, we end up at the edge of both of our knowledge and figure out what the system is actually doing.
Network troubleshooting has required that kind of curiosity for a long time because the network connects systems we do not necessarily own.
The more infrastructure becomes abstracted, the more useful I think that habit becomes.
Abstraction did not remove the fundamentals
There have been a lot of technologies that were supposed to change what network engineering looked like.
Cloud changed it.
SD-WAN changed it.
SASE is changing it.
Automation changed it.
Kubernetes certainly created some new vocabulary.
AI will change it too.
I am less convinced that any of them made networking fundamentals less valuable.
In some ways, they doubled down on their value.
A security group is easier to reason about if ports, protocols, state, and traffic direction already make sense to you. Cloud routing is less mysterious if routing was never mysterious in the first place. NAT inside another abstraction is still easier to troubleshoot when you understand what NAT is doing. A SASE platform can hide a lot of implementation detail, but traffic still has to get from a user to a service and policy still has to be applied somewhere along the way.
The abstraction changes what we have to administer directly.
It does not necessarily change what we need to understand when something does not behave the way we expected.
I think technology broadly gets a little too excited about the idea that a new abstraction makes the fundamentals underneath it irrelevant. My experience has mostly been the opposite.
The abstraction lets me do more because I do not have to manage every detail myself. The fundamentals help me understand what the abstraction is doing for me.
“That’s another team’s problem” can still be true
There is a reasonable limit to all of this.
I don’t think every network engineer needs root access to Linux servers, administrator rights in every cloud account, permissions to modify Kubernetes clusters, or the ability to change security policy.
Authority and accountability boundaries exist for good reasons.
There are also times during an incident when saying, “This is an application problem,” is simply accurate. The network may be healthy. The network team may have provided the evidence it owns. Someone else may need to take the next action.
I would not try to eliminate those boundaries.
I would be careful about turning them into learning boundaries.
“That’s a security problem” can mean the security team owns the decision.
It does not have to mean I should stop trying to understand it.
“That’s Kubernetes” can mean someone else administers the cluster.
It does not have to mean NAT, DNS, routing, or service exposure inside the cluster are none of my concern.
If a problem keeps appearing at the edge of your domain, that might be a good indication of what to learn next.
Not because you need to take somebody else’s job. Mostly because understanding their side of the boundary makes you better at your own.
You do not need a new career identity
I don’t think the conclusion is that every network engineer should become a generalist.
There is plenty of room for deep technical specialists. Careers take stamina, and for some people that stamina comes from going very deep into a discipline they enjoy.
The environment matters too.
In enterprise IT, breadth can be particularly useful because organizations do not always have a deep specialist available for every problem. Even large enterprises ask people to wear multiple hats, connect teams, or help move an initiative that crosses several domains.
A vendor, VAR, or service provider may reward a different shape of expertise. Someone may spend an entire career going extraordinarily deep in networking and be very successful doing it.
Personal goals matter.
For me, becoming broader eventually contributed to moving into architecture. I can see how that happened. The work increasingly required me to understand the context around networking rather than only the network itself.
That is not the only destination.
The same breadth can make someone a better senior engineer, principal engineer, technical lead, consultant, or solutions engineer. You do not need an architect title to benefit from understanding how your domain interacts with the rest of the system.
Learning something new has never felt like it held me back.
Not learning it probably could.
Let the problem tell you what to learn
I would not build a giant checklist of everything a modern network engineer is supposed to know.
That sounds exhausting, and I am not sure it would be particularly useful.
I would start closer to the work.
Where does your organization struggle today?
Where do you find yourself saying:
“That’s security.”
“That’s observability.”
“That’s the application.”
“That’s the cloud team.”
“That’s Kubernetes.”
Pick one of those boundaries and get curious about what is on the other side.
You may only learn enough to troubleshoot across it. That is useful.
You may discover that the neighboring discipline is much more complicated than you assumed. That is useful too.
Or you may find something that unexpectedly becomes part of what you enjoy.
Programming was like that for me. Learning programming for the sake of programming never resonated with me as much as learning it because I wanted to automate a network. Automation gave me a reason to understand more about Linux. Cloud gave me another environment where networking fundamentals could be applied differently. Observability created questions about telemetry and system design that I would not have asked if I stayed entirely inside the network.
Networking gave me a path into those things.
It still does.
Hold on to the part you enjoy
I think this is the part I would most want a network engineer earlier in their career to hear.
Learning cloud is not abandoning networking.
Learning security is not abandoning networking.
Learning observability, Linux, automation, Kubernetes, OT, or application architecture does not require giving up the thing you already know.
If networking is what you are passionate about, use it to fuel the next thing you learn.
Ask where the two disciplines meet. Ask what that other domain can teach you about designing or operating a better network. Ask what networking knowledge lets you see in that domain that was not obvious before.
You do not have to know as much as the specialist.
You should probably respect that they know things you do not.
But you can know enough to participate in the problem instead of disengaging from it.
Most of us are figuring out some part of this as we go anyway.
Be excellent at solving problems. Learn the systems that make the problem interesting. Follow the things that make you curious enough to leave your comfort zone once in a while.
The future of network engineering is bigger than networking.
I don’t think that makes networking less important.
I think it gives us more places to use it.