Only Amateurs Think Leadership Is About Having the Answers

When you got promoted into leadership, something strange happened.

You started thinking your job was to know things.

Not everything. Not the answer to every question. But enough. Enough technical depth. Enough domain expertise to justify your seat at the table.

Most of us walk straight into this trap.

You spent years being the person who solved problems. You built a reputation on knowing how things worked. You got recognised for being right. Then someone handed you a team and said, "You're in charge now."

So you kept doing what worked before. You kept being the one with answers.

That was the mistake.

The Confidence Trap

Here's what happens in most tech organisations: the people who get promoted are the ones who look like they know what they're doing. Not the ones who do.

Dr. Tomas Chamorro-Premuzic, professor of business psychology at Columbia University, has spent years studying why so many leaders are incompetent. His finding: we consistently mistake confidence for competence. The person who speaks first, speaks loudest, and radiates certainty gets mistaken for the best leader in the room.

In tech, this problem compounds. We have a cultural worship of the "10x engineer." The person who knows everything, writes the most code, solves the hardest problems. When you promote someone like that, they often become the single point of failure for every decision the team makes.

Not leadership. A bottleneck with a title.

What Google Found Out

In 2012, Google launched a multi-year study called Project Aristotle. The goal: identify what made their best teams outperform the rest. They studied 180 teams across the company, tracking 250 different attributes.

Most people guess it's a combination of the smartest individuals, an experienced manager, and ample resources.

Wrong.

The single biggest predictor of team performance was psychological safety. Whether people felt safe enough to speak up, raise concerns, flag problems, and challenge each other.

Individual expertise ranked way down the list. Having the sharpest people in the room didn't matter nearly as much as whether those people felt free to use their brains.

Think about what that means. You hire ten brilliant engineers. You install an expert-leader above them. The expert-leader has most of the answers, so they dominate every technical discussion. The brilliant engineers learn to defer.

You have built a team that performs at a fraction of its capacity. And your expert-leader will never know, because they'll attribute every win to their own decisions.

The Ego Bug

A piece published on Medium in late 2025 described it well: "In many tech organisations, technical expertise quietly turns into perceived superiority. Questions about cost, coordination, users, or timing get treated as distractions, while code becomes the unquestionable centre of every decision."

I've watched this play out more times than I'd like to admit.

A senior engineer gets promoted to team lead. Excellent at solving problems individually. Now in meetings, they're already formulating a better answer before the previous speaker has finished. They cut across ideas. They finish other people's sentences. They have the solution before the question is even fully stated.

The team picks this up fast. They stop raising half-formed ideas. They stop flagging concerns early. They show you what you want to see, not what's true.

Then you wonder why your retrospectives are so quiet.

The ego isn't always arrogance. Sometimes it's habit. A deeply ingrained habit of being the most technically capable person around and acting accordingly. The engineer-turned-leader doesn't think they're shutting down conversation. They think they're being efficient.

They're being efficient at producing the wrong outcomes.

The Code Review Trap

Code reviews are where this failure mode shows up most clearly.

A leader who needs to be right turns code reviews into lectures. They comment on every deviation from their preferred approach, even when the alternative works fine. Junior engineers stop submitting ambitious code and start submitting safe code. The thing you thought was quality control becomes a monoculture factory.

Great technical leaders treat code reviews differently. They ask: "Why did you approach it this way? What trade-offs were you weighing?" They're genuinely curious. Sometimes the junior engineer's approach is better. Sometimes it isn't, but the explanation reveals a gap in documentation or shared understanding worth addressing.

Either way, you learn something. Either way, the engineer feels respected.

The expert-leader who skips the question and jumps to the correction loses both outcomes.

What Effective Leaders Do Instead

Chamorro-Premuzic made a point worth sitting with. AI commoditises technical knowledge faster every year. Want to know how something works? Ask an AI. The knowledge gap which used to justify expert-leaders is narrowing fast.

What's left is the ability to create conditions where your team does its best thinking. The ability to ask questions that open up possibilities rather than close them down.

Forbes calls this "inquisitive leadership". It's not a soft skill. It's the hardest shift a technical person makes: from performer to enabler.

Here's what it looks like in practice:

Replace declarations with questions in your next meeting

Instead of "we should use microservices here," ask "what are the trade-offs we'd see with microservices versus a monolith for this use case?" You'll hear things you didn't know. Your team will feel heard. And on the days when they propose something genuinely wrong, they'll have articulated the reasoning, which makes the correction land better.

Stay quiet for ten seconds after someone stops speaking

This is brutal if you think fast and talk faster. Ten seconds feels like forever. But the pause signals you're processing, not queuing your rebuttal. It changes the dynamic in the room completely. People start to finish their thoughts properly, knowing they won't be interrupted before the point lands.

Say "I don't know" out loud, then ask who does

This feels like weakness. It isn't. Leadership coach Ruth Wooderson puts it plainly: "Don't trust a leader who never says, 'I don't know.'" When you admit not knowing, two things happen. Your team stops pretending to know things they don't. And they trust you more, not less.

The follow-up matters as much as the admission. "I don't know... who in the team is closest to this?" You're redistributing authority in real time. You're signalling whose expertise matters.

Stop making decisions alone that the team should make together

Every time you make a decision in isolation that your team was equipped to make, you do three things: you miss the information they held, you deprive them of the growth that comes from making the call, and you reinforce their belief that thinking for themselves is optional.

The best leaders I've worked with sit in meetings where they know the answer... and ask the question anyway. They want to see the team get there. When the team does, the decision is theirs, which means the execution is theirs too.

The Real Performance Lever

The technical leaders who build the best teams over time share one trait. They're more interested in what the team knows than in what they know themselves. They see their role as creating conditions for good decisions, not making all the decisions themselves.

This isn't idealism. The data backs it up. Research consistently shows leaders who ask better questions and build psychological safety outperform those who invest in demonstrating their own expertise.

And the opposite? The leaders who prioritise being right over being effective are the bad bosses people remember for the rest of their careers. In our research on workplace experiences, 99.5% of respondents said they've had at least one of those. The story they tell about those leaders is almost never about incompetence. It's about ego. The boss who couldn't admit they were wrong. The boss who made every meeting about proving their own intelligence.

What you're building, one meeting at a time, is a team where people bring their thinking. Not a team performing deference to yours.

Your team is smarter than you give them credit for. Give them the room to prove it.

What's one question you've been answering, when you should have been asking it instead?