What Actually Leaves When a Key Person Leaves

The handover happens in the two weeks nobody knows what to ask

Someone resigns and a clock starts. The company responds the way every company responds. There is a handover document, a shared folder, and a run of transfer meetings squeezed into a notice period that is already half consumed by wrapping up live work.

The whole arrangement rests on two assumptions that fall apart the moment you say them out loud. The first is that the person leaving can sit down and list what only they know. The second is that the colleagues absorbing their work already know which questions matter. Neither group has the information the handover needs.

The questions that actually cost you do not arrive during the notice period. They arrive four months later, when a customer references a promise nobody remembers making, or a renewal comes up and the discount on the contract does not match any pricing anyone recognises, or a vendor gets in touch about a project that was quietly killed for reasons that were only ever discussed on a call.

Engineering can measure this exposure. The rest of the company cannot.

Software teams have a name for the risk and a way to count it. The truck factor is defined as the number of people on a team who have to be hit by a truck, or quit, before the project is in serious trouble. It is a blunt phrase for a specific question: how concentrated is the knowledge.

Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente built an automated way to estimate it and ran it against 133 popular GitHub projects covering more than 373,000 files, 41 million lines of code and over two million commits. Their finding is worth sitting with. Sixty five percent of those systems had a truck factor of two or less. Forty five of them, 34 percent, had a truck factor of exactly one. Another 42, 31 percent, had a truck factor of two.

These are not abandoned side projects. They are among the most starred repositories in six major languages, built by teams with real contributor counts. The paper points at Backbone as an example: 248 developers appear in its history, and six of them account for 67 percent of the commits.

The reason any of this can be measured is mundane. Every change to a file carries a name and a timestamp. Authorship of code is recorded whether anyone intends to record it or not, so the concentration can be computed after the fact by anyone who asks.

Decisions have no commit history

Now ask the same question about the part of the company that does not write code. How many of the last two years of decisions have exactly one person who can explain why they went that way.

Nobody can answer that, because nothing records it. A pricing page shows the price and not the argument. A closed deal shows the terms and not the three concessions that were traded to get there. A shipped feature shows what was built and not the two options that were rejected in a room, for reasons that were good at the time and were never written down.

The exposure is just as real as the truck factor of a codebase. The difference is that you cannot compute it in advance. You discover it after the person is gone, one unanswerable question at a time, over a period long enough that most teams never connect the questions back to the departure that caused them.

The brain dump misses the part you needed

The notice-period knowledge transfer underperforms for a specific reason that has nothing to do with effort. Most people leaving on good terms genuinely try. The problem is that you are asking someone to report on the one variable they have no access to.

Michael Polanyi's work on tacit knowledge is built around the line that we can know more than we can tell. The category he described is knowledge that resists being extracted or articulated, as distinct from knowledge that has been formalised or written down, and is therefore harder to pass on through speech or writing. The part that matters here is a smaller observation that follows from it: people are not often aware of the knowledge they possess or how it can be valuable to others.

That is the mechanism. A person who has held a relationship for three years does not experience their read on that account as knowledge. It feels like ordinary awareness, the same way knowing your way around your own neighbourhood does. Asking them to enumerate it produces a list of processes and passwords, because processes and passwords are the parts they can see from the inside.

What a record can hold, and what it cannot

This is where an honest line has to be drawn, because the temptation is to claim that a good archive solves the problem. It does not, and Polanyi's distinction is exactly the boundary.

What gets said out loud in a meeting is, by definition, the articulated part. That is the portion a record can keep: the reasoning someone gave for a decision, the objection a colleague raised and how it was answered, the constraint that ruled out the obvious option, the commitment made to a customer in the third week of a negotiation. None of that is trivial. It is most of what people go looking for after a departure.

What a record cannot keep is the judgement underneath. The same source notes that transferring tacit knowledge generally requires extensive personal contact, regular interaction and trust, which is a fair description of an apprenticeship and a poor description of a search box. Someone can read every meeting your best salesperson ever ran and still not have their instinct for which objection is real.

So the claim worth making is a modest one. Capture shrinks the loss. It does not prevent it. A team that treats a searchable archive as a substitute for succession planning has misread which half of the problem it solves.

A departure is a slow reveal, not a single day

Companies treat the last day as the event. In practice it is the start of a reveal that runs on an external schedule rather than an internal one.

The questions surface when the outside world asks them. A contract comes up for renewal on its own anniversary. An annual planning cycle reopens a decision from the previous year. A customer who was quiet for two quarters comes back referencing a conversation. A partner asks about an integration that was scoped and shelved.

That timing explains why the standard fix feels adequate and is not. The handover looks complete on the last day because nothing has tested it yet. The real question is how many months the team keeps hitting the same wall, and that number is set long before anyone resigns.

Where the exposure actually sits

You can get a rough version of your own truck factor this week without any tooling, by looking at three things.

Start with recurring meetings that have exactly one attendee from your side. Every standing call where one person is the only one in the room is a relationship with a truck factor of one, and the list is usually longer than expected because those meetings are efficient and nobody wants to double-staff them.

Then look at where questions get routed. If a name is the standing answer to an entire category of question in your team chat, that category has a single owner regardless of what the org chart says. The chat history is a surprisingly honest map of who holds what.

Last, look at the decisions from the past year that a new person would have to take on faith. Not the ones that were documented after the fact, the ones where the reasoning only ever existed in a conversation. Those are the ones that come back as questions later.

The work has to happen before the notice period

Everything above points the same direction. Anything that depends on someone predicting which questions will matter is going to fail, so the version that works has to be routine enough that no prediction is required.

In practice that means capturing the recurring meetings where one person is the sole attendee, rather than only the meetings that feel important. It means writing down the option that was rejected and why, since the rejected option is what a successor will reopen first. It means making the record findable by the people who will inherit the relationship, which is a decision about access rather than about note quality.

The bar here is lower than most documentation efforts aim for and that is the point. Nobody needs a polished internal wiki. The test is whether a colleague can find the meeting six months later and read what was said.

Where Driffle fits

Driffle transcribes your computer's audio directly, so no bot joins the call and no notification goes out to the other side. Nothing auto-joins, auto-records, or runs in the background. Audio is transcribed in real time and discarded, and the text is what gets kept. You can search across past meetings, pull action items and owners out of a call, and ask questions across the archive rather than reading it.

Two limits are worth stating plainly. The first is that none of this recovers a conversation that was never captured. The archive helps to the degree the meetings happened while the person was still there, which is the whole argument for doing it as routine rather than in a notice period.

The second is about access, and it cuts against the easy version of this pitch. Notes are visible only to their author until they are explicitly shared, and workspace admins do not see private notes, only what has been shared into shared folders. A departing person's private notes do not become team memory on their own. If continuity is the goal, the meetings that carry continuity need to be shared while the person is still around. That is a decision a team makes deliberately, and quiet capture removes no obligation to be clear with the people in the room about what is being kept.

One measurement worth taking

After the next departure, keep a log for 90 days of every question that comes up about that person's former work. Write down the question and who ended up answering it.

Then split the list in two. On one side, questions that could have been answered from something somebody said out loud in a meeting. On the other, questions that needed judgement nobody could have written down in advance.

The first pile is a retrieval problem, and it is fixable with capture and search. The second pile is a succession problem, and it tells you exactly where the next person's first month should be spent. Most teams assume the second pile is the big one. It usually is not, and knowing the ratio for your own company is worth more than any generic advice about knowledge management.