What Happens When a Key Employee Leaves Tomorrow?

What Happens When a Key Employee Leaves Tomorrow?

Most businesses know who the people are that they really rely on.

They are the person everyone rings when something unusual happens. They know why a process works the way it does, which client needs something handled differently, where the problems normally occur and which issue that looks fairly minor is actually worth worrying about.

Those people are incredibly valuable to a business, but they can also become a risk if too much of the way the business operates exists only in their head.

I have seen this plenty of times on projects and in businesses. Someone leaves and suddenly everyone realises just how much they knew. You can replace the position fairly quickly, but replacing the context is much harder.

The question I would ask is not really, "Who is going to do their job?"

It is: "What work, responsibilities and knowledge are we depending on this person to carry for us every day?"

That is where key-person dependency becomes a business-process problem rather than simply an HR problem.

The four-week handover rarely solves it

When someone resigns, the normal response is to start a handover. We ask them to document what they do, update files, brief the next person and make sure everything important is written down before they leave.

There is nothing wrong with doing that, but I think we often expect far too much from it.

Imagine somebody has worked in a role for five years. During that time they have been involved in hundreds of decisions, meetings, problems and exceptions. They know why a deadline moved six months ago, why one supplier needs to be followed up differently, why a particular risk deserves more attention than its rating suggests and why a process contains an unusual extra step.

Now we give them four weeks and ask them to document all of that.

They cannot.

Not because they do not want to, but because much of what they know has become part of the way they work. They may not even recognise some of it as information that somebody else will need until the question comes up six months after they have gone.

For me, the better answer is to capture more of the context while the work is actually happening rather than trying to reconstruct it when somebody resigns.

The position description is only a small part of the story

Take someone like a Project Controls Manager. Their position description might tell you what their formal responsibilities are, but that is only part of what the project actually depends on them for.

They may own several risks, have outstanding Actions from management meetings, be responsible for the monthly reporting cycle, know about a recurring data-quality problem and have several approvals sitting with them. They might understand why particular schedule assumptions were made six months ago, know which contractor needs more follow-up than everyone else and have a collection of recurring tasks that were never formally written down because everybody on the project simply knew they did them.

If that person leaves tomorrow, giving the new person access to their folders does not really solve the problem.

Everything might technically be there, but the new person still has to work out what is current, what is important, what is overdue, what somebody is waiting for and what needs to happen next.

That reconstruction takes time, and while it is happening there is a real chance that something gets missed.

The real problem is losing the context around the work

This is where I think traditional document management and handover processes only get you so far.

Imagine inheriting 100 documents from somebody. Having the files is obviously better than not having them, but what do those files actually tell you?

Which ones relate to something that is still open? Which Actions are overdue? Which risk needs attention? Is somebody waiting for a response? Is there an approval outstanding? Why was the last decision made? What happens next?

A folder does not necessarily tell you any of that.

The information becomes much more valuable when it is connected to the work it supports. An Action should show what created it and who owns it. A risk should retain its history and treatments. A decision should remain connected to the process around it. Evidence should sit with the activity it supports rather than disappearing into somebody's personal filing system.

That is the difference between simply retaining information and retaining organisational context.

Key-person dependency is not just about senior people

It is also easy to assume that key-person risk only exists around executives or highly specialised technical staff. In practice, some of the biggest dependencies can sit in fairly ordinary roles.

An administrator might understand the invoicing process better than anyone else. A project coordinator might know exactly how a complicated monthly report gets assembled. A payroll officer might know every exception that the written procedure does not cover. A site supervisor may have years of practical knowledge about recurring safety issues.

Sometimes it is even a contractor who understands one of the company's systems better than the permanent employees using it.

Seniority does not tell you how difficult somebody is to replace.

A much better test is: If this person disappeared for a month tomorrow, what would stop working properly?

That question tends to expose some interesting dependencies.

Work should leave a history behind it

I do not think the objective should be to make experienced people less important. Their judgement, relationships and experience are still incredibly valuable.

The objective should be to stop making the organisation unnecessarily dependent on information that exists only inside one person's memory or inbox.

When somebody makes an important decision, there should be a record of what happened and why. When an Action is assigned, the owner and context should be clear. When somebody changes roles, the responsibility should not disappear with them. When a risk changes, the history of that risk should still be there for the next person to understand.

Over time, that creates something much more useful than a handover folder. It creates an organisational history around the work itself.

Where WorkMesh fits

This is an area where the way we are building WorkMesh becomes particularly useful.

If the work is being managed through WorkMesh, the system is holding more than just a collection of documents. It can hold the records, Actions, responsibilities, history and supporting information around the process.

That changes the handover question.

Instead of starting with, "Can you tell me everything Gary was doing before he left?", we should be able to start with, "What does Gary currently own, what remains outstanding and what work is connected to those responsibilities?"

That is a much better starting point.

If an Action belongs to a business role rather than permanently to one individual, changing the person performing that role can also make the transition much cleaner. The new person is not starting from an empty inbox and a handover document. They can inherit the work in the context of the process that created it.

The system does not replace the conversation with the outgoing employee, and it does not somehow capture every piece of experience somebody has accumulated over their career. I do not think any system can do that.

What it can do is make sure far less of the operational picture disappears when that person walks out the door.

A simple test for your business

Think about one person in your business who would be particularly difficult to lose tomorrow.

If they did not turn up, how quickly could you work out what they currently own, which Actions are outstanding, which risks or issues they are managing, what decisions are waiting for them and which recurring activities depend on them?

More importantly, could you tell what needs to happen next without spending the first week searching through emails, spreadsheets, folders and meeting minutes?

If the answer is no, there is probably more going on than a succession-planning issue.

You have a process and organisational-knowledge dependency as well.

For me, the objective is not to make people replaceable. Good people matter, and experience matters.

The objective is to build a business that does not lose control of important work simply because circumstances change.

People will leave. People will take holidays. People will change roles. Sometimes somebody will just be unavailable when you need them.

The work and its history should still be there when they are not.

Build better processes. Drive action. Reduce cost.