Your Best Engineer Gave Notice. Where's the Knowledge Transfer Plan?

Maya runs payroll. She's also, and nobody quite planned it this way, the only person who knows the workaround for the vendor whose system breaks every March, the name of the contact at the bank who actually picks up the phone, and why the year-end export has to run before 6 a.m. or it quietly times out. None of it is written down. It's all in Maya's head. And on Tuesday, Maya gave two weeks' notice.

Now the clock is running, and her manager is realizing how much of the team's work was actually just Maya.

This is the exact moment a knowledge transfer plan is supposed to prevent, and the exact moment most teams find out they don't have one. The plan itself is nothing fancy: it's a written approach to moving what one person knows into a form other people can use, before that person is gone. Done well, it turns a panic handover into a calm one. Done badly, or not at all, you're reconstructing a process from bank statements in April. Here's how to build the kind that holds up.

Why most knowledge transfer fails

It's rarely because nobody tried. It's because the attempt was shaped wrong from the start.

It starts the day someone resigns. Two weeks of notice against ten years of accumulated context. That's a losing trade. By the time the plan kicks off, the person is also wrapping up live work, training a replacement who might not even exist yet, and mentally halfway out the door. The richest knowledge is the first thing to go.

It captures the easy stuff and misses the hard stuff. Asking someone to "write up what you do" gets you a list of the obvious tasks they could have explained in five minutes anyway. The valuable knowledge is the part they don't think to mention because, to them, it's just how things work. That's the part that leaves with them.

It produces a doc dump nobody can use. Forty pages written in a rush, with no order and no owner, isn't knowledge transfer. It's a pile. The receiver opens it, can't tell what actually matters, and ends up reverse-engineering the job anyway.

There's no one on the receiving end. Knowledge has to land somewhere. If you collect everything Maya knows but haven't named the person who now owns payroll, you've made a museum, not a handover.

What to capture: explicit vs tacit

Before you plan anything, it helps to see what you're actually trying to move. Knowledge splits into two kinds, and they need completely different handling.

Explicit knowledge is anything already documented or trivial to document. The SOP for running payroll. Where the files live. Who has which login. You move it by copying it somewhere findable and pointing the receiver at it. Important, but not where things go wrong.

Tacit knowledge is the judgment, the shortcuts, the context that never made it into a doc, because the person doing the work stopped noticing it years ago. It's knowing the March vendor outage isn't an emergency, because it happens every single year. It's knowing which "urgent" requests are actually urgent. This is the stuff that's expensive to lose and slow to capture, so your plan should spend most of its effort dragging it into the open. And the fastest way to surface it? Watch the person work, and ask "wait, why did you do that?" at every step that looked automatic.

How to build the plan, step by step

Five moves. The order matters more than the polish.

1. Inventory what they own

List every recurring task, every system, and every relationship the person is responsible for. Don't filter yet. The goal is a complete map, including the small stuff, because "small" tasks are often the ones with no backup. Sit with the person for this. A list they write alone always misses the things they've stopped seeing.

2. Rank each item by risk

For every item, ask one question: if this knowledge vanished tomorrow, what breaks, and how badly? A weekly report that's easy to rebuild is low risk. A compliance filing only they know how to submit is high risk. Sort the list so the high-damage items sit at the top. You almost certainly won't get to everything in the time you have, so make sure the things you do lose are the cheap ones, not the load-bearing ones.

3. Pick a transfer method for each item

Not everything deserves the same treatment. Low-risk, simple items get a short written note. Anything done in software, or done often, is worth recording as a step-by-step guide so the receiver can follow along exactly. The highest-risk, most-judgment-heavy items need live shadowing, because some things only surface when a real case comes in.

This is where capture either happens or quietly doesn't. Writing a guide by hand (grabbing screenshots, cropping them, redoing the one that came out blurry) is tedious enough that busy people just skip it, and the knowledge stays stuck in someone's head. A tool like WriteHow helps here: the person records themselves doing the task once, and it drafts an ordered, step-by-step guide with screenshots and annotations already in place, which someone then reviews and approves. And if the receiver speaks a different language than the person leaving, it can produce that guide in 50+ languages, so the handover isn't gated on who happens to share a first language. The point isn't magic. It's making capture cheap enough that it actually gets done while you still have the person in the building.

4. Put it on a calendar

An unscheduled plan is a wish. Map the items across the time you have, front-loading the high-risk ones. A realistic shape for a two-week window looks like this.

5. Reverse-shadow, then sign off

Reading a guide is not the same as doing the job. Not even close. So before the last day, flip the roles: the receiver does the real task while the person leaving watches and stays quiet, unless something's about to break. Every hesitation is a hole in the documentation, and you can still patch it while the expert is sitting right there. When the receiver can run the high-risk items alone, that's your sign-off. Not when the docs exist, but when someone has actually done the work.

A copy-paste knowledge transfer plan template

One row per item the person owns. Keep it in a shared sheet or wiki so the receiver and manager can both see progress. Fill the brackets and delete what you don't need.

Notice what does the heavy lifting: the risk column and the status column. The first tells you what to do first. The second stops the plan from looking finished when it's only half done.

The handover checklist (and not waiting for notice)

Plans drift. A short checklist keeps the last stretch honest. Run through this before you call a transfer complete.

That last line matters. You will not transfer everything, and pretending otherwise is how teams get surprised. Naming the gaps turns "we have no idea how this works" into "we know this one's thin, and Priya's picking it up next month."

The real fix, though, isn't a better two-week sprint. It's not needing one. The teams that handle departures calmly are the ones capturing knowledge while people are still doing the work, not when they're heading for the exit. Make recording a guide part of how a task gets done the first time, keep an internal wiki people actually trust, and treat tribal knowledge as something you surface every quarter, not something you chase on someone's way out. A knowledge transfer plan you can run in a single afternoon, because the documentation already exists, is the whole goal.

Maya's two weeks are going to be tight. No way around that. But if her team had been capturing as they went, those two weeks would be a review, not a rescue, and that's the difference worth building toward.