Escalation Is Not Failure. Escalating Late Is.

Nobody has ever been quietly removed from a project for escalating a problem in week four. People get removed for escalating in week eleven, when the same problem has eaten every option that was available in week four. The industry has this exactly backwards, and it costs good engineers their first lead role.

Ask most new technical leads why they sat on something and you get a version of the same answer. "I wanted to try and sort it myself first." Which sounds responsible. It sounds like ownership.

It usually isn't. Underneath it is the worry that raising a problem is an admission you couldn't handle it, and that the person you raise it to will file you mentally under "needs help". So you give it another week. Then another. You're not managing the risk, you're managing how you look while the risk gets worse.

Here's the reframe that took me far too long. Escalation is a routing decision, not a confession. You are deciding whose desk a decision belongs on. That's it. Some decisions are yours and some aren't, and sorting them correctly is the job. A lead who escalates nothing is not more capable than one who escalates well. They're just making other people's decisions without permission, and eventually one of those goes badly.

The senior people you're worried about impressing are not tracking how many problems you brought them. They're tracking how often you brought them one late.

When something lands on you, run it:

Can I change this outcome with the authority I already have? Not "could I with a heroic effort", not "could I if three people do me a favour". Do you have the decision rights? If a supplier is missing a contractual date, you almost certainly don't. That's a commercial conversation and it belongs to whoever signed the contract.

Can I change it with the resources I already have? If the answer requires two more engineers, a budget line, or somebody else's team to reprioritise, the resource holder has to be in the room. You can recommend. You can't allocate.

Can I change it in time for it to still matter? This is the one people skip. You might genuinely be able to fix it yourself, in six weeks, by which point the change freeze has closed and the fix is worthless. Time is part of the test.

Fail any one of those three and it goes up. Not as a complaint. As a decision request with a date on it.

Worked example, and it's a common shape.

A platform team at a national law firm is standing up a new internal API gateway. Their plan depends on a 10-person identity team delivering a token service by the end of March. The lead, first time in the role, gets a message in early February: the identity team has been pulled onto a regulatory piece and the token service is "probably April, maybe May".

She does the reasonable-looking thing. She talks to the identity lead. They agree to look at a workaround. She adds an amber flag to her weekly report with the note "dependency under discussion". She genuinely believes she's handling it.

Five weeks pass. In mid-March the identity lead confirms May. Now the gateway cutover misses the window before the year end freeze, the two contractors booked for migration work are sitting idle at a cost nobody planned for, and the sponsor finds out at the same time as everyone else, from a slide.

The conversation that follows is not about the identity team. It's about the five weeks. And the honest answer is that in the first week of February she had at least four options: get the identity work reprioritised at director level, buy a short-term commercial token service, re-sequence the gateway so the token dependency lands last, or move the cutover date deliberately and tell the finance team early while they could still plan around it. By mid-March she had one, and it was the expensive one.

The failure wasn't the dependency slipping. Dependencies slip constantly and everybody knows it. The failure was holding a decision that was never hers to hold, for five weeks, while the option set shrank.

There is a version of escalation that is almost as damaging as silence, and that's the person who forwards the problem with "FYI, this is now a risk" and considers themselves covered. That's not escalation. That's transferring anxiety and calling it governance.

What a useful escalation contains, in about a page:

The situation, in one paragraph, with the facts and no adjectives. The impact, stated in something the recipient actually manages: a date, a number, a regulatory exposure, a customer commitment. Two or three options, each with its real cost, including the option of doing nothing. Your recommendation, said plainly, because you know more about this than they do. And the decision you need, with the date you need it by.

That last line is the one people leave off, and it is the one that makes the thing move. "I need a call on this by Friday the 14th, because after that the contractor booking is non-refundable" gets an answer. "Let me know your thoughts" gets nothing, forever.

And when you've sent it, it is still yours. An escalation that disappears into someone's inbox has not been actioned, it has been received. If the date passes without a decision, you chase, and if you chase twice without an answer you escalate the silence itself. Writing it down does not move ownership off your desk. It puts a second name next to yours.

Open your risk log, or whatever passes for one, and look at the amber items. Pick the oldest one. Ask the three questions: authority, resources, time.

If it fails any of them, write the escalation today. One page: situation, impact in their currency, two or three options with costs, your recommendation, and an explicit decision date. Send it to the person who can actually make the call, and copy the person who'll be affected if they don't.

If it passes all three, put your name against it and a date by which it will be closed. Then it really is yours, and everybody can see that you know it.