The Tribal Knowledge Tax
Every team has one. The person who’s been there the longest, who built half the system by hand before anyone wrote it down, who gets pinged first in every incident channel because everyone else’s next message is “let’s wait and see what they say.” That’s tribal knowledge incident response in practice — not a process, just a person, and the whole team’s recovery time is quietly pegged to whether that person is awake, reachable, and in a good mood.
Nobody designed it this way. It just accumulates, one unwritten shortcut at a time, until the org chart says twelve engineers and the incident reality says one.
Why Does Tribal Knowledge Build Up in the First Place?
It builds up because writing things down loses every time to shipping the next feature. The engineer who diagnosed last quarter’s outage learned something true and useful — that the payments queue backs up whenever the nightly batch job overlaps with a deploy, say — and then went back to their sprint. Nobody assigned “turn what you just learned into something the rest of us can find” as a ticket, so it never became one. The knowledge is real. It’s just stored in exactly one place: a skull.
This compounds because the person holding the knowledge becomes the fastest path to a fix, which means they get looped in on every related incident, which means they accumulate even more context nobody else has, which means the gap gets wider every single time instead of closing. The system that should be distributing expertise is instead concentrating it.
What Single Point of Failure Engineer Knowledge Actually Costs
The obvious cost is the one everyone already complains about: that person’s vacation becomes a risk to be managed, their Slack status becomes an operational input, and every on-call rotation quietly routes around whichever week they’re unreachable. But the deeper cost shows up in the incidents where they’re not unreachable — where they do answer the page, and the team still loses an hour first.
That hour goes into a strange kind of throttling. Five engineers are staring at the same dashboard, each one capable of reasoning through the problem, but all five are stalled on the same question: has this happened before, and if so, what actually fixed it? Nobody wants to guess wrong and make things worse, so the default becomes waiting — for a reply, a callback, a “oh yeah, this is the thing from March.” The team’s combined headcount stops mattering. Throughput during the incident is capped at whatever one person’s attention can process, one Slack thread at a time.
And that person is now a bottleneck twice over. They’re triaging the current incident while simultaneously being asked to recall and narrate the last three that looked similar, from memory, under time pressure, at whatever hour the page went off. The rest of the team isn’t idle by choice — they’re idle because the only available interface to the organization’s accumulated experience is a single, tired human being typing into a chat window.
How Does This Multiply Incident Length?
Multiply, not add — that’s the part that’s easy to underestimate. A team with the context already distributed might resolve a familiar failure mode in twenty minutes: recognize the pattern, confirm it, apply the known fix. A team dependent on one person’s memory doesn’t just add a delay to that twenty minutes — it replaces “recognize the pattern” with “wait for someone to recognize it on your behalf,” and that wait doesn’t scale down no matter how urgent the incident is. A page at 3 AM waits exactly as long for a reply as a page at 3 PM, except at 3 AM it waits longer, because the one person is now also asleep.
It shows up again in the postmortem, which is where the compounding really bites. The writeup gets filed, the timeline gets documented, and the root cause gets a paragraph — but the specific, hard-won judgment call that actually solved it (“check the batch job overlap before anything else”) usually lives in that same one head, restated verbally in the retro and then not anywhere else. The next time this exact failure mode appears, the team is right back to square one, because the postmortem documented what happened without capturing how the expert actually knew. The tax gets paid again, in full, by whoever’s on call next.
This is also why growing the team doesn’t fix it, and can even make it worse. Every new hire is another person who needs the senior engineer’s context to be useful during an incident, and none of them can get it anywhere except by asking. The bottleneck doesn’t get diluted across a bigger team — it gets busier. More people paging the same one person is not the same thing as more people who can independently resolve the incident.
The pattern is the same one that shows up whenever root cause analysisstretches past the point the fix itself would have taken: the delay isn’t in the fixing, it’s in the finding, and when the only place to find it is a single person’s memory, that person’s availability becomes the incident’s real service-level objective, whether anyone wrote it down that way or not.