Originally posted on LinkedIn on March 10, 2026. Read and engage with the original post here.
Of all the words I ever uttered at work, I don’t think any struck more fear in the hearts of my colleagues and partner teams than “escalate.” The word brought to mind thoughts of failure, getting blamed for problems on projects and “getting in trouble” with the bosses. Often partner teams assumed that the PM was going to use the escalation as a club to extract unrealistic or impossible results when everybody was doing the best they could.
And to be honest, early in my career, I also was afraid of the word “escalation.” As a PM and leader of the project, wasn’t I supposed to have everything under control? Escalation was like ripping away the curtains and letting the intrusive, penetrating light of day expose all that was wrong with the project. It was inviting eyeballs to examine (and potentially criticize) every aspect of the project, from the way requirements were articulated, to the schedule and even the team structure.
Escalation felt like waving a huge flag for the entire company to see that said, “Hey Everyone! I don’t know what I’m doing and have lost control of the project!”
It also felt bad because “nice” people didn’t escalate. They would jump in and fix the problems directly and save the team from embarrassment, or the prying eyes of management. Escalation was only used by “mean” PM’s who wanted to get people in trouble.
So I did what post people do when they are uncomfortable. I avoided. Early in my career, when I should have been leaning on leadership support heavily. This led to churn on projects and a couple of failures. This led me to ask myself, “Why didn’t I say something sooner?”
Escalation is one of the hardest skills for a PM. Nobody really teaches it, even though it is essential to master. It is tricky because if done poorly, relationships and team morale can be damaged severely. If not done at all, projects will likely fail or have major issues.
Here is what I learned about the art of escalation:
What Escalation Actually Is (And Isn’t)
Escalation IS:
- Raising visibility on a risk, blocker or decision to the appropriate leaders
- Asking for help that you (or the team) can’t provide independently
- Protecting the project and team
- Professional communication
Escalation is NOT:
- Throwing someone under the bus
- Admitting failure
- Passing the buck
- Being “unable to handle it”
Understanding the real definition of escalation helped. The intent wasn’t to hurt or harm, it was to help. And that help came in the form of transparency, honesty and truth telling. When you regularly practice these things, you feel lighter since honesty is always the best way to go.
Ironically, everybody on the team knows deep down that there is a big problem brewing. And yet not facing it directly can feel better in the moment. Its like when your credit card bill comes in the mail. There is the pain of seeing the number on paper that causes us to toss the unopened envelope in a random pile. If we don’t SEE it, its not real, right? Unfortunately, without facing the issue directly, we can’t take action to improve things.
Escalation is like ripping open that bill, looking directly at the balance and then putting in up on the fridge for everyone to see.
The reframe: Escalation isn’t a failure of your ability. Its an exercise of your judgement.
When to Escalate
When I encountered a difficult situation on a project I ask myself three key questions to inform if it’s time to escalate:
- Can I solve this myself with the authority I have?
- Will waiting make this worse?
- Does leadership need to know or decide?
If I have the ability to solve it directly, I will. This might involve an area where I can make a call on budget, resource allocation or readjustment of a date that will not cause overall issues on the project. These are squarely in my circle of control.
If waiting will not make the situation worse, I’ll generally monitor closely, and be prepared to escalate. Usually, I will timebound the waiting to a specific date in the near future.
If leadership needs to know or weigh in on the decision, escalation is a no brainer.
Examples of WHEN to escalate:
- Resource conflicts you can’t resolve (need director+ to prioritize)
- External dependencies blocking progress (need cross-org coordination)
- Scope/timeline misalignment (need leadership decision)
- Budget overruns (need approval for more resources)
- Team member performance issues (need HR involvement)
- Technical debt creating risk (need business decision on trade-offs)
Examples of when NOT to escalate:
- Temporary setbacks you can recover from
- Interpersonal conflicts you can mediate
- Process inefficiencies you can fix
- Minor timeline slips with buffer
- Issues within your authority to resolve
The reality is, leadership is STARVED for information about what is really going on. The want to hear about the actual problems on projects so they can use their power and influence to help. Radio silence, or constant green signal doesn’t erase the fact that they know the level of complexity on projects and that there are constant problems. Making these issues clear and including leadership in the solution will build trust and increase the level of support the project gets.
Escalation – Better Together!
Once you have determined that an escalation is necessary, my strong suggestion is to include affected members of your team directly in crafting the message. Nobody likes surprises or to feel like they have been “told on.” The way to build trust is to transparently communicate the need and plan to escalate directly with all those affected and solicit their feedback.
Alignment around the need and messaging of escalation is the hardest part!
And again, this is why many PM’s will escalate in a vacuum. Alignment is difficult, especially around problems on projects and exposing these to leadership. But if this step is not at least attempted, trust will be lost quickly. 30 minutes spent getting alignment can save weeks of damaged trust.
Usually, a team will agree that an escalation is needed and will actively participate in putting the message together. But what if you can’t get agreement from a key team member, despite sharing the need and working to convince them?
Despite it being hard, you have to proceed with the escalation. By all means, make sure to continue to keep them informed of what you are doing, including sharing the exact messaging. They will not be surprised by the escalation and may change their mind and decide to support it.
If the escalation is time sensitive, you may need to grab the team urgently and collaborate synchronously and send together. If you have some time (a day or two), collaborate in a document on the exact message and meet if there are specific points to resolve.
When you send the escalation up the chain, copy the folks who collaborated directly in the message as the default. This will give them viz into what is going on, and allow questions that they can answer go directly to them without you being a bottleneck.
Do go out of your way to include folks. Nothing will affect team morale like having a culture where people feel they have no control of the messaging about their project.
Types of Escalation
Leads are busy and are often bombarded with messages. If they get quick signal that a message is an escalation, with a specific action for them, it will help expedite the process. Articulate the type of escalation directly in the message subject.I have found success with the following escalation types:
Inform
Inform escalation provides a synopsis of the situation without asking for specific support. This type of escalation helps let leads know of a specific risk, and the steps you are taking to mitigate it. It allows the project team to get out ahead of a risk and allow leadership to weigh in if they would like any other information.
Example Subject:[INFORM] – Team Capacity at 110%, Monitoring Closely
Decision Needed
Decision Needed escalation requests leadership make a call, often regarding major priorities, scheduling or performance tradeoffs. It is vital to provide the full list of options available, the impacts of each decision and what the team recommends. Include the date by which a decision is required.
Example Subject:[DECISION NEEDED] – Team Priority – Customer Bug vs New Feature
Resources Needed
Resources Needed escalation requests leadership grant or approve a resource that is not directly in your control. This may include headcount, budget, lab access priority, or support from departments outside your purview. It should be clear in the messaging specifically what you need, the impact of receiving (or not receiving) the resource, as well as the date it is needed.
Example Subject: [RESOURCES NEEDED] – API Migration – $25K Infrastructure Budget
Escalation Structure
Crafting an effective escalation message is an art. You should aim for a clear, concise message that explains the situations, the risks and what you need of leadership. If there are options, list them clearly, along with your recommendation. If possible, aim for the entire escalation to be on a single page, a 3-5 minute read. If there are additional details or documents, consider adding them at the very bottom as an appendix or links. If the leaders want that level of detail, they can access it. Below is a sample escalation e-mail:
Subject: [DECISION NEEDED] Project Delta – Scope Vs Timeline Trade-Off
Hi VP Engineering,
We need your help with a decision on Project Delta.
SITUATION: We’re 2 weeks from launch and facing a scope vs. timeline trade-off. New customer feedback suggests Feature X is critical, but adding it delays launch by 3 weeks.
OPTIONS:
1. Launch April 15, add Feature X in May patch
- Pros: Hit date, still deliver feature
- Cons: Customer experiences incomplete product initially
2. Launch on time (April 15) without Feature X
- Pros: Hit committed date, get feedback sooner
- Cons: Customer disappointment, may miss adoption targets
3. Delay launch (May 6), include Feature X
- Pros: More complete product, better customer reception
- Cons: Miss Q1 goal, team morale hit from delay
TEAM RECOMMENDATION:
- Option 1 – Launch on time with clear communication that Feature X comes in 2 weeks. Maintains momentum while addressing customer need.
DECISION NEEDED BY:
- EOD Friday (need to communicate to team and customers)
Happy to discuss further or answer questions. Please see this document with additional details on the option space.
How to Practice
Like anything, getting proficient with escalation will take time and practice. There will likely be alot of uncomfortable feelings at first, but over time, these will get easier. And as you observe projects going better and the energy that comes from full transparency, the practice will become an engrained habit, a tool to be used when necessary. You will also earn the respect of your team as they know that you will keep them in the loop on messaging to leadership and will quickly work to get full support to unblock them. Leads will rely on you to keep them informed and trust your judgement.
Start Small:
- Next time you see a risk → raise it early
- Frame it as: “I want to flag something before it becomes a problem”
- Propose a solution
- Observe the response (usually positive)
Build Muscle:
- Weekly risk reviews with your manager
- “Here’s what I’m monitoring…”
- “Here’s what I need help with…”
- “Here’s what I’m handling…”
Get Feedback:
- Ask your manager: “Do I escalate too much? Too little? Just right?”
- Calibrate based on their preference
- Different leaders have different styles
Early in my career, I had a lot of misconceptions about escalation, and I got burned by not utilizing it frequently enough. But over time, through coaching, observation and getting out of my comfort zone, I’ve found it to be an advanced tool that helps move projects and people forward. Now it’s almost second nature.
If you are a leader on a project, know that it is not your job to fix every problem yourself. That is a recipe for failure actually. Your job is to make sure the right problems get to the right people at the right time. Sometimes that is getting that gnarly bug to the software engineers. And sometimes that means getting a major decision to the leads who can unblock the team.
What is something you have been holding onto that you should escalate?