Stop solving your team's problems for them
ESTIMATED TIME
8
mins

Written by
Shikha Prasad
Published on
The instinct to jump in feels like leadership. It is quietly the thing keeping your team small, and you stuck.
I can tell you the exact moment I realized I was the problem. It was a Tuesday, and I was three Slack threads deep, solving a dependency issue for a developer who, I found out later, already knew the answer. He had just learned that if he brought it to me, I'd handle it. Faster for him. Easier for me. And quietly, one small rescue at a time, it was making my team worse.
I thought I was being helpful. I was being a bottleneck with good intentions.
The hero trap
Here's the trap almost every new Scrum Master and delivery lead walks straight into. Someone hits a blocker. You know the answer, or you can get it in one message. So you do. It feels great. You were useful, the thing moved, the sprint kept going. Do that fifty times and you've trained an entire team to route every problem through you.
Now you're the single point of failure. Take a week off and delivery wobbles. That isn't proof you're indispensable. It's proof you built something fragile and called it a strength.
The uncomfortable version: a team that can't function without you is not evidence of your value. It's the clearest sign you haven't done the actual job yet.
What the research keeps finding
This isn't a soft, be-nicer point. It shows up in the hard data on what actually makes teams work.
When Google studied thousands of its own managers in Project Oxygen, the single most important behavior of the best ones was not technical brilliance. It was being a good coach. Technical expertise, the very thing that makes you itch to jump in and solve, ranked dead last on the list {Google, Project Oxygen}.

And how you show up matters more than most people let themselves believe. Gallup, tracking millions of workers, found that managers account for at least 70 percent of the variance in team engagement {Gallup, 2015}. Not the perks. Not the mission statement on the wall. The person, and how they lead. If that person is a bottleneck who quietly signals “don't think too hard, just bring it to me,” the team learns precisely that lesson.

Why solving feels right and costs so much
Solving is seductive because the math is hidden. Giving the answer is fast today. The cost is paid later, by a future version of your team that still can't do the thing without you. You never see the bill in the moment, so you keep reaching for the card.

Asking instead of answering feels slower, because it is, the first time. The teammate sits with it, maybe struggles for ten minutes, and works it out. Now they can do it next time without you. You traded a little speed today for a capable person tomorrow. Make that trade a hundred times and you have the difference between a team that needs you and a team you actually grew.
But isn't removing impediments the job?
Fair challenge, and it's the one the framework hands you. The Scrum Guide does say the Scrum Master helps remove impediments to the team's progress. So doesn't that mean solving? Here's the distinction that does the work. An impediment is something the team genuinely cannot move on their own: a broken environment, a missing access, an approval stuck two levels up, another team that won't return calls. That's yours to clear, and clearing it is real, valuable work. A developer who simply hasn't thought through their own design problem yet is not blocked by the organization. They're blocked by not having sat with it.
Put it simply: clear the obstacles around the work, not the thinking inside it.
The shift
This is not about withholding help, or going quiet and calling it empowerment. That's just neglect with a nicer label. It's about changing your first move when someone brings you a problem. Instead of the answer, reach for the question.
Swap “here's what you do” for “what have you tried, and what's your read?” You'll be surprised how often they already know, and only wanted permission to trust it.
When they're genuinely stuck, resist the full fix. Offer the next step, not the whole staircase. “Who would know?” beats “I'll go ask them for you.”
Let them keep the problem. The second you lift it onto your own plate, you've taught them it was never theirs to carry. Hand it back, with support, not abandonment.
It helps to keep one real question ready, because in the moment your instinct will lunge for the answer. Mine is boring and it works: “What would you do if I were on vacation?” Most of the time they tell me, correctly, and the only thing they were short on was someone to confirm it. The rare times they truly don't know, now we both know exactly where the real gap sits, which is worth far more than me quietly papering over it.
Some problems you should still take yourself. An executive escalation, a cross-team political mess, a fire that needs your authority right now. The day someone hits their first production incident at 2am is not the day for a coaching question. Judgment is knowing which is which. But for the everyday blocker, the default should be the question, not the rescue.
What it looks like when it works
Six months after that Tuesday, the same developer hit a nastier version of the original problem. He didn't message me. He pulled the two teams into a call, sorted the handoff, and mentioned it in standup like it was nothing. That's the whole job, right there. Not me solving faster. Him not needing me to.
And here's the part that matters for your own career. In an interview, “I unblock my team” sounds fine, until you notice every junior says it. “I build teams that unblock themselves” sounds like someone ready for the next level up. One is a doer listing tasks. The other is a leader describing outcomes, and a hiring manager can hear the gap from across the table.
If you're the person every problem flows through, the goal isn't to care less or help less. It's to change your first instinct from “I'll handle it” to “what's your thinking?” Pick one teammate, one problem, this week. Ask the question. Then sit on your hands long enough for them to grow into the answer.
Sources
Garvin, David A. “How Google Sold Its Engineers on Management.” Harvard Business Review, 2013 (Project Oxygen). hbr.org
Gallup. “Managers Account for 70% of Variance in Employee Engagement.” 2015. news.gallup.com

Subscribe to the Newsletter
Join our growing community and get alerted first on our every article.
*By subscribing, you agree to send your information to our Company who agrees to use it according to their Terms and conditions and Privacy Policy
About the author
I believe the strongest tool and flex each of us has is our belief. When we truly believe in something, we align our mindset, energy, and actions with the right effort and guidance. That is when achieving almost anything becomes possible. This is how I help mentees at OAKKTREEUNII move into Software and Project Management careers for better pay, better confidence, and better work-life balance.
Comments

