If the Process Still Needs a Translator, It Hasn’t Been Transferred

The SOP exists.

It is current.

It has screenshots.

Owners are named.

Steps are numbered.

A new employee opens it and begins.

Five minutes later:

“What does ‘review the request’ mean here?”

The author explains.

Ten minutes later:

“It says escalate unusual cases. What counts as unusual?”

The author explains.

Then:

“Which version should be used if the client has already approved something verbally?”

Another explanation.

The employee finishes the process successfully.

The documentation appears to have worked.

Except something else did most of the work.

The author was still in the room.

Not necessarily physically.

Perhaps on Slack.

Perhaps beside the employee on a call.

Perhaps answering questions from another floor.

But the process still required somebody who knew what the document meant to translate it into action.

The knowledge may have been documented.

It has not yet been fully transferred.

Documentation can preserve the steps and lose the meaning

This is one reason process documentation often creates false confidence.

The visible sequence is captured.

Open this.

Check that.

Send this.

Approve that.

Move the record.

Notify the customer.

The document may be completely accurate.

But experienced employees rarely execute only the visible sequence.

They also know:

what “good enough” looks like;

which information deserves suspicion;

when a normal step should be skipped;

which deadline is actually rigid;

what a particular customer phrase usually signals;

when a missing item matters and when it does not;

which exception is routine;

and which apparently small exception should stop the work.

Those things may never appear in the step list.

Not because someone forgot to document them.

Sometimes because the author no longer notices they know them.

Expertise has compressed the reasoning.

What once required conscious thought now feels obvious.

So the author writes:

Review for completeness.

And believes the process has been captured.

The new employee encounters a much harder instruction.

Know what complete means.

The translator supplies what the process forgot

Watch what happens when the author remains nearby.

The employee asks:

“Can this proceed without the purchase order?”

The author says:

“Normally no, but this customer is different.”

Translation.

The SOP says:

“Escalate if the request is commercially significant.”

The employee asks:

“How significant?”

The author says:

“Anything that materially changes margin or creates a precedent.”

Translation.

The document says:

“Confirm the final version with the client.”

The employee asks:

“Email confirmation?”

The author says:

“For most clients, yes. For these three accounts, the signed portal approval is the actual control.”

Translation.

Each answer appears small.

Collectively, they reveal the real process.

The document contains the syntax.

The author is supplying the semantics.

That is translator dependency.

A process can survive the author and still depend on them

This distinction is subtle.

The usual key-person test asks:

What happens if this person leaves?

Useful question.

But dependency appears earlier than resignation.

The process may already be distributed across the team.

Several people may perform it.

The SOP may already exist.

Nothing stops when the original author takes a day off.

And yet unusual cases keep returning to them.

New employees still need them to explain what phrases mean.

Managers still ask whether a situation “counts.”

The team can reproduce the sequence.

It cannot yet reproduce the interpretation.

That is a more mature form of dependency because it hides behind apparent delegation.

The work has moved.

The meaning has not.

Instructions are only one layer of transfer

Process transfer usually involves several different things.

The first is obvious:

Sequence.

What happens first?

What happens next?

Who does it?

Where?

With which tool?

This is what most SOPs capture well.

Then comes:

Standard.

What does acceptable output look like?

How much accuracy is enough?

What constitutes complete?

What quality threshold must be met before the next step begins?

Then:

Decision logic.

What information changes the choice?

What trade-off is being made?

Which conditions matter?

Then:

Boundary recognition.

When does the normal process stop being appropriate?

When is the case no longer routine?

And finally:

Judgment.

What remains genuinely difficult even after the other layers are clear?

A business that documents only the first layer has recorded instructions.

It has not necessarily transferred the process.

“Use judgment” is often where process design gives up

There are situations where judgment genuinely belongs.

A difficult commercial negotiation.

A sensitive people decision.

A novel technical issue.

An ambiguous customer situation where several objectives conflict.

Trying to reduce those decisions to rigid rules can make the organisation worse.

