Escalation Is a System, Not a Failure

In most organisations, escalating a problem feels like admitting defeat. The employee who cannot solve something alone, who needs help from above, feels like they have failed. The manager who receives the escalation feels like they are being handed a problem they did not create. The whole act is wrapped in shame, and the shame has a cost: people escalate too late, too quietly, or not at all, and small problems become disasters.

The truth is the opposite of the feeling. Escalation is not a failure of the person who escalates, it is a failure of the system that made escalation rare, late, or frightening. In healthy organisations, escalation is a designed process, as normal as a code review or a handover. It is the mechanism that brings the right information to the right level at the right time.

1. The Anatomy of a Stuck Problem

A problem becomes a candidate for escalation when three things are true at once. The problem is important: it will hurt the business if it is not resolved. The problem is stuck: the person or team holding it has run out of moves within their authority. And the problem is time-sensitive: waiting is making it worse.

The definition matters because it separates escalation from the alternatives. Complaining is escalation without a request. Delegating is escalation without the holder being stuck. Abdicating is escalation without any analysis. Real escalation is none of those. It is a specific move: I am holding a problem that is important, stuck, and urgent, and I need you to do something I cannot do.

2. The Two Kinds of Escalation

There are two distinct escalations, and confusing them is a common source of dysfunction. The first is escalation of decision: the team needs an answer that only a more senior person can give, a budget approval, a priority call, a trade-off. The second is escalation of help: the team needs resources, skills, or political weight that they do not have.

The difference matters because the response is different. A decision escalation wants speed and clarity: here is the situation, here are the options, here is what I recommend, decide. A help escalation wants support: here is the situation, here is what I have tried, here is what I need. Teams that name the kind of escalation they are making get much better responses.

3. The Rule of Three

The simplest escalation protocol is the rule of three: try three approaches, document what you tried, then escalate. The rule has two purposes. It forces the person to actually work the problem before handing it up, and it gives the receiver the context they need to be useful instead of starting from zero.

The rule is not a barrier, it is a filter. It catches the escalations that are really laziness, and it sharpens the ones that are real. The person who arrives with "I tried A, B, and C, here is what happened, here is what I need" is not a burden. They are a professional doing the work of escalation well. The person who arrives with "this is broken" is the burden, and the rule protects everyone from them.

4. Escalation Is Information, Not Blame

The culture of an organisation is visible in how it receives escalations. In a blame culture, the escalation is heard as an accusation: you did not give me enough, you set this up wrong, you should have known. The receiver gets defensive, the sender gets punished, and the next problem gets hidden.

In a learning culture, the escalation is heard as information: here is a signal about where the system is failing. The receiver thanks the sender, digs into the root cause, and fixes the system so the next escalation of the same kind is unnecessary. The difference is not in the words, it is in the reaction. The leader who reacts to escalations with curiosity instead of defensiveness is building the culture that catches problems early.

5. The Escalation Path Is a Design

Every team should be able to answer two questions instantly: what problems get escalated, and to whom. If the answers take more than a sentence, the escalation path is not designed, it is improvised, and improvised paths fail exactly when they are needed most, in a crisis.

The design is simple. Define the criteria that trigger escalation: thresholds of impact, delay, or risk. Name the owners at each level: who decides, who helps, who is the final stop. And write it down, in two paragraphs, not a policy document. The team that knows the path does not waste time wondering where the problem goes. The path itself is a decision that was made calmly, before the crisis made it in panic.

6. The Manager's Escalation Duties

Receiving an escalation is a job with its own duties. The first duty is speed: a stuck problem is costing money every hour, and the receiver's value is largely about unblocking it fast. The second duty is clarity: the receiver must make the decision or provide the help that was requested, or explicitly decline with a reason. The worst response is no response.

The third duty is teaching: the receiver should show their work, explain the reasoning, so the next similar escalation can be handled one level lower. The manager who always answers but never explains is creating permanent dependency. The manager who answers and explains is creating capability. The goal of a good escalation system is to make the current escalations unnecessary, one by one.

7. The Escalation That Never Happens

The most dangerous escalation is the one that never happens. The employee who sits on a problem for three weeks, hoping it resolves, dreading the conversation. The team that hides a slipping date until it is unrecoverable. The silence is not a sign of a healthy team, it is a sign of a system where escalation is unsafe, and the safety problem is the real issue to fix.

The fix is not a process, it is a permission. The leader says, explicitly and repeatedly: bring me the bad news early, bring me the stuck problem before it is urgent, and you will never be punished for it. The permission has to survive its first real test, the first escalation that is genuinely bad news, handled without blame. After that, the escalations flow, and the problems get small.

8. The System, Not the Hero

The romantic image of management is the hero who personally swoops in and solves the impossible. The professional image is much less glamorous: a manager who built a system where problems surface early, get escalated cleanly, and get resolved at the right level. The hero saves the day sometimes. The system saves the day every day.

The test of the system is simple: what happens when the manager is away for a month? In a hero culture, everything waits. In a system culture, the escalations route, the decisions get made, and the manager returns to find the business running. The escalation system is not a sign of weakness in the team, it is a sign of strength in the design. Build it, and the crises that used to define the job become rare, small, and routine.

Tags

#management #operations