Testing Your Bus Factor: The Muted Expert Exercise

Adopting transfer practices proves nothing until you've verified they work. Here's how to measure your bus factor, with a simple, risk-free exercise: the muted expert.

Throughout this series, we’ve seen how to pass knowledge on: in real time, in writing, through organization. One question remains, and it’s the one we carefully avoid: does it actually work? You believe a team is robust because it documents and pairs — until the day a departure reveals the gaps. This article suggests not waiting for that day, and measuring your vulnerability while there’s still time.

I. What is the bus factor?  

The bus factor answers a blunt question: how many people would have to disappear for a project to grind to a halt? The name comes from a deliberately crude image — how many team members could be hit by a bus before the work becomes impossible.

A bus factor of 1 means a single person holds critical knowledge: their departure alone is enough to block the project. The higher the number, the more the knowledge is spread, the more resilient the team.

The value of this indicator isn’t its precision — you rarely compute it to the exact figure — but what it forces you to look at: the points where knowledge concentrates, the ones no one talks about because “it works.”

II. Why you never see it coming  

The bus-factor risk has a formidable property: it’s invisible as long as the expert is there. The system works, questions find answers, incidents get resolved. Nothing raises the alarm, because the person absorbing the risk makes it imperceptible.

It’s a classic blind spot: confusing “it works” with “it’s robust.” A system that holds together only thanks to one person works perfectly… until the second that person is gone. The risk only shows up at the worst possible moment — the departure — when it’s too late to fix it.

Hence the need to trigger it deliberately, in a safe setting, rather than suffer it.

III. The muted expert exercise  

The most honest test is also the simplest. It’s called the muted expert (silent expert): the expert stays present, but stays quiet, while the rest of the team tackles a real problem from their domain.

The format:

1. You pick a realistic task or incident in the expert’s domain.
2. The expert is in the room (or on the call), but doesn’t intervene: no answers, no guidance, no touching the keyboard.
3. The team solves the problem with its own resources: what it knows, and what’s documented.
4. The expert observes and notes every place where the team gets stuck, searches, or goes down the wrong path.

The gaps appear within minutes. Every hesitation, every “only So-and-so knows that” is a knowledge leak pinpointed precisely — and with no risk at all, since the expert is there as a safety net if the situation truly goes off the rails.

The absolute rule: the expert does not take back control. This is the decisive moment of the exercise. The natural reflex — “let me just do it” — cancels everything: you save ten minutes and lose the diagnosis. The expert’s silence is precisely what makes the test valid.

IV. Reading the results  

At the end of the exercise, the expert’s list of blockers is a map of the knowledge debt. Each point is one of two natures — and the remedy differs (this is the whole logic of this series’ guide):

• A blocker on explicit knowledge — an unfindable procedure, an unknown config value, a forgotten reason behind a decision. Asynchronous remedy: a runbook, an ADR, docs glued to the code.
• A blocker on tacit knowledge — a missing diagnostic reflex, a missing mental map of the system. Synchronous remedy: pairing, shadowing, a game day.

So the exercise doesn’t just reveal the problem: it points to the right transfer practice. It’s a diagnosis that comes with its prescription.

V. The other signals to watch  

The muted expert is a one-off test. Day to day, several signals betray a fragile bus factor, without you having to organize anything:

• “We don’t touch that.” A module no one dares modify is a module whose knowledge has already left.
• A single systematic reviewer on a domain: the bottleneck is also the breaking point.
• The concentration of contributions. If the repository history shows a single person has touched a component for years, the bus factor there is 1.
• Panic during incidents. When an outage triggers “we need to call So-and-so” rather than a procedure, the knowledge isn’t shared.
• Time off that causes anxiety. If one person’s absence makes you postpone subjects, they’re a single point of passage.

These signals are free: they’re already in front of you, in the version control tool and in the team’s habits.

VI. Making it a habit  

A one-off test gives you a snapshot; it’s repetition that gives you a trajectory. The value of the muted expert grows when you make it a light, regular ritual — once a quarter, on a different domain each time.

Repeated, the exercise also changes the team’s culture. It normalizes the idea that depending on a single person is a team problem, not an individual quality. It values the person who documents and transfers as much as the one who “saves the day” — an essential reversal, because as long as solitary heroism is rewarded more than sharing, the bus factor will stay low.

And it gives you a concrete indicator to track over time: does the number of blockers decrease from one quarter to the next? That’s the proof, in numbers, that the transfer is working.

Conclusion  

Adopting transfer practices without ever testing them is believing you’re insured without having read the contract. The muted expert exercise clears the doubt in a few hours, with no risk: it reveals exactly where knowledge concentrates, and which practice to turn to in order to fix it.

The real test of a team’s robustness isn’t in what its best person knows, but in what would survive their departure. Mute the expert for a morning, and you’ll finally know the answer — while they’re still there to help you correct it.

Useful links  

• Bus factor (Wikipedia)
  Definition, origin, and limits of the bus factor as an indicator of knowledge concentration in a team.

• Chesterton’s Fence — the principle explained
  Why you shouldn’t tear anything down without understanding why it exists: the foundation of the value of a documented why.

• Google SRE Workbook — On-Call
  Concrete approaches for spreading operational knowledge and reducing dependence on a single person.