The message you’ve been putting off for two weeks takes five minutes to write, and it’s probably the highest-leverage thing you’ll do this month.
You know the one. The thing that’s been stuck since last sprint. The other team that owes you a decision. The vendor who said Thursday, and it’s now Tuesday. The architecture call your skip needs to make but won’t unless someone asks. 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 it isn’t patience. It’s avoidance that looks like discretion from the inside.
Escalation isn’t telling on someone
The block is usually a category error. You think escalating means complaining about a colleague to their boss. It almost never means that.
Escalating is asking for a decision from the person whose job it is to make that decision. If two teams can’t agree on a contract and the deadline is real, someone above both teams has to call it. That person is paid to make exactly these calls. You’re not bothering them. You’re handing them a piece of their job with the context attached.
The framing changes how you write the message. “X is being unreasonable” loses before it’s read. “We need a decision on X by Friday or the launch slips, here are the two options, which one should I run with” is the same situation written as a request instead of a complaint, and it gets a 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 picture your manager thinking less of you for asking. In practice your manager thinks less of you when they hear about the stuck thing from someone else, two weeks later. Competence isn’t solving everything alone. It’s knowing what you can’t unblock yourself and surfacing it early and 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’re not throwing anyone anywhere. You’re describing a situation. If a factual description makes someone look bad, the description isn’t the problem.
You’re hoping it resolves on its own. Sometimes it does. But the math is bad. Escalating something that would have resolved itself costs fifteen minutes of mild awkwardness. Not escalating something that wouldn’t have costs the rest of the quarter. Those aren’t close.
The cost is asymmetric
Escalate two weeks early: you send a message, your manager maybe asks a clarifying question, and you get a decision or a nudge that unblocks you. Slightly uncomfortable, fully recoverable.
Escalate two weeks late: a deadline slips, the other team is annoyed because the conversation is now happening above them instead of with you, your manager learns about the problem when it’s already a problem, and your reputation for situational awareness takes a small but real hit. That one compounds.
Late escalations also tend to involve more senior people, because by the time you finally raise it, the problem has grown to the size that needs them. The thing you could have taken to your manager three weeks ago is now a thing you’re taking to their manager.
What a good one looks like
A good escalation has four parts. Anything missing one of them is venting, not escalating.
- What’s stuck, in one sentence.
- What you’ve tried: two or three concrete attempts, with dates.
- What you need: a decision, a person, a deadline change, or a meeting.
- By when, as a specific date tied to a downstream consequence.
The “by when” is the part most people leave out, and it’s the part that turns a complaint into a request. Without it your manager can’t rank the ask against the other six things on their plate. With it they know exactly how urgent it is and can act or push back.
A good escalation reads like a status update with an ask at the end, not like a vent. The difference is mostly tone. Compare:
- “X is impossible to work with” versus “X and I agreed on A on Monday and B on Wednesday. I need a tiebreaker.”
- “We’re never going to ship this” versus “If we don’t decide on the indexing strategy by Friday, the migration slips a sprint.”
- “Nobody responds to my messages” versus “I sent the spec to the platform team on the 3rd and again on the 10th. No reply. Can you pull them in?”
Same problems, different work product.
The bar is lower than you think
Most engineers carry a mental bar for escalation that’s far too high. It doesn’t need to be a crisis. The bar is roughly: something has been blocked for more than a few days, and you’ve tried the obvious things. Nothing more dramatic than that. You don’t wait until it’s on fire. The point of escalating is to prevent the fire.
If you’re not sure whether something clears the bar, the uncertainty is the signal. Send it and let your manager decide whether it deserves their attention. For them that’s a one-sentence decision. For you it’s been a two-week one.
The hard part
The structure is easy. The hard part is naming what’s stuck without softening it into nothing.
“I’m a little concerned about the timeline” isn’t an escalation. “We will miss the deadline unless X is resolved by Wednesday” is. The first one lets everyone off the hook. The second puts the situation on the table where it can be dealt with.
The senior version of this 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 the job that nobody else can do for you.
The escalation you should have sent yesterday is almost never as costly as you think, and almost always more costly to delay. Send it.