What If All the Important Knowledge in My Business Is in My Head?

Adam Fox • 29 September 2026

If all the important knowledge in your business is in your head, you do not primarily have a documentation problem.

You have a business dependency problem.

The company may depend on you to remember:

How certain customers really work.

Which jobs are worth taking.

How you price unusual work.

Which supplier can get you out of trouble.

What happened the last time this problem appeared.

Which employee can handle which customer.

Why a particular process exists.

Where the commercial risks are hidden.

Which numbers matter.

When an exception is genuinely dangerous.

And hundreds of tiny decisions you no longer consciously recognise as knowledge because you have been carrying them for years.

That knowledge can be enormously valuable.

It can also make the company extremely fragile.

Because if the business cannot access what it needs without accessing you, then your knowledge has not really become organisational capability yet.

The answer is not spending six months writing everything you know into a giant procedure manual.

Some knowledge can be documented.

Some needs to be demonstrated.

Some needs to be practised.

Some needs to be distributed across several people.

And some judgement can only really be developed through experience.

The objective is not:

"How do I empty my brain into SharePoint?"

It is:

"How do I make sure the company can still think, decide and operate when my brain isn't immediately available?"

Owner knowledge becomes invisible because you use it automatically

This is why the problem can be difficult to recognise.

Ask an experienced owner:

"How do you price this?"

They might say:

"I just know."

But they don't just know.

Perhaps they subconsciously consider:

Customer.

Complexity.

Labour.

Travel.

Material.

Risk.

Who will deliver it.

Current capacity.

Likelihood of scope creep.

Competitor position.

How desperate they are for the work.

Whether the customer pays on time.

How similar jobs performed previously.

Twenty years of pattern recognition happens in thirty seconds.

To the owner, it feels obvious.

To somebody else, it may look like magic.

That is tacit knowledge.

Not all business knowledge can be written down neatly

This distinction matters.

There is explicit knowledge.

Things you can relatively easily capture.

Processes.

Prices.

Specifications.

Customer records.

Templates.

Checklists.

Instructions.

Contracts.

Technical information.

Then there is tacit knowledge.

Experience.

Instinct.

Pattern recognition.

Commercial judgement.

Context.

Knowing when the normal rule should not apply.

A systematic review of organisational tacit-knowledge research highlights how important this less easily codified knowledge can be and how knowledge transfer depends on factors including opportunities for transfer, the characteristics of the knowledge itself and the mechanisms used to transfer it.

That means:

"Document everything."

is not enough.

You need to understand what kind of knowledge you are trying to transfer.

Knowledge management is a real organisational discipline

This is not simply a founder problem someone invented for LinkedIn.

ISO 30401 is the international standard specifically concerned with knowledge-management systems. The currently published edition is ISO 30401:2018, while a second edition is progressing through ISO's revision process during 2026. The standard applies to organisations regardless of type or size and focuses on developing, maintaining, reviewing and improving organisational knowledge capability.

The 2026 draft describes the purpose particularly well: organisations should be able to develop and apply knowledge to create value rather than simply hold information somewhere.

You do not need certification.

You do not need a Knowledge Management Director.

But the principle is highly relevant to an SME:

Knowledge should increasingly belong to the organisation, not only to particular individuals.

The first risk is obvious: what happens if you are unavailable?

Forget selling the business.

Forget succession planning.

Start with next Tuesday.

You wake up ill.

Cannot work for two weeks.

What stops?

Who cannot make a decision?

Which customer needs you personally?

Which quotations cannot be completed?

Which supplier problem sits waiting?

Who cannot access information?

Which employee says:

"Adam normally handles that."

That tells you where knowledge dependency exists.

The National Cyber Security Centre gives similar advice when discussing small-business resilience: identify critical processes and information, assign shared responsibility where appropriate and ensure key documentation is available and current so others can operate during absence.

That is not only cyber resilience.

It is basic business resilience.

Do the holiday test

Think about the last proper period when you were unavailable.

What happened?

Did employees contact you?

What about?

Did decisions wait?

Did customers wait?

Were quotations delayed?

Did somebody say:

"Nobody else knows how to do it"?

Those interruptions are useful evidence.

Do not simply answer them.

Record them.

Your holiday inbox can become a knowledge-risk assessment.

There is a difference between owner dependency and key-person dependency

Maybe the knowledge is not in your head.

Fantastic.

It is all in Sarah's.

Same structural problem.

Sarah knows:

The payroll process.

Customer billing portals.

Historic pricing.

Supplier arrangements.

How the spreadsheet works.

What happens at month end.

Everyone says:

"Ask Sarah."

What happens if Sarah leaves?

Holiday?

Long-term illness?

Promotion?

Lottery win?

Business continuity guidance routinely treats loss of key staff, skills and specialist knowledge as a risk organisations should prepare for.

Your objective is not making Sarah less valuable.

It is stopping Sarah's value from becoming a single point of organisational failure.

Start by finding the knowledge that actually matters

Do not document your entire company.

You will die of boredom before you finish.

Ask:

What knowledge would create a serious problem if one person suddenly became unavailable?

Start there.

Potential examples:

Pricing judgement.

Technical estimating.

Major customer requirements.

Regulatory knowledge.

Critical supplier relationships.

Contract administration.

Job scheduling.

Credit-control quirks.

Machine setup.

Key operational processes.

Tender submission.

Management reporting.

Specialist repair knowledge.

Commercial negotiation.

Look for concentration.

Build a simple knowledge-risk register

Take your important activities and capture:

Knowledge area

What does the business need to know?

Current holder

Who really understands it?

Criticality

What happens if that knowledge becomes unavailable?

Coverage

Who else could currently handle it?

Transfer difficulty

Can it be documented, or does it need experience?

Action

What should we do next?

That can fit on one spreadsheet.

You do not need a £60,000 knowledge-management platform to discover that only Dave knows how your £2 million customer account works.

Score knowledge on three dimensions

A particularly simple test is:

How important is it?

If unavailable, does anything significant happen?

How concentrated is it?

One person?

Several?

How difficult is it to transfer?

A checklist?

Three months' shadowing?

Five years' technical experience?

Knowledge that is:

Highly important.

Held by one person.

Difficult to transfer.

should move towards the top of your risk list.

Do not document knowledge nobody needs

This is where documentation projects go wrong.

Somebody decides:

"We need SOPs."

Now every conceivable activity gets documented.

How to order stationery.

How to replace printer paper.

How to book Meeting Room 2.

Meanwhile only the owner knows how £500,000 contracts are priced.

Priorities slightly wrong.

Document where loss or inconsistency matters.

Separate information from knowledge

This makes the task much easier.

Suppose an important customer pays on sixty-day terms.

That is information.

Put it in CRM.

But perhaps you also know:

They normally reject invoices unless a particular reference appears.

Their Project Director wants early warning before variations.

Their Finance Director becomes difficult if commercial issues reach them late.

The best time to discuss renewals is three months before budget year-end.

That is knowledge.

Some can still be captured.

Some requires relationship transfer.

Different mechanisms.

Separate knowledge from judgement too

Imagine your estimating process.

Material cost?

Documentable.

Labour assumptions?

Documentable.

Standard margin?

Documentable.

But:

"That job has trouble written all over it."

