What If the Best Leader in the Room Isn't the One With All the Answers?

The Question That Stuck With Me

I've been asked a lot of questions throughout my career.

Some were thoughtful. Some were predictable. Others seemed designed to see how well I could navigate an uncomfortable conversation.

But there's one question from an interview that has stayed with me more than any other.

"If you don't have the background of being a developer, how do you expect to help them?"

I remember thinking about the weight of that question.

Not because I thought it was unfair. In fact, I thought it was a perfectly reasonable thing to ask someone interviewing for a position managing software engineers.

Here I was, pursuing an engineering leadership role without having followed the traditional path of spending years as a software developer.

I understood the fundamentals of software development. I'd spent time learning, experimenting, and building things of my own. I had enough technical familiarity to appreciate the work, but I wasn't going to pretend that made me equivalent to someone who had spent a decade writing, deploying, and maintaining production software.

The person asking the question wanted to know how I intended to support people whose technical expertise was greater than mine.

And that's a legitimate concern.

After all, how can you lead someone through challenges you've never personally experienced?

How can you provide value to people who know more about the work than you do?

How can you possibly be effective when someone comes to you with a problem you don't know how to solve?

Those questions get to the heart of a much larger conversation about what we expect from leaders.

And for me, the answer began with a simple acknowledgment.

Not everyone can have every answer.

The Answer I Gave

I don't remember every word of my response, but I remember the conviction behind it.

I explained that I understood I wasn't going to be the person every engineer approached when they encountered a difficult technical problem.

And frankly, I didn't want to build a team where I had to be.

If an engineer came to me with a question about a complex framework, an architectural decision, or an unfamiliar piece of code, there was a very real possibility that I wouldn't immediately know the answer.

But why should that automatically mean I couldn't help?

I could connect that person with someone who had the experience they needed.

I could help them identify resources.

I could introduce them to another engineer who had encountered something similar.

I could ask questions that helped them look at the problem from a different perspective.

And if we still couldn't find an answer, I could help create the time, space, and support necessary for them to investigate it.

But my response went beyond connecting people to resources.

Because I explained that what I really wanted was to help develop engineers who didn't always need someone to provide an answer in the first place.

People who could approach an unfamiliar problem with confidence.

People who understood that not knowing something wasn't a reflection of their intelligence.

People who knew their teammates well enough to recognize where expertise existed.

People who were comfortable admitting when they needed help.

And people who had enough confidence in themselves to believe that even if they didn't know the answer today, they could develop the ability to find it tomorrow.

I didn't want to become the person my team depended on for every solution. I wanted to help build a team that knew how to find solutions without depending on any single person.

That was my answer.

And the more experience I've gained in engineering leadership, the more strongly I've come to believe in it.

We've Confused Leadership With Having Answers

Somewhere along the way, I think we developed an unfortunate expectation of leadership.

We began associating leadership with being the person who knows.

The person who can answer every question.

The person who can walk into a room, assess a problem, and immediately provide direction.

The person whose experience somehow makes their judgment more valuable than everyone else's.

And don't misunderstand me.

Knowledge matters.

Experience matters.

Technical credibility matters, particularly in environments where decisions can have significant consequences.

There are situations where a leader needs to possess enough domain expertise to recognize an unacceptable risk, challenge an unrealistic commitment, or know when a proposed solution hasn't been adequately examined.

I'm not suggesting that leaders should be ignorant of the work they're responsible for.

But I do question whether the value of leadership should be measured primarily by the number of answers a person can provide.

Because there's a fundamental problem with building a team around someone who always has the answer.

Eventually, everyone starts waiting for that person to provide it.

Think about what happens when a manager becomes the center of every decision.

A problem emerges.

Someone raises it to the manager.

The manager evaluates the situation, proposes a solution, and tells everyone what to do.

The problem gets solved.

On the surface, that might look like effective leadership.

But what happens the next time a similar problem emerges?

People return to the manager.

And the next time?

They return again.

Eventually, the manager becomes the mechanism through which the team operates.

That may feel important. It may even feel rewarding to be needed.

But it introduces a dangerous dependency.

If your team's ability to solve problems depends on your ability to provide answers, you haven't necessarily developed a stronger team. You may have simply made yourself the most important bottleneck in the system.

I've never wanted to be that bottleneck.

