Key-person risk: the question that ends diligence calls

"What happens if your CTO leaves?" is a question about where knowledge lives, not about your CTO. The investor is testing whether the company's working context sits in one head or in artefacts a competent stranger can pick up. Answer with reassurance about loyalty and you have confirmed the risk. Answer by showing what the codebase carries on its own and the call moves on.

It usually lands late, after the architecture questions have gone fine. The ordering is deliberate. Code problems come with a price and a timeline attached, and most of the red flags that stop a funding round cost money and weeks. A team problem has neither. It ends a conversation rather than repricing one.

Key-person risk is the part of a business that stops working when one person stops answering.

What the question is testing

The polite version asks about your CTO. The version underneath is a survey of where context lives, and it comes back in different clothes across the same hour. Who is the only person who can deploy. Who knows why the scheduling logic carries that odd exception.

Week one without them is usually fine: somebody has the credentials and the build runs. Month four is where the damage shows, in the migration nobody knew was half finished and the constraint that existed for a reason nobody wrote down. An investor who has lived through one of those is not asking whether you have a bus factor. They want to know how much of the business is stored in a format that survives a resignation letter.

Team and key-person risk is one of the seven areas a technical diligence review covers, and the only one you cannot fix in the week before the call. Knowledge that exists in a head takes months to move, and the proof it moved is other people using it while the head is on holiday.

We are not above this, incidentally. Every build starts with its working context in the heads of the people building it, and most of our habits exist to get it out of them.

Why the usual mitigations decay

The standard advice arrives in a fixed order. Write documentation. Then pair people so knowledge moves by osmosis. Then hire until no single person owns a system. All of it works, and all of it rots, for one shared reason: nothing downstream depends on any of it being right.

A wiki page is correct on the day it is written and unfalsifiable afterwards. No build fails when it goes stale. The first person to hit the error is a new starter, who cannot tell a wrong document from their own misunderstanding, so they ask the one person who knows. The risk you were mitigating has just been confirmed, this time with a witness.

Pairing spreads today's context and does little for the decision made fourteen months ago. Ask two engineers who paired all year why a table has a redundant column and you will often get two versions of the same shrug.

Spreading ownership works properly, at a price most companies at raise stage cannot pay. Two people who both understand a system is genuinely twice the resilience. It is also a second salary and a standing tax on both their weeks. At forty engineers, the right answer. At six, a plan to hire your way out of a writing problem.

Conventions short enough to be used

What changed our answer was not writing more. It was keeping the conventions short, in the repository beside the code, and in use. A reviewer cites the rule on the change that breaks it, so a wrong rule turns up that week as a disputed review comment. That gives a convention the property that makes tests useful: it can fail. A wiki page nobody cites on a change never gets that event, and stays wrong quietly until the person it was meant to replace explains it in a meeting.

On a field operations platform we build for a regulated compliance industry, the written engineering conventions open with one short page: what the product is, and the handful of documents to read before touching anything. The rule that closes it carries the weight: a new dependency, a change to the authentication model or a break from anything marked non-negotiable is agreed before it is made, and when the code drifts from the spec, the spec is updated in the same change.

Length is where people go wrong. A ten thousand line architecture document is useless to a new starter. On a healthcare platform we build, the engineering guidance is long, as it has to be, but nobody reads it from the top: a short index sends each type of task to the one or two sections that cover it.

A new engineer starts from the same short page, so the conventions double as onboarding, which is the part worth taking. Keeping it short costs something, mind: every convention has to earn its line, and most of the arguing is about what to delete.

The dated log of things that went wrong

Conventions say how the code should be written. They do not say what bit someone last time.

On the field operations platform, the conventions sit beside a dated log of lessons that grew entry by entry through the build. Most entries record what shipped in a feature area, why it was built that way, and the trap in it: a nested numeric field needs its index rebuilt before the first write, or the row goes missing from the dual write. Nothing in there is profound. Every entry exists because somebody lost an afternoon, and the log is why nobody loses that afternoon twice.

The healthcare platform has the better version of the story, because it went differently from how we planned. We expected its lessons to collect in a log of its own, as they had on the field platform. That repository has no such log. The lessons went one level up instead, into the shared architecture we maintain across the platforms we build, as a list of symptoms and fixes grouped by subsystem that every new build inherits. A local log helps one project and dies with the repository. The shared one is why the next build starts with the last build's scar tissue already in it.

What keeps written conventions from rotting

Two habits keep written conventions current. Changes update the spec in the same commit, so drift becomes a review comment rather than a backlog item. And every disagreement between code and convention counts as two fixes. The code is the cheap one. The correction to the written convention is the one worth the afternoon, because that is what stops the same drift arriving again next quarter.

The practice has a limit. It only covers rules somebody thought to write down, and a check against the conventions says nothing about the rule that is missing.

A reader tests all of this in about an hour, which is worth knowing before somebody does it to you. Read the conventions and time yourself, look through the decision records for a superseded one, then ask when somebody who is not a founder last shipped here. The same hour opens our technical due diligence for startups when a founder asks for it before a raise.

What still leaves in a head

Written conventions raise the floor. They do not touch the ceiling, and it would be a sales pitch to pretend otherwise.

Architecture judgement goes with the person. A decision record captures what we chose and rejected. It cannot make the next call. That one runs on a read of where the business is heading and a read of what this particular team can realistically operate, and neither of those is written down anywhere, in our repositories or anybody else's.

So does knowing which rule is safe to break. On one platform we violate a convention our own shared architecture calls non-negotiable, in about forty places, because the rule was written for a mobile client hitting a single catch-all route and this is a web application that keeps each proxy route next to the feature it serves. We wrote the divergence down with the reasoning. The shared architecture still has not caught up, and that lag is the honest limit of the practice.

No document touches client trust. The person who held an account through a bad quarter did not do it with a specification.

What the writing moves is the mechanical knowledge: most of the volume, almost none of the anxiety. Still enough to change the answer, because the fear underneath the question is not that your CTO is irreplaceable. It is that nobody can tell how much of the company would leave with them.

What founders ask us next

Do instruction files for AI coding tools count as documentation?

They count if they are current. No investor cares about the audience; they care whether the file matches the code. A file the team works from every day, and checks changes against, stays current in a way a wiki rarely does. Show the file and the commit that last changed it.

Our CTO is the only person who has ever deployed. How bad is that?

Bad in a way you can fix in a fortnight, which is the good news. Write the deploy down as steps somebody else can follow, then have that somebody else run the next release while the CTO watches and says nothing. The evidence is a second name in the deployment history, not the document.

We are two engineers at seed. Is key-person risk even in scope?

Yes, and it gets judged differently. Nobody expects redundancy at that size. They expect the knowledge to be recoverable. The question worth answering is what a competent stranger could pick up from the repository in a week without asking anyone.

Can we fix this in the month before a raise?

Partly. A month buys written conventions, decision records, a deploy runbook and a dependency inventory, which is more than most companies at that stage have. It does not buy the dated log of things that went wrong, because those entries only exist if somebody wrote them at the time.