The Offboarding Knowledge Protocol

The resignation letter is not the beginning of knowledge transfer. It is the last chance to accelerate what should have already been ongoing. An offboarding knowledge protocol defines exactly what happens between resignation and departure to maximize knowledge transfer within the available window. Without a protocol, offboarding knowledge transfer is ad hoc — sometimes good, often inadequate, never systematic.

1. Day 1-3: Knowledge Inventory As soon as notice is given, begin a knowledge inventory with the departing employee: list every critical process they own, every system they are the primary or only operator for, every external relationship they manage, every project in flight, and every undocumented institutional knowledge they hold. This inventory drives the rest of the protocol. Budget two to four hours for this conversation. It is the most valuable investment in the entire offboarding.
2. Days 4-14: Structured Transfer Sessions Use the knowledge inventory to schedule focused transfer sessions: one session per critical knowledge domain, structured as a CTA session — not a verbal handoff, but a documented extraction. The departing employee is the subject matter expert. The knowledge analyst or designated successor is the extractor. Every session produces a documented artifact, not just a conversation.
3. Days 14-Last Day: Documentation Review and Certification The departing employee reviews every artifact produced from the transfer sessions and certifies accuracy. They identify gaps. They confirm that a successor who uses the artifacts could execute the critical processes at an acceptable standard. Gaps identified in this review are addressed before departure, not after.
4. 30-Day Post-Departure Check The successor contacts the departing employee (if the relationship supports it) thirty days after departure to report on the gaps discovered in actual execution — the knowledge that was not covered in the transfer sessions. This check is not about relitigating the offboarding. It is about closing the final gaps while the former employee still remembers them and before they have fully context-switched to their new role.

# Offboarding Knowledge Protocol — [Employee Name]
Notice Date: [Date] | Last Day: [Date] | Manager: [Name]

## Phase 1: Knowledge Inventory (Days 1–3)
- [ ] Critical processes owned (list all)
- [ ] Systems with primary/sole operation responsibility
- [ ] External relationships requiring handoff
- [ ] Projects in flight with context
- [ ] Undocumented institutional knowledge (self-reported)

## Phase 2: Transfer Sessions (Days 4–14)
| Domain | Session Date | Successor | Artifact Owner | Status |
|--------|-------------|-----------|----------------|--------|
| [Domain 1] | [Date] | [Name] | [Name] | Scheduled |
| [Domain 2] | [Date] | [Name] | [Name] | Scheduled |

Each session produces:
→ Process documentation or updated existing doc
→ Decision log for the domain
→ Contact list and relationship context
→ Known gotchas, failure modes, historical context

## Phase 3: Certification Review (Days 14 – Last Day)
- [ ] [Domain 1] artifact reviewed and certified accurate
- [ ] [Domain 2] artifact reviewed and certified accurate
- [ ] Gaps identified: [list]
- [ ] Gaps addressed before departure: [list]

## Phase 4: Post-Departure Check (Day +30)
- [ ] Successor debrief with departing employee
- [ ] Execution gaps reported: [list]
- [ ] Final documentation updates: [list]