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. One platform we build was written in roughly twelve weeks by a single engineer working with coding agents, plus a second person making the calls. By any definition that is a bus factor of one, and adding headcount was never the thing that made it survivable.

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 written in a form a machine reads

What changed our answer was not writing more. It was writing in a form that something reads every day.

On a field operations platform we build for a regulated compliance industry, the instruction file at the root of the repository is 57 lines. It says what the product is, names four documents to read before touching anything, and spends a third of its length on writing voice, because the agent drafts specifications and commit messages as well as code. The closing rule carries the weight: ask before adding a dependency, changing the auth model, or breaking a rule marked non-negotiable, and when reality drifts from the spec, update the spec in the same change.

Length is where people go wrong. A ten thousand line architecture document is useless to a coding agent and to a new starter alike. On a healthcare platform we build, the guidance runs to roughly 10,350 lines across 25 reference files, but the entry point is a 163-line router that maps a task type to the one or two files you need.

The file is not written for the machine alone. A new human engineer joins on exactly the same page, which is the part worth taking even if you never run an agent. Keeping it short costs something, mind: every convention has to earn its line, and most of the arguing is about what to delete.

Persistent memory and the file 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, 81 memory files sit beside the instruction file, about a megabyte in total, accumulated over twelve weeks and loaded at the start of every session. An index carries 79 one-line summaries with links, so nothing has to be hunted for. 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 file 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. Its root instructions mandate a local lessons file after any correction from a human, in strong language. There is no lessons file in that repository. What exists instead is a traps file one level up, inside the shared architecture the studio maintains across products: roughly 60 symptom and fix rows across 11 subsystem categories, versioned on its own and pulled into each build as a dependency. A local file 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.

Why written conventions stop rotting when something reads them

The mechanism is boring and it is the whole argument. A document an agent loads every session acquires the property that makes tests useful: it can fail. When the written rule and the code disagree, the agent applies the rule, produces something wrong, and somebody finds out this week. A wiki has no equivalent event. It stays wrong quietly until the person it was meant to replace explains it in a meeting.

Two habits keep that alive. Changes update the spec in the same commit, so drift becomes a review comment rather than a backlog item. And periodically we point an agent at the codebase and ask it to check the code against the architecture we wrote down, which is a blunter exercise than it sounds and has never yet come back empty. The findings we care least about are the code fixes. The ones worth the afternoon are the corrections to the briefing files themselves, because those are what stop the same drift arriving again next quarter.

We have written at length about where coding agents still fail us, and one of those limits lands here. The practice only covers rules somebody thought to write down. An agent applies what is in front of it and will not raise a hand about an absence.

A reader tests all of this in about an hour, which is worth knowing before somebody does it to you. Read the root file and time yourself, look through the decision records for a superseded one, then ask when somebody who is not a founder last shipped here.

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 file 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

Does it help that our documentation is written for coding agents?

It helps that it is written for something that reads it. No investor cares about the audience. They care whether the document is current, and a file a machine consults every session is current in a way a wiki never manages. 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 the instruction file, 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 file of things that went wrong, because those entries only exist if somebody wrote them at the time.