Learning to Ask Better "Why" Questions

I'm bad at asking "why."

Someone on my team hits a problem. I ask why once. Get a surface answer. And that's it.

I either accept it or just tell them what I think they should do.

Neither helps them think deeper. Neither builds ownership. Neither helps them figure it out themselves.

I've heard that asking "why" repeatedly is powerful. Gets to root causes. Challenges assumptions. Helps people grow.

I do it sometimes. But not consistently. And I think there's room to get better at it.

So I did some research. Here's what I found and what I'm going to try.

What I'm Actually Trying to Learn

It's not just "ask why more." That's too simple.

I want to ask questions that:

• Help my team discover solutions themselves
• Get them thinking deeper than the first answer that pops up
• Make them own the solution, not just execute mine
• Challenge assumptions (mine too)

Right now I take the first decent answer and move on. I should be pushing more. Asking better. Guiding instead of telling.

The Frameworks

Five Whys (The Toyota Thing)

Classic. Ask "why" five times to get past the symptom to the actual root cause.

When to use it: Post-mortems, when the same problem keeps happening, retros, technical debugging.

What's good: Gets to root causes fast. Simple. Exposes systemic issues. Works great for technical stuff.

What sucks: Can feel like interrogation. Assumes one root cause. People get defensive. Only works if they feel safe being honest.

Example:

Project is delayed.

1. Why is the project delayed? "We didn't finish the API integration on time"

2. Why didn't you finish it? "The documentation was unclear, we had to figure it out ourselves"

3. Why was the documentation unclear? "The vendor's docs are outdated"

4. Why didn't we catch this earlier? "We didn't do a technical spike before committing to the timeline"

5. Why didn't we do a spike? "We assumed the integration would be straightforward based on the sales demo"

Root cause: We're committing to timelines without technical validation.

By the fifth "why," you're not talking about documentation anymore. You're talking about how we plan projects.

The problem: Asking "why" five times in a row feels aggressive. Like you're hunting for who screwed up.

Five Whats (Less Aggressive)

Same idea, but ask "what" instead. Feels more collaborative.

When to use it: Same as Five Whys, but when you need it less confrontational. With junior people. When emotions are high. When you want to focus on fixing, not blaming.

What's good: Feels like solving together. People are more open. Still gets to root causes. Better for psychological safety.

What sucks: Can still hit resistance. "What" questions are broader, might take longer. Sometimes you need the directness of "why."

Same scenario, different vibe:

1. What's blocking us from shipping? "The API integration isn't working yet"

2. What's making it difficult? "The documentation doesn't match the actual API behavior"

3. What did we try to fix that? "We reached out to support but they're slow. We're reverse-engineering from error messages"

4. What could have helped us avoid this? "Testing the integration earlier, or doing a spike before committing"

5. What would need to change in our process next time? "Build in technical validation before we commit to timelines"

Same root cause. But the conversation feels more like problem-solving together.

I'm going to try this. The shift seems small but might make people way less defensive.

GROW Model (Structured Coaching)

Different approach. Less drilling down, more walking someone through thinking systematically.

GROW = Goal, Reality, Options, Will/Way Forward.

When to use it: 1:1s when someone's stuck. Career conversations. Complex problems with no obvious answer. Performance stuff where you want them to own the improvement.

What's good: Gives structure. Helps stuck people see their own path. Makes them do the thinking. Great for open-ended problems.

What sucks: Can feel formulaic if you follow it too strictly. Doesn't work for urgent stuff. Some people just want advice. Takes more time than just telling them.

Example:

Someone's struggling with unclear requirements.

Goal:

• "What would success look like for you on this project?"
• "What specifically do you want to achieve next sprint?"

Reality:

• "What's making the requirements feel unclear?"
• "What have you tried so far?"
• "What's blocking you from moving forward?"

Options:

• "What are some ways you could get clarity?"
• "If you had to brainstorm three approaches, what would they be?"
• "What would happen if you built a quick prototype to test assumptions?"

Will/Way Forward:

• "Which option feels most actionable?"
• "What's your first step?"
• "What support do you need from me?"

You're not giving the answer. You're walking them through discovering it.

What Good Questions Look Like

This is what I needed. Concrete examples.

Shallow vs. Deep

Shallow (kills it):