The Difference Between Giving Someone an Answer and Helping Them Find One

Imagine an engineer approaches their manager with a problem.

They've been troubleshooting an issue for hours. They've reviewed the documentation, searched through the codebase, and tried several different approaches.

Nothing is working.

They're frustrated.

Now imagine two possible responses.

The first manager immediately tells them what to do.

Perhaps the manager has encountered the problem before. They recognize the issue, provide a solution, and the engineer returns to their desk.

The problem is resolved.

That's certainly valuable, particularly when time is critical or the consequences of delay are significant.

But consider another approach.

The manager begins asking questions.

"What have you already tried?"

"What do you know for certain?"

"What assumptions are you making?"

"Who else might have experience with this part of the system?"

"What would you investigate next if I weren't here?"

The manager may not know the technical answer.

But the conversation can still be enormously valuable.

Because rather than replacing the engineer's thinking, the manager is helping strengthen it.

They're encouraging the individual to examine the problem more deliberately.

To question assumptions.

To recognize available resources.

To identify the next reasonable step.

And perhaps most importantly, they're communicating something that doesn't always get said explicitly.

I believe you're capable of figuring this out.

Sometimes that belief can be more powerful than an immediate answer.

Of course, there's a balance.

Repeatedly responding to someone who's genuinely stuck with nothing more than another question can become frustrating and unhelpful.

Coaching should never become an excuse for withholding support.

Sometimes people need direct answers, escalation, access to expertise, or someone willing to remove an obstacle.

But helping someone solve the problem in front of them and helping them become a stronger problem-solver are not mutually exclusive objectives.

The best leaders understand when to do each.

An answer might solve today's problem. Developing someone's ability to find answers can change how they approach every problem that follows.

The Most Underutilized Resource on a Team Is Often the Team Itself

Something else has always fascinated me about organizations.

We spend enormous amounts of time identifying individual skills, evaluating competencies, and measuring performance.

We create development plans, capability matrices, and elaborate processes for determining who knows what.

Yet sometimes we overlook one of the most obvious opportunities sitting directly in front of us.

The collective intelligence of the people already working together.

Consider a team of engineers.

One person might have an exceptional understanding of front-end architecture.

Another might excel at database design.

Someone else may know the deployment pipeline better than anyone.

Another engineer may have an incredible ability to troubleshoot difficult issues, even if they aren't the most experienced person on the team.

And there may be a relatively new associate engineer who brings a fresh perspective that challenges assumptions everyone else has stopped questioning.

Individually, each person has strengths and limitations.

Collectively, they possess a range of knowledge and experience that no single individual could reasonably be expected to reproduce.

But here's the catch.

That collective intelligence only creates value if people are willing and able to access it.

If teammates don't know one another's strengths, they'll struggle to recognize who might help.

If they don't trust one another, they'll hesitate to ask.

If the environment rewards appearing knowledgeable more than becoming knowledgeable, people may hide their uncertainty.

And if every question is expected to travel through the manager, much of that collective capability remains untapped.

This is where I believe leadership has an extraordinary opportunity.

Not to become the central repository of knowledge, but to help build the relationships that allow knowledge to move freely.

Introduce people to one another.

Encourage collaboration across areas of expertise.

Create opportunities for engineers to teach what they know and learn what they don't.

Recognize the person who takes time to help a teammate, not just the person who delivers an impressive individual result.

Make knowledge sharing something the team values rather than something people do only when they have spare time.

Because a team doesn't become more capable simply by accumulating talented individuals. It becomes more capable when those individuals learn how to make one another better.

And that brings me to something I believe is even more important than technical knowledge.

The Courage to Say, "I Don't Know"

Three words.

That's all it takes.

I don't know.

Yet I've watched incredibly capable people struggle to say them.

And I understand why.

There's an unspoken pressure in many professional environments to appear competent at all times.

We worry that asking a question will make us look inexperienced.

We hesitate to admit confusion because someone else might interpret it as a weakness.

We convince ourselves that we should already understand something, particularly when we've been working in a field for years.

So instead of asking for help, we struggle silently.

We spend hours trying to solve problems that someone else could help us understand in minutes.

We make assumptions.

We avoid conversations.

And sometimes we create even larger problems because we're more concerned about protecting our image than acknowledging our limitations.

