11 Rules of Thumb for When and How to Escalate Any Issue at Work
A Comprehensive Escalation Guide for Scrum Masters
Welcome to the 🔥 free edition 🔥 of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. If you’d like to become a paid member, please see the benefits here, and feel free to use this expense template to request approval from your manager.
Escalation is a double-edged sword for Scrum Masters.
Handle it well, and you protect the team and the project. Handle it poorly, like escalating too soon, too late, or to the wrong person, and it could cost you your credibility, or worse, your job.
I recall standing outside a meeting room after a particularly heated sprint review, debating whether to email the department head about a stakeholder who was consistently derailing team confidence.
The question kept echoing in my mind: "Is this the right thing to do? Should I escalate?"
If you're a Scrum Master, you've probably been there too.
So, when do you escalate?
And how do you do it without crossing boundaries?
Escalation is sometimes necessary, but it must always be done with care, clarity, and a sense of the organization's culture.
Over the years, after coaching teams in various sectors, including start-ups, banks, and government IT, I’ve developed 11 rules of thumb for when and how to escalate issues so you not only protect your team but also protect yourself.
In this post, you will learn:
When to escalate (and when to hold back)
How to protect both your team and your role
Who to approach first (and who to avoid)
What alternatives exist before escalation
Let's get started.
If you’re new, here’s what you missed
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
#1 Tie the issue to a Business Risk first
Before you even think about escalating, ask yourself: Can I tie this problem to a real business risk?
Here’s a rule of thumb:
If you can’t complete the sentence, “Because of X, we may miss Y (deadline, revenue, compliance, morale),” then the issue you’re dealing with isn’t an escalation item. It’s just a nuisance.
I’ve seen Scrum Masters escalating every impediment, big or small.
It’s tempting, especially when you care about your team. But without a clear business risk, your escalation will sound like noise, not a signal. Worse, you risk being seen as someone who overreacts.
The test is simple:
Ask yourself, “What’s at stake for the business if this continues?”
If the answer is vague or unconvincing, pause for a moment. Go back and clarify the impact before you raise any flags.
Escalation is about protecting outcomes, not just fixing annoyances.
When you tie every issue you escalate to a real business risk, you speak the language that leadership cares about.
#2 Exhaust team level options before going up
Escalation should never be your first course of action.
Before you even think about reaching outside the team, pause and ask yourself:
"Have I tried facilitation, data transparency, experiments, and education inside the Scrum Team?"
If the answer is no, it’s not time to escalate. Stay local.
In my early days as a Scrum Master, I once flagged a recurring blocker to management before even discussing it with the team. The result? The team felt blindsided and lost trust in me.
I learned the hard way: Most issues can and should be solved at the team level first.
Facilitate a tough conversation
Make the problem visible with data
Run a small experiment
Share knowledge or clarify roles
If you haven’t worked through these options, you’re skipping the most critical step: Empowering your Team.
Escalation is for what the team can’t resolve, not what it hasn’t tried to resolve.
#3 Do a written, time boxed agreement
One of the quickest ways to lose credibility during escalation is to lack evidence. Before you escalate someone’s broken promise or unfulfilled commitment, make sure you can prove that the promise existed in the first place.
A simple, two-line email is enough.
For example:
“The API team will provide the authentication endpoint by next Thursday.”
That’s it.
It sets expectations and provides everyone with a clear reference point.
The best escalations are the ones you never have to make because expectations were clear from the start.
#4 Look for multiple occurrences, not one-offs
Not every problem is worth escalating, especially if it’s a one-time issue.
Escalation becomes far more credible and impactful when you can show a pattern of repeated behaviour or a systemic weakness.
Here’s a simple rule of thumb:
First occurrence → Coach with curiosity
Second occurrence → Coach with clarity
Third occurrence → Now we're talking escalation
Let me share an example. I once dealt with a Product Owner who kept changing sprint priorities mid-sprint:
Sprint 1: Changed priorities once → Had a friendly coffee chat about sprint commitment
Sprint 2: Changed again → Scheduled a focused workshop on agile principles
Sprint 3: Same behaviour → Now we had a pattern worthy of escalation
Why this "rule of three"?
Because patterns reveal either:
Intentional disregard for agreed-upon processes
Systemic problems in the organization
Cultural misalignment that needs leadership attention
These are exactly the things leaders are paid to address.
Show your support
Every post on Winning Strategy takes ~ 3 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 recommend 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.
#5 Collect 2 metrics, not 20
When you’re preparing to escalate, don’t show up with a spreadsheet full of problematic metrics.
Pick two metrics, no more:
One delivery metric (like Sprint Goal met percentage)
One quality metric (like escaped defects)
That’s it.
Leaders don’t have time for a “metric soup.”
They need a clear, focused signal. Trending data on two well-chosen metrics earns attention.
Twenty scattered numbers earn eye-rolls.
Escalation doesn’t require you to prove how much data you can gather. It requires you to present the correct data to drive action.
#6 Escalate with an ally
When it’s time to escalate, don’t go it alone.
Solo escalations risk coming across as personal grievances, regardless of how valid your concerns may be. To avoid this, always bring an ally into the conversation.
This could be:
The Product Owner, who can speak to business priorities
The Tech Lead, who can provide technical context
An Agile Coach, who can offer an unbiased perspective
I’ve seen solo escalations backfire.
It’s too easy for leadership to dismiss it as one person’s opinion (or agenda). But when you walk in with a respected peer by your side, you send a message that says: this isn’t just your problem, it’s the team’s.
Even a quick sync beforehand, “Are we seeing this the same way?” can make all the difference.
Don’t be the lone voice in the hallway. Build a coalition, then speak up.
You’ll be heard.
#7 Offer a solution, not just a complaint
There's an old saying: "Don't bring problems to leadership; bring problems with proposals."
Escalation is about moving things forward.
If you come to leadership with only a problem, you risk sounding like just another complainer. But if you pair the problem with a rough solution, you demonstrate initiative.
Here’s the difference:
Bad: “People keep changing requirements. It’s unproductive for the team.”
Good: “Mid-Sprint priority swaps increased carry-over by 25%. I suggest we limit swaps to Sev-1 incidents only.”
The first is noise. The second is data-driven, specific, and actionable.
In my experience, leaders respond best when you show you’ve thought things through. You’re not just pointing out the fire, you’re handing them a fire extinguisher.
#8 Keep the message ≤ 3 minutes
Executives tune out fast.
Executives are busy, and their attention spans are short. If you can’t deliver your message in under three minutes, you risk losing their focus.
I now live by this formula:
3 slides = 3 minutes = 3 chances to get your message across
Slide 1: Impact Trend
One clear graph
"Team delivery rate dropped 40% since March"
No complex annotations needed
Slide 2: Root Cause
One powerful sentence
"Lack of dedicated UX resource creates rework loops"
That's it. Move on.
Slide 3: Solution & Ask
Proposed experiment
Required support
Expected outcome
Timeline
Example:
Slide 1: Chart showing sprint goal completion dropping from 90% to 45%
Slide 2: "Technical debt from rushed features is causing 60% of our bugs"
Slide 3: "Request: Two-sprint technical cleanup window. Expected outcome: 30% faster delivery by Q4"
That’s it. No rambling, no deep dives, no detours. Just a crisp summary that respects their time and gets straight to the point.
#9 Don’t use Agile jargon
When escalating an issue, avoid using terminology specific to Agile.
Terms like “violating Scrum” or “breaking WIP limits” might resonate with your team, but they won’t land well with leadership. Executives speak the language of cost, time, scope, and risk. And that’s the language you need to use.
Here’s the universal language of business:
Cost (dollars, hours, resources)
Time (delays, deadlines, delivery dates)
Scope (features, functionality, deliverables)
Risk (compliance, market share, customer satisfaction)
Your job isn't to educate leaders on Agile terminology during an escalation. Your job is to communicate business impact and solutions clearly.
#10 Maintain Psychological Safety
Escalation shouldn’t come at the cost of trust.
This means never naming and shaming individual Developers in escalation. If you’re pointing fingers at specific team members, you risk creating a culture of fear and defensiveness.
Focus on the system, not the people.
Don’t say: “Developer X isn’t completing their tasks on time.”
Say: “The team’s work is being delayed due to unclear priorities and frequent context switching.”
The first statement singles out an individual.
The second highlights a systemic issue.
If psychological safety is compromised, collaboration, creativity, and productivity will suffer.
So!
As a rule, always frame escalation around processes, workflows, or systemic challenges.
When in doubt, ask yourself, “Will this message help my team feel supported or attacked?”
Then adjust accordingly.
#11 Escalate up, then let go
Once you’ve escalated, take a step back. Don’t be a helicopter or try to micromanage the result. After leadership addresses the issue, your role shifts from being a driver to a facilitator.
What good letting go looks like:
"I'm available if you need any additional data"
"Let me know how I can help move this forward"
"I trust you'll handle this appropriately"
"Keep me posted on what you need from the team."
What hovering looks like:
"Just checking in on that escalation again"
"Have you made a decision yet?"
"The team is asking me daily about this"
"When will we see action on this?"
Hovering over the process or micromanaging the outcome makes you look political and undermines trust.
Trust the process.
You can also set up regular check-in points instead of constantly following up.
"Would it be helpful to review progress in next month's review?"
Your job is to raise the flag, not to keep waving it.
Once leadership acknowledges the issue, trust them to do their job just as you want them to trust you to do yours.
The Journey Forward
Escalation is a powerful tool, but it must be used thoughtfully.
You can use these 12 rules of thumb as a personal checklist to evaluate every situation before escalating.
Have I exhausted coaching options?
Is this truly an organizational impediment?
Do I have written agreements?
Can I show a pattern?
Are my metrics clear and focused?
Have I enlisted allies?
Is my solution concrete?
Is my message concise?
Have I translated the Agile-speak?
Am I protecting my team?
Am I ready to let go?
Lessons I have learned:
Escalation is a powerful tool, not a first resort
Your credibility is built over the years but can be lost in minutes
Team trust is harder to rebuild
Sometimes the best escalation is the one you don't make
Use them wisely, and they'll serve you well in building credibility and, more importantly, in keeping your job.
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.
Thank you Vibhor for the detailed thoughtful post.
I once faced a peculiar situation which needed escalation in the end. I wish I had these insights to tackle it in more data driven, escalation with an ally and using universal language of business.
Great share!