How to build a knowledge transfer plan before a retirement

Before you start

Prerequisites: a departure date (even approximate), management ownership of the plan (it dies as an HR side-task), and the expert's agreement on the approach. Rule of thumb for the real window: announced time minus a third.

The steps

Step 1 — Count backwards from the date

Take the departure date, subtract the wind-down (last 2–3 months are logistics and goodbyes), subtract holiday seasons, and see what remains. That number — not the announced years — is the plan's budget. Eighteen announced months is typically ten usable ones.

Pitfall: Planning forward from today ('we'll start with…'). Forward plans expand comfortably and hit the date unfinished; backward plans expose the shortage on day one.

Step 2 — Inventory what must move

List the knowledge domains with the team's help: what does everyone ask him? What does he decide alone? What breaks when he's on holiday? Rank by damage-if-lost. Ten to fifteen domains is typical for a senior role.

Pitfall: Inventorying by job description. The critical knowledge is usually orthogonal to the formal role — the informal arrangement book, the failure memory.

Step 3 — Match instruments to knowledge types

Split the inventory: explicit knowledge (procedures, configurations, contacts) goes to documents — cheap and adequate. Tacit knowledge (judgment, diagnosis, relationships) goes to capture: recorded reasoning, structured interviews, and where possible a mentoring pair. One instrument for everything is the classic failure.

Pitfall: Assigning everything to 'documentation'. Writing is the weakest instrument for exactly the knowledge that matters most — see why documentation pushes stall.

Step 4 — Put it on a rhythm, not a project plan

Capture works as a cadence: meetings ingested continuously, one deep-dive session per week or fortnight, a monthly review of what's been covered. Cadences survive busy periods; project phases don't.

Pitfall: The 'big push in Q4' structure. Q4 will be busy — it always is — and the push will move to Q1, which is the departure quarter.

Step 5 — Make the team the question engine

The plan's quality control is the team's real questions: collect them continuously, aim capture at them, and test the captured knowledge against them. If a successor is known, his first-100-days questions lead the list.

Pitfall: Letting the expert decide alone what's worth transferring. He undervalues what feels obvious to him — which is precisely the tacit layer.

Step 6 — Plan past the date

Decide now what happens after departure: who owns the knowledge base, how new questions get answered, whether post-departure sessions are agreed (they are cheap insurance while goodwill is fresh). A transfer plan that ends at the farewell forfeits the verification period.

Pitfall: Assuming 'he'll stay reachable' as the post-departure plan. Availability halves every few months; structure beats goodwill.

How MentX compresses this

MentX is a personality-aware knowledge base: it captures the knowledge of a company's key person — from meetings and a guided intake track — into a living, temporal knowledge graph with full source attribution. MentX turns the plan's hardest parts into defaults: the cadence is the product (Connect ingests meetings continuously; Deepen schedules the intake track), the team's questions flow in through DigiME from the moment it goes live, and the knowledge base — a living, temporal knowledge graph with full source attribution — is built to outlast the departure by design.

Checklist

• Real window computed backwards (announced minus wind-down)
• Knowledge inventory built with the team, ranked by damage
• Explicit → documents; tacit → capture (instruments matched)
• Weekly/fortnightly capture cadence in calendars
• Team question list live and feeding the capture
• Post-departure ownership and verification agreed