knowledge-transfer

Knowledge Transfer

When to Use

When a team member is leaving, changing roles, or when critical knowledge is concentrated in one person (bus factor = 1).

Core Jobs

1. Identify What Needs Transfer

Map the knowledge:

• Systems owned: what does this person know that nobody else does?
• Undocumented processes: what do they do manually that isn't written down?
• Tribal knowledge: decisions made without ADRs, vendor relationships, historical context
• Access and credentials: what do they control?

2. Structured Handoff Sessions

For each area:

• Walkthrough session: they show, new owner drives (not watch)
• Q&A session: new owner has had 1 week with docs, asks questions
• Shadow session: new owner handles it, original provides safety net
• Solo session: new owner is on their own, original is available async

3. Documentation Artifacts

Produce per system/area:

• Architecture overview (1-pager: what it does, how it works, key components)
• Operational runbook (how to keep it running, common issues)
• Decision log (why it's built this way — the ADRs or equivalent)
• Access inventory (what credentials, where stored, how to rotate)

4. Knowledge Transfer Checklist

• All systems have a named new owner
• Runbooks written and reviewed by new owner
• Access transferred (not just shared — actual ownership)
• 30-day support period agreed (original available for questions)
• Knowledge gaps identified and addressed before departure

Key Outputs

• Knowledge map (what → who knows it)
• Handoff documentation per system
• Session recordings (if permitted)
• 30-day support plan

Anti-Patterns

• Documentation dump without walkthrough sessions
• Assuming new owner will "figure it out"
• Knowledge transfer the week before departure (not enough time)
• Bus factor not tracked — discovering the problem after the person leaves