The most dangerous technical debt isn't in the code—it's in the heads of the people who wrote it. When critical knowledge exists only in one or two individuals, you're one resignation away from a crisis.
The Key Person Risk Problem
In technology acquisitions, key person risk manifests in several ways:
- Architectural knowledge: Only one person understands why the system is designed the way it is
- Operational expertise: Only one person knows how to deploy, monitor, and troubleshoot
- Customer relationships: Technical customer relationships tied to specific individuals
- Domain expertise: Business logic and industry knowledge not documented
Post-acquisition, 40% of key technical staff leave within 18 months. The reasons vary—cultural mismatch, better opportunities, burnout from integration—but the impact is consistent: critical knowledge walks out the door.
Identifying Key Person Risk
1. Code Analysis
Git history reveals concentration risk:
- What percentage of code was written by each developer?
- Are there critical modules touched by only one person?
- Who has made recent changes to core systems?
2. Team Interviews
Ask pointed questions:
- "Who would you go to if X system broke at 2 AM?"
- "Who understands how the billing system works?"
- "If you had to rebuild this from scratch, who would you need?"
3. Documentation Assessment
Evaluate knowledge capture:
- Is architecture documented?
- Are runbooks and playbooks current?
- Do onboarding materials exist?
- When was documentation last updated?
4. Bus Factor Analysis
For each critical system, ask: how many people would need to be hit by a bus before we can't maintain this?
- Bus factor of 1 = extreme risk
- Bus factor of 2-3 = elevated risk
- Bus factor of 4+ = manageable
Mitigating Key Person Risk
Pre-Close
- Retention agreements: Structure earnouts and retention bonuses to keep key technical staff
- Documentation requirements: Make knowledge transfer a closing condition
- Shadow staffing: Plan to add redundant resources immediately post-close
Post-Close
- Knowledge extraction: Prioritize documentation of critical systems
- Pair programming: Have key individuals work alongside new team members
- Video documentation: Record walkthroughs of critical processes
- Cross-training: Ensure multiple people can handle each critical function
Case Study: The Founder Departure
A PE firm acquired a data analytics company for $22M. The technical founder, who had built the core platform, had a 2-year earnout tied to revenue targets.
Month 14: The founder announced he was leaving to start a new company. The earnout wasn't motivating enough compared to a new opportunity.
The impact:
- Core platform had minimal documentation
- No one else understood the proprietary algorithms
- 6-month project to reverse-engineer and document the system
- Two customer escalations during the transition
- $400K in additional engineering costs to rebuild knowledge
The lesson: retention agreements don't guarantee retention. Knowledge transfer should happen immediately, not over years.