I Used to Think Leadership Meant Having the Answers

What I believed for most of my career, the moment it stopped being enough, and what I lead from now.

I want to write something I haven't written publicly before.

Not a client story. Not a framework. Not an observation about what I've watched happen in other people's leadership. Something about my own.

I've been building toward this for a while: five months of writing about leadership, identity, and the human side of high performance. Somewhere in that writing, I've become more honest with readers about what is beneath it all. What I believe about leadership and where that belief came from.

So here it is.

The Belief That Built My Career

For most of my professional life, I held a belief about leadership that I never examined directly because it had always worked.

The belief was this: leadership is fundamentally about competence. About knowing more, seeing further, and deciding faster than the people around you. About being the person in the room whose technical depth commands respect, whose judgment can be relied on, and whose answers, when they arrive, tend to be right.

This belief served me well for a long time. I spent more than twenty years in engineering leadership across aerospace, financial services, fintech, and enterprise technology. I built teams, solved hard problems, and delivered solutions that worked. I got every promotion because I was the person who knew the most in the conversation. Or at least knew it in the way that mattered most to the problem we were trying to solve.

I was proud of that. I still am, in some ways. The depth is real, and it matters.

But the belief had a ceiling. And I didn't see it until I hit it.

The Moment It Stopped Being Enough

The moment didn't announce itself. That's the thing about ceilings — you don't know you've hit them until you're standing there with your head pressed against something you can't see through.

What I started to notice, somewhere in the middle of leading a significantly larger organization than I'd led before, was that my instinct — in almost every situation — was to have the answer. Not to create the conditions for the team to find it. Not to hold the question long enough for something better than my first response to emerge. To have it, and to offer it, and to move on.

And I started to notice what that instinct cost.

It cost the team the experience of finding the answer themselves; which is the experience that actually builds capability. It cost me the answers that were better than mine, that existed in the room but didn't surface because I'd filled the space first. It cost the quality of something I valued enormously: the psychological safety that lets people bring you the hard thing, the real thing, the thing they wouldn't normally say.

Because the leader who always has the answer trains the people around them, over time, to bring him questions rather than thinking. And that is a slower and more invisible cost than almost any technical problem I've ever had to solve.

What the Work Actually Was

I've written about this in the context of clients — the engineering leader who stopped being the smartest person in the room and watched his career take off. The pattern is common enough that I've written about it from the outside many times.

What I haven't written is that I know it from the inside.

The work, for me, has not been a single insight or a dramatic shift. It has been slower and less glamorous than that. It has been the practice — ongoing, imperfect, still in progress — of staying in the question a beat longer than feels comfortable. Of asking something genuinely instead of reaching for what I already know. Of finding out what my team thinks before I've offered what I think. Of letting someone in the room be right without needing to have been part of getting them there.

None of that sounds remarkable written down. It sounds obvious, even — of course a leader should listen before they speak, create space before they fill it. The gap between knowing that and actually doing it, consistently, under pressure, when the instinct to have the answer is so well-established that it fires before conscious thought — that gap is where the actual work lives.

I am still in it. I suspect I always will be.

What I Lead from Now

What has shifted is not the belief — not entirely. Technical depth still matters to me. I still want to understand the problems my team is working on at a level that lets me ask better questions. I don't think that changes.

What has shifted is what I understand the depth to be for.

Not to have the answer. To know the right questions. To recognize when something that looks like a solution is actually a workaround. To see the architectural implication that a less experienced engineer might miss — not so I can name it first, but so I can create the conditions in which someone on the team names it, owns it, grows from the experience of finding it.

The depth is in service of something larger now. And that larger thing — the quality of the team's thinking, the conditions under which people can do their best work, the culture of honesty and capability that I am trying to build — that is what I understand leadership to actually be.

It took me a long time to get here. I'm not done getting here.

But I wanted to say it plainly, in this space where I've been writing about leadership for months: the thing I help clients work through is not separate from the thing I am working through myself. The identity shift from expert to leader. The practice of creating space rather than filling it. The slow, unglamorous, ongoing work of becoming someone who makes the room more capable rather than being the most capable person in it.

I know it from the inside because I live there.

Why I'm Writing This

I've thought about why I wanted to write this piece; not just leave it implied in the client stories and frameworks I share more comfortably.

Part of it is honesty. The coaching I do is about helping people develop as human beings, not just as professionals. That work has more integrity when I'm transparent about my own development. I don't have this figured out. I'm in it, the same way the people I work with are.

Part of it is the specific reader I have in mind as I write. The senior technical leader who recognizes the pattern: the reliance on expertise, the ceiling it creates, the discomfort of letting it go but hasn't yet found the language for it, permission to name it, or a path through it. This is for them.

And part of it is simpler than either of those things. After five months of writing about leadership, I wanted to say something true. Not something useful, necessarily. Not something that lands as advice. Something that is simply, honestly, what is actually going on in my experience as a leader.

This is what is actually going on.