Light the beacons and actually get aid

A framework for driving resolutions

The ticket was a thing of beauty.

Detailed logs. Exact timestamps. A verbose description as well as precise steps to reproduce the bug that had the deployment of our newest solution to one of our largest customers at a standstill...their dev team sitting on their hands waiting on...us. My employee thought they had done everything right — documented the issue thoroughly, opened a ticket, forwarded it to the right people. Well done.

What happened? Our engineering partners filed it in the lo-pri bucket because nothing in that beautiful, detailed ticket informed them of the actual impact the bug was having on our customer.

Four weeks later, my frustrated engineer brought it to my attention as they struggled to get a timeline out of our partners. How long did it take to get it resolved once I got involved? Three days — the fix happened to be incredibly simple.

Now, I can already hear your thoughts because I've heard this pushback a number of times over the years: "Sure Paul, you've got a fancy title — of course it got fixed when you got involved." The thing is, I've seen people with fancier titles than mine scream and holler but still can't move the ball. While the title does help, it's the approach that gets things done.

Let me walk you through mine.

CATS: A Framework for Hairy Situations

None of what follows is rocket science — odds are you'll read each of these points and think "Duh." That said, every failed escalation I've encountered has been missing one or more of these.

I’d struggled for quite some time to break it down into an easy to remember structure.  Lucky for me, one of my folk recently pointed out the obvious when getting advice on handling one of his escalations: CATS.

CATS stands for:

• C — start with Criticality and impact
• A — make clear Asks
• T — unique issues per Ticket
• S — own your Situation

We'll quickly dig into how to apply each below.

C — start with Criticality and impact

The story in our cold open is a textbook example of missing this one. My engineer documented the bug perfectly — but never explained what it was costing the customer. That single omission drove their resolution into a ditch. I've watched this same pattern play out across every type of situation imaginable.

The facts of a situation are necessary, but they are not sufficient. When sharing a need we must clearly articulate the criticality, or how time sensitive a situation is, and its impact, as in the effect or potential for damage. Both are essential and both need to be clearly communicated, preferably FIRST. As Simon Sinek has been saying for decades, you have to "Start with Why".

How many people are affected? What is their business impact? What are the financial consequences to them or to you? What else is on the line?

If it's not immediately and obviously apparent to the people you are engaging with, they will not prioritize your ask. And they won't be wrong to do so — that one's on you.

Lead every request for help with criticality and impact. Regardless of whether it's an escalation, a defect, a feature gap, or a ticket — state it plainly. State it first.

A — make clear Asks

Not long ago, one of the folks in my organization wrote a multi-page email that he sent to two dozen leaders and experts across our company. The email — a blow by blow description and full history of the challenges facing one of their customers — exuded a level of detail not found in encyclopedias (do those still exist?). The content itself was a work of prose, sculpted with exquisite care. If he spent less than five hours writing it, I'd be surprised.

How did he end his magnum opus? With this banger: "What questions do you have?"

How many people responded to his email the next day? Zero. What about that week? Also zero. And I'd wager that the number of people who actually read past the first paragraph wasn't much higher.

The lesson should already be clear, but let's make it crystal: describing a problem and asking someone for help are two completely different things.

When asking for help, make your asks clear. Specific. Actionable. And where possible — time bound. Put them near the top, immediately below your Criticality and Impact. If people need more detail to understand your request, that detail can live below — though ancillary information is better suited to an attached document or a separate reference.

Every communication should clearly articulate what you need and from whom. If your audience has to guess, they'll either do nothing or do the wrong thing.

T — unique issues per Ticket

One issue per ticket, email, defect, or whatever medium you're using. That’s it.  Ask any of my leaders, this is one of my biggest pet peeves.  I know it's tempting to load every open issue into one giant email, blast it out to an audience of thousands, and call it done. Piling multiple issues into a single communication creates tremendous friction to your resolution efforts - I just experienced this a few weeks ago when someone from our IT department sent a four page email with asks for a dozen different folks. Would you like to guess at the reaction they received?

