At RingStone, we are regularly asked to assess key-person risks as part of the technical diligence process. Experienced investors are acutely aware that unmitigated key-person risks have the potential to cause serious harm. Yet this is also one of the most overlooked issues at early-stage companies, and in our experience, it is also all too common for growing and mid-stage companies to be overexposed to key-person risks.

In this blog post, we’ll look at some of the most common mistakes we see around key-person risks and what smart companies can do about them. If you’re a founder, this will help you prepare for this area of diligence, and if you’re a deal partner, we hope it will give you helpful questions and talking points for potential targets, based on what we’ve heard from hundreds of companies as they grow.

Mistake #1 - Assuming There Will Be Ample Warnings

If you have 150 staff members, you’ve got at least a 10 percent chance per year of losing one of your team to a disaster.

Probably the most common key-person mistake I’ve seen in my 100+ diligence engagements is that of assuming that a departure will happen with ample warning. That, for example, a team member will give their notice and then be around for a few weeks of friendly and leisurely knowledge transfer. While this is, statistically speaking, the most likely scenario, it ignores the reality of unplanned and sudden disasters.

According to the US National Center for Health Statistics, the number of “unintentional injury deaths” in 2023 was 66.5 per 100,000 people annually, or 0.0665%. However, this figure is for death only, not including incapacitating injuries. So if we factor in incapacitating injury, this means that if you have 150 staff members, you’ve got at least a 10 percent chance per year of losing one of your team to a disaster. We talk in software about the “truck number” to the point that it almost seems like a metaphor. But earlier in my career, a team member was literally hit by a truck while cycling and was hospitalized in a coma for months, cutting her off from any contact immediately. The truck number is real.

Furthermore, sudden departures are not limited to just accidents. I once conducted diligence on a company that had lost contact with an entire development team because of the outbreak of hostilities in Ukraine. The team did eventually get back in touch, but there was over a week of no contact at all, with no knowledge of whether any contact would ever be forthcoming. Other causes of sudden loss of contact include grave sickness, mental health issues, family catastrophes, and natural disasters. All in all, a mature company must ensure that operations can continue if any of their people are, as I like to put it during diligence, abducted by aliens.

Mistake #2 - Assuming Departures Are Isolated Events

Staff frequently leave in clumps. On tight-knit teams, the loss of a development lead who is respected and valued by their reports can quickly lead to further departures.

A second common mistake is assuming that key person risks are isolated. You might think that with more than one developer working on a key area, the risk is under control. And while it’s unlikely that a physical catastrophe will befall all the developers who know a particular area, this assumption neglects the fact that many changes, such as new management practices or job expectations, affect everyone at the same time.

Worse, these kinds of changes are precisely what happen following an acquisition, or even in the lead-up to a sale. In the face of company upheaval, staff frequently leave in clumps. On tight-knit teams, the loss of a development lead who is respected and valued by their reports can quickly lead to further departures.

At one startup where I worked, over three-quarters of the development team left within the first three months following the company being acquired. Additionally, even if staff don’t leave together, the issues created by departures compound. Working as a developer when the people who really know the system have just left isn’t much fun, increasing the odds of a domino effect. The bottom line is that, at a mature company, simply having one or two secondary people is not enough for coverage of critical systems and processes.

Mistake #3 - Allowing Expertise Silos To Develop

While it’s commendable to be concerned that developers are happy in their jobs, allowing specialist silos to develop just because programmers like working that way is optimizing for the individual over the team.

A more insidious mistake is that of inadvertently rewarding people for the key person risks around their roles. The cliché of IT workers making themselves indispensable exists for a reason. In companies where layoffs are common, this can be a viable job protection tactic. Less nefariously, developers often have a favourite type of work and would prefer, given their druthers, to be on a team of specialists where each expert operates in their own, owned area.

While it’s commendable to be concerned that developers are happy in their jobs, allowing specialist silos to develop just because programmers like working that way is optimizing for the individual over the team. Prevention requires leaders to actively look out for knowledge silos before they get established, ensuring every area has multiple contributors. In a healthy company, this should be an easy sell to employees; it’s the same approach that enables employees to fully unplug on their days off.

Mistake #4 - Underestimating The Breadth Of Key Person Risks

Another mistake we’ve witnessed is that of thinking key person risks are only relevant to the development team. However, in any company with ongoing sales relationships, customer-facing roles can be equally problematic. Even though customers may like having “their person”, a policy of ensuring major accounts have interacted with more than one contact prevents key members from holding accounts hostage. It also prevents accounts from dictating your timelines when someone’s not available.

Ensuring all accounts have a primary and secondary contact with whom they regularly interact goes a long way to reducing this risk, and also ensures that customers get timely responses even when team members are sick or otherwise slammed.

Mistake #5 - Waiting Too Long To Document And Automate

Most companies put off documenting for too long, becoming dangerously exposed to shocks as they transition to mid-stage levels of responsibility and maturity.

