About Me

My day-to-day spans high-stakes: keeping clinical systems running, leading incident response when things break, building out IT operations and monitoring practices, and translating between the people who run the wires and the people who sign the checks. I care about the parts of this work that don't always get attention — clear documentation, defensible architecture decisions, and the discipline of leaving systems better documented than you found them.

My path into technology started a long way from any data center. I grew up rural, in the era when AOL dial-up was a genuine event in a household, when AIM screen names were a form of identity, and when customizing a MySpace page with hand-rolled HTML was the closest thing to magic a kid could get their hands on. That's the spark — the moment I realized a computer wasn't just a tool but a place you could build things. Everything since has been an extension of that: T9 texting gave way to Linux command lines, P2P clients gave way to home labs running Proxmox and TrueNAS, and the kid hacking on stylesheets eventually became the engineer designing infrastructure that real organizations depend on.

What I bring to a problem is a preference for the durable answer over the convenient one. I lean toward infrastructure-as-code, headless and CLI-driven tooling, and architectures that survive their authors. I'm equally comfortable in the weeds of a production incident and in a room arguing the strategic case for replacing a tool that's outlived its usefulness. I read constantly — about cloud economics, AI infrastructure, where enterprise compute is heading next — because the field doesn't sit still, and neither should anyone working in it.

Longer term, I'm building toward an independent consulting practice focused on helping mid-market organizations make infrastructure decisions they won't regret in three years. Until then, I'm in the work — running the lab, sharpening the certifications, and writing about what I learn along the way.