How to reduce key person dependency before someone resigns

A resignation letter lands on a Tuesday, and by Wednesday someone notices that only one person knew how the month-end export worked, or which engineer could safely upgrade the cluster. Nobody was careless. The work had sat with one person for so long that it stopped looking like a risk.

That is key person dependency: a critical skill, system or relationship that nobody else can handle. The person who holds it is a single point of failure, because when they leave, retire or go on long leave, the process they hold slows down or stops. The word critical matters. Plenty of skills have one holder and nobody would notice if they went, so the job is to find the ones the business would feel.

These dependencies form quietly. The person who set up a system becomes the person who fixes it, then the person who explains it, and each step feels efficient at the time. Nothing flags the risk until the day that person is not there, so you need a routine for looking. You can start one today with a spreadsheet, or take a quick first pass on up to six skills with our one-resignation check.

Warning signs you already have one

Before you count anything, look for signs that a dependency already exists. The first is in your incident history: take the last 10 times something went wrong in one area and note who ended up being called. If it is the same person each time, that person is holding the skill alone, and often it is the quiet expert everyone asks first. Treat the sentence "she just knows that system" as an alert.

The second sign is in the calendar. Some tasks get pushed to "when Sam is back". A release, a customer migration or a supplier call that cannot move for 2 weeks is showing you, on a small scale, what a long leave would do.

The third is in the documentation. If the only description of how something works is in one person's head, or in a script nobody else has opened, the knowledge cannot move even when someone wants to learn it. Ask the team where the instructions live. A long pause is your answer.

The fourth sign comes from a holiday. Most teams treat a holder's holiday as something to work around. It works better as a test: before the person goes, agree that nobody contacts them, then write down every task that stalls or needs a workaround. That list is more honest than anything people will tell you in a meeting, and it costs nothing to collect. Add every candidate these signs give you to the starting list for the count.

Find them with a three-column count

The method needs one sheet and three columns. It does not need a finished skills framework, and a rough count you complete is worth more than a perfect one you abandon. MuchSkills started the same way: Noel Braganza, our co-founder, kept his team's skills in a colour-coded Google Sheet at his previous studio, so we know how far a plain sheet can take one team.

The first column lists the critical skills. Start with the work that would hurt if it stopped for a fortnight: running production, closing the books, supporting your largest customer, passing an audit. Break each into the skills, systems and relationships it depends on, such as "Kubernetes upgrades" or "the contact at the hosting provider". Aim for 15 to 40 rows for one team, because longer lists rarely get finished.

Next, record who could do each skill today without help, and how well. A 1 to 9 scale works, with beginner, intermediate and expert as bands on it. Count only people who could run the task alone when it matters, which here means a level of 6 or above, since someone who has watched it twice is not a holder. A skill with three beginners and no expert still has nobody to rely on, and this column is where that shows.

Last comes time: ask the holder and their manager how long it would take to bring a capable colleague to the same level: 2 weeks, 3 months, a year. These are estimates, and holders often underestimate because the task feels easy to them, so round up. The number tells you how much warning you need. A 2-week skill can be covered after someone hands in their notice; a 6-month skill cannot.

You can build this in a blank sheet or start from the skill gap analysis template. It works well for one team of 10 or 20 people. The one-resignation check asks the same three questions for up to six skills, so it is a quick way to test the rows you are least sure of.

Rank by holders, build time and impact together

With the count done you will probably have a dozen rows that look worrying, and you cannot fix a dozen at once. Score each row from 1 to 3 on three questions, then multiply the scores, which gives a range from 1 to 27. These scores are separate from the 1 to 9 levels in your count: the level only decides who counts as a holder (6 or above), and the 1 to 3 scores rank the risk.

A simple scoring scale

Multiplying matters because a low score on any one question pulls the row down. A skill with one holder, a 2-week build time and low impact scores 3, so it can wait, because you could recover from losing it. Ranking on holders alone would have sent you after it first. In most teams two or three rows score far above the rest, and those are your priorities for this quarter.

A worked example with an invented team

Here is the whole method on one team, and everything in it is invented: the people, the skills and the scores. Take a platform team of 6 with five critical skills. Levels are on the 1 to 9 scale, and only people at 6 or above count as holders. The first four rows are the ones from the sample count above, with a fifth added, and the table adds the impact of each skill stopping, the score from the ranking step and the resulting rank.

Invented example: count and ranking for a 6-person platform team

Incident command has high impact but three holders and a short build time, so it falls to the bottom. Kubernetes upgrades score 3 on all three questions, and the legacy billing batch job and the payment reconciliation scripts follow. Those three rows are where this team's knowledge transfer starts.

How to reduce key person dependency with a knowledge transfer plan

There are five ways to reduce key person dependency, and each is a form of knowledge transfer. Work through them from quickest to slowest, because the quick steps protect you while the slow ones take effect.

Document. Ask the holder to write a short runbook or record a walkthrough: how the task works, where things live, what goes wrong. In the example, Jon would write the runbook for the legacy billing batch job. It takes days and captures knowledge while the person is still here. A document on its own makes nobody competent, though, and it goes stale, so treat it as the starting point for the next steps.

Pair. Have a second person shadow the holder on real work, then do the task with the holder watching. Marcus, at 5 on Kubernetes, could shadow Priya on the next cluster upgrade, then run a step himself. Pairing turns the document into practice and shows which parts the document missed.

Mentor. For skills that need judgement, set a regular slot where the holder coaches a chosen successor over several weeks. Tom could spend an hour a week with a colleague on the payment reconciliation scripts, going through which mismatches matter. It takes more of the holder's time, so keep it for the highest-scoring rows.

Train. Where the skill is common in the market, such as a cloud platform, formal training or a certification can bring someone to a working level without drawing on the holder. A cloud platform certification for Marcus, alongside the pairing on Kubernetes upgrades, would be one example.

Hire. Hiring is the slowest and most expensive option, so it goes last. Use it when nobody inside can reasonably build the skill, or when the work is too much for one person even after you have spread it. None of the five rows in the example needs it, since every row has an internal candidate.

Whichever step you start with, the holder's goodwill decides how well it works. Some holders hear "knowledge transfer" as "we are planning to replace you", and a holder who feels threatened will hand over a thin runbook. Most are also the people who never get a quiet holiday. Start by asking what they would like to stop being called about, and frame the work as giving that back to them. Then pick the person closest to stepping in: someone at 4 on the 1 to 9 scale needs mentoring, while someone at 1 needs documentation and pairing first.

Put together, the example team's plan is short. Priya, Jon and Tom each write a runbook this month, Marcus pairs with Priya on the next upgrade because he is closest to stepping in, and nobody is hired. The team re-scores the sheet next quarter to see whether any holder count has moved from 1 to 2.

Re-check every quarter, and after every change

We recommend repeating the count every quarter, and again after any leaver, reorganisation or new project, because each of those changes who holds what. The second pass is much quicker than the first, since you are updating rows rather than building the list. Keep the scores from each round, so you can see whether a risk is shrinking or whether the runbook was written and nothing else happened.

Share those scores beyond the team. The rows at the top of your sheet are rarely a surprise to the people doing the work. They are a surprise to the people who plan around them, who assign the projects, approve the leave and promise the dates. Show them the scored list and the gap between what the team knows and what the plan assumes becomes visible.

The sheet gets harder once it covers several teams and sites. It is a small skills matrix, and like most spreadsheet matrices it drifts: each team keeps its own copy, a 6 means different things in each, and the copies go stale because one person updates them. MuchSkills helps at that point, with one shared 1 to 9 scale across teams and sites, so you can count holders per skill and level and see who is closest to the level needed.

Takeaways

Count only the critical skills with one holder; a single holder on a skill nobody depends on can wait.

A planned holiday is the cheapest test you have, so use it on purpose.

Count holders at a working level, because three beginners equal nobody.

Multiply holders, build time and impact so one low score pulls a row down.

Speak to the holder before you plan the transfer.

A document is the first step of knowledge transfer and is never enough on its own.