The departing engineer provides a 'brain dump' — why is this insufficient as a knowledge transfer?
Brain dump vs. structured handover: knowledge dump = information soup. Structured = recipient-centric: what to do day one, who to contact for what, prioritised gotchas, system rundown in operational order.
Key vocab: "brain dump", "structured knowledge transfer", "recipient-centric documentation", "operational order of knowledge".
2 / 5
The team is concerned about their 'bus factor' — what is this?
Bus factor = knowledge concentration risk metric. Bus factor 1 = single point of failure. Mitigation: documentation, cross-training, pair programming, runbooks.
Key vocab: "bus factor", "single point of knowledge failure", "knowledge concentration", "knowledge distribution strategy".
3 / 5
The team has 'tribal knowledge' that isn't documented — what is this and why is it a risk?
Tribal knowledge: "the database needs restarting every Sunday at 2am because..." — lives in heads, not docs. Mitigation: ADRs, runbooks, onboarding docs, video explainers.
The knowledge transfer includes a 'runbook' — what is it?
Runbook: operational guide (not architecture doc). Good runbook: numbered steps, expected output at each step, what to do if step fails. Runbook ≠ playbook (emergency response) ≠ ADR (decision record).
The knowledge transfer session uses the 'say-back' technique — what is this?
Say-back/teach-back: comprehension check that surfaces gaps. "So if I understand correctly, when X happens I should..." = knowledge-giver can immediately correct.