The Escalation You Should Have Made Yesterday

The five-minute message you’ve been avoiding for two weeks is usually the highest-leverage move you can make this quarter.

You know the one. The thing that’s been stuck since the last sprint. The peer team that owes you a decision. The vendor who said they’d come back to you on Thursday and it’s now Tuesday. The architectural call your skip needs to make but won’t unless you ask. You’ve been telling yourself you’re being patient, that you don’t want to push, that it’ll probably sort itself out.

It won’t. And the patience is not patience. It’s avoidance dressed up to look like discretion.

Escalation is not tattling

The mental block on escalation is almost always a category error. You think escalation means complaining about a colleague to their boss. It almost never does.

Escalation is asking for a decision from the person whose job is to make that decision. That’s it. If two teams can’t agree on a contract and the deadline is real, someone above both teams has to make the call. That person is paid to make calls like this. You are not bothering them by surfacing it. You are handing them useful work.

The framing matters because of how you write the message. If you frame it as “X is being unreasonable,” you’ve already lost. If you frame it as “we need a decision on X by Friday or the launch slips, here are the two options, which do you want me to run with,” you’ve turned a complaint into a request. Same situation, completely different reception.

Why you don’t do it

There are three reasons engineers don’t escalate, and all three feel like virtue from the inside.

You don’t want to look like you can’t handle it. This is the most common one and the most expensive. You imagine your manager thinking less of you for asking. In practice, your manager thinks less of you when they find out about the stuck thing from someone else two weeks later. The signal of competence is not solving everything alone. It is recognizing what you can’t unblock yourself and surfacing it cleanly.

You don’t want to throw a peer under the bus. This is the most flattering reason and the most misleading. If you describe the situation factually, you are not throwing anyone under any bus. You are describing a situation. If a factual description makes someone look bad, the problem is not your description.

You’re hoping it’ll resolve itself. Sometimes it does. The hope is real. But the math is bad. The cost of escalating something that would have resolved itself is fifteen minutes of slightly awkward back-and-forth. The cost of not escalating something that wouldn’t have resolved is the rest of the quarter. The expected value is not close.

The cost asymmetry

Think about the two timelines.

Escalate two weeks early: you send a message your manager might have to ask a clarifying question on, and you get a decision or a nudge that unblocks you. Mild discomfort, fully recoverable.

Escalate two weeks late: a deadline slips, a peer team is annoyed because the conversation happens at high altitude instead of between them and you, your manager finds out about the problem when it’s already a problem, and your reputation as someone with good situational awareness takes a small but real hit. Compound, hard to recover.

Late escalations don’t just cost more. They also tend to involve more senior people, because by the time you finally surface it, the problem has grown enough to require it. The thing you could have escalated to your manager three weeks ago is now a thing you’re escalating to their manager.

What a good escalation looks like

When you finally do it, the message has four parts. Anything missing one of these parts is venting, not escalating.

The “by when” is the part most engineers leave off, and it’s the part that turns a complaint into a request. Without it, your manager has no way to prioritize the ask against the other six things on their plate. With it, they know exactly how urgent it is and can either act or push back.

A good escalation reads more like a status report with an ask on the end. It does not read like a vent. The difference is mostly tone.

Same problems. Different work product.

The bar is lower than you think

Most engineers carry around a mental bar for escalation that is set way too high. They think it has to be a crisis. It doesn’t.

The bar is roughly: something has been blocked for more than a few days, and you’ve already tried the obvious unblockers. That’s it. You don’t need to wait until it’s on fire. You should not wait until it’s on fire. The whole point of escalating is to prevent the fire.

If you’re not sure whether something clears the bar, that uncertainty itself is the signal. Send the message. Let your manager decide whether it’s worth their attention. That is a one-sentence decision for them. It has been a two-week decision for you.

The skill is the unflinching part

The structure of escalation is easy. The hard part is the unflinching willingness to name what’s stuck without softening it into nothing.

“I’m a little concerned about timeline” is not an escalation. “We will miss the deadline if we don’t resolve X by Wednesday” is. The first one lets everyone off the hook. The second one puts the situation on the table where it can actually be dealt with.

The senior version of this skill is doing it without drama. No theatrics, no apology, no “sorry to bother you.” You’re not bothering anyone. You’re doing the part of your job that nobody else can do for you.

The escalation you should have made yesterday is almost never as costly to send as you think. It is almost always more costly to delay. And the discomfort you’re avoiding is not protecting anyone, including yourself.

Send the message.