Key person dependency in technical due diligence
Key person dependency is the risk that critical knowledge, systems or responsibilities sit with one or two individuals. Buyers care because they are paying for a business that must keep working after completion, often while the people concerned are negotiating their own future. Due diligence finds it through interviews, code history and access records. Management reduces it by spreading knowledge and responsibility well before a deal, not by documenting it at the last minute.
For seven years I was CTO of iamproperty, and for a good part of that time I was one of the key people a buyer would have worried about. It is an uncomfortable thing to recognise in yourself, because the knowledge that makes you valuable is the same knowledge that makes the business fragile. These days, at Stable State, I help founders and technology leaders find those dependencies and reduce them before a deal. Here is what buyers look for, with a few anonymised stories from that work.
Why buyers care
- Continuity. If one person leaves, can the business still release, recover from an incident or deliver the roadmap?
- Timing. Founders and technical leaders often change roles, earn out or leave after a transaction, exactly when the buyer needs stability.
- Cost. Retaining critical individuals may require packages the buyer had not planned for.
- Leverage. A person the deal cannot proceed without has a strong negotiating position of their own.
From experience: A founder I worked with was sure the business could run without their CTO for a month. Then the CTO went on a long-planned holiday, a payment provider changed an API, and nobody else knew how the integration worked. Three days of failed payments later, the CTO was fixing it from a hotel room. The founder told me afterwards that a buyer would have asked exactly the question they had been avoiding: what happens if this person is not here?
Where it usually sits
- A founding CTO who wrote the core of the platform and still holds its design in their head.
- One engineer with production access who handles every release and every incident.
- A contractor or agency that owns a critical component, with no in-house knowledge of it.
- A product or operations person who is the only one who understands a complex area of the business logic.
- A single relationship with a critical supplier.
From experience: At one client the platform was in good shape, but the billing engine had been built years earlier by a contractor who still invoiced for a few days each month. Nobody in the team had ever changed it, and the contract said nothing about handover. If that contractor had decided to stop, the business would have lost the ability to change its own pricing. Bringing that knowledge in-house took two engineers the best part of a quarter.
How due diligence identifies it
It rarely appears in documents. Reviewers find it by triangulating several sources:
- Interviews. Asking different people who they go to when something breaks, and hearing the same name each time.
- Code history. Who changes the critical parts of the codebase, and whether anyone else ever does.
- Access. Who holds production, administrative and infrastructure credentials.
- Operational records. Who handles releases, on-call and incidents in practice.
- Documentation gaps. Areas where the only documentation is a person.
From experience: In one assessment I asked six people, separately, who they would call if the platform went down at two in the morning. All six gave the same name, and so did the person whose name it was. The code history told the same story: every change to the deployment pipeline in eighteen months had come from one engineer. Nothing in the documentation suggested a problem. The interviews made it obvious in an afternoon.
Reducing it before a transaction
Real reduction takes months, which is why it should start 12 to 18 months before a deal.
- Pair and rotate. Have others work alongside key people on critical systems, and rotate releases and incident response.
- Write down the critical paths. Architecture decisions, runbooks for recovery and deployment, and the reasoning behind unusual design choices.
- Share access properly. Move from personal credentials to managed, audited access held by more than one person.
- Build a second layer. Develop or hire a credible deputy beneath each critical role.
- Bring outsourced knowledge in. Make sure contracts require proper handover, and that someone in-house understands what the agency owns.
- Retain deliberately. Put sensible retention arrangements in place for the people who remain genuinely critical.
From experience: One CTO I advised was the only person who released to production, and had been for four years. We put the rest of the team on a rota, with the CTO pairing on the first few releases and then stepping back. The first month was slower and a little nervous. By the third, releases were going out more often than before, and the CTO had their evenings back. When the buyer's reviewer later asked who handled releases, the answer was a rota with six names on it and a year of records to prove it.
What does not work
- A documentation sprint during due diligence. Buyers can tell, and it does not change who actually knows how things work.
- Retention payments on their own. They keep a person in place without reducing the dependency.
- Claiming the problem is solved. If every interview still names the same person, the claim will not survive.
From experience: A business I was asked to look at during a sale had spent the three weeks before due diligence writing documentation. There were dozens of new pages, all dated within the same fortnight and all written by the same person, the one the business depended on. The buyer's reviewer noticed the dates straight away. The documents were perfectly good, but they confirmed the dependency rather than reducing it.
How to show it has been reduced
- Release and incident records showing several people handling both.
- Code history showing critical areas changed by more than one engineer.
- Runbooks that have actually been used, not just written.
- An organisation chart with depth beneath each critical role.
Being the person everyone calls feels like a compliment, and in a way it is. But the most useful thing I did as a CTO was to make myself less necessary, and the businesses I have seen sell well since are the ones whose key people did the same, well before anyone asked them to.
Key person dependency is one of the six areas a ClearView assessment looks at under Team. Find it 18 months before the deal and it is fixable. Find it in due diligence and it becomes a deal issue.
For the wider picture, see the Technology Exit Readiness guide. Investors assessing a target can read how Stable State approaches technical due diligence.
Is your technology in one person's head?
ClearView will show you where the dependencies are and what to do about them, in two weeks.