Why?

Perhaps you spotted:

Vague scope.

Aggressive programme.

Poor customer history.

Difficult access.

Unusual liability.

That judgement comes from experience.

You cannot solve every piece of tacit knowledge with a form.

You need people making decisions alongside you until they learn what you notice.

Use shadowing for judgement-heavy work

If someone needs to learn how you think, let them see you think.

Take them into:

Pricing decisions.

Customer negotiations.

Supplier problems.

Operational planning.

Recruitment decisions.

Then explain your reasoning.

Not only:

"We're doing option B."

Explain:

"These are the five things that made me choose B."

This exposes tacit judgement.

Over time, ask them first:

"What would you do?"

Now you can compare thinking.

That is knowledge transfer.

Think aloud more deliberately

Experienced people often skip reasoning because the conclusion feels obvious.

Slow down occasionally.

"I am rejecting this job because the margin looks fine but the programme creates too much delivery risk."

"I am not discounting for this customer because their problem is availability, not price."

"I am calling the customer now because if we wait until Friday the issue becomes political."

Those explanations transfer far more than the decision itself.

Debrief unusual decisions

This is one of the easiest tools available.

Something unusual happened.

You solved it.

Before everyone moves on, spend ten minutes asking:

What happened?

What did we notice?

What did we decide?

Why?

Would we do the same again?

Does anything need changing?

Now one person's experience can become shared organisational learning.

Otherwise the lesson disappears back into whoever experienced it.

Capture exceptions because exceptions contain knowledge

Normal processes are relatively easy to document.

Exceptions reveal expertise.

Standard quote follows standard rules.

Fine.

What causes an owner to say:

"Bring this one to me"?

Those triggers matter.

Write them down.

For example:

Margin below 30%.

Unusual indemnity.

Customer asks for 120-day terms.

Project requires unfamiliar certification.

Delivery period below four weeks.

Now some of the owner's judgement has become a visible escalation rule.

Create decision rules before creating procedures

Sometimes a rule transfers more knowledge than ten pages of instructions.

For example:

Never commit delivery before Operations confirms capacity.

No customer credit above X without Finance review.

Variations over £5,000 need written agreement before work proceeds.

Strategic customers get same-day escalation for service failure.

Those rules capture lessons someone probably learned painfully.

Use them.

Record the "why" behind important rules

Otherwise five years from now:

"Why do we do this?"

Nobody knows.

So somebody removes it.

Then discovers the reason.

If a rule matters, capture enough rationale.

Not War and Peace.

One sentence may be enough.

"Introduced after recurring margin losses caused by unapproved scope changes."

Now future managers can distinguish:

Important control.

from:

Historical nonsense.

But challenge old knowledge too

This is another important point.

Owner knowledge is not automatically correct because it is old.

Some of it may be:

Outdated.

Habit.

Bias.

Workaround.

Based on a customer who left six years ago.

Based on software you no longer use.

Knowledge transfer should not fossilise every historical decision.

Ask:

Is this still useful?

Transfer what matters.

Improve what doesn't.

Documentation should be usable by the person who needs it

Not impressive.

Usable.

A process may need:

One page.

A flowchart.

A video.

Checklist.

Template.

Decision tree.

Photographs.

Screen recording.

Example.

Choose the format based on the knowledge.

A 45-minute video is terrible when someone needs a thirty-second answer.

A checklist is terrible when someone needs nuanced judgement.

Use the right tool.

Video is brilliant for some operational knowledge

Showing:

How to configure something.

How to use a particular system.

How to perform a complex sequence.

How to inspect a finished product.

Record the expert doing it.

Explain the important parts.

Useful.

But do not confuse:

"We recorded Dave doing it once."

with:

"Someone else can now actually do it."

They need to practise.

Transfer requires doing, not just consuming

You can watch fifty videos about riding a bike.

Eventually you need a bike.

The same principle applies at work.

If someone needs to replace you in:

Quoting.

Negotiation.

Management.

Planning.

let them do it.

Supervised initially.

Then independently.

Knowledge becomes capability through application.

A 2024 systematic review reinforces this point

A review of 28 studies examining organisational knowledge transfer during generational or personnel change found organisations commonly use collective approaches to transfer both tacit and explicit knowledge, with digital tools and internal communication playing important roles.

In other words:

Repositories matter.

People matter too.

Do not attempt to solve a human knowledge problem entirely with storage.

Build overlap between people

One-person ownership can create efficiency.

It also creates fragility.

For genuinely critical knowledge, aim for sensible overlap.

Primary owner.

Secondary person.

Perhaps third-level emergency cover.

Not everybody needs to know everything.

That creates chaos.

But critical capability should rarely have exactly one access point forever.

Use a primary and deputy model

For critical processes:

Primary owner.

Deputy.

The deputy does not need identical expertise.

But should understand enough to:

Access information.

Keep the process moving.

Know where to get help.

Handle normal work.

Recognise genuine exceptions.

Then periodically test the deputy.

Otherwise the backup exists only on the organisation chart.

Holidays are excellent training opportunities

Sarah goes away for a week.

Instead of treating this purely as inconvenience:

Who covers?

What did they struggle with?

What information was missing?

What decisions waited?

What only Sarah could answer?

Update the system afterwards.

Every absence can improve resilience.

Cross-training should follow risk, not fairness

You do not need everyone trained in everything.

That is expensive and impractical.

Cross-train where:

Knowledge is critical.

Cover is weak.

Absence would cause disruption.

The skill is reasonably transferable.

Prioritise.

Customer knowledge needs transferring particularly carefully

Owner-managed businesses often have customer relationships that exist partly because of the owner.

You know:

Their history.

Their personalities.

Commercial sensitivities.

What they care about.

What annoys them.

Excellent.

Now build another relationship.

Bring your manager into meetings.

Let them own follow-up.

Let the customer call them.

Share context.

Customer knowledge transfers through participation far better than:

"Here's the CRM. Good luck."

Supplier knowledge matters too

Who knows:

Which supplier can genuinely expedite?

Who has flexible credit?

Which representative solves problems?

Which alternatives are acceptable?

Which product substitutions cause issues?

If procurement depends on one person's relationship memory, capture and distribute enough of it.

Do not put passwords into your procedure manual

Important distinction.

Access is part of resilience.

Poor credential security is not.

Use appropriate business accounts, access controls and secure password-management arrangements rather than storing passwords inside general documents.

The NCSC advises small organisations to identify critical information, systems and processes, ensure essential information can be recovered, and assign shared responsibility so business continuity does not depend on one unavailable person.

Knowledge access and secure access should be designed together.

Your CRM should contain customer knowledge rather than merely contact details

Lots of CRMs are expensive phone books.

Name.

Email.

Company.

Great.

What would somebody need to know to manage this account well?

Commercial terms.

History.

Open issues.

Key contacts.

Decision process.

Important commitments.

Relevant preferences.

Keep it proportionate.

But build organisational customer memory.

Your project system should tell someone what happened without requiring oral history

Why did margin drop?

Why was deadline extended?

What variation was agreed?

What decision changed?

If every completed project requires asking the Project Manager what really happened, you are not building much organisational learning.

Record the things worth learning from.

Knowledge transfer should be part of management work

This is where managers matter.

