---

title: "Knowing when to escalate"

module: 9

module_title: "Boundaries & Self-Management"

order: 6

access: "paid"

summary: "Escalation is a judgment call about matching the right resource to the right problem, not an admission of failure. Learn the signals that a situation has outgrown your tools, how to frame an escalation request that proposes a solution rather than dumping a problem, and when not to escalate."

related:

• "protecting-team-bandwidth-while-maintaining-client-satisfaction"
• "admitting-limitations-while-maintaining-authority"
• "de-escalating-tense-situations"

---

Knowing when to escalate

I once sat on a client problem for two weeks because I thought I could fix it myself. The client was increasingly frustrated with a deliverable that wasn't meeting their expectations. I kept revising, kept having conversations, kept thinking the next iteration would be the one that landed. By the time I brought it to my manager, the client was ready to walk. What had been a fixable misalignment had become a trust crisis.

My manager handled it in one 30-minute call. Fresh perspective, different authority level, different kind of conversation. The client calmed down. The project got back on track. And I spent the next month wondering why I hadn't escalated sooner.

The answer, of course, was ego. I wanted to prove I could handle it. Most people who escalate too late are motivated by the same thing.

Why escalation is a skill

Somewhere along the way, a lot of us internalized the idea that escalating means admitting you can't handle something. That asking for help is a weakness. That good professionals solve their own problems.

This is wrong, and it's dangerous. Escalation is a judgment call about matching the right resource to the right problem. A junior developer asking a senior for help isn't failing; they're being efficient. A project lead bringing in an account director for a difficult client conversation isn't incapable; they're using the tools available to them.

The real failure is sitting on a problem too long. I've seen more projects damaged by late escalation than early escalation. When someone escalates too early, the worst that happens is they're told "you can handle this, here's how." When someone escalates too late, the worst that happens is you lose the client.

How I think about this

Escalation is about fit, not incompetence. Some conversations need a different relationship or a different authority level. When a client is angry and you're the person they're angry at, bringing in someone they're not angry at isn't weakness. It's practical.

Watch for the spiral. If you've tried to resolve something twice and it's not improving, that's a signal. The definition of a situation that needs escalation is simple: you've used your tools and they're not working. Trying the same approach a third time rarely produces different results.

Your discomfort is data. If a situation is keeping you up at night, if you're drafting and redrafting the same email, if you're dreading a meeting more than usual, those feelings are information. They're telling you this has outgrown your normal capacity to manage it.

Time pressure changes the calculus. A slow-burning issue you might have time to work through yourself becomes urgent when there's a deadline in two days or the client has a board meeting next week. Factor in the available runway when deciding whether to escalate.

Escalate to a person, not just upward. Don't send a vague "help" message up the chain. Identify the specific person whose involvement would help and explain why. "I think Rachel should join the next call because the client is pushing back on the contract terms and that's her area" is actionable. "I need to escalate this" is not.

What this looks like

Escalating a frustrated client

You've had two conversations trying to resolve a client's dissatisfaction, and it's not improving:

To your team lead: "I want to loop you in on the Henderson project. The client is unhappy with the dashboard design direction, and I've had two revision rounds trying to align with their feedback. I think the disconnect is at a higher level than the design itself. They might be uncertain about the overall strategy, and that's coming out as design feedback.

I think it would help if you joined the next call. Not to take over, but having a fresh voice and a broader perspective might break the pattern we're stuck in. I can prep you on the history before the call."

Escalating a scope conflict

The client keeps requesting work outside the contract, and your attempts to redirect haven't stuck:

To your account manager: "I need some help with the Whitfield project. The client has asked for three significant additions in the past two weeks that are outside our scope. I've flagged each one and offered to scope them as change orders, but they keep pushing back, saying it should be included.

I don't think this is bad faith. I think there was a misunderstanding about what the project included, and I'm not the right person to realign on that because I'm in the weeds with them daily. Could you have a direct conversation about the contract scope? I think it'll carry different weight coming from you."

Escalating a technical risk

Something is going wrong technically and you need a more senior perspective:

To a senior engineer on your team: "Can I get your eyes on something? The payment integration on the Orion project is behaving unpredictably in staging. Transactions work about 80% of the time, and I can't identify the pattern behind the failures. I've spent two days debugging and I'm not confident I'm looking in the right place.

