How would I help my team resolve impediments without depending on me?
Making self dependant teams
Most Scrum Masters believe their job is to remove impediments. It says so right there in the Scrum Guide. It’s the first thing they teach you.
And…
It’s the single biggest reason your team can’t remove impediments… Without YOU!
When teams default to handing you every impediment, two things happen:
you burn out, and
the team learns helplessness
Agility at scale requires autonomous teams that can navigate their own roadblocks. If your team stops moving the moment you are not around, you are basically facilitating dependency.
To help your team resolve impediments without relying on you, you have to intentionally change your stance from fixing to enabling.
In this post, I want to show you
why teams become dependent on their Scrum Masters,
what’s happening in their brains when this happens, and
a four-part behavioural model for rewiring the habit
Let’s get started.
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
The Psychology of Learned Helplessness
In 1967, psychologist Martin Seligman conducted a famous experiment at the University of Pennsylvania. Dogs were placed in a box with two chambers separated by a low barrier.
When a mild electric shock was applied to the floor, dogs who had never been shocked before quickly learned to jump over the barrier to the safe side.
But the dogs who had previously been placed in an inescapable shock condition, where nothing they did could stop the discomfort…
They behaved differently!
When placed in the new box, these dogs didn't even try to escape. They lay down and whimpered. The barrier was low. The safe side was right there. But they had already learned that their actions didn't matter.
Seligman called this learned helplessness, and it remains one of the most replicated findings in Human Behavioural Psychology.
Now, I'm not comparing your development team to dogs in a lab.
But the underlying mechanism is the same, and if you're honest with yourself, you've probably seen it. A team gets an impediment. They mention it in the Daily Scrum. The Scrum Master (or Delivery Lead) picks it up and somehow resolves it. This happens again. And again. And again.
Over time, the team learns that the Scrum Master will handle it. So they do nothing to resolve the impediment themselves.
What should we do then? What’s the next step? Should we ask the team to “take more ownership?”
Probably not!
Why asking your team to "Take More Ownership" doesn't work?
Before I walk you through the 4-step model, I want to address something I see most Scrum Masters do, which makes the problem worse.
They notice this dependency of their team. They bring it up in the retro and say something along the lines of: "I'd love to see the team take more ownership of impediments." Next?
Everyone agrees, but nothing changes.
This happens because the request violates one of the core principles of behavioural design:
“You cannot reliably change behaviour by changing intentions.”
In fact, according to BJ Fogg (a researcher at Stanford), behaviour change requires three conditions to meet simultaneously:
motivation,
ability, and
a prompt
Most Scrum Masters address MOTIVATION ("please take ownership") while ignoring ANILITY ("do you know how to resolve cross-team impediments?") and PROMPTS ("what in your environment triggers the resolution behaviour?")
Telling a team to take ownership without changing the structural conditions is like telling someone to eat healthier without changing what's in their refrigerator.
The intention is good and honest, but as we all know, the environment wins every time.
The 4-step Self-Resolving Team Model
I've organized the approach into 4 behavioural changes.
Each one targets a specific mechanism that supports the dependency cycle.
These four steps work independently, but they are most effective when combined because, together, they reshape the “choice architecture” around obstacles, making “depending on the Scrum Master”, the more difficult path rather than the easier one.
Let’s look into each change one by one.
#1: Ask Before You Act
The simplest change is asking the following three questions.
When someone brings you an impediment, don’t touch it. Instead, ask:
What have you already tried?
Who have you spoken to directly?
What do you think the next step should be?
That’s it.
The best advice doesn’t give people answers. It helps them realize they already have answers. These three questions do the same thing. They redirect your team’s or the person’s attention from “who can solve this for me” to “what can I do about this myself.”
What you’ll find, almost every time, is that the person hasn’t tried anything yet.
When you ask these questions every time, the team starts asking them of themselves. The questions become internalized, and the habit changes.
Coaching, done well, looks like asking the same questions until people no longer need to hear them.
#2: Make Impediments Visible
If an impediment isn’t visible, it isn’t shared.
Most of the time, impediments are mentioned briefly in the Daily Scrum, then silently dumped into a mental to-do list of you know who. There is a vague expectation that the Scrum Master will sort it out.
This is how Scrum Masters quietly become the single point of failure.
What we need to do is make them visible by converting them into a backlog item with an owner and a status.
When an impediment has been sitting on the board for four days, with someone's name on it and no movement, people naturally feel compelled to act on it.
Because it’s right there, visible to the whole team.
"There's something about seeing your name next to a stale impediment in front of the whole team. Nobody has to say anything. The visibility itself creates the motivation."
Start by making an impediment section on your board.
When the impediment is raised, create a Jira issue for it with an owner and a date.
That's it.
The visibility does the rest.
#3: Change the default owner
The person who raises the impediment (or whose work is most directly blocked) automatically becomes the Impediment Owner. Not the Scrum Master.
In most Scrum teams, the implicit default owner of every impediment is the Scrum Master. And because it's the default, it persists even when everyone agrees the team should own more.
You have to explicitly change this default.
New rule:
The person who raises the impediment owns driving it to resolution. They make the calls, send the messages, schedule the syncs. The Scrum Master is available as a coach for advice on who to talk to, how to navigate the org, and when to escalate, but not as the first responder.
When does the Scrum Master step in?
Only when the impediment exceeds the team’s organizational reach. VP-level escalations, cross-departmental budget issues, and political dynamics the team can’t see. Everything else? The team handles it.
Announce the new default in your next sprint planning or retro.
For example, say:
"Going forward, the person who surfaces a blocker is the default owner of resolving it. I'm here to coach and advise, but you're in the driver's seat."
#4: Build a Resolution Map
A simple, shared document that maps common impediment types to the specific person, team, channel, or process for resolving them.
Here's something that surprised me when I learned it the first time:
Often, team members route impediments and blockers through the Scrum Master because they genuinely don't know who to talk to.
The Scrum Master has accumulated months (or years) of organizational knowledge, for example,
which person handles environmental issues,
whether to email or talk in person for design requests,
who owns the vendor relationship,
All of that knowledge lives in their head.
The only low-friction path to resolution runs directly through the Scrum Master, and the only way to change that is to give the team an equally low-friction alternative.
The Resolution Map does exactly this.
It looks something like:
"I realized I was the human version of this document. Every time someone asked me, 'Who do I talk to about X?' I was just a lookup table. So I wrote the lookup table down and pinned it in our Slack channel.”
How these four changes work together
Each change targets a different root cause of dependency:
Individually, each one helps, but together, they rewire the team's relationship with impediments.
And the Scrum Master goes from being the team's problem-solver to being the architect of a system where problems get solved without them.
A final thought
The best Scrum Masters I’ve seen and worked with share this belief: their goal is to make themselves unnecessary.
I am sure you have heard this before.
It says unnecessary… NOT unimportant.
There’s a huge difference. A Scrum Master who has built a self-resolving team isn’t out of a job. They’ve freed themselves up to work on the harder, higher-leverage stuff like team dynamics, organizational impediments, coaching individuals, and improving the system.
A measure of great Scrum Mastery is how many impediments get resolved without you ever hearing about them.
Show your support
Every post on Winning Strategy takes a few days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.