The more issues you pile together, the longer the note. The more people in the audience. The harder it is to craft clear asks. The more complex the communication. The less likely anyone is to read to the content relevant to them — or understand what you actually need from them.

In the words of the immortal Dale Carnegie — look at it from the other person's point of view. Your requests, regardless of medium, should be written to garner specific action from a specific audience. Sculpted to give THEM what THEY need to understand and act on the thing you want THEM to do. You are the asker. You need them. They don't need you.

If that sounds overly pedantic, it's because I've seen people screw this up thousands of times. Yes, it's more convenient for you to write one email — but you're not the point. When multiple unrelated issues get piled together it becomes nearly impossible for anyone to prioritize, assign, or cleanly resolve them. Your audience doesn't know what order things need to happen and will often pick the simplest item to address — if they do anything — and consider their box checked.

Separate them. Make it easy to manage. Each issue has its own urgency, its own owner, and its own resolution. Treat them as unique — and own project managing each of them to conclusion.

S — own your Situation

If the T section didn't sound like "old man yells at cloud," this one will.

You own situation.  Not the people you are asking for help.

Yes, you sent an email. Congratulations! But God help you if I ever ask for a status update and you tell me "I sent so-and-so an email last week and I'm waiting to hear back." Sending an email, submitting a ticket, or dropping a question in a Slack channel does not transfer responsibility for a resolution to the recipients. You still own the damn thing.

In a former role, someone two levels down in my organization once sent me an email asking that I engage in a time sensitive situation involving one of our Gaming customers. Unfortunately — and let's not pretend that I'm not partially at fault here — our spam filters decided that because this wasn't the "video" kind of gaming company, their note belonged in a special folder in my mailbox. I missed it. Two weeks later the situation bubbled up to our CRO and became something unhappy for literally everyone involved.

During the post mortem, I asked the engineer what other steps they had taken after reaching out to me.

"None. I'd sent you an email."

/sigh

When you're managing a critical situation, you own it. You're responsible for the resolution regardless of how many other people's support you need to get it done. You're tracking it. You're following up. If necessary, you're chasing folks down. You are the connective tissue between everyone supporting the situation and the end result.

Nobody is coming to save you from your escalation. You have to drive it.

Conclusion

Early in my career I was handed a career defining opportunity disguised as a giant pile of flaming garbage. A joint venture between two of the largest companies in telecom industry had completely broken down and I was hired as part of the last ditch effort to fix it. The stakes were about as high as they get: I was told plainly that if the situation wasn't resolved within six months, the two organizations would sue each other and my entire team would be out of a job.

What was wrong? Almost everything. But at the root of it was poor communication between two smart, committed teams. Issues were scattered across emails and conversations with no organized tracking. Nobody was driving. Problems were being thrown over walls. The impact of individual problems was never clearly communicated, so nothing was ever properly prioritized. Sound familiar?

Through an incredible effort from a remarkable team, we sorted it out. Not because we were the smartest people in the room. But because we were relentless about the fundamentals. Communicate impact. Make clear asks. Separate the issues. Own the outcome.

I didn't realize it at the time, but my team was developing CATS. It's not complicated, none of this is. This all sounds like common sense, but the gap between understanding these principles and executing them — when a customer is furious, when the pressure is high, when you're overloaded and you just want someone to take the issue off your plate — that's where resolutions go to die.

The next time you light the beacons and call for aid, ask yourself: Did you lead with criticality and impact? Did you make a clear ask? Is each issue standing on its own? And are you ready to own it until it's done?

If you can answer yes to all four — you're well on your way to resolution.

This topic is a bit of a diversion from most of my more recent content, but its many times more critical than the next post on doing a thing with AI (sorry Claude, I love you). Handling high priority situations transcends technology, standard, and role...and people that handle them well will steadily rise.