Engineering Leadership: Diagnostics, Ambition, and Mentorship

Building software is hard. Building the teams that build software is harder. Over the years, I have distilled my approach to engineering leadership into a few diagnostic frameworks and interviewing patterns. This isn't management theory; it is what I do when I join a new team or interview a critical hire.

The Ambition Diagnostic

When interviewing engineers, especially for leadership roles, technical skills are table stakes. What I really hunt for is alignment between their ambition and the company's reality. I ask one question to reveal this:

"Suppose you could design your dream job. You start Monday. It is at your ideal company, with your ideal title and salary. All you have to do is tell me: what does your day look like?"

This question strips away the negotiation. It removes the constraints of "what is available" and exposes "what is desired."

The Builder talks about code, architecture, and shipping.
The Manager talks about people, unblocking teams, and strategy.
The Specialist talks about deep-diving into specific technologies.

If their dream job doesn't look like the role I am hiring for, we are setting them up to fail.

Solving Problems vs. Inventing Them

New engineers often rush to solutioning. Experienced leaders rush to definition. When a team brings me a "problem," I walk them through a five-step filter before we write a line of code:

Is it really a problem? Or is it just an annoyance or a "nice to have"?
Does it need to be solved? What happens if we do nothing?
Does it need to be solved now? Can we wait until we have more data?
Does it need to be solved by us? Can we buy a solution or use a library?
Can we break it down? If we must solve it, what is the smallest verified step we can take?

This framework kills 50% of "urgent" projects before they start, saving massive amounts of engineering capital.

Mentoring Patterns

I don't believe in hand-holding, but I believe in guardrails. My mentoring style focuses on:

Socratic Debugging: I never give the answer. I ask, "What have you tried?" and "What is your hypothesis?" until they find the answer themselves.
Public Failure: I celebrate my own mistakes openly. This signals that failure is part of the process, provided we learn from it.
Business Context: I force engineers to explain why a feature matters to the business. If they can't, they don't understand the feature yet.

The Team Health Check

Finally, I diagnose team health by looking at their "say/do" ratio. High-performing teams deliver what they promise, even if they promise less. Low-performing teams promise the moon and deliver excuses. Trust is built on reliable delivery, not heroic efforts.