Every support leader who has been in the role long enough has a version of the same memory: the phone ringing at an hour that isn’t meant for work calls, an engineer on the line, and the dawning understanding that a major client’s system is down and the next few hours are going to be yours. Not your team’s. Yours.<\/p>\n
Being the executive escalation point for critical incidents<\/a> is one line in a job description and one of the most defining experiences in the job. I’ve been the named individual near the bottom of the escalation matrix at five companies over nearly two decades — third escalation at Tyco\/JCI, second at AudienceView, and various forms of “the person they call” at Tucows, Venda, and Q4. Here’s what I’ve learned about doing it well, and what it actually takes.<\/p>\n A good escalation matrix is a document that nobody looks at until everybody needs it. It lists, for each severity level<\/a>, who gets contacted and when: first contact at the moment the case opens, first escalation to a manager an hour in, second escalation to a senior manager or director, and onward to VP and executive levels as the incident persists. Each entry is a named human with a phone number and a defined trigger.<\/p>\n The reason this matters is that the worst possible time to figure out who to call is during the incident itself. When a client’s production system has been down for ninety minutes and the pressure is mounting, “who has the authority to approve this?” and “who do I wake up?” are questions that should already be answered. The matrix answers them in advance, which is the only time those answers are any use.<\/p>\n The escalation matrix exists to be used, not admired. If you’re on call at 2am, so is your senior leadership — and the budget gets released when the phone rings at 2am.<\/p>\n<\/blockquote>\n I learned early not to be afraid of escalating up my own chain. There’s a tendency among support leaders to absorb the pressure, to want to be the one who handled it without bothering the executives. That instinct is wrong. If an incident warrants senior leadership’s attention, escalating is the job — not a failure to do the job. The resources, the budget, and the decisions that resolve a major incident often sit above your authority, and the matrix is how you reach them legitimately. This same principle — clarity before urgency — is what makes ITIL’s incident and problem management frameworks<\/a> worth the implementation effort.<\/p>\n The single most important thing I’ve learned about major incidents is that clients rarely leave because of the outage itself. They leave because of how the outage was handled — and specifically because of silence.<\/p>\n During a sustained period of instability earlier in my career, I supported a portfolio of services that seemed to take turns failing. I was flown around the world to sit across from Tier-1 customers and explain what was happening. I’ve written about that period in more detail at CXMaster<\/a>, but the core lesson held across every one of those conversations: a client who hears from you on a predictable cadence — even when the message is “we don’t have a fix yet, here’s what we’re doing, I’ll update you in 30 minutes” — will stay far longer than a client left wondering whether anyone is even working on their problem.<\/p>\n At AudienceView<\/a>, our P1 standard was a first response within 15 minutes and updates every 30 minutes thereafter. That cadence wasn’t about having news every half hour. It was about the client never having to wonder. The discipline of the update — meeting the time you committed to, every time, news or no news — is what builds the trust that survives the incident. PagerDuty’s incident communication playbook<\/a> describes a similar cadence, and for good reason: the pattern works across industries and incident types.<\/p>\n Here’s the part that surprises people new to the escalation role: the difficult communication isn’t with the client. It’s with your own internal teams.<\/p>\n Engineering and development teams are often insulated from what an outage actually costs. They see a technical problem to be solved on its technical merits and its own timeline. They don’t see the client’s operations director who can’t process orders, or the reputational damage accumulating by the hour, or the contract renewal conversation that this incident just made much harder. Part of the escalation role — maybe the central part — is carrying that reality inward. Persuading the people who can actually fix the problem that the customer matters<\/strong>, that the urgency is real, and that the reason everyone has a job is the revenue the customer represents.<\/p>\n This is a version of the same challenge that shows up in M&A integration work<\/a>: your hardest communication problem is almost never external. It’s the internal alignment that determines whether the external outcome is survivable.<\/p>\n Communication is two-way. Speaking to the customer is the visible part. The harder part is making your internal teams feel the impact the customer is feeling.<\/p>\n<\/blockquote>\n Some incidents are too big for a single escalation chain. When multiple services degrade at once — the signature of an infrastructure-level problem rather than a single fault — you need a different mechanism. At Tucows, I worked within a formal War Room process built for exactly this.<\/p>\n The discipline of a good war room comes down to a few things: clear invocation criteria so anyone can trigger it without hesitation, a defined list of mandatory participants who each speak for their whole team, a fast clock (initial meeting 30 minutes from invocation), and — critically — a customer-communications workstream that runs in parallel with the technical resolution<\/strong> rather than waiting for it. The technical team fixes the problem; someone else owns keeping the customer informed while they do. Trying to do both from the same person is how clients end up in silence while everyone’s heads-down on the fix.<\/p>\n The other thing a mature war room process has is a memory. Every major incident ends with a post-incident review<\/a> (sometimes called a blameless postmortem) that feeds improvements back into the procedure. The version I operated within had been revised more than a dozen times. Each incident, painful as it was, made the next one more survivable.<\/p>\n If I compress everything I’ve learned about leading through major incidents into the things that genuinely determine whether a client stays, it’s these:<\/p>\n I’ll be honest about something the polished version of this story usually leaves out: being the always-on escalation point takes a real toll. There were periods — a sustained stretch at one company in particular — where the constant incidents affected my health. The 2am calls, the weekends interrupted, the low-grade dread of the phone. Anyone who has held this role knows the weight of it.<\/p>\n I name it because the support leaders reading this who are in the thick of it should know they’re not failing for finding it hard. It is hard. The mitigation isn’t toughing it out — it’s building the frameworks (severity definitions, escalation matrices, war room processes, robust on-call rotations<\/a>) that distribute the load and make each incident more manageable than the last. The systems are what make the role survivable. That’s the real work: not being a hero on the bridge call, but building the structure so that the bridge call is shorter, clearer, and less frequent every time.<\/p>\nThe Matrix Has Your Name on It for a Reason<\/h2>\n
\n
Communication Is the Whole Game<\/h2>\n
The Hardest Audience Is Internal<\/h2>\n
\n
When One Team Isn’t Enough: The War Room<\/h2>\n
What Actually Keeps Clients<\/h2>\n
The Toll, and Why It’s Worth Naming<\/h2>\n
Related reading<\/h4>\n
\n