How exposed are we if the one person who understands our system disappears?
Measure it concretely: pick a recent change and ask whether anyone else could have made it using only what is written down. Exposure is not about headcount, it is about whether knowledge exists outside one head. The fastest reduction is not hiring a second developer — it is a documented deployment path, credentials your company controls, and a second person who has actually shipped a change.
The exposure is usually not the code
Owners picture the risk as nobody can read the code. In practice code is the most recoverable part. A competent developer can read unfamiliar code, slowly but reliably.
What actually strands people is everything around the code: which server it runs on, how a release gets deployed, where the credentials are, which scheduled jobs exist and what they do, and which of the four databases is the live one. None of that is in the repository unless someone put it there deliberately.
A concrete way to measure it
Take a change made in the last month. Hand the request to someone who did not make it — an internal technical person or an outside developer — and give them only the repository and the documentation. Do not let them ask the original author.
Time how long it takes them to get the system running locally, find the right file, and describe the change they would make. You do not have to let them ship it. The exercise surfaces the gaps precisely, and the list of things they had to ask about is your remediation plan.
Cheap reductions that work
None of these require hiring anyone. They are the cheapest risk reduction available on any custom system, and each can be done in an afternoon.
- A runbook in the repository. How to run it, how to deploy it, what breaks routinely and what to do about it.
- Credentials in a company-owned vault. Not in a developer's password manager, not in a config file on one laptop.
- Infrastructure accounts billed to the company. An expired card on a personal account has taken down more small systems than bad code has.
- One recorded walkthrough. Thirty minutes of the author narrating the architecture is worth more than most written documentation and takes far less effort to produce.
- A second person who has deployed once. Reading about it is not the same as having done it.
Where AI systems add a wrinkle
With AI components, an unusual amount of value lives outside the code — in prompts, rubrics, thresholds, and the accumulated tuning that made output trustworthy. Those are frequently the least documented and the most personal to whoever built them.
Insist that configuration lives in version control with comments explaining why a threshold is set where it is, and that evaluation examples are stored alongside. That is part of what makes custom AI work maintainable rather than magic, and it applies just as much to a productized deployment as to a bespoke build. If you cannot find your rubric definitions in a repository today, that is your first task, not your developer's.
Topics: risk · documentation · handoff · operations
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.