Something breaks. An alert fires. Someone gets paged.
The first decision your team makes is not what to do. It is who to call.
And that decision is not random.
There is always a name. Maybe two. The person who has been around long enough to remember what shipped last week and why. The support lead who can read a customer complaint and hear what the customer actually meant. The engineer who knows which three deployments are worth looking at and which forty are noise.
That person gets the call.
Not because they’re available. Because nobody else can do what they’re about to do.
What they do next is not engineering. It is archaeology. They open Jira. They scan the recent tickets. They pull up GitHub. They look at the timestamp and try to remember what was unusual about that window. They open Salesforce. They read the case. They translate the customer’s description — a symptom written in plain language by someone who doesn’t know the technical name for what broke — into something that points at a cause.
They are holding four systems in their head at once, running a search none of those systems can run for them.
Hours pass. The customer is still waiting.
This is the part that does not show up in your incident metrics.
MTTR captures how long it took to resolve. It doesn’t capture who resolved it, or what they weren’t doing while they were in the war room.
Think about what that person does when they’re not reconstructing a timeline.
They’re the ones who know where the bodies are buried. Who can look at a new feature request and tell you in thirty seconds which two systems it will touch and why that matters. Who can onboard a new engineer in two weeks instead of six because they have the context that no document has ever fully captured. Who can take a customer call that has gone sideways and turn it around — because they understand the product deeply enough to improvise.
That’s not a role. That is institutional knowledge in human form.
And while they’re in the war room, that knowledge is offline.
The investigation always finds the person with the most context. That’s not a management failure. It’s the only rational response to a situation where the signals are not correlated and someone has to correlate them manually.
But there’s a compounding problem.
The investigation doesn’t just consume hours. It consumes the specific hours of your least substitutable people. Every incident that lands in the war room is a withdrawal from a very small account.
They get pulled in often enough, and something else starts to slip. The project that needed their input. The junior engineer who needed a review. The roadmap conversation they were supposed to lead. The things only they can do get deferred, because the thing they’re currently doing also requires them.
This is not burnout. Not yet. It’s displacement.
The cost is not measured in hours. It is measured in what those hours replace.
Your systems of record are not the problem. Jira captured the ticket. GitHub captured the commit. Salesforce captured the case. Each one did exactly what it was designed to do.
None of them were designed to do what your most experienced person is doing right now: reading across all three and finding what they have in common.
So that work lives where it has always lived. With the person who can do it. Every time.
And every time it does, something else waits.
Teams where the investigation always finds the same small group — where the senior engineer or support lead is the de facto correlation engine — are exactly who we’re thinking about.
If that’s your team, we offer a complimentary Investigation Cost Audit. Forty-five minutes. Structured diagnostic across five dimensions. You leave with a scorecard that quantifies what the investigation is actually costing you: in time, in recurrence, and in the hours your most irreplaceable people aren’t spending on the work only they can do.