I think that's incredibly unfortunate.

Because vulnerability, when met with respect and support, can become one of the most powerful catalysts for team development.

Imagine an associate engineer saying to a senior engineer, "I don't understand why we're approaching the problem this way. Can you help me?"

Now imagine that senior engineer responding with curiosity and patience rather than frustration or condescension.

The associate learns something.

But something else happens too.

Trust grows.

A relationship strengthens.

The associate becomes more comfortable asking questions.

And the senior engineer has an opportunity to develop their ability to communicate, mentor, and lead.

Now imagine the reverse.

The senior engineer encounters a problem in an unfamiliar area and turns to that same associate, who happens to have recent experience with the technology.

Suddenly, the relationship becomes reciprocal.

Both people recognize that expertise is contextual.

Both discover that they have something valuable to contribute.

And both become more comfortable acknowledging that their knowledge has limitations.

That's the kind of environment I want to create.

An environment where asking for help isn't interpreted as a lack of capability, but as evidence that someone is committed to finding a better answer.

Psychological safety doesn't mean everyone is always comfortable, that mistakes have no consequences, or that difficult conversations disappear.

It means people believe they can speak honestly, ask questions, raise concerns, and acknowledge uncertainty without being humiliated for doing so.

And when that exists alongside clear expectations and accountability, extraordinary collaboration becomes possible.

Self-Sufficiency Doesn't Mean Doing Everything Yourself

There's an important distinction I want to make here.

When I talk about developing self-sufficient engineers, I'm not suggesting that people should become completely independent of everyone around them.

In fact, I believe that interpretation of self-sufficiency can be counterproductive.

No one knows everything.

No one has unlimited experience.

And no one, regardless of talent, can reasonably solve every complex problem alone.

To me, self-sufficiency isn't the ability to operate without help.

It's the confidence and judgment to recognize what you can solve independently, identify when you need support, and know how to move forward when the answer isn't immediately available.

That might mean researching a technology.

It might mean experimenting with a proof of concept.

It might mean contacting someone on another team.

It might mean asking a colleague to review an approach.

And sometimes it might mean raising your hand and saying, "I've gone as far as I can with what I know. I need some help."

None of those actions represent failure.

They represent resourcefulness.

They demonstrate an understanding that solving a problem isn't necessarily about proving how much you know.

It's about finding the best path toward the outcome.

I would much rather work with someone who knows how to seek help than someone who believes their value depends on never needing it.

Because the first person is willing to grow.

The second may be limiting their growth by protecting an image of competence.

And as a leader, I want to encourage the first behavior.

Not because I'm uninterested in people developing deep expertise.

Quite the opposite.

I want people to develop exceptional capabilities.

But I also want them to recognize that capability and vulnerability can coexist.

You can be brilliant and still need assistance.

You can be experienced and still be wrong.

You can be confident and still ask questions.

And you can be a leader without having every answer.

My Job Is to See What People Are Capable Of

Throughout my career, one of the things I've always felt confident in is my ability to connect with people.

To recognize their strengths.

To understand what motivates them.

To see potential that they sometimes struggle to recognize in themselves.

I don't say that because I believe I have some extraordinary ability to predict the future.

I say it because I've spent years watching what happens when people are given the right combination of trust, opportunity, challenge, and support.

People are capable of remarkable things.

Sometimes far more than they initially believe.

I've seen people hesitate to take on responsibilities because they were convinced they weren't ready.

I've watched talented individuals underestimate their abilities because they were comparing themselves to someone with entirely different experiences.

I've seen people become so accustomed to asking for permission that they temporarily lose confidence in their own judgment.

And I've seen what happens when someone finally begins believing that they're capable of figuring things out.

Their behavior changes.

They become more willing to experiment.

They ask better questions.

They take ownership of increasingly complex problems.

They become more comfortable with uncertainty.

And eventually, they begin helping others develop that same confidence.

That last part is especially meaningful to me.

Because when someone I've helped develop begins investing in another person's growth, something much larger than an individual success has occurred.

Capability is beginning to multiply.

The influence of leadership is moving beyond the leader.

The team is becoming stronger in ways that no longer require my direct involvement.

And that's precisely what I want.

I don't want people coming to me for every answer five years from now simply because that's what they've always done.

