All posts

What Experience in Networking Actually Teaches You

Technical skills fade. Judgment compounds. Some thoughts on a career spent keeping networks alive.


My first real job had me staging routers in a warehouse outside Muscat. Nobody was checking my work in real time. I had the equipment, a stack of documentation, and the understanding that whatever I configured had to actually work once a customer plugged it in and turned it on. That was 2008, and I still remember how nervous I was the first time a deployment went live without me standing next to it.

Gear has changed a lot since. Half of what used to live in a rack now lives somewhere I’ve never physically seen. But the calls that actually matter, the ones at 2am where someone’s production environment is down and nobody knows why yet, feel almost identical to the ones from fifteen years ago.

Diagnosis over tools

I’ve worked with engineers who knew every CLI command for a given platform and still couldn’t find the root cause of a problem, because they never learned to separate what correlates from what actually caused the failure. Tools and certifications get you access to the data. Recognizing the pattern in that data, usually because you’ve seen something similar go wrong before, is a different skill entirely, and it’s the one that actually gets rewarded when things break.

Nobody teaches you to explain it

I’ve watched genuinely brilliant engineers lose a room because they explained a routing issue the same way to a customer’s CFO as they would to another engineer. Being right about the cause doesn’t help if the person who needs to act on it can’t follow what you’re saying. I had to learn this the hard way, more than once, usually by watching a call go badly and figuring out afterward what I should have said differently.

What actually changed for me

I’m a Customer Reliability Engineer now, working with organisations whose infrastructure handles a real slice of global internet traffic. The scale is bigger than that warehouse job by a wide margin. But when I’m on a call trying to figure out why something’s broken, I’m doing roughly the same thing I was doing in 2008: work from what the data actually shows, say what I know plainly, and admit what I don’t know yet instead of guessing out loud.