A strong manager should be reducing dependency on themselves.

Not increasing it.

Ask:

Who are you developing?

Who can cover you?

What knowledge exists only with you?

Which decisions are you teaching others to make?

This is management leverage.

Beware creating a new knowledge bottleneck one level down

Owner transfers everything to Operations Manager.

Success?

Maybe.

Now Operations Manager is the only person who understands:

Scheduling.

Customers.

Suppliers.

People.

Systems.

Owner goes on holiday.

Fine.

Operations Manager goes on holiday.

Chaos.

Dependency moved.

It did not disappear.

Make knowledge-sharing part of the role

For key managers and specialists, one responsibility could simply be:

Develop enough capability around you that the function does not depend completely upon you.

That can include:

Training.

Deputy development.

Documentation.

Joint decisions.

Cross-training.

It should not be optional charity performed when someone finds spare time.

Capture knowledge during onboarding and offboarding

New employee joins.

What knowledge do they need to become effective?

That tells you what should be accessible.

Employee leaves.

What do they know that needs transferring?

Do not make exit-week knowledge capture your entire strategy.

It is too late.

But use it.

Never wait until someone's notice arrives to start transferring critical knowledge

Three months sounds long.

It disappears quickly.

Particularly if:

Recruitment is happening.

Customers need reassuring.

Replacement is not in place.

Employee has holiday.

Knowledge is complex.

Build resilience while people still intend to stay.

This also matters for eventual succession and sale

Imagine a buyer looking at your company.

They discover:

Every important customer relationship is yours.

Pricing comes from you.

Technical judgement comes from you.

Senior employees defer to you.

Supplier history is in your head.

Processes are undocumented.

What exactly are they buying?

Assets.

Customers.

Employees.

And a fairly significant Adam-shaped hole.

Reducing knowledge dependency can increase the quality and transferability of the business, regardless of whether you currently intend to sell it.

You do not need to be planning an exit for this to matter

Maybe you want to work another twenty years.

Fine.

Do you want twenty years of:

Every holiday interrupted?

Every unusual problem waiting?

Every important quote returning?

Every new manager needing your memory?

Probably not.

Knowledge transfer creates operating freedom long before exit.

AI can help, but do not confuse AI with knowledge management

This is increasingly relevant.

You can use AI to:

Summarise meetings.

Organise documentation.

Search internal information.

Draft processes.

Turn recordings into structured instructions.

Create FAQs.

Potentially very useful.

A 2026 systematic review of 82 academic studies examined AI's emerging role in converting and combining tacit and explicit organisational knowledge and found considerable potential for AI to support knowledge-creation processes.

But AI does not magically understand everything inside the owner's head.

You still need to:

Expose the knowledge.

Validate it.

Structure it.

Decide what matters.

And make sure people can apply it.

Do not dump thousands of documents into an AI tool and declare the problem solved

Garbage in.

Beautifully summarised garbage out.

You need:

Current information.

Clear ownership.

Permissions.

Appropriate security.

Useful structure.

Trusted sources.

AI can improve retrieval.

It cannot rescue a company that never decided what its critical knowledge was.

Search is arguably as important as storage

You document everything.

Fantastic.

Nobody can find anything.

Failure.

Ask:

If somebody needs the answer at 3pm on Thursday, can they find it in two minutes?

That is the test.

Knowledge unavailable at the moment of need is not especially useful.

Give documents owners and review dates

A procedure without ownership becomes historical literature.

Who maintains it?

When was it last checked?

When does it need reviewing?

What event should trigger an update?

New system?

New regulation?

Process change?

Customer change?

The ISO knowledge-management framework includes continual evaluation and improvement rather than treating knowledge repositories as something created once and forgotten.

Knowledge decays.

Maintain what matters.

Do not record every meeting forever

This is another modern temptation.

We can transcribe everything.

Therefore we should.

No.

You will create an enormous swamp.

Capture:

Decisions.

Rationale.

Actions.

Important learning.

Reusable knowledge.

The goal is useful organisational memory.

Not infinite storage.

Build a "How We Think" layer as well as a "How We Do" layer

This is particularly important in expert SMEs.

How We Do might contain:

Process.

Steps.

Systems.

Templates.

How We Think might contain:

Decision principles.

Commercial rules.

Examples.

Case studies.

Escalation criteria.

Lessons learned.

That second layer transfers judgement.

It is frequently the one missing.

Use case libraries

This can be excellent for complex work.

Example:

Unusual project.

What happened?

What risk existed?

What did we decide?

Outcome?

What would we repeat?

Now the next employee facing something similar has context.

You are gradually converting experience into organisational memory.

Record mistakes too

Businesses love documenting success.

Mistakes often contain more useful knowledge.

Major rework.

Bad customer.

Margin loss.

Supplier failure.

Commercial dispute.

Ask:

What do we never want to learn again the expensive way?

Capture that.

A good knowledge system should reduce the number of lessons the business has to purchase twice.

The goal is not to eliminate human judgement

Quite the opposite.

You want more people capable of exercising it.

A rigid company where everyone follows procedures regardless of reality is not sophisticated.

Build:

Rules for normal work.

Judgement for exceptions.

Escalation for high-risk situations.

That combination scales much better.

Give employees enough context to understand why

If people only know their small step, they cannot adapt intelligently.

Explain enough of:

Customer promise.

Commercial model.

Quality requirement.

Risk.

Downstream consequences.

Now employees can make better decisions when the exact situation was not documented.

Knowledge is connected to purpose.

A good test: can somebody answer without asking you?

Choose ten questions people regularly bring to you.

For example:

Can we discount this?

Can we use this supplier?

How should we price this?

What happens if the job overruns?

What do we do with this customer issue?

Now ask:

Could the business answer each without you?

If not, what is missing?

Information?

Rule?

Authority?

Experience?

That gives you your transfer plan.

Another good test: can somebody explain why?

Employee can follow the process.

Fine.

Ask:

"Why do we do it this way?"

If they have no idea, you transferred activity.

Not knowledge.

Understanding creates resilience.

Use a controlled absence test

Pick an area you currently dominate.

For one week:

Do not handle its normal questions.

Nominate the person responsible.

Give them access to required information.

Define genuine escalation.

Then observe.

What failed?

What was missing?

What worked perfectly well?

That is an enormously useful experiment.

Do not wait for an emergency to discover the answer.

Build a 30-day knowledge-dependency audit

Week 1: Capture

Every time someone asks you something because:

Only you know.

Only you remember.

Only you have the relationship.

Only you understand the history.

Write it down.

Week 2: Prioritise

Score each area by:

Importance.

Concentration.

Transfer difficulty.

Choose the highest-risk five.

Week 3: Transfer

For each one, decide the right mechanism.

Document?

Train?

Shadow?

Introduce relationship?

Create rule?

Develop deputy?

Improve system?

Week 4: Test

Remove yourself from routine access.

Can the other person:

Find information?

Make the decision?

Perform the work?

Know when to escalate?

Fix whatever failed.

Then repeat.

A 90-day knowledge transfer plan

For the first month, identify the ten to twenty areas where critical business knowledge remains concentrated in one person. Establish who should become the secondary holder.

During month two, begin transfer through the appropriate method. Document explicit knowledge, shadow judgement-heavy work, transfer relationships and introduce deputies into live decisions.

