A Process Is Not a Backup Plan: How to Make Critical Work Transferable
Imagine one of the most important people in your business is unexpectedly unavailable for two weeks.
Perhaps they are your Operations Manager, senior consultant, estimator, project manager, financial controller or one of your most experienced technical people.
There is a procedure for what they do.
Someone else has watched them perform the work.
The files are all there.
Yet within a day or two, questions start appearing.
A customer needs something slightly unusual. A deadline may need to move. An employee is unsure whether they can approve a decision. A problem arises that is not covered neatly by the procedure.
Before long, those questions start finding their way back to you.
Eventually, you step in.
The work gets done, the customer is looked after and the immediate problem disappears.
But you may also have discovered something important:
A documented process is not necessarily a backup plan.
Documentation records how work should happen.
Transferability demonstrates that your business can still produce the required outcome when the person who normally carries the work is unavailable.
Those are very different things.
A Documented Process and a Transferable Capability Are Not the Same Thing
Process documentation matters.
A good standard operating procedure, checklist or workflow can capture:
the steps involved;
the order in which things happen;
the systems used;
the people responsible for different activities;
recurring deadlines;
important checks.
But there is a higher standard worth considering:
Could another appropriate person produce the required result, to the required standard, without the normal person being there?
If the answer is no, you may have documented the work without making it transferable.
I think of the distinction this way:
Process = information.
Transferability = demonstrated organisational capability.
A procedure sitting in a folder tells you that something has been written down.
It does not tell you whether somebody else can use it successfully when it matters.
Why Critical Work Becomes Attached to Particular People
Experienced people rarely operate from written instructions alone.
Over time, they accumulate knowledge.
They know which customers need extra attention. They know what good work looks like. They know which deadline can move and which one cannot.
They can often sense when a small problem is likely to become a large one.
They also understand which mistakes can be corrected later and which need to be escalated immediately.
Much of this knowledge eventually becomes instinctive.
That means an important role may contain several different forms of knowledge:
Explicit knowledge: The steps, forms, templates, checklists and procedures that can be written down.
Standards: What a good result looks like, including the quality, accuracy, timing and customer expectations that matter.
Judgement: How an experienced person decides what to do when there is more than one reasonable option.
Context: Why one customer, project or situation might need to be treated differently from another.
Exception handling: What to do when reality does not follow the normal process.
A procedure may cover the routine work reasonably well.
The real dependency often becomes visible when something falls outside the routine.
What happens when a customer asks for an exception?
What happens when a project falls behind?
What happens when two important priorities conflict?
What happens when a number sits outside the expected range?
What happens when somebody needs to make a judgement call?
That is where supposedly delegated work often starts travelling back up the organisation.
Not every dependency is a problem
The objective is not to make every employee interchangeable.
Some work may properly remain with a particular director, licence holder, registered professional, technical specialist or authorised decision-maker.
Certain approvals may also be restricted by legal, professional, contractual or internal-control requirements.
Those dependencies need to be recognised and managed deliberately.
The goal is not to eliminate every form of key-person dependence.
It is to:
identify unnecessary dependence; and
build appropriate continuity around the dependence that genuinely needs to remain.
Start With the Work That Cannot Afford to Depend on One Person
For most businesses, cross-training everybody in everything would be expensive and inefficient.
Some work can safely wait.
If the person who prepares an internal monthly report is away for several days, the consequences may be manageable.
Other work may be much more important.
A critical customer deliverable, payroll process, technical approval, quoting function, project handover or operational decision may carry a very different risk.
Before trying to make everything transferable, identify the work that matters most.
Ask:
If this person became unavailable for two weeks, what would stop?
What would materially affect customers?
What could delay revenue or cash collection?
What could expose the business to financial, reputational or regulatory risk?
What work would immediately come back to me?
What could nobody else currently complete with confidence?
These are your critical dependencies.
Prioritise them by consequence, not convenience.
That gives you a sensible place to begin.
The Six-Question Transferability Test
Once you have identified one important dependency, run it through the following six questions.
1. Is There a Named Backup Owner?
A common backup plan sounds like this:
“Someone else in the team could probably handle it.”
Who?
If the usual person is unavailable tomorrow morning, who specifically owns making sure the outcome still happens?
There is a difference between someone who:
knows something about the work;
occasionally assists with it;
has watched it being performed;
and is accountable for getting the outcome delivered.
A backup should be identified before the absence occurs.
For an important function, both the primary person and the backup should be able to answer:
“If the primary person is unavailable, who owns this?”
If the answer is unclear, you may have an assumption rather than a dependable backup arrangement.
2. Do They Know What Good Looks Like?
A checklist can tell somebody what to do without telling them what a good result looks like.
Imagine a professional services firm has a documented process for preparing a client report.
The procedure might say:
Gather the required information.
Complete the analysis.
Prepare the report.
Review it.
Send it to the client.
Technically, the process has been documented.
But several important questions remain.
What constitutes good analysis?
Which errors are unacceptable?
What requires a second review?
What does the customer expect to see?
Which deadlines are genuinely non-negotiable?
A capable backup needs to understand the required standard, not merely the sequence of activities.
That may mean capturing:
quality requirements;
acceptable tolerances;
customer expectations;
important deadlines;
non-negotiables;
common mistakes;
examples of acceptable and unacceptable work.
Ask:
Could the backup recognise a good result without the usual person standing beside them?
If not, the steps may be clear while the standard remains trapped inside somebody’s head.
3. Do They Know How to Decide When the Normal Process Does Not Apply?
This is where many process-improvement projects stop too early.
The procedure explains what normally happens.
Business does not always behave normally.
The next question is therefore:
Does the backup understand how to make a sound decision when the usual rule no longer fits the situation?
For example:
When can a deadline move?
When should a customer issue be escalated?
What size discount can be approved without further permission?
What level of project risk requires immediate attention?
When should work be returned for rework?
When can a reasonable exception be made?
When should the person stop and seek help?
You cannot write a procedure for every possible scenario.
Nor should you try.
A long manual that nobody uses is not necessarily more valuable than a shorter guide that helps people exercise sound judgement.
The aim is to capture enough of the principles, thresholds and decision rules behind the work for another person to respond appropriately.
Consider an Operations Manager overseeing project delivery.
Instead of trying to document every possible delay, the business might establish rules such as:
short internal delays can be managed within the delivery team;
anything likely to affect a committed customer deadline must be raised early;
external expenditure above an agreed amount requires approval;
contractual, safety or significant reputational issues are escalated immediately.
Those boundaries transfer some of the judgement behind the process without pretending every situation can be predicted.
4. Do They Have the Access and Authority to Act?
Sometimes the backup understands what needs to happen but cannot act.
They may lack the correct system permissions, customer information, supplier contacts, approval limits or authority to move resources.
As a result, nearly every meaningful decision still needs to be passed upwards.
That creates the appearance of delegation without the ability to execute it.
Ask:
If the usual person became unavailable tomorrow, could the backup access what they need and make the routine decisions required to keep the work moving?
Check:
individual system access and permissions;
relevant files and templates;
supplier and customer information;
approval levels;
spending limits;
escalation contacts;
secure access to any required credentials.
Individual access should be established through the business’s approved security and credential-management processes rather than by relying on another person’s login.
Authority should also remain within any legal, licensing, professional, contractual or internal-control requirements that properly restrict who may make particular decisions.
Backup capability does not mean abandoning sensible controls.
For example, payroll, banking and payment processes may still require:
segregation of duties;
independent review;
dual approval;
clearly defined financial limits.
The goal is appropriate autonomy within clear and secure boundaries.
5. Have They Actually Performed the Work?
A common assumption is:
“They’ve seen me do it plenty of times.”
Observation is not competence.
Watching somebody manage a difficult customer conversation is not the same as conducting one yourself.
Seeing an experienced project manager reallocate resources is not the same as making the decision when several projects are under pressure at once.
Reading a procedure is also not the same as executing it.
A useful development sequence is:
Observe → Assist → Perform with support → Perform independently → Handle an exception
The further the person progresses through that sequence, the more confidence you can reasonably have in the arrangement.
For low-risk work, the progression may happen quickly.
For complex, technical or commercially sensitive work, it may take considerably longer.
The important point is that capability should be demonstrated.
If the person has never performed the work, you know that information has been shared.
You do not yet know whether the capability has been transferred.
6. Have You Tested the Arrangement Without the Usual Person?
If the first genuine test of your backup arrangement happens during an emergency, you are learning at the most expensive possible time.
A better approach is to create a controlled test.
Depending on the work involved, the usual person might step away from:
one recurring task;
one customer account;
one project;
half a day;
a full day;
eventually, several days.
The test should be proportionate to the risk.
Define in advance:
what the backup owns;
what they can decide;
what must still be escalated;
the circumstances in which the usual person should be contacted.
The aim is not to create unnecessary risk or interfere with legal, customer or professional requirements.
It is to discover what still depends on the usual person while the stakes are manageable.
After the test, review what happened:
What stopped?
What questions arose?
What information was missing?
Which decisions created uncertainty?
What still required escalation?
Where did the quality change?
What unexpectedly came back to the owner?
What should be improved before the next test?
This turns absence into something useful.
Absence is not merely a risk. In controlled doses, it can be a diagnostic.
The gaps you discover are not necessarily failures.
They are information about what still needs to be transferred.
The Real Backup Plan Is a Loop, Not a Folder
A process should not be considered complete simply because somebody has written it down.
A more useful model is:
Document → Train → Practise → Test → Review → Improve
Document
Capture the important steps, standards, information and decision rules.
Train
Explain the reasoning behind the process, not merely which buttons to press.
Practise
Give the backup genuine opportunities to perform the work.
Test
Allow the arrangement to operate without the usual person carrying it.
Review
Identify what worked and where dependence still remains.
Improve
Update the process, development plan, access or authority arrangements based on what you discovered.
Then repeat the loop where the consequences justify it.
The document is part of the system.
It is not the whole system.
Beware of the Owner Becoming the Backup Plan
There is another trap worth watching.
One of your key people becomes unexpectedly unavailable. The designated backup starts doing the work but reaches something they cannot handle.
Who steps in?
You do.
The customer is looked after, the deadline is met and the business continues.
From the outside, the backup plan may appear to have worked.
Look more closely, however:
Key person unavailable
↓
Backup gets stuck
↓
Owner takes over
The owner remains the final operating safety net.
This can conceal weaknesses because capable owners are often very good at rescuing situations.
You understand the customer. You know the technical work. You can make the decision quickly.
In a genuine emergency, stepping in may be exactly the right response.
The problem arises when rescue becomes the normal mechanism keeping an inadequate system functioning.
Once the immediate issue has been contained, ask:
Why did this need me?
Was the process unclear?
Was the required standard unclear?
Had the judgement behind the process never been transferred?
Did the person lack access or authority?
Did they lack the necessary capability?
Was there no suitable backup in the first place?
The answer tells you where the operating model needs strengthening.
Start With One Critical Outcome This Week
Do not begin by launching a six-month project to document the entire business.
Start with one important dependency.
Ask yourself:
If one person became unexpectedly unavailable for two weeks, which absence would concern me most?
Identify the critical outcome attached to that person.
Then run it through the Six-Question Transferability Test:
Is there a named backup owner?
Do they know what good looks like?
Do they know how to decide when the normal process does not apply?
Do they have the appropriate access and authority?
Have they actually performed the work?
Has the arrangement been tested without the usual person carrying it?
The test may reveal that you need:
better documentation;
clearer standards;
more explicit decision rules;
additional training;
different access or approval arrangements;
more opportunities to practise;
another team member;
or a genuine capability or role-fit conversation.
Different gaps require different responses.
That is why the diagnostic matters.
A good process is valuable, but the objective is not to create an impressive library of procedures.
The objective is to build an organisation where important work can continue to the required standard even when a particular person is unavailable.
That does not require every person to become interchangeable.
It means reducing unnecessary dependency, deliberately managing the dependency that must remain, and making the owner less likely to become the automatic backstop whenever something unexpected occurs.
You cannot be very confident in a backup arrangement until the business has shown that it can work without the person who normally carries it.
If running the Six-Question Transferability Test exposes several important dependencies and you are unsure which one to tackle first, that is the type of operating-model problem I help established business owners work through.
You can learn more or book a conversation with me here:
