If one person leaving would put your platform — or your business — in jeopardy, you have key-person risk. It’s one of the most common and most dangerous issues we find, and it’s invisible until the day it isn’t. Here’s how to spot it and remove it.
What key-person risk really is
Key-person risk is the dependence of your platform on a small number of individuals who hold critical knowledge that exists nowhere else. It’s the developer who’s the only one who understands how deployments work, the architect who carries the system design in their head, or the founder-engineer who built the core and never wrote anything down. While they’re around, everything’s fine. The risk is entirely in what happens if they’re not.
Why it’s so dangerous
Unlike most technical risks, key-person risk has a binary, catastrophic failure mode: the person becomes unavailable — resignation, illness, a competitor’s offer — and suddenly no one can safely change, fix or operate part of your platform. It also quietly caps your growth, because the business can’t move faster than that one person, and it directly damages your valuation: investors and acquirers treat concentrated knowledge as a serious, sometimes deal-breaking, red flag.
How to spot it
- The “bus factor” test. For each critical system, ask: how many people could keep this running if the main person vanished tomorrow? If the answer is “one”, that’s your risk.
- Undocumented operations. Deployments, environment setup, incident recovery — if these live only in someone’s head, they’re a single point of failure.
- Commit concentration. When repository history shows one person touching the vast majority of critical code, knowledge is concentrating.
- “Ask [name]”. If the answer to most technical questions is the same person’s name, you’ve found your dependency.
How to remove it
The fix isn’t dramatic — it’s deliberate, steady de-risking:
- Document the critical paths. Architecture overview, deployment runbook, environment setup, incident playbook. Start with what only one person knows.
- Cross-train. Pair people on critical systems so at least two understand each one. Make review the default, so knowledge spreads as code is written.
- Reduce hero dependencies in the architecture. Simplify and standardise the parts that are “special” precisely because one person built them their own way.
- Retain deliberately. Where a person genuinely is critical, manage that with retention, not just hope — but use the time to transfer their knowledge.
The mindset shift
Healthy engineering organisations treat knowledge as something to spread, not hoard. That’s a cultural change as much as a technical one — and it pays off in resilience, faster delivery, and a business that’s worth more because it doesn’t depend on any single person.
Frequently asked questions
How do we measure key-person risk?
Start with the bus-factor test on each critical system, and review your repository history for commit concentration. An independent assessment maps exactly where knowledge is concentrated.
Isn’t documentation a waste of time?
Lightweight, current documentation of the critical paths is some of the highest-return work you can do — it’s the difference between a smooth handover and a crisis.
Does this affect our valuation?
Yes. Buyers and investors view key-person dependency as a serious risk; reducing it before a raise or sale directly protects your value.
Worried about single points of failure in your team? Our independent assessment identifies and helps remove them — get in touch or book a call.