The Technical Leader's New Superpower Is Asking Better Questions
Most leaders approach AI the wrong way. They ask it for answers. They prompt for outputs. They treat it as a faster way to get to done.
Understandable. We're trained to value answers. Answers close tickets. Answers unblock teams. Answers make you look smart in meetings. But in the AI era, answers are cheap. The scarce resource is questions.
Why questions matter more now
Before AI, the limiting factor was execution. Could we build it? Could we ship it? The leader who could produce answers was the leader who added value.
AI has inverted this. Any engineer with a prompt can now generate a reasonable answer to most technical questions. What remains scarce is knowing which questions to ask.
A leader who asks better questions produces better outcomes not because they know more, but because they direct attention more effectively. "What assumptions does this depend on?" surfaces risk no prompt would reveal. "What would have to be true for this to fail?" identifies failure modes no code review catches.
The three types of questions that matter most
I've noticed three categories that produce the most leverage. Framing questions establish boundaries — "What problem are we actually solving?" "What does success look like?" These prevent teams from building the wrong thing efficiently.
Constraint questions surface hidden limitations — "What are we assuming about this dependency?" "What would break if this system were unavailable?" These catch assumptions that turn into incidents.
Legacy questions connect the present to the past — "Has this approach been tried before?" "What did we learn last time?" These prevent organizations from repeating mistakes no one documented.
The best question I ask now
Before a review, I ask the AI: "What questions should I be asking about this proposal?" The answers are rarely the questions I would have come up with on my own. They're better because they're based on data and history I can't hold in my head.
The result is that I contribute more value by asking three good questions than I would by providing ten answers. That was a hard lesson to learn. My instinct is still to provide the answer. But the data doesn't lie — the teams that get the best questions make better decisions than the teams that get the best answers.
What this means for your role
If you're a technical leader who prides yourself on having the answers, this transition is uncomfortable. Your identity is built on being the person who knows. The shift to being the person who asks requires letting go of that identity.
But the leverage is real. A team that learns to ask better questions outperforms a team with better answers every time. Good questions lead to better understanding. Better understanding leads to decisions that hold up.
The best technical leaders in the AI era won't be the ones with the best answers. They'll be the ones who ask the questions that make everyone else's answers better.
The most valuable skill nobody teaches
We spend years teaching engineers to produce good answers. Write clean code. Design solid architectures. Debug effectively. All of these are answer skills. Valuable skills. But they're the skills AI is best at.
Question skills — the ability to ask things that reframe problems, surface hidden assumptions, and connect past experiences to present decisions — those are what distinguish great leaders from good ones. And they're almost never taught.
I learned this the hard way. Early in my career, I thought my value came from knowing more than everyone else. I was the person with the answers. That worked until the problems got too complex for any one person to hold. Then I had to learn to ask better questions — and it was humbling.
A practical exercise
Next time you're in a technical discussion, try this: don't offer a solution. Ask three questions that help the team find the solution themselves. Notice how the dynamic changes. The team feels ownership. The decision sticks better. And you've multiplied your impact without multiplying your workload.
That's the leverage of questions over answers.
Why this is hard for technical leaders
Technical leaders are selected for their ability to answer hard questions. That's how you get promoted. You know things. You provide direction. Your answers are trusted.
Asking questions instead of providing answers can feel like a step backward. It can feel like you don't know. But the best technical leaders I've worked with understand that their role is not to be the sole source of knowledge. It's to create the conditions where the best knowledge emerges from the team.
That shifts the job from "I have the answer" to "I know what questions will get us to the best answer." It's a harder skill. It requires more confidence, not less. And it's the skill that actually scales across an organization.
The daily practice
I try to start every design review, every architecture discussion, every strategic conversation with questions instead of answers. The questions are rarely perfect. But they set a tone. They tell the team that the goal is shared understanding, not agreement with my position.
That tone matters more than any single technical decision I've ever made.
Think this argument fits your event? Tell me about the room — the calendar is selective.
Start a conversation