I want them to look back and recognize how many problems they can now solve that once seemed beyond their abilities.

I want them to become the person someone else feels comfortable approaching.

The person who doesn't make a teammate feel small for asking a question.

The person who recognizes potential and helps bring it forward.

The person who understands that sharing knowledge doesn't diminish their value.

It expands it.

The greatest impact I can have as a leader isn't the number of problems I personally solve. It's the number of people who become more capable of solving problems because we worked together.

The Responsibility That Comes With Trust

There's something deeply personal about all of this.

When someone agrees to work under your leadership, they're entrusting you with more than their daily assignments.

They're allowing you to influence their experiences, opportunities, confidence, and professional development.

That trust deserves to be treated with care.

And I don't think leaders always appreciate how much their behavior influences whether someone feels capable.

A dismissive comment can make a person hesitant to ask another question.

A poorly handled mistake can teach someone to conceal future problems.

Constantly overriding decisions can slowly convince capable people that their judgment isn't trusted.

But the reverse is also true.

A thoughtful question can encourage someone to look at a problem differently.

A moment of encouragement can help someone attempt something they've been avoiding.

An opportunity to lead can reveal abilities that might otherwise have remained undiscovered.

And a leader who is willing to say, "I don't know, but let's figure it out," can demonstrate that uncertainty isn't something to fear.

That's the kind of trust I want to earn.

Not the trust that comes from convincing people I have all the answers.

The trust that comes from showing them I'll support them when we don't.

There will be times when I need to step in.

Times when I need to make a difficult decision.

Times when I need to challenge someone's approach or hold them accountable for an outcome.

Empowerment doesn't eliminate responsibility.

But those moments should exist within a relationship where people understand that my objective isn't to prove my authority.

It's to help them succeed.

And if I've done that consistently, I believe people will give me something far more valuable than compliance.

They'll give me their trust.

So, How Do I Expect to Help Them?

If I were asked that same interview question today, I think my answer would be even simpler.

By helping them realize they don't need me to have every answer.

I'll help by understanding their aspirations and finding opportunities that challenge them to grow.

I'll help by connecting them with people whose knowledge complements their own.

I'll help by removing barriers that prevent them from doing meaningful work.

I'll help by asking questions that encourage independent thinking instead of immediately providing solutions.

I'll help by creating an environment where they can challenge ideas, acknowledge mistakes, and ask for support without fearing that doing so diminishes their value.

And I'll help by reminding them, particularly when they're facing something difficult, that being unable to solve a problem immediately doesn't mean they're incapable of solving it.

Sometimes the answer is already within their reach.

Sometimes it's sitting with someone on the other side of the room.

Sometimes it requires research, experimentation, collaboration, or an entirely different perspective.

And sometimes the answer simply hasn't been discovered yet.

But I want the people I lead to believe that they have the intelligence, capability, relationships, and resilience to find a way forward.

I can't promise to know everything.

I can't promise that every problem will have an easy solution.

And I certainly can't promise that we'll never encounter something that challenges every assumption we have.

But I can promise that they won't have to navigate those moments without support.

And I can work to ensure they become increasingly confident in their ability to navigate them.

Because when I think about the kind of engineering team I want to build, I don't picture a room full of people waiting for direction.

I picture people collaborating.

Challenging one another.

Sharing what they know.

Admitting what they don't.

Celebrating one another's accomplishments.

And approaching difficult problems with the belief that, together, they have the capacity to figure things out.

That's what high performance looks like to me.

Not a team that never needs help.

Not a team where everyone knows everything.

And certainly not a team whose success depends on one person's expertise.

A team that trusts itself enough to be vulnerable, respects one another enough to collaborate, and believes in its collective ability to overcome what it doesn't yet understand.

So, to the person who asked me that question during the interview, I remain grateful.

Because it forced me to articulate something I had believed for years but hadn't necessarily expressed so clearly.

Leadership isn't always about being the person people turn to for the answer.

Sometimes it's about being the person who helps them discover that they're capable of finding it themselves.

And when they can't?

They know it's perfectly acceptable to reach out a hand.

Because someone on the team will be there to take it.

If I've built a team where people feel confident enough to try, humble enough to learn, and safe enough to ask for help, then I believe I've answered that interview question through something far more meaningful than words.

I've answered it through the people they've become.