This is the career arc series. It’s not a curriculum and it’s not a retrospective — it’s an account of how the work actually changed over the years, and what the progression from physical infrastructure to systems engineering looks like from the inside.

It doesn’t read as a straight line because it wasn’t one.

What changed, and when

The early work was physical and concrete. You built things you could touch, in environments where failure was visible and immediate. If a server didn’t boot, you knew about it because you were in the room. If a cable was the wrong one, you found out when the link didn’t come up. The feedback loop was short, and the skills were largely manual.

What changes — slowly, and not through a single decision — is the level of abstraction you’re operating at. Scripts replace procedures. Platforms replace servers. You spend less time building the thing and more time understanding why the thing is built the way it is, and whether that’s still the right reason.

The thinking transfers. The instincts about what makes a system stable, maintainable, and honest about its failure modes — those come from the physical layer, and they remain useful at every layer above it.

The posts, in order

Early Dev Work (optional prologue) Before the infrastructure career, there was a period of building things on the web with whatever was available at the time. It’s included here as an origin story, not a main thread — but the habit of inheriting something undocumented and making it work is here in its earliest form.

Learning at Layer 1 Where it actually starts. A Siemens PABX with no documentation, a network that needed managing, and the beginning of a long relationship with systems that nobody had written down.

Scripting the Network The first formal step toward automation — not for its own sake, but because the alternative was human error at scale. On using scripting as a consistency tool rather than a speed tool.

Building Linux Servers Before Automation The server build period. Before configuration management, before IaC — repeatable meant having a process and following it carefully. This is what that looked like.

When IT Stops Being Systems and Starts Being Strategy The pivot point. The post where the job changes from building and administering to planning and defending. Not a comfortable transition, but an instructive one.

What comes next

The series ends at the strategic planning period, but the work continues. The current chapter — platform engineering, cloud infrastructure, the SRE direction — is the subject of ongoing posts that will be linked here as they’re written.

If the series resonates, Systems Thinking is the perspective tag that runs through all of it.

Tags