Learning at Layer 1 | I build things

I’ve always preferred to understand things by pulling at them. Not recklessly — there are environments where that approach would get you into serious trouble — but carefully enough to see how something behaves when it’s nudged out of shape.

Break it slightly.
Watch what happens.
Learn how to bring it back.

That instinct has probably shaped more of my career than any certification. At one point, I was sent in as a technical lead to support a site that had drifted into a difficult place. A mix of legacy systems, very little internal knowledge, and just enough remaining staff to keep things running — but not enough to really understand them. The people who had understood it had mostly left. What remained was fragile.

The Telephone System

One of the more intimidating pieces of that environment was the telephony system. An old Siemens PABX, backed by a contract that assumed there would be an experienced telecoms engineer onsite. There wasn’t. The contract allowed for a limited number of vendor call-outs, intended for serious issues. Instead, those credits were being burned on basic tasks. Not basic in the modern sense — not plugging a cable into a socket — but physically patching connections on a Krone block, tracing lines across an MDF, making changes by hand. When those credits ran out, things started to stall.

The comms room was something else.

Wall-to-wall MDF.
Jumper wires everywhere.
No obvious map.

It intimidated most people but I found it fascinating. So I started mapping it.

Desk → patch panel → comms room → MDF.

Following paths, testing assumptions, figuring out how things were connected. I picked up a punchdown tool so I could make changes. Tracked down a lineman’s handset so I could listen for dial tone directly on the lines. Piece by piece, it started to make sense.

In the middle of the room were the Siemens racks. Line cards, trunking, and a management system that — somewhat surprisingly — wasn’t locked down. Inside it was a job diary from previous engineers. Some of them had left notes. Those notes were enough. From there, I worked out how the system was structured, how the contact centre queues functioned, how numbers were assigned, how phones were added and removed. Even how the hold music was wired in — via a slightly questionable 3.5mm setup Velcroed to the back of a cabinet.

Most of that learning happened after hours. When the building was quiet, I could make small, controlled changes and observe the results without disrupting anyone. That’s where the real understanding came from. Not from documentation, but from interaction.

What stood out was how resilient the system was. The Siemens platform — HiCom or HiPath, I can’t remember which — was effectively a rock. It didn’t fall over. That gave me confidence to explore further. And before long, I’d become the telecoms person on site. Not by design. Just by following the problem far enough. The irony was, telecoms wasn’t where I wanted to be.

Self-taught CCNA

I’d spent the previous 18 months trying to move into the network team. I’d studied for my Cisco CCNA, applied for roles internally, but never quite had the “right” experience. So I looked elsewhere and I got an offer. I handed in my notice and suddenly, there was a role for me on the network team.

It wasn’t purely coincidence. No one else wanted ownership of the telecoms estate. I’d already demonstrated I could handle it. That was my way in. Once inside the team, I broadened quickly.

Switches first.
Then routers.
Then firewalls.

Mostly Cisco to begin with, then expanding out into Juniper SRX, Check Point, and Riverbed WAN optimisation.

The telecoms work continued alongside that, but it became less central. Older systems that required dial-in access via modem, issuing obscure commands to manage hunt groups. Newer systems like Avaya, where everything was abstracted behind a UI — easier to use, but far less interesting.

Looking back, that early exposure mattered.

Understanding how an ISDN circuit landed on a PABX.
How that mapped to line cards.
How those mapped to an MDF.
And how that ultimately connected back to a user’s desk.

It’s a level of visibility that’s easy to lose as systems become more abstracted. I was probably one of the last people in that environment to work that close to layer 1.

From there, the path was clearer.

I moved into a dedicated network security role elsewhere. Larger environments, more responsibility — Cisco switching from access layer through to core, firewalls, routing, wireless. At one point we moved away from Cisco wireless entirely, shifting to Aruba and using ClearPass for network authentication. Later still, I worked with Meraki. Efficient. Clean. Abstracted. And, if I’m honest, a bit less satisfying.

I’m no longer a network engineer but parts of that way of working have stuck.