During month three, test independence. Have the secondary person perform the work, make normal decisions and handle routine issues while the original knowledge-holder remains available only for defined exceptions.

Measure:

Questions.

Errors.

Escalations.

Time to competency.

Then improve.

Measure knowledge dependency through questions

You do not need a complicated metric.

Track:

How many times did somebody need me because only I knew?

How many times did they need Sarah?

Which questions repeated?

Over time, those should decline in the targeted areas.

That is evidence knowledge is spreading.

Measure coverage too

For each critical activity:

Primary person?

Secondary person?

Documented enough?

Tested?

Green.

Amber.

Red.

Simple.

The point is visibility.

Do not aim for zero key people

Impossible.

Great companies employ valuable people.

You should have specialists.

Experienced managers.

Trusted relationships.

The objective is not making everybody interchangeable.

It is preventing unnecessary fragility.

There should be a difference between:

"We would genuinely miss Sarah."

and:

"We literally cannot invoice customers without Sarah."

The first is normal.

The second needs attention.

Important people should create more capability than they personally contain

This is a useful leadership standard.

A great specialist:

Teaches.

Documents.

Improves.

Develops others.

Creates reusable knowledge.

A great manager:

Builds people.

Transfers judgement.

Creates deputies.

The organisation gets stronger because they are there.

Not simply more dependent on them.

This applies to the owner most of all

You may currently be the most knowledgeable person in the business.

Reasonable.

You built it.

But after ten years with:

Thirty employees.

Managers.

Systems.

Customers.

should the gap still be enormous?

Your job should increasingly include converting your own accumulated knowledge into organisational capability.

That is one of the least discussed parts of stepping out of day-to-day operations.

What should stay in the owner's head?

Some things will.

Personal judgement.

Ideas.

Private shareholder matters.

Sensitive information.

Long-term ambitions.

Fine.

We do not need to turn the owner into a publicly searchable database.

Focus on knowledge the company requires to operate well.

Not every thought you possess.

What if I don't have time to document everything?

Don't.

Start with one dependency.

What question did someone ask you three times this month?

Solve that.

Then another.

Knowledge transfer can happen through ordinary work.

Record the screen-share.

Invite somebody into the customer meeting.

Explain your decision.

Create the checklist while doing the process.

You do not need a six-month knowledge project.

You need a new habit:

When something important depends on one person, deliberately create a second route to it.

Knowledge capture should happen while the business operates

This makes it far more sustainable.

Completed unusual job?

Debrief it.

Important pricing decision?

Explain it.

New process?

Document while implementing.

Customer transfer?

Bring manager into meetings.

Manager holiday?

Test deputy.

Knowledge management becomes part of management.

Not another enormous project everyone avoids.

How Evolve approaches owner knowledge dependency

If an owner tells me:

"Everything is in my head."

I do not start by suggesting a knowledge-management platform.

I want to know:

What exactly is in your head?

What does the company repeatedly need from it?

Which parts are information?

Which are process?

Which are judgement?

Which are relationships?

What creates the greatest operational risk?

Who could become the second person?

Then we choose the right intervention.

Some things belong in systems.

Some in procedures.

Some need training.

Some need shadowing.

Some need management development.

Some customer relationships need transferring.

Some supposed "knowledge" turns out to be an unnecessary owner habit we can eliminate altogether.

Documentation is not the objective

This matters enough to repeat.

You could create 800 immaculate process documents.

If every meaningful decision still comes back to you, dependency remains.

The objective is distributed capability.

Can somebody else:

Know?

Understand?

Decide?

Act?

Learn?

That is the outcome.

This is another form of Dependency Removal

Owner dependency is not only about tasks.

It can live in:

Knowledge.

Judgement.

Relationships.

Memory.

Access.

The company may have delegated a lot of physical work and still remain completely dependent on the owner's brain.

That is why some owners say:

"I hardly do any actual work anymore, but everybody still needs me."

Exactly.

You transferred the hands.

Not the thinking.

The next stage is distributing thinking.

So, what if all the important knowledge in your business is in your head?

Do not panic and start writing an encyclopaedia.

First identify which knowledge genuinely matters.

Find where it is concentrated.

Separate information, process and judgement.

Document what can be documented.

Demonstrate what needs demonstrating.

Explain your reasoning.

Use shadowing.

Build deputies.

Transfer customer and supplier relationships.

Capture important exceptions and lessons.

Create searchable organisational memory.

Develop managers who make decisions rather than simply requesting yours.

Then test whether the business can operate without immediate access to the original knowledge-holder.

Start with the highest-risk dependencies.

One at a time.

Because your experience should absolutely make the business stronger.

It just should not require your permanent presence for the business to access it.

The goal is not extracting everything from your brain.

It is turning enough of what you know into what the business can do.

That is when knowledge stops being another form of owner dependency.

And starts becoming an asset the organisation actually owns.

Something in your business needs to change?

You probably already know more than enough to keep reading about it.


If you want an experienced outside perspective to help you work out what’s really getting in the way — and what to do about it — let’s have a conversation.

