My management philosophy comes down to one question I ask myself: how can I make myself replaceable? People grow most when they have clarity on what success looks like, the autonomy and trust to find their own way through, and consistent, pointed feedback along the way. My engineers would describe my style as collaborative, structured, trusting and autonomous. I am a hands-on coach early on, then I deliberately step back so people can grow into ownership.

Four tech leads I coached now own their roadmaps and operate without me in the room. At GovSpend I promoted two engineers to Staff and one to engineering manager. That is the measure I actually care about.

The hardest part of working this way is the discipline to refrain from stepping in, especially when you can see something about to go wrong and you know exactly how to fix it. Letting someone experience it and then coaching them through the reflection is almost always more effective than solving it for them. The risk is stepping back too early, before somebody is ready, and I guard against that by being explicit about what success looks like and staying closely observant at the start.

When somebody wants a decision from me, I ask for four things: the problem, the options they considered, the tradeoffs, and their recommendation. I call it the Decision Stack. People stop bringing me problems and start bringing me their call. They own the decision, and I weigh in if I see a risk they missed.

Telling whether a team is actually succeeding comes down to four things, and they build on each other. Clarity: everyone individually understands the why behind the mission. Metrics: measuring cause and effect, so we understand our impact and can realign when we need to. Synergy and ownership: an environment where everyone feels responsible for the outcome, with no egos and no gatekeeping, just a shared urgency to succeed together. And delivery: a target date is the focal point that closes the loop, because knowing the when informs both the strategy and the urgency.

Once a team has clarity, metrics and ownership, I rarely have to chase the date. They hit it on their own.

I evaluate engineers on two pillars. Impact, which is reliability, performance and scalability. And communication and leadership, which is alignment, clarity and knowledge-sharing. At the higher levels I expect engineers to design systems that other teams build on. I wrote these into a career matrix with four levels: Associate, Engineer, Senior and Staff. Using AI well is part of what I expect at every level.

On team structure, I aim for roughly thirty percent senior, forty percent mid and thirty percent junior. It creates growth paths without sacrificing delivery on complex work. I keep a primary and a secondary on every project so no single person is a point of failure. I change the structure as the business changes, and I keep each engineer's growth in mind when I do.

Across a larger org, I made RFCs mandatory for significant work and anchor my reviews on production risk, scale and maintainability: what happens if this fails, how do we mitigate it, what will this cost in production? I lean on the experts on my team. My job is to set things up so the right decisions get made, even when I am not in the room.