MindKeepr
September 24, 2026 · 8 min read

What a handover misses when someone leaves

Faizan Khan
By Faizan Khan, Co-founder & COO, MindKeepr
An empty desk by a window in late afternoon light, with an open notebook and a cold cup of coffee
TL;DR

Offboarding checklists are built around assets: the laptop, the accounts, the files, the open tickets. What walks out of the building is the reasoning: why a supplier is handled differently, the threshold that decides an exception, the workaround that quietly prevents an outage. Six months later the team reopens a decision that was already made and paid for. The fix is to start from decisions rather than documents, and to record who else can confirm each one.

What the checklist is good at

Most offboarding checklists are competent at what they were designed for. The laptop comes back, the accounts are closed, the building card is returned, open tickets are reassigned, and somebody writes a handover document in the final week.

All of that is necessary. None of it captures the part that makes the person hard to replace.

Ask MindKeepr about what a handover misses when someone leaves
A live taste of the product, on this page
Pick a question to see how MindKeepr answers.

What actually leaves

Ask anyone who has inherited a complex role what they wished they had been told, and the answers are strikingly consistent. Not where the files are. Why the process bends for one client. What the number in the policy really means in practice. Which alarm everybody ignores, and the one time it must not be ignored.

These are criteria and exceptions, and they live in the reasoning behind decisions rather than in their outcomes. A handover document written in the last fortnight, under time pressure, by somebody who is already mentally elsewhere, is not going to contain them.

The person is not withholding anything. They cannot write down what they have stopped noticing they know.

See it on your own knowledge

MindKeepr captures what your team knows and keeps it usable, even after people leave.

The bill arrives later

The cost of this rarely shows up in the month somebody leaves. It shows up two quarters later, when a new person asks a reasonable question about why something is done a certain way, and nobody in the room can answer it.

What follows is a rerun. The team reopens a decision the organisation already made, paid for and settled, not because the original answer was wrong but because the case for it left with its author. Sometimes the rerun lands in the same place. Sometimes it quietly reverses something that was right.

I have started to think of this as interest. When the reasoning behind a decision cannot be confirmed by anyone still in the building, every innocent question can trigger the full debate again.

A desk lamp lit over an empty desk at dusk, the rest of the room in shadow

Start from decisions, not documents

There is a version of this exercise that takes an afternoon and needs no software. Pick one role you could not lose next month. List the decisions that role makes, not the documents it produces. For each decision, write the names of the people who could confirm that the reasoning still holds.

Where that list has one name, you have a dependency. Where it has none, you have an exposure, and now it is written down instead of being a feeling you have on a Sunday evening.

Most leaders can do the first part in seconds and find the second part uncomfortable. That discomfort is the actual finding.

Absence costs the same as departure

The reason to do this before anyone resigns is that departure is only the extreme case. The same gap appears when the person is on leave, in another timezone, in a workshop all day, or simply busy.

Work either waits or somebody guesses, and the second one is more expensive than it looks, because a guess made under time pressure becomes precedent. Nobody records that it was a guess.

What to do with what you find

Writing the list is most of the value. Keeping it current is where a system earns its place: routing each open question to the named person, keeping what they write as a candidate until somebody with the authority approves it, and binding that approval to the exact version, so a later change reopens the review instead of inheriting a tick.

The practical test of whether it worked is simple. If the person who is leaving went on holiday tomorrow, could the work continue without them? If the honest answer is no, the handover is not finished, however complete the checklist looks.

Key takeaways
  • ✓A handover that lists artifacts will miss the criteria behind decisions.
  • ✓The cost appears months later, as a settled decision being relitigated.
  • ✓Start from the decisions a role owns, not from the documents it produced.
  • ✓Any decision with exactly one person who can confirm it is a dependency you are carrying.
  • ✓Absence is as expensive as departure: the same gap appears when someone is on leave.

FAQ

When should a knowledge handover start?

Before there is a resignation. Once notice is given, the reasoning is reconstructed from memory under time pressure, which is exactly the condition in which criteria and exceptions get missed.

What should a handover capture that a checklist does not?

The decisions the role owns, the criteria behind them, the exceptions, and the name of somebody else who can confirm each one still holds.

How do I find the single points of knowledge?

List the decisions a critical role makes, then write who else could confirm each one. Any row with one name, or none, is a dependency you are already carrying.

Does this apply to people who are simply away?

Yes, and that is the more common case. Absence produces the same stall as departure, and guesses made under time pressure quietly become precedent.

What does MindKeepr do here?

It keeps the open questions visible, routes each to a named person with a deadline, and keeps their answer as a candidate until somebody with the authority approves it, bound to that exact version.

Keep what your company knows

Start free in minutes, or get a demo on your own tools and team.

Start freeBook a demo
Faizan Khan, Co-founder & COO, MindKeepr
Written by
Faizan Khan
Co-founder & COO, MindKeepr

Faizan Khan is the co-founder and COO of MindKeepr, the operating memory for governed AI. He has twelve-plus years across enterprise IT and digital marketing and is also the founder and CEO of Cubitrek. At MindKeepr he leads growth, go-to-market, and customer experience.

Stay in the loop
Get the knowledge-retention brief

Practical takes on offboarding, institutional knowledge, and enterprise AI. Once or twice a month. No spam.

By subscribing you agree to receive emails from MindKeepr. Unsubscribe anytime.

Keep reading
Employee offboarding knowledge transfer checklistPreventing knowledge loss when employees leaveHow to capture tacit knowledge