There's a specific kind of dread that hits when you're mid-incident and you realize the one person who actually understands this service is on a plane to Lisbon. Not because the documentation is missing — there's plenty of documentation. But because the documentation was written by that person, for that person, and it assumes a mental model that only exists in their head.
This is the tribal knowledge problem, and it's more dangerous than most teams admit. Not because knowledge concentration is new — it's as old as engineering itself — but because the operational patterns that were supposed to solve it have quietly made it worse.
The Runbook Isn't the Problem. The Expert Who Wrote It Is.
Teams invest heavily in runbooks, wikis, and internal documentation as the antidote to knowledge silos. The instinct is right. The execution usually isn't.
The failure mode is subtle: documentation written by experts tends to document what the expert finds interesting or non-obvious, not what a responder at 3am actually needs. The expert already knows which metrics matter during a cache saturation event. They know which dashboard to ignore because it's always noisy on Tuesdays. They know that the "restart the service" step in the runbook only works if you drain connections first, and that detail just never made it into the doc because it seemed obvious.
What gets written down is the skeleton. What stays in someone's head is the connective tissue.
The result is documentation that looks complete and fails in practice — which, as I've argued before, is worse than no documentation at all. A blank runbook tells you to find a human. A wrong runbook tells you you're fine when you're not.
Redundancy in Systems, Not in People
The SRE discipline has a well-developed vocabulary for single points of failure in systems: eliminate them, add redundancy, design for graceful degradation. The same rigor rarely gets applied to the humans running those systems.
A service with one engineer who truly understands it is running with no redundancy on the most critical component of its incident response. When that engineer is unavailable — vacation, illness, attrition, a bad timezone overlap — the blast radius of any incident expands immediately. Not because the system changed, but because the team's ability to reason about it did.
The uncomfortable truth is that many teams treat this as an acceptable risk because the expert is usually available. Until they aren't. And the first time they aren't is rarely a quiet Tuesday afternoon.
The fix isn't documentation sprints or knowledge transfer sessions, though those help at the margins. The real fix is structured exposure: rotating oncall ownership across services, requiring that engineers outside the core team lead incident response on services they don't own, and treating "I had to ask the expert" as a signal worth tracking. Every time someone escalates to the tribal knowledge holder, that's a data point about where the redundancy gap lives.
What "Bus Factor" Actually Measures
The bus factor — how many people need to be hit by a bus before a project is in serious trouble — gets treated as a cute thought experiment. It should be treated as an operational metric.
For any service your team runs, you should be able to answer: who can independently diagnose and mitigate a P1 on this service at 2am, without calling anyone? If the honest answer is one person, or two people who work the same shift in the same timezone, you have a reliability problem that no amount of monitoring will fix.
This matters especially during growth phases, when teams are moving fast and the person who built the service is also the person running it. The knowledge concentration that feels efficient in a small team becomes a structural liability as the system scales and the team grows around it. By the time the problem is obvious, the expert has often moved on to the next thing, and the window for organic knowledge transfer has closed.
The teams that handle this well tend to share one habit: they treat incident response as a teaching surface, not just a recovery mechanism. When the expert is available, they're in the incident channel — but they're not driving. They're watching someone else drive, asking questions, letting the less-experienced responder make the next move. The incident takes slightly longer to resolve. The team gets slightly more capable. Over time, that trade compounds.
The Metric Worth Adding to Your Next Retrospective
Before your next sprint planning or quarterly review, pull one number: for each of your critical services, how many engineers on your team have led at least one incident response in the last 90 days? Not participated — led. Owned the timeline, made the calls, wrote the postmortem.
If that number is one, you're not running a reliable service. You're running a reliable expert, and hoping they stay.
The goal isn't to make everyone equally expert in everything — that's not realistic and probably not even desirable. The goal is to ensure that when your best person is unreachable, the system degrades gracefully. Same as you'd design any other component.