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.
The Immediate Impact
Week 1-2 (notice period):
- Sarah is mentally checked out (normal and expected)
- The team starts realizing how much context lives in her head
- Frantic knowledge transfer sessions that capture 20% of what she knows
Week 3-4 (after departure):
- Tickets in Sarah's areas take 3x longer
- Other engineers Slack each other: "How does the payment webhook work?" Nobody knows
- A PR to the auth system gets merged without proper review because nobody else understands it
- A production incident in the payment flow takes 6 hours to resolve instead of 30 minutes
Month 2-6:
- The team slowly rebuilds understanding through trial and error
- 2-3 regressions occur in Sarah's code areas because new maintainers miss edge cases
- A new hire is assigned to Sarah's areas and takes 4 months to reach basic competence
The Hidden Costs
- Direct productivity loss: 10-15% team-wide for 3-6 months in affected areas
- Incident costs: 2-3 additional incidents, each costing $5K-$50K
- Recruitment: $30K-$50K to replace Sarah
- Ramp-up: 6-9 months for the replacement to reach Sarah's level
- Total: $150K-$400K in direct and indirect costs
Prevention, Not Reaction
The goal isn't to prevent people from leaving. It's to ensure that when they do, the knowledge doesn't leave with them.
1. Measure Knowledge Concentration
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.
2. Automated Knowledge Extraction
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.
3. Rotation and Pairing
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.
4. Codebase Intelligence
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.
Originally published on glue.tools. Glue is the pre-code intelligence platform — paste a ticket, get a battle plan.
Top comments (0)