• "Is everything okay?" → Yes/no, done
• "Why didn't this work?" → Blame-y, defensive
• "What's the status?" → Generic, no insight
• "Can you fix this?" → Just tells them to solve it

Deep (opens it up):

• "What's the biggest challenge you're facing right now?"
• "What would need to be true for this to work?"
• "If you were starting fresh, what would you do differently?"
• "What assumptions are we making that we should test?"
• "What's preventing you from moving forward?"
• "How does this connect to the bigger picture?"

Don't Say This, Say That

What I actually want to practice. Catching myself.

Converting "Why" to "What"

Instead of	Try
"Why is this taking so long?"	"What's making this more complex than expected?"
"Why didn't you ask for help?"	"What stopped you from reaching out?"
"Why did you choose that approach?"	"What led you to that solution?"
"Why isn't this working?"	"What have we learned from what's not working?"
"Why are we behind?"	"What's changed since we set this timeline?"

When You Already Know the Answer

My biggest trap. I know what they should do. So I just tell them.

Don't say: "You should break this function into smaller pieces"

Ask instead:

• "What would make this function easier to test?"
• "If someone new joined, what part might confuse them?"
• "What would happen if we needed to reuse just one piece of this?"

They'll get there. And it'll stick better.

When They're Stuck

Don't say: "Did you check the logs?"

Ask instead:

• "What information would help you debug this?"
• "If you could know one thing right now, what would it be?"
• "Where have you looked so far?"

When They Made a Decision You Disagree With

Don't say: "That won't work because..."

Ask instead:

• "What happens when [the edge case you're worried about]?"
• "How would this scale if we had 10x the traffic?"
• "What tradeoffs did you consider?"

What I'm Going to Try

Here's my plan. And if you're reading this thinking "where do I even start?" - start with the "Why to What" conversions. That's the easiest shift.

In 1:1s: Use GROW when someone's really stuck and we have time. Not for quick questions, but for the meaty career or performance conversations.

In team discussions: Try Five Whats when we're debugging why something went wrong. Post-mortems, retros, that kind of thing.

Day-to-day Slack/meetings: Just practice the "Don't say this, say that" conversions. Catch myself before I tell them the answer.

Track what works: Pay attention to which questions open up thinking vs. which get shallow answers.

When NOT to Use This

Real talk - sometimes you should just give the answer:

• When it's urgent. Production is down? Don't Socratic method your way through the incident. Tell them what to do.
• When they're junior and overwhelmed. If someone's already drowning, asking five layers of questions isn't helpful. Sometimes they just need direction.
• When you've already asked and they're stuck. If you've tried guiding and they're genuinely blocked, just help them. Don't make it painful.
• When it's a quick decision. Not everything needs to be a learning moment. "Should this button be blue or green?" doesn't need GROW model.

The point is to use these when there's actual value in them discovering it themselves. Not to turn every interaction into a teaching moment.

I'm not expecting to nail this immediately. I'll mess it up sometimes. Ask a question that lands wrong. Push too hard when I should've just given the answer. That's fine.

What I'm Still Figuring Out

• How do you know when to stop asking and just give them the answer?
• What do you do when someone gives a shallow answer and clearly doesn't want to go deeper?
• How do you balance this with just being efficient?

I don't know yet. I'll find out by trying.

Resources I Used

• The Five Whys technique
• Socratic questioning in leadership
• The GROW model
• Powerful coaching questions

Nothing here is gospel. Just tools to try.

What Do You Actually Use?

I want to hear from you. Specifically:

Do you find "why" or "what" works better with your team? Does one feel more natural to you?

Have you tried any of these frameworks? What worked? What flopped?

What's your go-to question when you want someone to think deeper but you're worried about just giving them the answer?

I'm genuinely curious. I think we all figure this out by sharing what actually works in practice.

I'll come back once I've tried these for a while. Report back on what worked, what flopped, what surprised me.

For now, I'm just going to start asking better questions.

Let's connect on LinkedIn - tell me what questioning techniques work for you. The team that crushed it during my Japan trip? That wasn't luck. It was the invisible work paying off. They didn't need me in those three weeks because I had already done my job.

That's the EM challenge: The best job you do is the one nobody ever has to see.

If you're an EM struggling with the lack of tangible proof or the imposter syndrome that comes with it, you're not alone. That's actually the job.

---

Let's connect on LinkedIn—I'm always down to talk about this stuff with peers who understand the struggle.