The Only Person Who Understands the Billing System Is Off Sick: A Survival Guide for the One-Man Knowledge Trap

Every town in Britain has one. The software firm where the entire billing system lives in one person's head. He's been there since the migration nobody talks about in 2019. He knows why the VAT logic has that weird exception for the Channel Islands. He knows the staging credentials. He knows which cron job you must never, under any circumstances, restart on a Tuesday.

And then, one ordinary Wednesday, he hands in his notice.

We've all heard the horror stories. What's less discussed is that the fix isn't a heroic documentation push — because we all know how those end. It's a slower, less glamorous set of habits that any team of two or more can start this week.

The Documentation Sprint That Never Happens

Ask any engineering lead about knowledge transfer and they'll say the same thing: "We know, we know, we need to document it." Then ask to see the documentation and you'll get a sheepish look.

The problem isn't laziness. It's that documentation framed as a project competes with delivery, and delivery always wins — especially in an SME where the person with the knowledge is also the person billing the hours. A two-week "documentation sprint" is a fantasy in a company where the one knowledgeable person is also the only one who can keep the system alive while writing about it.

The teams who survive resignations don't document more. They document differently — little and often, attached to the work itself.

What Actually Happened When He Left

We spoke to three UK teams who went through it. The patterns were remarkably similar.

A fintech outfit in Leeds lost their sole backend contractor with four weeks' notice. "We thought four weeks was loads," their CTO told us. "It took us eleven months to fully understand the reconciliation logic. We were reverse-engineering it from the bank statements."

An e-commerce agency in Bristol had it worse: their platform contractor went off sick with no notice at all. Nobody knew the deploy process. Nobody knew the infrastructure was a single VPS in Frankfurt that hadn't been backed up properly since 2022. They got lucky — he recovered, and spent a painful fortnight writing everything down from his hospital wifi.

The common thread? In both cases, the knowledge wasn't written down because it was never asked for while the person was around. Everyone assumed there'd be time later.

Pairing Rotas: The Boring Answer That Works

The most effective thing we saw wasn't documentation at all. It was a rota.

One team in Manchester instituted what they called "Thursdays with Dave" — every Thursday afternoon, the contractor paired with a different team member on whatever he was working on. No agenda, no deliverable, just a second pair of eyes on the gnarly bits.

Within six months, every developer had touched the billing code at least once. When Dave eventually moved on, the transition was genuinely uneventful. "It was almost boring," the engineering manager said. "That's how we knew it had worked."

The rota matters more than the pairing. If it's voluntary, the same confident person always volunteers and the shy ones never do. Rotate it. Put it in the calendar. Make it slightly annoying to skip.

Write the Doc You'd Need at 3am

For the documentation that does get written, there's a useful filter: don't write what the system does — write what the next person will desperately need at 3am when it's broken.

That means:

• How to deploy, from a clean laptop. Not "see the wiki" — actual steps, tested by someone who isn't you.
• Which things are load-bearing and scary. The cron job you can't restart. The table nobody's allowed to ALTER.
• Where the credentials live and who can rotate them.
• The decisions that look wrong but aren't. The weird VAT exception. The hardcoded IP. Every "why is it like this?" answer, captured before the person who knows leaves the building.

A plain markdown file in the repo beats a beautiful Confluence space nobody maintains. Keep it next to the code, review it in PRs, and it'll stay roughly current.

Bus Factor Is a Habit, Not a Number

There's a temptation to treat bus factor as a metric to fix once — run the audit, write the docs, tick the box. But knowledge re-concentrates. The contractor who fixed the outage becomes the person who understands the outage. Six months later you're back where you started.

The sustainable version is small and continuous: rotate who reviews the scary code. Rotate who's on call for each system. Rotate who runs the deploys. None of this needs a policy document — it needs someone senior to occasionally say "you do it this time, talk me through it afterwards."

Start Before the Notice Period

If you're reading this with a nagging feeling about one specific person at your company — that's your sign. Don't wait for the resignation email. Book a pairing session this week. Ask them to walk you through the one bit of the system that frightens you most.

Worst case, they think it's a bit odd. Best case, you're the team in Manchester with a boring, uneventful handover instead of eleven months of reverse-engineering bank statements.

The bus factor of one isn't a character flaw in your contractor. It's an organisational habit you haven't built yet — and habits are cheaper to build now than to need in a hurry later.