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

Maya runs payroll. She also happens to be 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 the reason the year-end export has to run before 6 a.m. or it quietly times out. None of that is written down anywhere. It lives in Maya's head. 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 moment a knowledge transfer plan is supposed to prevent, and the moment most teams discover they don't have one. A knowledge transfer plan is simply a written plan for 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, it leaves you 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 is a losing trade. By the time the plan kicks off, the person is also wrapping up live work, training a replacement who may not exist yet, and mentally halfway out the door. The richest knowledge is the first casualty.

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. A folder of 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 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, and the context that never made it into a doc because the person doing the work stopped noticing it years ago. It's knowing that the March vendor outage isn't an emergency because it happens every year. It's knowing which "urgent" requests are actually urgent. This is the knowledge that's expensive to lose and slow to capture, so your plan should spend most of its effort dragging it into the open. The fastest way to surface it is to 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 you lose the right things, 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, and cropping them is tedious enough that busy people skip it, and the knowledge stays trapped. 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. For a team where the receiver speaks a different language than the person leaving, it can also produce the guide in 50+ languages, so the handover isn't gated on who shares a first language. The point isn't magic; it's lowering the cost of capture enough that it actually gets done while you still have the person.

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. Before the last day, flip the roles: the receiver does the real task while the person leaving watches and stays quiet unless something is about to break. Every hesitation is a hole in the documentation you can still fix while the expert is in the room. 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 leaving it. 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 to surface every quarter, not something to chase on someone's way out. A knowledge transfer plan you can run in an afternoon, because the documentation already exists, is the whole goal.

Maya's two weeks will be tight. But if her team had been capturing as they went, those two weeks would be a review, not a rescue. That's the difference worth building toward.