Your best expert left in March. You feel it in September.

Anna gave notice in March. Four years ago, she built your integration layer. She knew which customer had a special setup, and why. When a strange bug showed up, she was the one who said "check the retry queue first".

You did everything right. You planned handover meetings. She wrote down the deploy steps. She recorded a video of the release process. On her last Friday there was cake, and everyone signed the card.

Everything looked fine. But you do not feel a departure on the first day without that person. The cost builds up slowly.

What really left with her

Martin Robillard interviewed 27 developers and managers at three software companies. He asked what happened after a colleague left. People did not talk about lost procedures. They talked about lost reasons.

Nobody missed the steps, because those were written down. People missed the answer to "why is this here?". Why one customer had a different setup. Why the team said no to an idea two years ago. Which warning was safe to ignore. Anna knew all of this. She never wrote it down, because nobody ever asked her a question that made her say it out loud.

The people in the study explain what they do now. They dig through old work. They ask around until they find someone who was in the meeting. They puzzle the reasoning back together. It works, but it is slow. Your team probably does this today. It shows up in no report, because it looks exactly like normal work.

The damage comes slowly, so nobody links it to the departure

Two studies show what this costs. Audris Mockus found that when people had recently left a team, the chance of a bug that a customer reports later went up. In his model, when twice as many people left as normal, that chance went up by 26 percent. New people joining had almost no effect. The leaving is what costs you.

Mathieu Nassif and Martin Robillard then looked at how long this lasts. In eight projects, they marked the work whose authors had all left. In every project, at least a quarter of that work was still untouched two years later. In five of the eight projects, it was more than half.

These are large projects, so do not copy the numbers to your team of twenty. Copy the lesson: knowledge that leaves does not grow back on its own. It waits in the corners that nobody wants to touch.

In September, a customer reported a problem in the integration layer. The fix took four days. Normally it would have taken half a day. Nobody wrote "Anna left in March" in the ticket.

Your second best person becomes the new bottleneck

There is a second effect, and it comes faster than the first.

After Anna left, the hard cases went to Tom. He was the next best person, so on the day itself, this was the fastest route. Every time it happened, Tom learned a bit more. The rest of the team learned nothing. Six months later, he was the only one who knew the integration layer. His days were full of questions, and the work you hired him for was left waiting.

Now you have the same risk as before, in one person. And that person is tired. This is how one departure becomes two.

A handover cannot fix this

A handover captures what a person can remember when you ask. That is a small part of what they know.

The rest only comes out when a real question triggers it. Anna never thought "I should write down how the retry queue works". She thought about it at the moment a colleague showed her a stack trace. Four weeks of handover meetings cannot replace three years of real questions.

So do the handover, and do it well. Start in the first week after the notice. We wrote a separate article about how to capture knowledge before a key employee leaves. But see it as damage control. The knowledge you keep is the knowledge you already wrote down while she was still working normally.

How Sarrai handles this

Sarrai answers questions from your own documentation, and it shows the source. When it is not sure, it does not guess. It sends the question to the person who knows.

That person answers once, the way they always did. Then Sarrai asks one thing: should this become an article? One click, and the next colleague with the same question gets the answer right away. Your expert gives each answer one time, and the whole team can find it after that.

So your knowledge base grows on normal workdays, question by question, while your expert is still there. There is no panic and no rushed notice period. You can see how we set this up on our page about better knowledge management. For a software company, this matters most in the technical corners of your product. We describe that case in Sarrai for software companies.

What you can do on Monday

Do not start a big documentation round. The knowledge that matters is the knowledge nobody thinks to ask about. A documentation round has the same blind spot as a handover.

Start by measuring your risk. Take your team list and go through it, one person at a time. For each name, ask one question: if this person left tomorrow, what would become slower, and what would stop completely? Write the answer next to the name. Also do this for the people you do not see as experts. The answer there is sometimes a surprise.

You end up with a short list of names where the answer feels uncomfortable. That list is your risk. If one name carries too much, or several do, you need a way to keep knowledge that does not depend on someone remembering to write it down. That is what a knowledge management system is for. An automated one does the part that people never get around to.

The bill for a departure arrives late. The work that lowers it can only be done now.