Engineering Leadership: Diagnostics, Ambition, and Mentorship

Building software is hard. Building the teams that build software is harder. I've been doing both for a while now, and I've learned that most of the hard parts aren't technical — they're about figuring out who people actually are versus who they think they should present themselves as, and then arranging things so the work matches the person. This isn't management theory; it's what I actually do when I join a new team or interview for a critical hire.

The Ambition Diagnostic

When I'm interviewing engineers — especially for leadership roles — technical skills are table stakes. What I'm really trying to understand is whether their actual ambitions map onto what the role requires. I've learned to ask one question that tends to cut through the rehearsed answers:

"Suppose you could design your dream job. You start Monday. It's 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 "what's available" and surfaces "what's actually wanted." Builders talk about code, architecture, shipping things. Managers talk about people, unblocking teams, strategy. Specialists go deep on a specific technology and could talk about it for an hour. None of these is wrong — but if their dream day looks nothing like the role I'm hiring for, we're both setting ourselves up for frustration.

I once spent three months trying to figure out why a technically excellent engineer wasn't thriving in a team lead role. Eventually had a conversation where it became obvious their dream job looked like a staff IC role, lots of deep technical work, minimal people management. We'd put them in the wrong place entirely. Moving them fixed things almost immediately. I should have asked this question in the interview.

Solving Problems vs. Inventing Them

New engineers often rush to solutions. Experienced leaders rush to definitions. When a team brings me a "problem," I try to slow down before we write a single line of code.

The questions I work through: Is this actually a problem, or just an annoyance? What happens if we do nothing — does anything break, does anyone notice? Can this wait until we have more data, or is something genuinely blocked right now? Can we buy a solution or use a library instead of building? And if we have to build, what's the smallest verified step we can take?

This probably kills about half the "urgent" projects before they start. That sounds like it would frustrate engineers, and sometimes it does briefly, but mostly they're relieved. Nobody wants to spend weeks building something that didn't need to exist.

How I Mentor

I don't believe in hand-holding. I do believe in guardrails — making sure people have what they need to figure things out themselves, which is different from just telling them the answer.

When someone comes to me debugging a problem, I almost never give the answer directly. I ask what they've tried. I ask what their hypothesis is. I ask what they'd check next. Usually they talk their way to the answer without needing me at all, which is the point. The goal is for them to need me less over time, not more.

I also try to be open about my own mistakes. I'll bring up things that went wrong in standup or retrospectives — not to be performatively self-deprecating, but because it signals that failure is a normal part of the process and not something to hide. Teams that hide failure accumulate invisible problems.

The other thing I push on: making sure engineers can explain why a feature matters to the business. Not what it does technically, but why it exists. If someone can't articulate that, they don't fully understand what they're building, and that shows up eventually in the decisions they make.

Team Health

The diagnostic I trust most is what I think of as the say/do ratio. High-performing teams deliver what they commit to, even when that means promising less upfront. Low-performing teams promise the moon and deliver explanations for why the moon wasn't deliverable. Trust accumulates through reliable delivery, not through optimistic estimates and heroic scrambles at the end of every sprint.

A team that consistently does what it said it would do — even if the scope is smaller than you'd like — is a team you can plan around. That predictability is worth more than the occasional sprint where everything comes together perfectly after a lot of drama.