But “use judgment” can also become a convenient hiding place.

Sometimes the required judgment is not inherently sophisticated.

The organisation simply never made its criteria explicit.

“Use judgment on discounting.”

Does that mean:

protect margin?

protect strategic relationships?

avoid setting precedent?

consider customer lifetime value?

stay within a percentage threshold?

ask what caused the request?

All of the above?

If the author knows how to balance those things but everyone else has to ask them, the organisation has not preserved judgment.

It has preserved access to the judge.

Those are not the same thing.

The author’s presence can make a weak process look mature

This creates an awkward testing problem.

Ask the person who designed the workflow to demonstrate it.

Everything works.

Of course it does.

They know what every field means.

They know which parts of the document are outdated but harmless.

They know that Step 6 occasionally comes before Step 5.

They know why a rule exists and therefore know when violating it is safe.

They know which missing information matters.

They know where to look when the system does not contain the answer.

Their fluency smooths over the process’s weaknesses.

The process gets credited for capability that still resides inside the author.

This is similar to watching an expert chef use a poorly written recipe and concluding the recipe is excellent.

The expert is carrying the missing information.

Test the process with someone competent but unfamiliar

The better test is not whether a novice can blindly follow instructions.

That sets the bar strangely low.

Choose someone competent enough to perform the kind of work, but unfamiliar enough that they cannot rely on institutional memory.

Give them the process.

Let them run it.

Then watch where they stop.

Every question is evidence.

Not necessarily evidence that more documentation is required.

Evidence that something has not yet transferred.

The useful question is:

What did the person need from the author that the process itself could not supply?

The answers tend to fall into different categories.

A missing instruction.

A missing standard.

A hidden assumption.

An unclear decision right.

An undefined threshold.

An exception with no route.

Institutional history.

Or genuine expert judgment.

Those categories deserve different responses.

Adding another paragraph to the SOP is not automatically one of them.

Some questions should disappear. Others should improve.

This is an important test of transfer.

Suppose a new employee initially asks:

“Who approves a discount above 10%?”

After the process improves, that question should disappear.

The answer should be cheap.

But another question may remain:

“This client is asking for 12%, but they are entering a second market with us next quarter and the concession could affect the larger commercial structure. Does the normal threshold still apply?”

That is a better question.

The system has removed the avoidable ambiguity and exposed the real judgment.

That is progress.

A strong process does not eliminate questions.

It improves the quality of the questions that reach people.

This is a much better measure of transfer than whether nobody ever asks for help.

The author should become a coach, not a translator

There is a useful distinction here.

A translator repeatedly explains what the process means.

A coach helps someone develop the judgment required where the process legitimately ends.

The translator says:

“When the document says ‘material’, it means anything above this threshold.”

The coach says:

“You have the threshold. Now let’s examine why this case may still deserve different treatment.”

Translation compensates for missing process architecture.

Coaching develops capability beyond the process.

The first should reduce over time.

The second may remain valuable indefinitely.

That distinction also protects against the opposite mistake: trying to document expertise out of existence.

The objective is not to remove experienced people from the work.

It is to ensure their experience is being used at the level where experience genuinely matters.

Do not document every answer the author gives

Another trap appears once translator dependency becomes visible.

Capture everything.

Every question.

Every exception.

Every explanation.

Soon the SOP becomes a transcript of one person’s accumulated experience.

It grows.

The author is needed less often.

Nobody else reads the document.

The dependency has merely changed form.

A better response is to ask why the question occurred.

If ten people ask:

“Which template should be used?”

perhaps the template architecture is confusing.

Do not add a paragraph explaining the confusion.

Fix the architecture.

If people repeatedly ask:

“Who owns this?”

clarify ownership.

If people ask:

“When does this need escalation?”

define the threshold or exception boundary.

If people repeatedly need historical context to interpret a customer agreement, perhaps that context belongs in the customer record rather than the SOP.

The purpose is not to capture every answer.

