Key Person Risk

In an organization that has to move fast, whoever knows how just does it. The engineer who wired up payments handles the next payment incident too, and having handled it once, keeps owning that area. It genuinely is the quickest path early on, because it skips deciding who takes the work and explaining it to them.

The bill arrives on the first day that person isn't around. At Pagedeck, Theo had always done the payment deploys alone. Payments went down for an hour during the week he was on vacation, and nobody left in the office knew the recovery steps, so they called him. It ended with Theo opening a laptop at the airport and reading out two commands. An hour of downtime is survivable; what stung was that the company had no way to end it on its own.

The question Grace raised afterward wasn't why Theo was the only one who knew. It was where else the same setup existed. Work concentrating on one person isn't an accident; it's a shape that reappears every time a company grows, so solving one instance doesn't stop the next. That's the reason the risk carries a name. A name makes it a line on a checklist, and a line on a checklist gets re-read every quarter.

The risk comes not from someone being good at their job but from holding something other people can't reach. What gets held is usually one of three things.

1. Knowledge. Steps that exist in one person's experience and nowhere in writing — who the contact at the payments vendor is, what order to roll things back in during an incident.
2. Access. Accounts and keys that only one person holds. Companies that spent days unable to change anything because a departing employee walked off with the domain administrator account are not rare.
3. Relationships. Customers or investors who stay because of a specific individual. A contract signed on someone's name rather than the company's tends to move with them.

The size of the risk is measured by how long things stop, not by how talented the person is. A team where payment deploys slip half a day without Theo is not in the same situation as one where nobody touches payments for two weeks. So the question to ask during a review isn't who matters most. It's what stops if this person can't come in for the next two weeks.

The fix is dividing what they hold rather than trying to keep them forever. Knowledge moves when the next occurrence of that work is done by somebody else with the original owner watching. Writing a document feels like the transfer happened, but a document nobody has followed end to end still has holes in it that only show up under pressure. Access gets split across two or more people, or kept under the principle of least privilege with a separate emergency path defined in advance. Relationships change by adding a second person to the next meeting and letting the account become a company relationship.

Three settings account for most uses of the term.

Investor diligence and board meetings come first. Investors look for whether the company hangs on a founder or a single engineer, so the phrase appears in the risk section of a business plan. Insurance policies a company takes out on its own executives come from here too — money set aside to keep the company running if that person is suddenly gone.

Second is the risk register. That's the exercise of laying out everything that could shake the company in one table and ranking it by likelihood and size, and key person risk sits on a row next to customer concentration risk and regulatory risk. Rows near the top get concrete preparation attached, such as a business continuity plan or a contingency plan.

Third is ordinary engineering work. There the conversation rarely uses the word risk; it's about how many people know a given area. Collective code ownership, the principle that anyone can change any code, pair programming, where two people write code at one screen, and code review, where a colleague reads the change before it merges, all work as ways of raising that count. Rotating the on-call duty does the same thing, since taking the pager requires knowing the system. None of these practices were invented to manage risk, which is part of why they work — the coverage is a side effect of how the team already writes and ships code, rather than an extra chore nobody has time for.

"Nobody but Theo can touch payments. Let's put it on the risk list this quarter."

A proposal to turn a concentration everyone already knows about into a tracked item.

"The CEO holding every major account personally will get flagged in diligence."

A warning that investors will read the revenue as attached to a person, not the company.

"Theo watches the next incident and someone else runs it."

The most reliable way to move knowledge, stated as an action.

Since that vacation week, Pagedeck spends an hour every quarter rereading the same table. Areas go in the left column and the number of people who can handle each one alone goes in the right, and only the rows reading 1 become that quarter's work. The row for payment deploys went from 1 to 2 in two quarters. Nothing clever was involved — Noa simply ran each deploy that came up during that time.

The most common misreading treats the person as the problem. One name on a table looks like someone hoarding information. But the state is the accumulated result of an organization letting whoever knows how do it, and that person is usually the one who carried the most. Once the meeting turns into blame, nobody ever says "I'm the only one who knows this" again, and the risk stays where it is, unseen.

The other is assuming documentation closes the issue. A handover doc lands in a folder and it's tempting to change the number from 1 to 2. Documents get written from the author's head, though, so the steps obvious to the author are exactly the ones missing. Leave the number alone until someone else has worked through the document once, and let that second person be the one who edits it afterward, since they are the only one who can see what was missing.