Knowledge Transfer: How to Keep Expertise When People Move On
Someone on your team gives notice. Within a day, you realize how much of the work lives only in their head: the workaround for the billing export, the supplier who needs a call before every order, the reason a setting must never be changed. You have a few weeks to get it out.
That is knowledge transfer. Done well, the next person picks up the work without guessing. Done badly, the team spends months rediscovering what it already knew. This guide gives you a simple plan, the questions to ask, and a way to turn what you learn into documentation that keeps working after the handover.
What is knowledge transfer?
Knowledge transfer is the process of moving know-how from one person or part of an organization to another, so the work continues without them. It covers both written facts (files, steps, contacts) and the unwritten judgment people build through experience.
It is closely related to knowledge retention: transfer is the act of handing knowledge over, and retention is the result — the organization still has it after the person moves on.
Why knowledge transfer is harder than it looks
If knowledge were easy to pass along, one handover meeting and a long email would do the job. Two things get in the way.
Knowledge is scattered. It sits in people, but also in the tools they use, the tasks they run, and the small networks of colleagues they rely on. No single folder holds it all.
Much of it is tacit. Tacit knowledge is the experience, intuition, and judgment people use without thinking about it. Experts often don't realize what they know, so they don't think to write it down. A research review of knowledge retention from older and retiring workers (Burmeister and Deller, 2016) describes tacit knowledge as more complex, more personal, and harder to transfer than explicit knowledge.
That same review points to something useful: the person receiving the knowledge matters as much as the person leaving. Less experienced colleagues can act as catalysts, asking the questions that pull knowledge out. Motivation to share and trust between colleagues also shape how well a handover goes.
The takeaway: knowledge transfer is a conversation, not a file dump. Plan for both.
Explicit vs. tacit knowledge: what you're really moving
It helps to separate the two kinds of knowledge before you start.
- Explicit knowledge is already written or easy to write: a list of open projects, a login process, a contact list, a report schedule.
- Tacit knowledge is the "how and why": which customer complaints are urgent, what to check when a report looks wrong, when to bend a rule.
Knowledge management researchers Ikujiro Nonaka and Hirotaka Takeuchi described the move from tacit to explicit as externalization — putting personal know-how into words or visuals so others can understand and use it. It is widely seen as one of the most difficult steps in knowledge transfer, and it is exactly where good documentation earns its keep.
How to build a knowledge transfer plan in three steps
A practical model comes from Cal Poly's employee development team, whose offboarding template breaks the work into three steps, each with a clear deadline. You can adapt it to any team.
Step 1: Gather the knowledge transfer documents that already exist
When: as soon as you learn someone is leaving.
Start with what can be collected without a meeting. Ask the departing person to pull together:
- A project status list: current, outstanding, and upcoming projects, deadlines, and tasks, plus their regular recurring work and any open items.
- A contact list: the internal and external people their successor should meet before they leave, and the outside groups they work with.
- The key files: records and documents that need to be kept, saved to a shared location rather than a personal drive, along with any existing notes on the processes and systems they use.
This first pass shows you where the gaps are. Whatever is missing or unclear becomes the agenda for step 2.
Step 2: Run a knowledge transfer interview (not an exit interview)
When: within the first week.
An exit interview asks how someone felt about their job. A knowledge transfer interview asks how they do their job. Hold it one-on-one with the manager, and include the successor or other stakeholders where it helps. Good questions include:
- Can you break your daily routine into step-by-step instructions?
- What do you repeat weekly, monthly, quarterly, or yearly — and how do you do it?
- Who are your regular contacts, inside and outside the organization?
- Which tasks take priority in your role?
- What three things do you wish you had known when you started?
- What will be your successor's biggest challenge, and what would you advise?
- Which systems will your successor need training on?
- Which files does your successor need to know about and have access to?
Questions 5 and 6 matter most. They invite stories, and stories are where tacit knowledge comes out. Record the answers, then write them up the same day while the details are fresh.
Step 3: Turn answers into a plan with owners and dates
When: right after the interview.
Now make it concrete. A simple knowledge transfer template needs two tables:
| Key task or project | Responsible | Accountable | Consulted | Informed | Handover date |
|---|---|---|---|---|---|
| Monthly billing export |
| Task or project | New owner | Knowledge or skill gap | Plan to close the gap | Start date | End date |
|---|---|---|---|---|---|
| Supplier ordering |
The first table makes sure every responsibility has a named owner. The second makes the gaps visible — and turns each one into a training task with a deadline instead of a vague hope.
How to capture tacit knowledge before it walks out the door
Interviews are a strong start, but tacit knowledge often needs more than one conversation. The KM Institute recommends a range of methods. These work especially well during a handover:
- Job shadowing. The successor watches real work happen, then does it while the expert watches. Questions come up that no one would think to ask in a meeting.
- Storytelling. Ask "tell me about a time this went wrong." The answer usually contains the real rule.
- After-action reviews. After a key task, take ten minutes to note what happened, what worked, and what to do differently.
- Mentoring. Pair the successor with the expert for regular check-ins, not just one handover session.
- Knowledge capture workshops. For a role that touches many people, bring the team together to map out what the expert does and where they are the only one who knows how.
Each of these produces raw material. The final step is always the same: write it down in a place the next person will actually look.
Turn the handover into living documentation
A knowledge transfer document that sits in an email thread is lost the moment the next person changes roles. To keep what you captured:
- Write in steps, not paragraphs. Turn the interview notes into short, numbered procedures with one action per step.
- Keep it in one shared home. A single, searchable source of truth beats a dozen documents spread across drives.
- Name an owner and a review date. Knowledge goes stale. Someone should check each page on a schedule.
- Let readers flag gaps. The successor is the best tester. When they get stuck, that page needs work.
This is the gap Sonat is built for. Teams draft in Google Docs, publish to one searchable home, and use feedback on each page to see where readers get stuck. If you're setting up an internal knowledge base for the first time, our knowledge management use case shows how teams organize it, and our templates give you a starting point so no one faces a blank page.
A reusable knowledge transfer checklist
Use this the next time someone gives notice:
- Project status, contacts, and key files collected (right away)
- Files moved from personal drives to a shared location
- Knowledge transfer interview held (week 1)
- Every key task has a named new owner and handover date
- Each skill gap has a training plan with dates
- Shadowing sessions scheduled for the trickiest tasks
- Interview notes turned into step-by-step documentation
- Each new page has an owner and a review date
Make knowledge transfer a habit, not a farewell task
The best time to plan a knowledge transfer is long before anyone resigns. When teams document as they work — a short procedure after each new task, a quick note after each fix — a departure becomes a handover instead of a scramble.
Start small. Pick the one role on your team that would hurt most to lose tomorrow, and run steps 1 to 3 this month — no resignation required. What you write down today is knowledge your team keeps.