What happens when Tom goes on holiday?

Documentation doesn't fail because people are lazy. It fails because it always comes on top of the real work.

The first time it suddenly clicked for me what it costs not to capture knowledge properly, I'd just come back from holiday myself. At that company I was normally the one who wrote the release notes. While I was away, releases had simply kept going out: bug fixes, new features, and so on. But nobody had properly picked up the release notes. Not out of bad will — it just hadn't happened. So on my first day back I got to play archaeologist: working out what had changed, digging the necessary knowledge out of the developers myself, and above all diving back in with an overflowing support inbox while I was already behind.

What happened to me back then happens in almost every growing organisation — only it usually goes the other way round. Somewhere there's always a "Tom" or a "Jan": that one colleague who knows the answer to most questions. As long as that person is around, everything runs. The moment they're away for two weeks, you suddenly notice that things are piling up. A quote can't go out, a customer can't get a watertight answer to their questions. A junior builds something that's technically correct but isn't actually right, and has to undo it again a week later.

There was also once a company where the lead developer had built himself in — without ever really consciously deciding to — as the final check before a release. Nothing went live without his sign-off. When he headed off into the Ardennes for two weeks, it wasn't just the new features that ground to a halt, but also the bug fixes for customers who were already complaining. Nobody had meant it that way; it had simply grown like that.

The classic reflex at that point is always the same. "We really should document that." We then ask that one colleague, when they get back, to write down how they do it, or where their team could have found the answers. Someone sets up a Notion, or starts using Confluence, or maybe a shared folder gets created where we agree to gather the knowledge from now on. The first week it works. The fourth week too, sort of. By the sixth week it's stalled again. That's not because the team is lazy, but because documenting always comes on top of the real workload. You have to find the time for it somewhere in your overflowing schedule. There's always a release that has to go out the door, a customer on the phone, a bug that can't wait. Documenting isn't only a matter of discipline, but also of priorities.

Time for a change

The way you really change this is by turning the starting point around. The best moments to capture knowledge aren't the ones where someone sits down separately to document. You usually don't have time for that anyway. The best moments are the ordinary working moments themselves. The knowledge is already there — it just needs to be caught at the right moment.

That was the starting point for Sarrai. Because I've noticed time and again in the past that you can't ask your engineers to just write two paragraphs about a new feature. It rarely worked, whether I asked over email or over Teams. But if I simply stood next to someone and said "just tell me how this works exactly", I'd get five minutes of clear explanation. Not because they suddenly had less on their plate, but because the threshold to start writing something is far higher than we like to admit.

At Sarrai we try to solve that problem. The system doesn't just hand you a blank page and a blinking cursor, but a question to answer. The writing itself — that's done for you by the AI. You can still do the final edit, and you decide what goes live.

That way Tom can keep going on holiday, and his knowledge still stays nicely with us.