I know we're a week from launch. I don't want to burn another two days going in circles when you might see the issue in an hour. Can we pair on this for a bit?"

When not to escalate

Escalation has a cost. It takes someone else's time and can change the dynamic with the client. Do it too often and it signals you can't handle your role.

Don't escalate because a conversation is uncomfortable. Difficult conversations are part of the job. If you escalate every time a client pushes back or asks a hard question, you're avoiding growth, not solving a problem.

Don't escalate without trying first. Having at least one real attempt under your belt before escalating is usually the minimum. The exception is when the situation clearly requires a different authority level from the start, like contract disputes or executive-level relationships.

Don't escalate to avoid responsibility. If you made a mistake, own it first. Then escalate if you need help with the recovery. Passing a problem up the chain to avoid being associated with it is transparent and damages your credibility more than the mistake did.

Don't escalate in front of the client without warning. Unless the client already knows someone else is getting involved, have the internal conversation first. "Let me bring in my director" mid-meeting can feel unplanned and raise concern. Better to say "I'd like to bring my director into our next conversation to get her perspective on this."

Getting better at this

Define your escalation threshold ahead of time. Before starting a project, think about what would make you escalate. Two failed attempts to resolve a conflict? A budget overrun above a certain amount? A technical problem you can't solve in 48 hours? Having thresholds ahead of time removes the ego from the decision in the moment.

Build the relationship before you need it. If you only talk to senior people when things are on fire, escalation feels dramatic. If you have regular check-ins where you mention both wins and challenges, bringing up a problem that needs their help is just part of the conversation.

Debrief after escalations. When someone else helps resolve a problem, pay attention to what they did differently. What did they say that you didn't? How did they frame the conversation? This is some of the most useful learning available to you.

Practice framing escalation requests. The format is consistent: what's happening, what I've tried, why I think you're the right person to help, and what kind of help I'm asking for. Get comfortable with this structure so it doesn't feel improvised when you actually need it.

How this connects

Knowing when to escalate sits between the "managing difficult conversations" topics and the "crisis communication" topics in this collection. It's the judgment call about when a difficult conversation has become something that needs a different kind of intervention. It also connects to protecting team bandwidth, because escalating well prevents drawn-out conflicts that drain energy from everyone involved. And it relates to admitting limitations while maintaining authority, because the best escalations show self-awareness, not weakness.

Things to try

• Think about a past situation where you escalated too late. What were the early warning signs you ignored?
• For your current project, define what would make you escalate. Write it down. Be specific.
• Next time you're stuck on something for more than a day, tell someone. Not necessarily a formal escalation. Just mention it.
• After your next escalation, ask the person who helped: "What did you see that I didn't?" Their answer will teach you something.
• Practice the escalation format: situation, what I've tried, why I need help, what I'm asking for. Use it even for small asks so it becomes natural.

Escalation gets easier the more you do it, and the more you see it work. The people I respect most in client work aren't the ones who never need help. They're the ones who recognize when they need it fast enough that the help actually makes a difference.

Template: Escalation Request To A Colleague

Use this when: you've tried to resolve something yourself, it isn't improving, and you want to loop in a specific person with a proposed solution rather than a vague cry for help.

Channel: Slack message

```template

I want to loop you in on [PROJECT / CLIENT NAME].

What's happening: [THE SITUATION IN ONE OR TWO SENTENCES].

What I've tried: [WHAT YOU'VE ALREADY DONE — e.g. "two revision rounds" or "two days debugging"], and it's not landing. My read is [WHY YOU THINK IT'S STUCK — e.g. "this is a strategic disconnect, not a design problem" or "I'm looking in the wrong place"].

Why you: I think [YOU'D CARRY DIFFERENT WEIGHT HERE / YOU MIGHT SEE IN AN HOUR WHAT I'M MISSING], because [SPECIFIC REASON].

What I'm asking for: [THE SPECIFIC HELP — e.g. "join the next call, not to take over but to break the pattern" or "pair on this for a bit"]. I can [PREP YOU ON THE HISTORY / SEND WHAT I HAVE] beforehand.

[Given DEADLINE / TIME PRESSURE], I'd rather bring you in now than keep going in circles.

```