The work nobody owns

Most escalations never reach the C-suite. The ones that do arrive with a strategic customer badly impaired, their CIO calling your CEO, a renewal suddenly in question and an hourly status call where every executive wants an answer the team can't give yet: when will this be over?

From there, the escalation runs on two tracks. The one leadership sees goes from the first alert to the all-clear, with orderly updates in between. The other is how the problem actually gets solved, and it starts with questions no system answers quickly. What changed? Who touched it last? What has already been tried, and what happened when we tried it? Who has seen this before? The first track is the one that gets measured. The second is where the hidden time and cost accumulate.

To answer those questions, teams work like forensic investigators. They rebuild a timeline from fragments, test each theory against the logs, and chase leads back to decisions made months ago by people who had no reason to think they'd matter now. The case says "customer reports degraded performance" on Monday and "issue resolved" on Friday. What happened in between is scattered across other systems, or was never written down at all.

I've been watching versions of this since the 1990s. Sometimes the break comes from one overlooked clue. A support engineer remembers a Slack thread from weeks back, where someone on another team mentioned that a different customer had hit the same symptom and found a way around it. The clue is one sentence. Making it useful is the work.

That work is what I call the second job. Your best people are doing two jobs. The first is the one you hired them for. The second is everything they do to get the first job done. It's nobody's job title. It's whoever knows, whoever notices, whoever cares, and on an escalation like this one it's usually several of them. In most escalations, the second job lives in the seams between groups. The pieces may be written down somewhere. The work of connecting them rarely is.

To make matters worse, every system we so carefully built to hold the truth holds a different vintage of it. The other customer's case sat in a different team's queue, frozen on the day it closed. The workaround lived in the Slack thread, still worded as a guess, though that customer had been running on it for weeks. The product change behind both sat in last quarter's engineering ticket. None of them linked to the others, and whether the workaround still held lived only in that colleague's head.

On the next hourly status call, the executives finally get their answer to when this will be over. None of them sees how it was found.

AI can collect the evidence. It can't read invisible ink.

AI is already doing some of the forensics. Connected to your CRM, ticketing system, engineering tracker and team chat, it can find the old case, surface the Slack thread, connect it to last quarter's engineering change and summarize three days of activity in minutes. Work that once depended on the veteran who remembered where to look becomes available to everyone.

Then it hits two limits. Records rarely mark the moment the truth changed: the theory that died, the stopgap that became how the system runs. AI can often infer it, the same way an experienced engineer does, and both get it right more often when someone wrote the change down. The second limit is the invisible ink: the call that replaced the ticket, the reason someone chose not to follow the documented process this time, whether a workaround still holds. What never reached a system isn't there to connect.

Across company lines, even more of the second job falls on the customer.

That story stayed inside one company. Your product also runs alongside a cloud provider's, a network vendor's and others the customer depends on. Each company may have excellent systems, connected context and capable AI, and each still starts from the evidence it is allowed to see. When the failure lives in the seam between two products, each vendor can check its own component and truthfully find it healthy.

So the customer is up at 2am with their own systems down, while every vendor they depend on answers within its SLA. Every vendor's dashboard shows the customer being taken care of, and every system is green. The second job now falls on the customer. The customer becomes the system of record for their own escalation, while paying every vendor for support.

It doesn't have to work this way. TSANet is a non-profit, vendor-neutral support alliance where I serve as an advisor. Since 1993, it has given member companies, including Cisco, Microsoft and Red Hat, a shared legal and operating framework for working a customer's problem together. They settle how they'll reach each other and work the case before the outage, so the customer doesn't have to invent that coordination in the middle of one.

Shrinking the second job

Fixing the second job has no clear owner in most companies, so it has to start deliberately. Take the last escalation that reached your executives, and walk the path the customer actually traveled with the people who worked it.

Along the way, look for the second job at work: someone digging through old systems, chasing down a person, solving something already solved, or leaving the customer to carry information between companies. At each one, ask three questions, and keep asking them of every process and every change until they become how the work runs:

How do we cut the customer's effort, especially when the work crosses vendors?

How do we cut the effort of every group this work passes through?

What did we learn that the next person, or the system, can use?

Inside your company, the second job runs on whoever knows, whoever notices, whoever cares. Across company lines, it runs on your customer. Either way, it's yours to make go away.

__

Collecting the evidence shouldn't be part of the second job. Computer, by DevRev, keeps each case and customer connected to the conversations and product changes around them. Those connections stay current as the work moves. So when the next escalation starts, the team begins with those connections instead of rebuilding them.