Sarah is your best engineer. She built the payment system, designed the auth architecture, and is the go-to person for anything related to the API layer. She's been at the company for 3 years.
Sarah just gave her 2-week notice.
Week 1-2 (notice period):
Week 3-4 (after departure):
Month 2-6:
The goal isn't to prevent people from leaving. It's to ensure that when they do, the knowledge doesn't leave with them.
For every feature, know: how many people have committed in the last 6 months? If the answer is 1, that's a bus factor risk that needs attention now, not when they give notice.
Sarah's knowledge exists in her PRs, code reviews, and commit messages. Extract it and make it queryable before she leaves. "Why is the payment webhook structured this way?" should be answerable from git history, not from Sarah.
Ensure at least 2 people have working knowledge of every critical system. This isn't just about code review — it's about actively working in each other's areas.
A tool that can answer "how does the payment system work?" from code analysis and git history means you're not dependent on any single person for context. The knowledge lives in the system, not in heads.
The best time to address knowledge concentration risk is before someone gives notice. The second best time is today.
Key person departure is the acute version of the Understanding Tax. The knowledge debt was always there — the departure just makes it visible.
For the proactive approach to knowledge preservation, read Your Codebase Knows Everything Your Team Has Forgotten.
Glue extracts and preserves engineering knowledge as pre-code intelligence — automatically, from git history and code analysis. When someone leaves, the knowledge stays in the system, not in their head.