Escalating well: when to raise it and how

Escalate too late and the cost compounds; escalate too early and you spend your own autonomy — the skill is telling which is which.

The idea

Not every problem should go up the chain, and not every problem should stay with you. Before you decide, run a quick test on three things: how irreversible it is, how wide the , and whether it’s yours to own.

Then, if you do raise it, do it well: inform early, bring options not just problems, and never surprise your manager.

Try it — read the severity, then choose

scenario 1 of 5

severity — low

how irreversibleeasy to undo → can’t undo

blast radiusjust me → all customers

time pressureplenty of time → needed now

manager trust

outcome log

Your decisions and their fallout will appear here.

Read the gauge and whether it’s yours to own, then pick a response. You can nudge the sliders to see how the severity changes.

How it works

First score the severity, then match your response to it and to ownership:

severity  =  irreversibility, blast radius, time pressure  (weigh all three)

  it’s YOURS to own
    low severity            -> handle it (deciding it yourself builds trust)
    moderate severity       -> handle it, but inform early  (no surprises)
    high severity           -> escalate WITH options + a recommendation

  it’s NOT yours to own  -> loop in the owner early; escalate if it’s serious

  going around your manager -> almost never; it burns trust fastest

Two failure modes sit on either side of the right call: too late (you sat on something severe and the cost compounded) and too early (you handed up something small and spent your own autonomy).

When to use it

Response	Fits when	The trade-off
Handle it	Reversible, contained, and yours to decide	Handling something truly severe alone is the classic late escalation
Inform (FYI)	You can handle it, but it’s visible enough that a surprise would sting	A stream of FYIs on trivia reads as low confidence
Escalate with options	High severity, or the call isn’t yours to make alone	Bring choices, not just a problem — and do it early
Go around	Only a genuine ethics/safety block, via a named channel	Skipping your manager as an ambush burns trust fastest

Watch out for

Sitting on a severe problem hoping it resolves itself. Irreversible, wide-blast issues only get more expensive the longer they’re hidden.
Escalating every small decision. Handing up things that are yours to call trains your manager to see you as someone who can’t run their own patch.
Bringing a problem with no options. “This is broken” makes it your manager’s problem; “here are three fixes, I’d pick B” keeps it yours.
Surprising your manager — especially in front of others. The cardinal rule is no surprises; brief them before it surfaces in a wider room.
Going around them to look decisive. Even when your underlying call is right, the bypass is what people remember, and trust doesn’t recover cheaply.

Worked example

“Tell me about a time you had to escalate something.”

“During a release I owned QA for, I found a bug that would silently corrupt customer records, and a rollback after ship would be painful. That’s high on all three: irreversible, wide blast radius, and time-critical — and the go/no-go wasn’t mine to make alone. So I didn’t sit on it and I didn’t just send a worried FYI. I pinged my lead immediately with the finding, the blast radius, and three options — hold the release, ship with the feature flagged off, or hotfix and re-test — with a recommendation to hold. We held, fixed it, and shipped a day later. Raising it early with options meant a two-minute decision instead of an incident.”

Check yourself

You can fix a minor, reversible config issue in your own service in five minutes. Best move?

You must escalate a serious, time-sensitive issue. What makes it land well?