Documentation as a Leadership Practice
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.
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.
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.