Specialist ground crews performing distinct roles around one aircraft in bright daylight.
by Adam Fox • 29 September 2026
Role clarity in a growing business means every important outcome has a clear answer to three questions: Who owns the result? What are they allowed to decide? Where does their responsibility stop and somebody else's begin? That sounds simple. Then the company grows. Sales says Operations owns it. Operations says Project Management owns it. Project Management says they were waiting for Finance. Finance says nobody sent the information. Three managers attended the meeting. Six people were copied into the email. The owner eventually sorts it. And somehow the business concludes: "We need better communication." Maybe. But often the real problem is much simpler. Nobody genuinely knew who owned what. Growing businesses do not usually lose role clarity overnight It happens gradually. At the beginning: Owner does almost everything. Then you hire someone. "Can you help with this?" Another person. "They'll take care of that." Then: Supervisor. Administrator. Salesperson. Project Manager. Operations Manager. Finance Manager. Roles accumulate around the work that already exists. Nobody stops to redesign the whole picture. Eventually one person's job overlaps another's. Responsibilities migrate informally. Managers inherit tasks without authority. Employees still ask the founder because they remember when the founder owned everything. And the owner retains a collection of responsibilities they supposedly delegated years ago. That is how a perfectly normal growing SME ends up with: More people. More managers. More meetings. And less certainty about who actually owns the result. Role clarity is not the same as having job descriptions You can have twenty beautifully formatted job descriptions and still have terrible role clarity. Because most job descriptions describe: Activities. Responsibilities. General duties. They often do not explain: Which outcomes the person actually owns. What they can decide. Which numbers they are accountable for. What belongs to somebody else. How two overlapping functions should work together. When something should escalate. Acas's current job-description template guidance includes the role's main duties and who the employee reports to, while current government recruitment guidance recommends defining tasks and responsibilities before recruiting. Useful foundations, certainly. But as a business becomes more complex, management normally needs more than a list of duties. A job description tells me: What you do. Role clarity should also tell me: What happens because you do it. Start with outcomes rather than activities Consider a Sales Manager. Activity-based description: Attend sales meetings. Manage CRM. Support sales team. Review proposals. Meet customers. Fine. Outcome-based version: Own qualified pipeline. Own sales conversion. Own performance of the sales team. Own sales forecasting accuracy. Ensure commercial commitments entering Operations are complete and achievable. Now we understand the job much better. The activities may change. The outcomes remain clearer. Activities are useful. Ownership is more useful. Someone might: Prepare a report. But who owns whether the information is accurate? Someone might: Schedule a job. But who owns whether delivery capacity is sufficient? Someone might: Send the invoice. But who owns ensuring completed work becomes invoiceable promptly? Several people may touch an outcome. One person should usually be clearly identifiable as the person responsible for seeing that outcome through. That distinction removes enormous amounts of ambiguity. "Everyone owns it" is usually dangerous Imagine: "Customer satisfaction is everyone's responsibility." Nice sentiment. Operationally? Who investigates complaints? Who tracks the trend? Who changes the process? Who reports performance? Who makes sure an unresolved complaint does not quietly disappear? Everyone can contribute to customer satisfaction. That does not mean accountability needs to be vague. Shared contribution is normal. Undefined ownership is different. This is where accountability gets muddled Four concepts are often collapsed into one. Responsibility Work you are expected to perform. Accountability The outcome you are expected to answer for. Authority What you are allowed to decide or change. Contribution Work you provide towards an outcome owned elsewhere. You need all four. Responsibility without authority creates frustration "You own customer delivery." Excellent. Can I change the schedule? "No." Approve overtime? "No." Prioritise jobs? "Ask me." Resolve ordinary customer issues? "Check first." Then you do not own customer delivery in any meaningful operational sense. You report on it. The owner still owns it. This is one reason Article #36 connected accountability with authority. Authority without accountability creates different problems Manager can: Spend. Recruit. Change priorities. Agree customer solutions. But nobody reviews the outcomes. Now discretion exists without enough consequence. You want the pair: Appropriate authority. Clear accountability. HSE treats role clarity as a genuine work-design issue The Health and Safety Executive includes Role as one of its six Management Standards for work-related stress. Its standard says employees should understand their role and responsibilities, requirements should be as clear and compatible as possible, and people should have routes for raising concerns about uncertainty or conflicting responsibilities. That is worth paying attention to. Role confusion is not merely annoying administration. Conflicting expectations create actual organisational strain. Imagine reporting to three unofficial bosses Operations Manager says: "Do A first." Sales Director says: "No, customer B is urgent." Owner walks through: "Forget both. Sort C." Employee fails A. Operations Manager asks: "Why didn't you do it?" What exactly was the role expectation? You can call that poor prioritisation from the employee. Or recognise that the organisation issued incompatible instructions. HSE's guidance explicitly says organisations should, as far as possible, ensure requirements placed on employees are compatible. That seems extremely sensible. Owner-managed businesses create this problem particularly easily Because everybody knows: The owner can override anything. Employee has manager. Owner asks employee directly: "Can you quickly do this?" Of course they say yes. Manager's priority gets displaced. Now the organisational chart says one thing. Real authority says another. Do that often enough and the owner becomes everybody's unofficial second manager. Your behaviour teaches people who really owns the decision You can write: "Operations Manager owns scheduling." Then personally change tomorrow's schedule three times. What did everyone learn? Owner owns scheduling. You can write: "Sales Manager owns commercial decisions." Then negotiate every important deal. Everyone learns: Owner owns commercial decisions. Structure is created through behaviour. Not PowerPoint. One of the first tests is simple Ask ten employees: "Who owns this?" Choose something important. Customer complaints. Recruitment. Pricing. Capacity. Quality. Debtors. Scheduling. Marketing. If you get six different answers? Useful finding. Then ask the supposed owner "What decisions can you make without Adam?" This is often even more revealing. Answer: "Not totally sure." There is your role-clarity problem. Role clarity becomes more important as the business grows ONS's latest published Management and Expectations Survey found that larger UK businesses reported more structured management practices on average. Firms with 10 to 19 employees scored 0.51 on its structured-management scale in 2023, rising to 0.58 among firms with 20 to 49 employees, 0.63 among firms with 50 to 99 employees and higher again among larger firms. The measure covers continuous improvement, KPIs, targets and employment practices rather than role clarity specifically, so it should not be interpreted as proof that organisational charts create productivity. But it does illustrate the wider shift towards more deliberate management as organisational scale increases. Informal coordination has limits. Eventually: "Everyone sort of knows what they do." stops being enough. The first growth stage: everybody does everything Often perfectly reasonable. Five-person business. Customer calls. Whoever is free answers. Problem arrives. Someone sorts it. Founder involved everywhere. Flexibility matters more than beautifully defined roles. Do not bureaucratise a tiny company unnecessarily. The second stage: specialists appear Someone mainly sells. Someone manages administration. Someone delivers. Someone handles finance. Still plenty of overlap. Usually manageable. But responsibilities begin becoming repeatable enough to name. The third stage: managers appear This is where clarity becomes far more important. Because now the company has: People. And people responsible for other people. Who handles performance? Who approves holiday? Who sets priorities? Who recruits? Who manages capacity? Who deals with customer escalation? If the answer remains: "Usually the owner." then the management layer exists mostly in title. The fourth stage: functions become interdependent Sales. Operations. Finance. Marketing. Customer Service. Projects. Now the biggest problems often exist between roles rather than inside them. Sales owns winning customer. Operations owns delivering. Who owns the handover? Finance owns invoicing. Project Manager owns completion. Who ensures completion information reaches Finance? The interfaces matter. Most role problems live in the gaps This is important. Often everybody performs their individual job reasonably well. The failure occurs here: Sales → Operations. Operations → Finance. Finance → Customer. Marketing → Sales. Manager → Manager. The handover has no clear owner. Then information drops. Map outcomes first Take the business's important recurring outcomes. For example: Qualified enquiries generated. Sales converted. Customer scope agreed. Work scheduled. Work delivered. Quality confirmed. Customer issue resolved. Invoice raised. Payment collected. Employee recruited. Employee performance managed. Capacity planned. Now ask: Who owns each outcome? Not who touches it. Who answers for it? You should be able to complete this sentence "If this outcome repeatedly fails, the first person accountable for understanding why is ______." That is extremely useful. It does not mean every failure is automatically their fault. It means: They own visibility. Diagnosis. Response. Escalation where required. Avoid building a blame map This exercise is not: Who gets bollocked? Ownership should answer: Who makes sure this works? Not: Who receives punishment when anything goes wrong? If role mapping becomes a blame exercise, managers will resist ownership. Understandably. Create an Ownership Map I prefer something simple. Columns: Outcome Primary owner Key contributors Decisions they can make When it escalates Measure For example: Customer onboarding. Owner: Customer Success Manager. Contributors: Sales, Finance, Operations. Authority: can set onboarding schedule and chase missing information. Escalation: contractual discrepancy or strategic account issue. Measure: onboarding completed by agreed date. That is vastly more useful than three pages of generic duties. Do not create a spreadsheet containing 400 activities You can. Please don't. You will spend three weeks deciding who owns: "Ordering printer toner." Then nobody will update it. Focus on meaningful outcomes and recurring decisions. The detail beneath them can sit in processes. Roles and processes are different Role answers: Who owns the outcome? Process answers: How does the work happen? Do not confuse them. You might completely redesign the invoicing process. Finance Manager still owns cash collection. Process evolves. Ownership remains. Define role purpose in one sentence For every significant role: Why does this job exist? Example: Operations Manager: "Ensure customer commitments are delivered safely, profitably and reliably through effective management of people, capacity and operational resources." That helps filter everything below it. Then define five to seven primary outcomes Not forty-seven tasks. For an Operations Manager: On-time delivery. Operational capacity. Team performance. Quality. Operational cost. Continuous improvement. Cross-functional coordination. Now we have a role. Skills England's current standards take exactly this kind of outcome-and-accountability view Its Operations Manager standard describes the role as accountable for developing team members, managing projects, planning and reviewing workloads and resources, delivering operational plans and resolving problems. It explicitly expects Operations Managers to take ownership of their own and their team's tasks and workload. The current Team Leader standard similarly expects first-line leaders to set and manage objectives, manage resources, interpret performance data and take accountability for their own workload. Those are clearer expectations than: "Help run the team." Define what the role does not own This can be equally powerful. Sales Manager does not own: Final operational scheduling. Finance approval. Technical quality. They may influence them. But no. Operations Manager does not own: Sales commission structure. Company strategy. Tax advice. Marketing campaigns. Again: Contribution is different from ownership. Boundaries reduce conflict Without boundaries: Sales says: "Operations is blocking growth." Operations says: "Sales keeps overpromising." Both might be right. Clarify: Sales owns commercial opportunity. Operations owns delivery capacity. Neither unilaterally commits something requiring the other's capacity beyond agreed parameters. Then define the decision process when they conflict. Now disagreement has architecture. Decision rights deserve their own conversation For every manager, list recurring decisions. Who decides: Price? Discount? Hiring? Overtime? Supplier? Customer remedy? Schedule? Purchasing? Capital expenditure? Priority? Marketing spend? Then assign levels. For example: Manager decides independently. Manager decides and informs. Manager recommends, owner approves. Owner decides. Do not leave this to habit. A lot of "poor communication" is actually decision ambiguity People keep discussing the same issue. Meeting after meeting. Why? Nobody knows who can decide. Once authority is clear: Discussion ends. Decision happens. This can remove enormous amounts of management noise. Do not require consensus for everything Collaborative management does not mean every decision needs six people to agree. Consult widely where useful. Then somebody decides. Otherwise: Meeting. Follow-up meeting. Email chain. Owner intervention. Consensus can become responsibility avoidance. RACI can be useful, but do not turn your entire company into one RACI typically distinguishes: Responsible. Accountable. Consulted. Informed. Useful for: Projects. Complex processes. Cross-functional implementation. But if every recurring business activity requires a forty-column RACI matrix, you may be designing complexity rather than solving it. Use the simplest tool that creates clarity. For everyday operations, named ownership is often enough Outcome: Monthly management accounts issued by working day ten. Owner: Finance Manager. Contributors: Bookkeeper, department managers. Done. You do not necessarily need a methodology acronym around everything. Clarify handovers explicitly A role can be crystal clear. Handover still broken. Sales hands work to Operations. What must exist before Operations accepts it? Signed scope? Customer contact? Programme? Margin? Special requirements? Purchase order? Deposit? Define the handover. Now: "I thought they knew." reduces. The receiving function should define what good handover looks like This is an excellent approach. Ask Operations: "What do you need from Sales before you can deliver this properly?" Ask Finance: "What do you need before you can invoice?" Ask Sales: "What information do you need back from Operations?" Interfaces become agreements between functions. Not assumptions. Ownership should follow the work through Project Manager says: "I sent Finance the information." Invoice still not raised. Do they own invoicing? Perhaps not. But if their outcome is: Project commercially closed, they may need to ensure the handover completed successfully. Passing an email is not necessarily completion. This is why outcome definitions matter. Avoid the phrase "I did my bit" That is task thinking. The customer does not care that: Sales did their bit. Operations did their bit. Finance did their bit. They care whether the overall result happened. Strong organisations preserve functional ownership while designing clean connections between functions. Meetings can expose role ambiguity Listen. Who continually says: "Who is doing that?" Useful. Who leaves meetings with: "I thought you were doing it." Useful. Who owns every action? Owner? Very useful. Your meetings are showing where the structure is unclear. End decisions with owner and date Decision: Change supplier. Owner: Sarah. Date: Friday. Not: "We should probably look at suppliers." That sentence owns nothing. Scorecards should map to ownership too Article #54 matters here. KPI: On-time delivery. Who owns it? Operations Manager. Pipeline. Sales Manager. Overdue debt. Finance Manager. If a number has no clear owner, ask why it exists on the scorecard. Performance visibility without accountability creates interesting meetings. Not necessarily better management. Give managers outcomes they can influence Do not tell Operations Manager: "You own company profit." They influence it. But maybe they directly own: Labour utilisation. Operational gross-margin drivers. Overtime. Rework. Delivery. Those connect to profit. Make ownership specific enough to be fair. Acas recommends the same basic connection between objectives and role Current Acas performance-management guidance says objectives should be specific, measurable, achievable and relevant to the employee's job and responsibilities, and regular reviews should allow performance and support needs to be discussed. Again: Clarity before accountability. If the objective has little relationship to what somebody can actually control, the management system is weak. Do not make two people equally accountable for the same result without good reason "James and Sarah both own it." Who has final say? Who notices if it fails? Who reports? Sometimes joint accountability is genuinely appropriate. Often it simply avoids choosing. Better: Sarah owns outcome. James owns a clearly defined contribution. Now both know. Be particularly careful with co-founders Two directors. Both involved everywhere. Employees shop for answers. Ask Director A. Don't like answer. Ask Director B. Different answer. Chaos. Co-founders need clear domains too. One company. Shared ownership of the business. Distinct operational authority. Founder relationships do not magically remove the need for governance Who owns: Commercial? Operations? Finance? People? Brand? Strategic decisions? Major disagreements? Define it. Particularly when the company becomes larger than the founders' ability to coordinate informally all day. Role clarity should include escalation Manager owns customer issues. Until what? Potential legal exposure? Safety issue? Compensation above £5,000? Strategic customer threat? Good. Write it. Ownership should not mean: "Never ask." It means: Know when the issue remains yours and when senior judgement is appropriate. Escalation should not automatically transfer the whole problem Manager escalates: "This requires your approval because it exceeds my £5,000 limit. I recommend option B and will implement it once approved." Good. Different from: "Customer's angry. Can you deal with it?" The manager still owns the process. Clarify priorities when two outcomes conflict Sales wants: Fast delivery. Operations wants: Stable schedule. Finance wants: Margin. Customer wants: Everything immediately. Someone needs rules for trade-offs. Otherwise role clarity fails the moment priorities collide. For example: Safety cannot be traded. Contractual commitments take precedence over speculative work. Strategic-customer exceptions require specific approval. Your rules will differ. But define enough to prevent constant owner refereeing. The owner should not be the default arbitration mechanism forever Early on? Probably unavoidable. Later? Managers should resolve many conflicts directly. Sales Manager and Operations Manager sit together. Understand issue. Make decision inside agreed authority. Owner does not need to mediate every disagreement between competent adults. Managers should manage across functions, not only downward The current Skills England Operations Manager standard explicitly describes working across functions such as finance, HR, IT, sales and marketing, as well as managing relationships with external stakeholders. That is important. Management is not only: Tell team what to do. It is also: Coordinate horizontally. Beware the heroic employee Every company has one. "Ask Emma." What does Emma own? "Everything really." Danger. Emma knows every process. Fixes every mistake. Helps every department. Nobody knows where role starts and stops. Emma is invaluable. And possibly becoming another bottleneck. Capability should not require unlimited role ambiguity. The same applies to the owner Founder: Floats everywhere. Fixes everything. Because: "I just fill the gaps." Exactly. Which gaps? Why do they still exist? Every recurring owner gap-fill is potential evidence of unclear organisational ownership. Map the owner's role too Do not only clarify employees. What does ownership retain? Perhaps: Strategy. Capital allocation. Management-team performance. Major commercial relationships. Significant risk. Senior recruitment. Culture. Then list what the owner no longer owns . Daily scheduling. Routine customer issues. Normal purchasing. First-line employee performance. Whatever applies. This is critical. You cannot create clarity below while remaining deliberately vague at the top If the owner reserves the right to enter every role whenever they fancy, all lower-level ownership remains conditional. Managers notice. Employees notice. Eventually everyone waits. An owner can still intervene Of course. Emergency. Major risk. Something genuinely failing. Ownership rights do not mean: Founder banned. But intervention should be exceptional enough that the normal structure remains credible. Temporary involvement should have an exit Owner steps into Operations because manager left. Fine. Temporary. Write: What am I covering? Until when? Who eventually receives it? Otherwise temporary responsibility quietly becomes permanent. Five years later: "Why am I still doing this?" Because nobody deliberately moved it back out. Role creep happens constantly Good employee. "Can you also handle this?" They do. Then: Another thing. Two years later their actual job bears almost no resemblance to the title. Review significant roles periodically. What are they really doing? Should they? Does title still fit? Does salary? Does authority? Does workload? Role clarity does not mean rigidity People worry: "We're small. Everyone needs to muck in." Agreed. You can have: Flexible execution. Clear ownership. Those are completely compatible. Sarah can help Operations during a crisis. That does not mean nobody knows who owns Operations. "That's not my job" culture is not the objective The goal is not employees refusing to help across imaginary departmental borders. It is: I know what I own. I know where I contribute. I know when another person owns the outcome. And I will collaborate without losing accountability. That is different. A mature business needs both flexibility and clarity Too little clarity: Chaos. Too much rigid bureaucracy: Slow. The target sits between them. Clear enough that outcomes have owners. Flexible enough that humans still help each other. The HSE language is useful here Its Role standard does not demand inflexible jobs. It asks organisations to provide enough information for employees to understand their role and responsibilities, keep requirements reasonably clear and compatible, and provide ways for people to raise concerns where responsibilities conflict. That is a sensible standard for almost any growing business. Role clarity is particularly important during change New manager. Acquisition. Restructure. Promotion. New department. System implementation. Someone leaves. These are moments when responsibility moves. Do not assume everyone sees the new map automatically. Say it. When you promote someone, explicitly transfer authority "You're now Operations Manager." Great. Which decisions changed? Who reports to them? What previously came to owner that now goes to them? Which meetings do they lead? Which KPIs? Without that transfer, promotion can be mostly salary and title. Communicate the change to everybody affected Do not tell Sarah privately: "You own this now." Then leave employees asking you. Explain: "From Monday, scheduling and resource allocation sit with Sarah. If you have a scheduling issue, take it to Sarah. These are the situations that still come to me." Now structure becomes real. Support the new owner publicly Employee bypasses Sarah and asks you. Do not answer reflexively. "This sits with Sarah." Redirect. Otherwise you undermine the transfer in thirty seconds. Do not allow managers to redirect everything back upwards either Manager says: "I wasn't sure, so I asked Adam." Question: Was it inside your authority? If yes: Make the decision. Role clarity is partly about knowing where responsibility ends. Then having the courage to operate inside it. What if people disagree about who should own something? Good. Discuss it. Ask: Who has the information? Who controls the resources? Who is closest to the outcome? Who can reasonably be accountable? Which role has the appropriate authority? Design it. Do not let responsibilities simply fall to the most conscientious person because: "They'll make sure it gets done." That is how great employees become overloaded. Ownership should follow capability and position, not personality The loudest person should not automatically own. The founder's favourite should not automatically own. Person who always volunteers should not own everything. Put responsibility where the organisational logic says it belongs. Make workload visible during role design You map Sarah's outcomes. Seven major areas. Then discover each one is a full-time job. Role clarity exposed a capacity problem. Excellent. Better than pretending Sarah owns all seven and blaming her when four fail. Clarity can reveal organisational gaps You map everything. One major outcome remains: Nobody sensible can own it. Perhaps you discovered a missing role. That can support: Recruitment. Restructure. Promotion. Process redesign. This is why role mapping is commercially useful. It can also reveal duplicated management Outcome: Supplier performance. Owned by: Operations Manager. Procurement Manager. Commercial Director. Owner. Four owners. Perhaps one is enough. Role clarity can remove work as well as allocate it. The best ownership map usually makes the organisation simpler Fewer: Approvals. Duplicates. Meetings. Escalations. Questions. Not more. If role clarification creates additional bureaucracy everywhere, redesign it. A simple role charter For each important role, one page. Purpose Why does this role exist? Primary outcomes Five to seven things it must make happen. Measures How do we know? Decision authority What can the person decide? Key interfaces Who do they depend on? Who depends on them? Escalation What should move upwards? Does not own Useful boundary. That is enough for many SMEs. Review role charters in one-to-ones Ask: Is this still accurate? What are you doing that is not here? What do you think you own that I think someone else owns? Where are decisions unclear? What continually gets bounced between departments? Those conversations reveal reality. Ask managers to write their own first This is useful. Without showing them your answer: "What do you believe you own?" Then compare. Manager says: "I own sales." Owner's expectation: "You own sales, marketing, forecasting and key accounts." Interesting. Or opposite. You thought they owned pricing. They thought you did. Better to discover in a conversation than through a lost customer. Run the same exercise between functions Sales writes: What we own. What we need from Operations. Operations writes: What we own. What we need from Sales. Compare. The mismatches become your improvement list. Watch for three classic gaps The invisible gap Nobody thinks they own it. The overlap Several people think they own it. The shadow owner Job officially belongs elsewhere but owner still controls it. Those three patterns explain enormous amounts of SME friction. Another classic: responsibility without final decision Project Manager owns project. But customer variations require owner approval. Purchasing requires owner. Resource changes require owner. Price requires owner. Fine if risk requires those controls. But if most normal project decisions travel upwards, Project Manager's role is narrower than you think. Be accurate about it. Authority should increase with competence New manager: More review. Experienced manager: Greater discretion. That is normal. Role clarity does not require identical authority forever. Document current boundaries and deliberately expand them. The role can evolve as the person develops This is much better than vague encouragement to: "Step up." Perhaps today: Manager can approve £1,000. Six months of strong judgement: £5,000. Now development has an observable form. Performance management becomes easier when ownership is clear Employee misses outcome. You can ask: Did they know it was theirs? Did they have authority? Resources? Capability? Acas recommends objectives that are clearly connected to a person's role and responsibilities and reviewed through regular performance conversations. That makes accountability considerably fairer. Without role clarity, poor performance conversations become arguments Manager: "You didn't do this." Employee: "I thought James was doing it." Manager: "Well, you should have known." Weak. Clear ownership removes some of that ambiguity. Not every performance issue. But a lot. Recruitment improves too Government guidance for employers says defining the role and what good looks like should happen before writing a job advert, including responsibilities, hours and required skills or experience. Exactly. Do not recruit: "General Manager to take stuff off me." Define: Which stuff. Which outcomes. Which authority. Then find the person. Organisational risk needs clear ownership as well Although written for public-sector organisations, the UK government's Orange Book states a broadly useful governance principle: roles and accountabilities for managing risks and controls should be clearly defined and assigned to people with appropriate seniority, skills and experience. The context is different from a typical owner-managed SME. The principle still travels well. Important risks should have owners. Think particularly carefully about: Health and safety. Cybersecurity. Data protection. Cash. Regulatory compliance. Key customer concentration. Quality. Business continuity. Someone should know: "I own making sure this risk is managed." Not: "I assumed IT dealt with it." Do not confuse ownership with technical expertise Finance Director may own ensuring tax obligations are properly managed. They may still use: Accountant. Tax specialist. Payroll. Ownership means ensuring the outcome is handled. Not personally possessing every specialist skill. This allows organisations to remain clear without expecting impossible breadth. The same applies to the owner You remain ultimately responsible for the company. That does not mean you personally perform every responsibility inside it. Ownership of the company is not the same as operational ownership of every task. That distinction is the whole game. A 30-day role-clarity reset Week 1: Find ambiguity For one week, record moments involving: "Who owns this?" "I thought they were doing it." "Can you decide?" "Adam needs to approve." "That's not my department." Those are your clues. Week 2: Map important outcomes List the twenty or thirty recurring outcomes that matter most. Assign: Primary owner. Contributors. Decision authority. Escalation. Week 3: Map management roles For every manager: Purpose. Primary outcomes. KPIs. Authority. Interfaces. What they do not own. Week 4: Communicate and test Tell the organisation. Redirect questions. Run meetings using the new ownership. Notice where reality does not fit the map. Adjust. Then test the structure through absence Owner unavailable for a day. Do people know who decides? Sales Manager unavailable. Who covers? Operations Manager on holiday. Which decisions have delegation? Role clarity includes resilience. One named owner with no backup creates key-person dependency. Primary owner does not mean only capable person You still need: Deputies. Cross-training. Succession. The distinction is: One person is clearly accountable today. Others can step in when required. Article #46's knowledge-transfer principles matter here. Build deputies deliberately For each critical role: Who acts when they are unavailable? Which decisions can deputy make? What information do they need? Now ownership does not disappear when someone goes to Tenerife. Role clarity should eventually reduce meetings Fewer meetings required to decide who decides. Fewer people invited "just in case." Fewer update meetings because ownership and KPIs already create visibility. That is a useful success measure. If role clarification leads to twelve new recurring meetings, something may have gone wrong. It should also reduce owner interruptions Employee knows: Who to ask. Manager knows: What they can decide. Functions know: How handovers work. Owner becomes less necessary as human routing software. That is Dependency Removal. It should improve speed Clear authority: Decision. Unclear authority: Discussion. Email. Manager. Owner. Back to manager. Clarification. Decision. Days disappear inside ambiguity. Role clarity can improve speed without asking anybody to work faster. It should improve accountability without creating micromanagement Because the owner no longer needs to watch: How everything happens. They can review: Outcome. Measure. Exceptions. That is the connection between role clarity and good delegation. It should make growth easier New employee arrives. Where do they sit? Who manages them? What outcome do they contribute to? Who decides? The organisational architecture becomes teachable. That matters as headcount rises. How Evolve approaches role clarity If an owner tells me: "My team needs to communicate better." I want examples. Because communication may not be the problem. Maybe: Nobody owns the outcome. Two people own the same decision. Manager has responsibility but no authority. Functions have no defined handover. Employees can bypass managers. Owner keeps changing priorities. Everything eventually escalates upwards. Then another communication workshop is unlikely to solve much. We need to redesign who owns what. I normally want to see where the work actually goes Not just the organisational chart. Customer enquiry enters. Where? Then what? Who decides? Who receives it? Who knows whether it happened? Where does the owner reappear? Trace reality. That tells us far more than job titles. The objective is not creating an organisation where nobody helps anybody Quite the opposite. Good role clarity makes collaboration easier. Because I can help you without worrying that: Nobody owns my work. I accidentally took responsibility permanently. Two managers will give contradictory instructions. The owner will reverse the decision tomorrow. Clarity gives collaboration structure. Nor is the objective making managers territorial "This is mine." "This is yours." Wrong interpretation. Functional boundaries exist to improve outcomes. Not build kingdoms. A strong management team cares about company performance while retaining clear individual accountability. Owners need to tolerate the loss of operational ownership This is the uncomfortable bit. Once Sarah genuinely owns Operations, you are no longer the person who automatically decides every operational question. You still own the company. But you transferred part of the operating responsibility. If you cannot tolerate that transfer, role clarity will remain theoretical. The test is not what the chart says The test is: When something happens on Thursday afternoon, who does everybody instinctively look at? If the answer is still: Owner. Then the real role map has not changed. So, who should actually own what in a growing small business? Start with outcomes. Not job titles. Not historic habits. Not whoever happens to be most reliable. Identify what the business needs to happen repeatedly. Assign one clear primary owner where practical. Define the contribution required from others. Give the owner enough authority to influence the result. Clarify the decisions they can make. Define where escalation begins. Build clean handovers between functions. Attach meaningful measures. Communicate changes. Then make your behaviour match the structure. And include yourself. Because a growing company does not need the owner involved everywhere. It needs the owner to make sure everything important has somewhere sensible to live . That is role clarity. Not bureaucracy. Not endless documentation. Just a company where, when something matters, people no longer need to ask: "Whose job is this?" They already know.
Two very different handmade ceramic pieces displayed with the same price.
by Adam Fox • 29 September 2026
Busy but not making enough profit? Learn the signs of underpricing, how to calculate true margin and when higher prices can improve the business.
Bright aerial view of one river dividing into many smaller channels across a wide plain.
by Adam Fox • 29 September 2026
Growing revenue but less cash? Learn how debtors, stock, WIP, payroll and payment terms consume working capital as a business expands.
Runner passing measured split points on a bright outdoor athletics track.
by Adam Fox • 29 September 2026
Which KPIs really matter in a small business? Build a simple owner scorecard covering cash, margin, sales, delivery, capacity and risk.
Swimmers occupying separate lanes in a bright outdoor pool with visible spare capacity.
by Adam Fox • 29 September 2026
A £35k employee costs more than £35k. Learn how to calculate true employment cost, cash impact and the value a new hire needs to create.
Dancer receiving precise feedback during a bright professional rehearsal.
by Adam Fox • 29 September 2026
Employee not performing? Learn how to diagnose the cause, set clear improvement expectations and know when formal action may be necessary.
Show More