I started on a help desk in 2012 and manage an infrastructure engineering team today. The path wasn't linear, wasn't planned, and involved at least four distinct technology transitions that each required unlearning the previous era's assumptions. These essays cover what I've learned about growing engineers, growing yourself, navigating organizational dynamics, and building a career that survives the industry's tendency to reshuffle the deck every few years.
A handful of books I've enjoyed over the years, split between career-focused reads that shaped how I lead, and fiction that reminds me why I love disappearing into a story.
Nothing is more frustrating for a senior engineer than repeating guidance they've already given. Nothing is more avoidable than building a note-taking habit that captures it the first time.
Our contractor came out expecting a corrugated system. What he found was an infiltrator setup nobody documented. We all learned something that day, and it reminded me why documentation matters everywhere.
The same principle applies everywhere: if you wait until the system is on fire to start looking at metrics, you've already lost. Early signals exist. You just have to be watching.
The best infrastructure I've ever built isn't a server cluster or an automation framework. It's a team of engineers who can make decisions I'd trust without being in the room.
Every undocumented system is a single point of failure wearing a person's name. Documentation isn't a nice-to-have. It's a resilience strategy.
Infrastructure teams build tools because their blast radius is enormous. When your work touches every application in the organization, the leverage of a good tool (or the damage of a bad one) scales differently than it does for an application team.
If your team's work isn't visible, it doesn't exist in the minds of the people who control headcount, budget, and priorities. Data fixes that, but only if you present it in a language leadership actually speaks.
The moment you start thinking about ROI on a hobby, you've turned something you love into something you owe. I've watched it happen with photography, copywriting, and smoking meat, and the pattern is always the same.
The value of AI on my team isn't that it writes code for us. It's that it lowers the activation energy for engineers to try things they wouldn't have attempted otherwise.
My kid builds redstone contraptions with no spec and no deadline. My engineers build their best prototypes under the same conditions. The pattern isn't a coincidence.
Both roles require the same voice: not a dictator, but a facilitator who removes blockers. The overlap is bigger than you think.
Wanted to share that I've been accepted into the Gies College of Business iMBA program at University of Illinois for the fall 2026 term.
In the datacenter, when a server goes down, we don't scream at the hardware. We look for the root cause. Why should a meltdown be any different?
In infrastructure, we phase rollouts because we know that too much change at once causes outages. At home, the same principle applies, just with higher emotional stakes.