The standard advice is to write everything down. Process documents, runbooks, a handover file per person. We tried a version of this early and it decayed within weeks.
The reason is simple. Documentation describes a system as it was on the day someone wrote about it. In a company shipping continuously, that is a snapshot of a moving object. Six weeks later the document is subtly wrong, which is worse than absent, because the next person trusts it.
The second problem is that documentation captures the steps and loses the judgement. Anyone can follow instructions for deploying a change. What matters is knowing which changes are safe to ship on a Friday, which third party breaks under load, and which user complaint signals a real defect rather than confusion. None of that survives being written down, and it is the part you actually lose when a person leaves.
So we stopped trying to write our way out and changed what we were building instead.
Reduce the surface a person has to hold
The single most effective thing we did was decide, deliberately, to own less.
We build the interface, the wallet, the cross-chain plumbing and the AI layer. Perpetuals route to Hyperliquid via builder codes. Prediction markets route to Polymarket. That started as a speed decision, Succession planning gets filed under things large companies do. Board seats, named deputies, a document in a drawer that nobody reads until the week it matters.
I run a three-person company, and the version of this problem we have is more acute than anything a large organisation faces. If one of us disappeared tomorrow, a third of everything we know how to do would leave with them. There is no bench. There is no second person who has touched that system. The concentration risk that a large firm spreads across departments sits, in our case, inside three heads.
What surprised me is that the fix had almost nothing to do with documentation.but the succession effect turned out to be larger than the speed effect. Every system we route to is a system nobody here has to carry in their head, and it is a system that keeps working on the day someone is unavailable.
Compare that with the alternative. Had we built our own matching engine, one person would inevitably have become the person who understood it. That is a permanent dependency, created by us, in exchange for infrastructure we could have rented. The bus factor of a company is not fixed by nature. It is a consequence of what you chose to build.
I would put it this way. Every bespoke system you own is a person you cannot afford to lose.
Rotate the things you cannot route
Some knowledge cannot be outsourced. Custody design, security decisions, why the product works the way it does. That has to live internally.
For those, the discipline is rotation rather than documentation. We make sure no surface has only ever been touched by one of us. It is slower in the short run, because the person who knows the area could obviously do the task faster. The point is that speed on a single task is not what we are optimising. We are trying to avoid a situation where a single absence stops the product.
This also has a benefit nobody warns you about. The moment a second person works on something, the first person’s assumptions get questioned. A meaningful share of the design decisions we later reversed were caught this way, not in review.
What actually needs writing down
I am not arguing against documentation. I am arguing about what belongs in it.
Do not document how a system works. The code does that, and the document will drift. Document the decisions instead. Why we route this rather than build it. Why custody is structured the way it is. What we tried before and rejected, and what would have to change for us to revisit it.
Decisions age far better than descriptions. A rationale from a year ago is still useful even when the implementation has changed completely, because the next person can tell whether the reasoning still holds. A procedure from a year ago is usually just wrong.
Keep the list short enough that it gets maintained. Ours would fit in a few pages, and it is the only internal document I would fight to keep current.
Where this applies beyond a company our size
None of this is specific to three people. Any business where a handful of individuals carry disproportionate operational knowledge has the same exposure, and most owner-led companies are in exactly that position without describing it that way.
The questions transfer directly. Which systems did we build that we could have rented, and what dependency did that create? Which areas has exactly one person ever touched? If that person were unavailable for a month, what specifically stops, and have we tested that rather than assumed it? And are we recording decisions, or only procedures?
Final takeaway. Succession planning in a small company is not an HR exercise to be completed and filed. It is a set of architectural choices about what you own, who has touched it, and what you wrote down about why. Make those choices well and the plan is mostly unnecessary. Make them badly and no document will save you.
Be the first to comment