It is to make recurring interpretation cheaper.

Sometimes the process is not ready to be transferred

There is an uncomfortable counter-case.

A business may attempt to document something too early.

The work is still changing weekly.

The author is still learning what good looks like.

Customer behaviour is unstable.

The commercial model is being tested.

Exceptions reveal more than the normal path.

In that environment, forcing formal process transfer too soon can freeze immature thinking.

The author may still need to remain close.

That is not necessarily founder dependency.

It may simply be active process development.

The question is whether the dependency is intentional and temporary.

There is a profound difference between:

“This still needs the author because the process is being discovered.”

and:

“This still needs the author because nobody ever completed the transfer.”

One is learning.

The other is operating debt.

The process needs an owner after the author leaves

Another reason authors remain indispensable is that organisations confuse creation with ownership.

Someone designs the workflow.

Documents it.

Trains the team.

Then everybody assumes the process somehow owns itself.

But reality changes.

Tools change.

Customers change.

A threshold stops making sense.

An exception becomes common.

A handoff shifts.

Someone discovers a better method.

Without an active process owner, the document and the work begin separating.

Then the original author gets called again.

“What were we supposed to do here?”

The author becomes the historian of a process they may no longer even operate.

A transferred process therefore needs someone responsible not merely for storing the document, but for maintaining the operating truth.

Not necessarily the original author.

Ideally, eventually, not the original author.

Watch for author-shaped language

There is a small but revealing diagnostic inside many SOPs.

Words such as:

appropriate;

reasonable;

significant;

standard;

normally;

where necessary;

if required;

as relevant;

use discretion.

None of these words is inherently bad.

Expert work sometimes needs them.

But each deserves scrutiny.

Would two competent people interpret the phrase similarly?

If not, what context is missing?

Perhaps the answer is a measurable threshold.

Perhaps an example.

Perhaps a principle.

Perhaps a decision owner.

Perhaps the phrase genuinely requires developed judgment.

The goal is not to ban ambiguous language.

It is to know where ambiguity has been deliberately preserved and where it has merely been inherited from the author.

A process is transferred when the dependency changes shape

Perfect independence is the wrong target.

Organisations are social systems.

People ask one another questions.

Experts remain valuable.

Managers make calls.

New employees need support.

The useful change is more specific.

At first, the process may depend on the author for:

steps;

context;

exceptions;

standards;

decisions;

and judgment.

After transfer, it should increasingly depend on the system for:

steps;

context;

standards;

routine decisions;

and known exception routes.

Then the author—or another expert—is needed mainly for:

novelty;

consequence;

complex trade-offs;

and capability development.

The dependency has not disappeared.

It has moved upward in value.

That is operating leverage.

Run the process without the translator

There is a simple test before declaring a process transferred.

Remove the author from the execution loop.

Not permanently.

For one run.

Give the process to someone capable.

Let the normal workflow proceed.

Record every point where the person would ordinarily ask the author.

Then resist the urge to treat all those questions as documentation defects.

Classify them.

What should the system already know?

What should the role know?

What should a manager decide?

What belongs in an exception route?

What genuinely requires expertise?

Then redesign accordingly.

Run it again.

The goal is not zero questions.

The goal is fewer cheap questions.

And better expensive ones.

The real handoff is not the document

A process document can be sent in seconds.

That is not process transfer.

Training can be completed.

That is not necessarily process transfer either.

The deeper handoff is successful when another capable person can:

understand the normal path;

recognise good output;

detect when normal no longer applies;

find the right authority when judgment is required;

and explain enough of the reasoning that the work does not collapse back into dependence on the original author.

At that point, the author no longer has to translate their own system.

They can improve it.

Coach beyond it.

Or leave the room entirely.

That is a much harder standard than:

The SOP exists.

It is also a much more useful one.

Because a process has not really been transferred when the instructions have moved from one person’s head into a document.

It has been transferred when the organisation can carry the meaning without carrying the author with it.