The Escalation Playbook: raise the problem without torching the relationship

Every organisation has a queue of problems that everybody can see and nobody has said out loud to the person who could fix them. The vendor who is three weeks late. The dependency that will not land. The teammate whose work keeps arriving unusable. The scope that quietly doubled and was never repriced.

People do not stay quiet because they are cowards. They stay quiet because escalating feels like an accusation, and because the folk wisdom in most companies is that escalating marks you as someone who cannot handle their own patch. So the problem is absorbed, worked around, and absorbed again — until the day it cannot be absorbed, which is also the day the cheap fixes have expired.

That is the actual cost. Not the awkwardness. Escalation is a mechanism for buying options, and options decay. A slipping deadline raised at week two can be solved by moving scope, adding a person, or renegotiating a date. The same slip raised at week nine can only be solved by apologising. Same problem, same facts, a tenth of the choices.

What follows is a repeatable process for raising a problem to someone with more authority than you, in a way that gets a decision instead of a reputation.

The one rule everything else hangs off

Escalate the decision, not the person.

An escalation that says "Dana is not delivering" invites a conversation about Dana, which your manager cannot resolve in the meeting and which guarantees Dana finds out you went over her head to complain. An escalation that says "we need a decision by Thursday on whether the API integration ships in v1 or moves to v1.1, because the current path misses the launch date by eleven days" invites a decision, which is the thing you actually wanted.

Every step below is a way of enforcing that one rule under pressure.

Step 1 — Confirm it is actually an escalation

Three tests. It qualifies only if you can answer yes to all three.

• Authority test: is the fix outside your authority? If you can solve it by spending money you control, moving work you own, or making a call you are allowed to make, it is not an escalation. It is a task you have been avoiding.
• Attempt test: have you asked directly at least twice, and can you name the dates? "I raised it on the 4th and again on the 11th" is an escalation. "I mentioned it a while back" is a grievance.
• Consequence test: can you state, in one sentence with a number in it, what happens if nothing changes? If you cannot, you do not yet understand the problem well enough to hand it to someone busier than you.

Most things that feel like escalations fail the first or second test. Fix those yourself. The ones that pass all three are genuinely someone else's call, and sitting on them is not restraint — it is a decision to let the default happen.

Step 2 — Give the 24-hour warning

Never let the other party learn about your escalation from your manager. It converts a solvable problem into a permanent enemy, and it is the single most common reason escalations damage careers.

Tell them first, plainly, and give them a last chance to make the escalation unnecessary. Keep it short.

Roughly a third of the time, this ends it. The date appears, the resource is found, the blocker turns out to be something they can clear in an afternoon. The other two thirds, you have preserved the relationship — you gave notice, you were specific, and nobody was ambushed.

Twenty-four hours is the standard. Use less only when the consequence lands sooner than that.

Step 3 — Write the one-pager before you speak to anyone

Verbal escalations get relitigated. Written ones get decided. Write this even if you plan to raise it in person — the writing is what forces the thinking, and you will send it afterwards anyway.

Six blocks, no more than a page:

• Decision needed. One sentence, phrased as a question with a deadline. "Do we ship v1 without the API integration, or move launch to 12 October? Needed by Thursday."
• Situation. Three to five factual sentences with dates. No adjectives. No motives.
• Impact if nothing changes. One sentence with a number: days, dollars, customers, or risk.
• What I have already tried. Dated bullets. This block is what separates you from a complainer.
• Options. Two or three, each with its cost and its consequence. Always include the do-nothing option and price it honestly.
• My recommendation. Pick one. Say why in a sentence.

The recommendation block is non-negotiable. Arriving with options and no view makes the problem entirely someone else's to think about, which is precisely the thing that makes senior people dread escalations. Arriving with a recommendation makes the meeting a five-minute yes-or-no.

Step 4 — Pick the right rung

Go exactly one level above the lowest person who can make the call. Not to the top. Not to whoever answers fastest.

Jumping levels feels efficient and is almost always a mistake: it embarrasses everyone you skipped, it lands the problem with someone who lacks the context to decide well, and it converts a scheduling issue into a political one. If you have already escalated one rung and nothing happened within the deadline you set, then you go up again — and you tell the person you are about to skip that you are doing it.

If the two parties report into different chains, escalate on your own side first and let the two managers meet. Escalating sideways into someone else's chain is how you get a reputation you cannot shed.

Step 5 — Run the meeting in five minutes

Lead with the decision, not the story. The instinct is to build the case chronologically so that by the end the listener agrees — that instinct is wrong. Busy people need to know what you want before they can listen properly.

Then stop talking. If they ask for detail, you have the one-pager. If they decide, you are done in ninety seconds and you have taught them that your escalations are cheap to handle — which is exactly why the next one will get taken seriously.

If they push it back to you ("can you not just sort it out?"), do not argue. Restate the authority test: "I can, if you are happy for me to move the launch date on my own call. That is the only lever I have." Nine times out of ten that produces the decision.

Step 6 — Close the loop in writing, same day

Send three lines to everyone affected, including the person you escalated about. Decision, owner, date. Nothing else — no relitigating, no victory lap.

The last clause matters. It gives anyone who disagrees a clean, low-cost way to correct the record now rather than in six weeks, and it makes the whole thing look like housekeeping instead of a manoeuvre.

The failure modes

• The ambush. Escalating without the warning in step 2. Buys you one decision and costs you the relationship permanently.
• The dossier. Eleven months of grievances presented at once. Reads as a campaign, not a problem, and shifts scrutiny onto why you waited.
• The adjective problem. "Unresponsive", "sloppy", "clearly does not care". Every adjective about a person is a sentence your reader has to discount. Dates and artefacts only.
• No deadline. An escalation without a by-when is a complaint with better formatting. It will sit.
• Escalating a preference. If the honest consequence is "I would have done it differently", that is not an escalation. Spend the credibility elsewhere.
• The unpriced do-nothing. Leaving the status quo off the options list makes you look like you are steering. Price it, even when it is obviously bad — especially then.

The twenty minutes that do most of the work

Before any of this, keep a running file for each significant dependency: date, what was asked, what was promised, what arrived. Two lines per event, updated as it happens. It takes about a minute a week.

That file is the whole game. It is the difference between an escalation that reads as documented fact and one that reads as a bad mood, and it is why the people who escalate well seem calm about it — they are not reconstructing anything under pressure. They are reading.

Escalation is not an admission that you lost control of your patch. It is the mechanism by which decisions get made at the level where they are allowed to be made, while there are still decisions worth making. Run it early, run it in writing, and run it on the problem rather than the person.