How I lead

Most of what I believe about engineering leadership comes from having been wrong about something first, and from watching which decisions compounded and which ones only looked decisive.

Problem→Strategy→Build→Scale→Optimize→Compound

That sequence is not a methodology. It is the order I have found the questions actually arrive in, and most of the trouble I have seen came from starting somewhere in the middle.

Start with the problem, not the technology

Technology is never the starting point. The questions that come first are whether the problem is real, whether the opportunity is large enough to matter, whether solving it creates something a customer would value, and whether it is worth capacity that could go elsewhere. If those answers hold, I am in. If they do not, no amount of architectural elegance rescues it.

The most useful work I have done usually did not look like an engineering problem when I found it. One of the largest adoption gains I was part of came from noticing that a capability was sitting next to a customer base twenty-five times larger and that nobody had filed a ticket about it.

Know the difference between parity and advantage

Some capabilities are the price of staying in the game. Others make the business harder to catch. They are not the same investment and they should not get the same weight.

The discipline is mostly subtractive. Deciding what not to build is a harder conversation than deciding what to build, because the thing you are declining usually has someone’s name attached to it. In the post-acquisition years I stopped work that was not aligned with retention or margin, including things customers had asked for, and worked those conversations directly rather than letting the roadmap absorb them quietly.

Build for the long game

The organizations I have found most frustrating are the ones that can see the opportunity to be genuinely large and settle for the quarter instead. Near-term wins are table stakes. The interesting question is whether a business will still be relevant in a decade, and that requires taking bets whose payoff arrives long after the meeting where you defended them.

This is harder than it sounds because it means holding a position without evidence for a while. When we ran modernization and cost reduction simultaneously, the payoff landed two to three quarters behind the work that produced it. The team held that on the strength of a model, not a result, and that is the cost of playing a longer game.

Decide fast, and stay willing to reverse

Slow decisions are more expensive than wrong ones that get corrected. Time spent not making progress is the most costly time there is, and it rarely shows up in anyone’s reporting.

Speed is only affordable if you are genuinely willing to unwind your own calls. I adopted a distributed SQL engine when the economics supported it and led the work to remove it three years later when they did not. Choosing a technology and staying loyal to it are different things, and the second one is what makes fast decisions dangerous.

Stay deep enough to see the trade-off

I want to be technical enough to challenge an architecture, understand what a decision costs to run rather than just to build, and know when an estimate is optimistic. That is a different thing from wanting to do the work myself.

The clearest example I can give is choosing polyglot persistence on a platform rebuild — three data technologies because three workloads genuinely wanted different things. It was the right call and it came with a permanent operational tax: more systems to run, more to hire for, fewer engineers who could hold the whole stack. You cannot weigh that if you are only looking at the benchmark.

Treat cost as an architectural property

Cost is not something finance discovers after engineering has finished. It is a property of the design, and it behaves in ways that are only visible from inside the architecture.

The most effective efficiency work I have led did not remove cost so much as move it — taking enormous processing out of one part of a pipeline and pushing a smaller amount into another. That was comfortably net positive and it was not free, and the only way to know which is which is to have instrumented the system before you needed the answer.

Build capability before you need headcount

Organizations do not become capable by getting bigger. They become capable when the people in them can take on problems nobody has handed them yet.

That means hiring for who someone will be in two years, not only who they are now. It means promotion conversations grounded in evidence rather than visibility, which is why I run readiness against the same questions for everyone. And it means accepting that distributing knowledge costs your senior people the time they would rather spend solving the next problem. The alternative is an organization that scales in headcount and not in capability.

Working with me

I am most useful setting technical direction alongside architects, a CTO and product leadership — challenging designs, making the trade-offs explicit, and going deep when a problem needs it.

I do not need to write the code. I need to be able to.