The Coaching Conversation: Asking Better Questions Instead of Giving Better Answers

If you’ve ever been in tech leadership for longer than five minutes, you’ve probably fallen into what I like to call “the Fix-It Trap.” Someone from your team comes to you with a problem, and before they even finish the sentence, you’re already halfway through giving them a detailed solution, complete with diagrams, bullet points, and maybe a flowchart that no one asked for.
I’ve been there. More than once. My brain goes: “Yes! A problem! This is my time to shine. Quick, assemble all the knowledge from years of firefighting servers, wrangling Jenkins pipelines, and convincing Docker Swarm to behave. Here’s the answer!”
And sure, sometimes that’s helpful. But if you’ve read (or in my case, listened to on audiobook while doing the dishes) Michael Bungay Stanier’s The Coaching Habit, you’ll know that giving answers isn’t the magic trick of leadership. Asking better questions is.
Why Answers Aren’t Enough
Here’s the problem with always supplying answers: you become the human equivalent of Stack Overflow. Useful, yes. Sustainable, no. Because while your answers might fix today’s problem, they don’t grow your team’s ability to solve tomorrow’s problem.
Think about it — if your eleven-year-old son Micah asks you how to solve a math problem, and you just give him the answer, great, the homework is done. But next week? Same question. Same homework meltdown. (And probably the same “but my teacher hates me” speech).
It’s the same with engineers. If you always swoop in with the fix, you train your team to wait for you instead of thinking it through themselves. That doesn’t scale. And worse, it builds dependency — not capability.
Questions Change the Game
In The Coaching Habit, Stanier lays out a series of questions designed to shift conversations from advice-giving to curiosity-driving. And man, once you start using them, you realize how many times you’ve been the “answer vending machine” instead of the “thinking partner.”
Take the Kickstart Question: “What’s on your mind?”
It sounds so simple. But instead of leaping into problem-solving mode, it opens the floor for your team to bring forward what’s really bugging them. Sometimes the issue isn’t even technical — it’s that they’re stuck in meetings all day and can’t get real work done.
Or the Focus Question: “What’s the real challenge here for you?”
Notice the sneaky bit: for you. Because nine times out of ten, the problem isn’t the Jenkins job failing. It’s the frustration of feeling like no one else understands the pipeline, or the fear of being blamed when deployments go wrong. That’s where coaching makes a difference.
Why It Works Better Than Answers
1. It builds ownership.
When your team talks themselves into clarity, they own the solution. And when people own their solutions, they’re way more motivated to follow through.
2. It saves you from becoming a bottleneck.
Instead of everyone queuing up outside your office (or Slack DMs) waiting for your genius fix, they start solving things on their own. Suddenly, you’re not the middle manager turned “help desk hotline.”
3. It grows capability, not dependency.
Every coaching conversation is like a gym session for your team’s problem-solving muscles. Over time, they get stronger — and you don’t have to lift every mental weight for them.
A Real-World Example
One of my engineers (let’s call him D) once came to me fuming over a failed docker image build. Old me would have jumped straight into: “Okay, show me the logs, let’s debug this step by step.”
Instead, I asked: “What’s the real challenge here for you?”
After a pause, he admitted it wasn’t about the broken build at all. He felt like he was the only one who truly understood that part of the system, and it was exhausting. He was burning out, not just debugging pipelines.
That conversation didn’t just fix a Jenkins job — it started a plan to spread knowledge across the team so D wasn’t the “single point of everything.” And you know what? The builds got more stable too.
The Temptation to “Just Answer It”
Now, don’t get me wrong — asking better questions doesn’t mean you never give answers. Sometimes someone just needs to know which command installs htop. (Answer: sudo apt install htop, you’re welcome).
But in leadership, the real leverage isn’t in uploading information into your team’s heads. It’s in drawing out their thinking.
The hard part? Sitting in the discomfort of not being the hero. You have to resist the urge to solve everything. To look smart. To be the one who saves the day. Instead, you become the one who grows the people who save the day.
Practical Takeaways for Tech Leaders
If you want to shift from “answer machine” to “coaching leader,” here are three easy ways to start:
Slow down before answering.
Next time someone comes to you, count to three before you say anything. Then ask: “What’s on your mind?”
Get curious about the real challenge.
Don’t settle for the surface problem. Ask: “What’s the real challenge here for you?”
End with action.
Wrap up by asking: “What’s the next step?” That way, the conversation turns into ownership, not just venting.
Closing Thought
At the end of the day, DevOps isn’t just tools. (Sorry, had to sneak that in). It’s about people, culture, and how we work together. And leadership isn’t just about removing blockers. It’s about asking the kinds of questions that help your team grow stronger, more capable, and more confident.
Because answers might solve problems, but questions build people.
And in the long run, I’d rather have a team of people who can think for themselves than a Slack channel full of folks waiting for me to debug their shell scripts.