Key person risk is the exposure a business carries when its most important functions depend on one person. In most small companies, that person is the founder. Closing deals, resolving escalations, approving refunds, signing off on payroll — the work keeps moving only because you keep showing up.
That feels like dedication. Functionally, it is a single point of failure with a pulse.
Key takeaways
- Key person risk is measured in functions, not feelings: name the three things only you can do, then score each one for unavailability and impact.
- A function you perform 100% of the time is not a strength; it is an uninsured liability that quietly inflates your annual operating cost.
- Probability multiplied by impact gives you a ranking, and the ranking tells you which function to document first — not the one that feels most urgent.
- Reducing key person risk is a 30-day project with three moves: document the function, delegate the decision, or systemize the trigger.
Why founders underrate their own key person risk
Ask a founder what would happen if they took two weeks offline and the answer usually starts with a laugh. Then a pause. Then a list.
The pause is the tell. Everyone knows the risk is there; almost nobody prices it. The reason is structural — founders experience key person risk from the inside, as normal. You have always been the one who closes the difficult deal, so it does not register as a bottleneck. It registers as competence.
But a business that cannot complete certain transactions without one specific human is not a business yet. It is a job with extra steps and a payroll. The goal of this stress test is to make that exposure visible, rank it, and shrink it.
The key person risk stress test, step by step
There is a specific sequence to this. Most people stop after step one and feel productive. The value lives in steps three and four.
Step 1: Name the three functions only you can perform
Not the three you are best at. The three where, if you were unreachable, the work would simply stop. Common candidates: closing deals above a certain size, resolving customer escalations, approving refunds or credits, signing contracts, releasing payments, making hiring calls, handling the one enterprise account.
Be narrow. "Sales" is not a function. "Approving discounts over a set threshold on enterprise deals" is a function.
Step 2: Estimate your unavailability honestly
For each function, ask a plain question: what is the realistic chance I am unavailable to perform this for a stretch in the next twelve months? Unavailability includes vacation, illness, burnout, a family emergency, or simply being unreachable for a few days at the wrong moment.
Use three buckets instead of fake precision: low, moderate, high. High means it is likely to happen at least once. Then note how long the function can sit unattended before the damage starts — hours, days, or a couple of weeks.
Step 3: Estimate the impact if it stalls
The impact question has two layers. The first is revenue: what deal, renewal, or payment is at risk while the function is frozen? The second is operational: what backlog, escalation, or customer trust problem builds in the meantime?
You do not need a formula to see the shape. A refund approval that stalls for two days is friction. A contract signature that stalls for two weeks is a lost quarter.
Step 4: Score and rank
Combine the two into a simple score: unavailability likelihood times impact severity. High likelihood plus high impact goes at the top. Low likelihood plus moderate impact goes at the bottom. Three functions, one ranked list, no debate needed.
The ranking is the output. It tells you where the next thirty days of your attention should go.
Step 5: Choose one of three moves per function
Each function gets one of three treatments.
| Situation | What to do | Why |
|---|---|---|
| The decision needs your judgment, not your hands | Document the decision criteria and hand the call to someone else | You keep the standard, lose the bottleneck |
| The function is repeatable and rules-based | Systemize the trigger — approvals, refunds, thresholds, templates | Rules do not take vacations |
| The function genuinely requires you for now | Document it fully and set a coverage plan for unavailability | A written process is still recoverable by someone else |
Notice that only the third option involves staying involved, and even then the requirement is documentation, not presence.
Where the cost actually shows up
The stress test tells you where the risk sits. It does not tell you what the risk costs you across a year, because the cost is not one dramatic outage. It is the accumulated drag: the deals that wait for your calendar, the escalations that queue while you are in another meeting, the refund that generates three more support tickets, the tools you pay for that were meant to remove the bottleneck and never did.
That drag is what the Chaos Tax framework calls the annual cost of founder chaos. It is worth quantifying rather than guessing. The free five-step diagnostic at https://tools.exiuss.com/radar takes six inputs and breaks the number down by category — weekly chaos cost, urgent problems, missed revenue, and wasted tools — then ranks what to fix. It is free, and it asks for real inputs. Estimate honestly or the output is decoration.
The full diagnosis adds a chaos archetype, a sovereignty maturity level, and a prioritized 30-day recovery plan tagged Systemize, Delegate, Automate, Eliminate. That tagging is the same logic as the three moves above, which is why the stress test and the calculator fit together: one ranks the functions, the other prices them.
The 30-day plan to reduce single-point-of-failure exposure
Take your top-ranked function and give it the month.
Days 1 to 7 — Document. Write the function down as if handing it to a competent stranger. What triggers it, what information is required, what the decision criteria are, what the exceptions look like. Keep it to one or two pages. If you cannot finish it in a week, the function is more tangled than you thought, which is itself the finding.
Days 8 to 14 — Shadow. Have someone else run the documented version while you watch. They will hit gaps you did not see. Fix the document, not the person.
Days 15 to 21 — Delegate the decision, not just the task. Set thresholds where the other person decides without asking. Start narrow and widen as trust accumulates. A delegate who must check every call has not reduced your risk at all.
Days 22 to 30 — Test the coverage. Step away deliberately, briefly, and unannounced. See what breaks. What breaks is your next documentation project.
Then take function two and repeat.
Quick checklist
- List the three functions that would stop completely if you were unreachable
- Score each for unavailability likelihood (low, moderate, high) and impact severity
- Rank the three and commit to the top one for this month
- Write a one-page procedure for the top function this week
- Set decision thresholds so someone else can act without you
- Price the annual drag with the free RADAR calculator at https://tools.exiuss.com/radar
The point of the test
Key person risk is not a compliment about how indispensable you are. It is a line item — an uninsured liability sitting inside your operating costs, billed to you every year you leave it unmeasured. The founders who move from firefighting to actual ownership are the ones who treat their own centrality as a problem to be engineered out, one function at a time.
Start with the test. Three functions, two scores each, one ranked list. Then put a number on what staying stuck costs you — and start shrinking it.