The documentation debt nobody notices until someone important leaves

The billing sync only ever worked because one person knew which script to restart on the first Monday of every month, nobody else really knew. It wasn't written down anywhere, it had run quietly for four years, so nobody thought to ask.

Then that person handed in their notice...

I've watched versions of this story play out for decades, from banking infrastructure in the 1980s to scale ups today. The systems change, the moment of panic doesn't.

The system that lived in one person's head

Teams build workflows, connections between platforms, approval chains and data flows at pace. They ship, they celebrate, they move on to the next thing. Somewhere along the way, the reasoning behind those decisions stays with whoever made them.

While the team is stable, this costs nothing you can see. Questions get answered in a quick message, the person who knows gets asked and the work carries on. That is exactly why the risk stays hidden, it only shows up when the person is on leave, changes role or walks out the door.

What actually walks out with them

It isn't only the code or the configuration. Those can usually be read, given time. What leaves is everything around them, why a workaround exists, which system quietly depends on which other system, what the approval process really looks like, as opposed to what the process diagram says, what breaks if you change a field name.

Rebuilding that knowledge is slow and expensive. Teams reverse engineer their own platforms, guess at intent and take cautious steps around things nobody dares touch. Operations slow down. Risk goes up. Decisions get made on assumptions rather than facts.

Why does documentation always get pushed to later?

Because later feels free. Delivery pressure is immediate and visible, documentation is quiet and its benefits are invisible until the day they matter. So it slips down the list, sprint after sprint.

Here is the myth worth challenging: documentation slows delivery, and you can always write it up afterwards.

In practice, afterwards rarely comes. When it does, the documentation is incomplete, because the detail has already faded. It is often out of date before anyone reads it. And sometimes it never gets written at all.

The most resilient organisations I work with treat documentation as part of delivery itself. A feature isn't finished until someone else could pick it up and understand it.

What good documentation actually changes

I see three practical benefits, and they compound as a business grows. First, it reduces dependency on key individuals, when processes, systems and decisions are visible and accessible, no single person becomes a bottleneck or a single point of failure. Holidays stop being a risk. Promotions stop being a problem.

Second, it makes operations more consistent. Well documented workflows mean people do things the same way, which supports compliance and makes quality easier to hold as headcount rises. What works for a team of fifteen tends to fall apart at seventy five unless it is written down.

Third, it costs far less than the alternative. Keeping documentation current takes a small, steady amount of effort. Rebuilding lost knowledge after someone leaves takes weeks or months of slow, expensive work, plus the risk you carry while you do it. The maths isn't close.

The bonus nobody budgets for
Documentation also shortens onboarding. New engineers get productive faster when they can read how things work rather than interrupt colleagues to find out. Troubleshooting speeds up too. When something breaks at 4pm on a Friday, the answer is written down rather than waiting on whoever happens to be online.

And when investors or acquirers start asking how your technology really works, you have an answer that doesn't begin with "you'd need to speak to Sam."

Let's wrap this up

Undocumented systems work fine right up until they don't. The moment they stop working is nearly always the moment someone important leaves. Documentation isn't an administrative chore, it is a strategic asset that protects your business from knowledge loss and keeps operations moving when people change. Treat it as part of delivery, not a job for later.

So here is the question to take away.

Pick the systems and processes your business depends on most. Then ask yourself: if the person who understands them best left tomorrow, would the documentation be enough for someone else to take over with confidence?

If the honest answer is no, you have documentation debt. Start with the single most critical system this week. Write down what it does, what it depends on and who decides what. Then make it part of how you deliver from here on. If you're weighing up where your biggest gaps sit, I'd be glad to talk it through.