Bus Factor of One: the Person Who Can Never Take a Holiday

Bus factor is normally raised as a disaster scenario, which is why nothing gets done about it. Disasters are hypothetical and this quarter's roadmap is not. The version worth acting on is much more mundane and happens every year: one person's holiday costs the team a fortnight of momentum.

"If she's off, we stop."

The ordinary cost, not the catastrophe

Ask the diagnostic question in its useful form. Not "what if she leaves", which invites a shrug, but "what happened the last time she took two weeks off". People remember that vividly, because it was recent and it was painful.

The answer is usually some combination of: three decisions waited, two pieces of work were paused, somebody messaged her twice while she was away, and one thing was done twice because nobody knew it had already been tried. That is a concrete cost with a date on it, and it is the same cost you would pay if she left, just bounded.

How a bus factor of one forms

Nobody decides to concentrate knowledge in one person. It accumulates through a sequence of sensible choices: she built the original system, so she is fastest at changes to it, so changes get routed to her, so she stays fastest. Each step is efficient in isolation and the aggregate is a dependency.

Two forces make it worse over time. Speed: giving the work to the person who will finish it in two hours rather than the person who will take two days is correct under deadline and wrong over a year. And helpfulness: she answers questions well, so she is asked, which deepens her context and reinforces her position as the route.

What they actually know

This is where documentation projects go wrong. Asked to write down what she knows, the natural output is a description of the system, which is the least valuable part, since much of it is inferable from the code.

What she knows	Value to the team	Captured by a wiki?
How the system is structured	Moderate, mostly in the code	Yes, and it goes stale
Why past decisions went the way they did	High, and unrecoverable if lost	Rarely, because nobody writes it
Where things currently stand	High, and the most asked-about	No, it changes daily
What has already been tried and failed	High, prevents repeated work	Almost never

Three of the four high-value rows are things a static document handles badly. Two are perishable and one is historical reasoning nobody thinks to record. That is why a documentation sprint aimed at a bus factor produces a lot of pages and changes nothing, a pattern covered in tribal knowledge without a documentation project.

What to do about it

Two interventions, and they are complementary rather than alternatives.

Route work away from her deliberately. Give the next three changes in her area to someone else, with her reviewing rather than implementing. It costs velocity for a quarter and it is the only thing that transfers judgement. Nothing else does.

Make the perishable knowledge answerable while she is off. This is what StandIn handles. Ninety seconds at the end of each day, mostly pre-drafted from the work she already did: current state, open questions, blockers, next actions, decisions made and why. While she is off, her StandIn answers questions from that brief in her words, with a source under every answer, clearly labelled, and never guessing. When the answer is not there, it says so and names who to ask.

So when she is off, her StandIn is on. The team is not blocked on the three rows of the table that a wiki cannot hold, which is most of what they were actually asking her for. See retire your out-of-office.

What this costs the person

Worth saying plainly, because bus factor is usually framed entirely as a company risk. The person in this position cannot take a real holiday, gets messaged when they do, carries a background anxiety that things are accumulating, and is often passed over for roles that would require them to leave the area they have become indispensable in.

They also usually cannot fix it themselves. Refusing work to reduce their own bus factor reads as being unhelpful, and the reward system does not recognise it. This is a manager's problem to solve, and the person's own discomfort with it is a signal rather than a complaint.

Common Questions

How do you fix a bus factor of one?

Route work to a second person with the first reviewing, and make the perishable knowledge answerable while they are away. Documentation alone does not fix it, because most of what the team asks for is current state and past reasoning rather than structure.

What is a healthy bus factor?

Two or three people per critical area, and for a distributed team they should not all be in one time zone. Two people in the same zone is still a single point of failure for most of the day.

Should we stop giving work to our fastest person?

For some work, yes, deliberately and temporarily. Giving every change in an area to the person who is quickest at it is right this sprint and wrong this year. Treat the slower option as an investment with a known cost.

How do we test whether we fixed it?

Have the person take a week off and count how many times the team was blocked on them. It is the only honest test, and it is much cheaper to run deliberately than to discover accidentally.