Given the above, we should all accept that if there are processes that must be operational to keep the company running, they need to be documented. And if a process is needed to just keep the lights on, even a skeleton crew should be able to do it while bringing new members up to speed.

The only truly reliable solution is to ensure that all critical processes are documented to the point that a sufficiently technical reader could replicate the work. Furthermore, there need to be systems in place that allow a new team member to come up to speed with minimal human help. If the documentation is only useful when a senior member is around to show the new member where to look, then it’s not sufficiently documented.

Naturally, this isn’t possible at scrappy startups, so the hard part is deciding at what point in a company’s evolution the unglamorous work of documentation should begin in earnest. In our experience, most companies put off documenting for too long, becoming dangerously exposed to shocks as they transition to mid-stage company levels of responsibility and maturity.

Additional Best Practices To Reduce Key-Person Risks

So, beyond keeping a sharp eye out for these mistakes, what can we be doing to spot, reduce, and mitigate key-person risks? Below are three additional best practices that we’ve seen used successfully in the field.

Tabletop Exercises

Tabletop exercises are a crucial component of robust disaster management and a great way to discover unnoticed key person dependencies. Talking as a group through precisely who does what in various situations almost inevitably reveals oversights and gaps. What is less obvious is that this is worth doing to improve day-to-day operations in addition to disaster recovery scenarios.

Tabletop exercises should be conducted at least annually as part of the disaster management plan, and should incorporate discussion of who does what, even when the disaster is simply a vacation or a cancelled flight home.

Automation And Testing

In the event of a sudden departure, the difference between a few manual steps and a single click can be the difference between meeting and missing your SLA.

Mature companies know that automating quality assurance is a smart investment. Additionally, the process of automating QA is a perfect opportunity to work on disaster prevention and key-person dependencies. Comprehensive automated testing involves replicating and seeding databases, spinning up test infrastructure, and creating repeatable pipelines of well-understood steps, all of which are also necessary for disaster recoveries.

That said, something I’ve noticed in diligence is that companies often automate just far enough to get a good boost in velocity, but not quite enough to ensure that new members can step in unaided. In the event of a sudden departure, the difference between a few manual steps and a single click can be the difference between meeting and missing your SLA. If someone still needs to check the output of each stage … and there is only one of those someones, you still have a problem.

Given this, robust companies should consider automation completed only when it’s at the point that a sufficiently qualified but brand new member can run and validate the automated workflows successfully, solely following the documentation that they can find.

Attending To Culture

If your people feel disposable, they’ll act that way when a better offer appears. If they feel valued, they’ll do their best to make transitions as smooth as possible.

Even with all the automation, documentation, and redundancy we can muster, key-person departures are still going to be disruptive if you’re running anything more complicated than a fast-food joint. Which brings me to the final practice: attending proactively to your company culture. If your people feel disposable, they’ll act that way when a better offer appears. If they feel valued, they’ll do their best to make transitions as smooth as possible.

Of course, this is the topic for a whole book, but we can share one tip that is an all too frequent blind spot: most tech companies don’t collect real employee feedback. You might think you do, but if you’re not getting anonymous feedback, you’re not getting feedback. If employees don’t feel completely safe, you can bet there are things they just won’t say. Something I’ve seen over and over again is smart technical leaders feeling that, as self-described “maverick rock star hackers”, they are somehow above and outside the regular laws of business and human behaviour. I’ve been in meetings where founders brag about how their culture is so good that everyone feels safe providing critical feedback without anonymity. Meanwhile, the body language in the room reveals that this is nonsense. Culture isn’t what we say we do, it’s what we actually do. And the best way to find out what we really do, is to ask for feedback both anonymously and confidentially.

Conclusion

Key-person risks are a reality of working in a field where deep expertise is valuable. But by recognizing the warning signs and the impacts of key-person dependencies, growing companies can significantly reduce the likelihood of disruptions. Furthermore, with proactive practices such as knowledge and role sharing, documentation, automation, and attention to culture, smart leaders can improve their day-to-day operations while also improving their business continuity position. If you’re a growing company and need help assessing organizational weak spots and key-person risks, RingStone can help.

About The Author

Iain C.T. Duncan has spent the last 20 years working in the software industry as a CTO, developer, software architect, and consultant, building B2B and internal web applications at startups, agencies, and early-stage companies in Canada and the U.S.

As a practitioner at RingStone, he works with private equity firms globally in an advisory capacity, conducting technical diligence on early and mid-stage companies and preparing companies for the diligence process. He has worked in the diligence sector for seven years and has been involved in hundreds of diligence efforts as a practitioner, reviewer, and trainer. Previous to the diligence sector, he worked on software in the spaces of e-commerce, association management, non-profit fundraising, genomics, and online education, among others.

Iain is an interdisciplinary PhD candidate in Computer Science and Music at the University of Victoria, working on applications of Scheme Lisp to algorithmic music and music pedagogy. He is the author of the Scheme for Max open-source programming extension to the Max/MSP audio programming platform, the developer of online music education tools, and an active musical performer in BC, Canada.