8 min read • Guide 707 of 877
Knowledge Gets Lost When Team Members Leave
Team departures shouldn't mean knowledge departures. GitScrum helps capture institutional knowledge through documentation features, task history, and decision records that preserve context regardless of who's on the team.
Knowledge Risk Assessment
Types of Knowledge
KNOWLEDGE CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPLICIT KNOWLEDGE (Easier to capture): │
│ • Code itself │
│ • Written documentation │
│ • Process documentation │
│ • Architecture diagrams │
│ │
│ TACIT KNOWLEDGE (Harder to capture): │
│ • Why decisions were made │
│ • System quirks and workarounds │
│ • "Don't do this because..." │
│ • Relationship context │
│ • Historical context │
│ │
│ TRIBAL KNOWLEDGE (Most at risk): │
│ • "Ask Sarah, she knows" │
│ • Unwritten rules │
│ • War stories about past failures │
│ • Shortcuts and tricks │
│ │
│ HIGH-RISK AREAS: │
│ ☐ Areas only one person knows │
│ ☐ Complex legacy systems │
│ ☐ Custom integrations │
│ ☐ Critical production systems │
│ ☐ Key stakeholder relationships │
└─────────────────────────────────────────────────────────────┘
Knowledge Audit
KNOWLEDGE MAPPING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ KNOWLEDGE CONCENTRATION CHECK: │
│ │
│ System/Area │ Primary │ Backup │ Risk Level │
│───────────────────────┼─────────┼────────┼────────────────│
│ Payment integration │ Alex │ Maria │ 🟢 Low │
│ Legacy billing system │ Jordan │ - │ 🔴 Critical │
│ CI/CD pipeline │ Alex │ Jordan │ 🟢 Low │
│ Customer import tool │ Maria │ - │ 🔴 Critical │
│ Main API │ Team │ Team │ 🟢 Low │
│ │
│ BUS FACTOR CHECK: │
│ "If this person got hit by a bus, how bad would it be?" │
│ │
│ • Bus factor = 1 → Critical risk (one person knows) │
│ • Bus factor = 2 → Moderate risk │
│ • Bus factor = 3+ → Lower risk │
│ │
│ IDENTIFIED RISKS: │
│ • Jordan is only person who knows legacy billing │
│ • Maria owns entire customer import process │
│ │
│ MITIGATION PLAN: │
│ • Jordan: Document and pair with team member │
│ • Maria: Create runbook and shadow training │
└─────────────────────────────────────────────────────────────┘
Prevention Strategies
Continuous Documentation
DOCUMENTATION-AS-YOU-GO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DON'T: Wait until someone leaves to capture knowledge │
│ DO: Capture continuously as work happens │
│ │
│ TRIGGER-BASED DOCUMENTATION: │
│ │
│ When this happens... │ Create/Update this... │
│─────────────────────────┼───────────────────────────────── │
│ Major decision made │ Architecture Decision Record │
│ Production incident │ Post-mortem + Runbook │
│ New process introduced │ Process documentation │
│ Integration built │ Integration guide │
│ Complex feature done │ Feature overview doc │
│ "Weird thing" discovered│ Gotchas/quirks document │
│ │
│ EMBEDDED IN WORKFLOW: │
│ • Code review: "Is there a doc for this?" │
│ • Sprint completion: "What should be documented?" │
│ • Incident resolution: "Did we update the runbook?" │
│ │
│ LOW-FRICTION: │
│ • Use templates │
│ • Accept "good enough" over perfect │
│ • Any doc is better than no doc │
└─────────────────────────────────────────────────────────────┘
Cross-Training
KNOWLEDGE DISTRIBUTION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PAIRING ROTATION: │
│ │
│ Week 1: Jordan teaches Maria about billing system │
│ Week 2: Maria teaches Jordan about import tool │
│ Week 3: Alex teaches team about payment integration │
│ │
│ FORMAT OPTIONS: │
│ │
│ Pairing (Best for tacit knowledge): │
│ • Work together on real tasks │
│ • Explain thought process │
│ • 2-4 hour sessions │
│ │
│ Demo (Good for overview): │
│ • Show how system works │
│ • Answer questions │
│ • Record for future reference │
│ │
│ Code Review (Good for context): │
│ • Include context in PR descriptions │
│ • Explain why, not just what │
│ • Knowledge transfers during review │
│ │
│ GOAL: No single point of failure for any system │
│ │
│ TRACKING: │
│ ☑ Jordan/Maria paired on billing - 4 hours │
│ ☐ Maria/Jordan pairing on imports - scheduled next week │
│ ☑ Alex recorded payment integration walkthrough │
└─────────────────────────────────────────────────────────────┘
Exit Process
Knowledge Transfer
DEPARTURE KNOWLEDGE TRANSFER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WHEN NOTICE GIVEN: │
│ │
│ WEEK 1: INVENTORY │
│ • List all systems/areas person owns │
│ • Identify gaps in documentation │
│ • Prioritize what must be transferred │
│ • Schedule transfer sessions │
│ │
│ WEEK 2-3: TRANSFER │
│ │
│ Daily knowledge transfer sessions: │
│ • Morning: 1-2 hour pairing/demo │
│ • Afternoon: Recipient practices, asks questions │
│ │
│ Documentation creation: │
│ • Fill gaps identified in inventory │
│ • Focus on "why" not just "what" │
│ • Record any video walkthroughs │
│ │
│ FINAL WEEK: VALIDATION │
│ • Recipient handles tasks independently │
│ • Departing person available for questions │
│ • Final documentation review │
│ • Handoff of any credentials/access │
│ │
│ CHECKLIST: │
│ ☐ All owned systems have backup person │
│ ☐ Documentation updated │
│ ☐ Runbooks verified by backup person │
│ ☐ Stakeholder introductions made │
│ ☐ Ongoing work assigned to others │
└─────────────────────────────────────────────────────────────┘
Exit Interview
KNOWLEDGE EXIT INTERVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUESTIONS TO ASK: │
│ │
│ SYSTEMS: │
│ • What systems do only you understand? │
│ • What would break if no one took over? │
│ • What's the trickiest thing to maintain? │
│ │
│ GOTCHAS: │
│ • What "surprises" should we know about? │
│ • What mistakes did you learn from? │
│ • What would you warn someone about? │
│ │
│ CONTEXT: │
│ • Why were certain decisions made? │
│ • What was tried that didn't work? │
│ • What would you do differently? │
│ │
│ RELATIONSHIPS: │
│ • Who are key contacts outside the team? │
│ • Any important vendor relationships? │
│ • Who should take over stakeholder relationships? │
│ │
│ FUTURE: │
│ • What should we prioritize fixing? │
│ • What would make your old job easier? │
│ • Any suggestions for improvement? │
│ │
│ CAPTURE: Record or take detailed notes │
│ Archive in team knowledge base │
└─────────────────────────────────────────────────────────────┘
Long-Term Health
Ongoing Prevention
SUSTAINABLE KNOWLEDGE PRACTICES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUARTERLY REVIEW: │
│ • Update knowledge concentration map │
│ • Identify new single-points-of-failure │
│ • Schedule cross-training for gaps │
│ │
│ DOCUMENTATION HEALTH: │
│ • Review freshness of key docs │
│ • Archive or update stale content │
│ • Fill documented gaps │
│ │
│ TEAM NORMS: │
│ • New complex work = documentation expected │
│ • Decisions captured as ADRs │
│ • Incidents followed by runbook updates │
│ • Cross-training is routine, not exceptional │
│ │
│ SUCCESS METRICS: │
│ • No system with bus factor = 1 │
│ • Key docs updated in last 6 months │
│ • Any team member can handle basic ops for any system │
│ • Departures don't cause emergencies │
│ │
│ CULTURE SHIFT: │
│ From: "I know this, ask me" │
│ To: "It's documented, I'll share the link" │
└─────────────────────────────────────────────────────────────┘