How Do I Get Critical Business Processes Out of People's Heads?
Why Documenting a Process Isn’t the Same as Making It Repeatable
An SOP can be completely accurate and still leave the process dependent on one person
Imagine an SOP that says:
Send the monthly report to leadership.
Technically, that's documented.
But:
Who starts it?
Where do the numbers come from?
Who owns each input?
What happens when someone doesn't respond?
Who approves the report?
Where does the final version go?
And what happens when something doesn't follow the normal path?
If one experienced employee still carries those answers around in their head, the process is documented—but it isn't operationalized.
The real test isn't whether you have SOPs
It’s this:
Could a capable new employee execute one of your critical processes without repeatedly finding someone to explain how it really works?
If not, the real process still lives somewhere outside the system.
Maybe it's:
an approval everyone knows to wait for;
an email that always gets sent but isn't documented;
a spreadsheet leadership forgot was part of the workflow;
two longtime employees who know when to hand something off;
or an exception that happens often enough to be normal but has never been built into the process.
The Digital Operations Assessment is designed to identify where the biggest operational dependencies are and what should be systematized first.
Getting information out of people's heads starts with understanding what actually happens
Asking everyone to write more SOPs won't surface everything you need to know.
You have to understand the work as it actually happens.
Where does it begin?
Who owns it?
What has to happen before the next person can move?
Where does it usually stall?
What requires a decision?
What happens when the normal path breaks?
And what does leadership actually need visibility into?
That gives you enough context to decide what actually needs documentation, workflow structure, automation, clearer ownership—or a different process entirely.
A quick diagnostic for CEOs
If you're wondering how much of your company is still operating on tribal knowledge, start here:
1. If one key employee disappeared for 30 days, what would stop moving?
Not what would become inconvenient. What would actually stall because nobody else fully understands what happens next?
2. How often does someone have to ask, “Who handles this?” or “What happens next?”
Occasional questions are normal. Repeated questions about recurring work usually point to something that isn't sufficiently visible.
3. Do your SOPs describe tasks, or do they show how work moves between people and departments?
Knowing how to complete an individual task is useful. Knowing where that task fits into the larger workflow is what makes the process repeatable.
4. When something doesn't follow the normal process, is it clear who makes the decision?
Many processes work perfectly until an exception appears. If every exception has to travel back to one particular employee or the CEO, you've found another dependency.
5. Could a capable new employee follow your critical workflows without repeatedly asking someone how things are really done?
If not, there is probably still important operational knowledge living outside the system.
If several of these questions are difficult to answer, you may not have a documentation problem.
You may have an operationalization problem.
That means identifying the processes the business depends on, understanding how work actually moves today, and turning the right knowledge into systems the team can reliably execute tomorrow.
That's how a business moves from:
“Ask Mike. He knows how we do that.”
to:
“This is how the company works.”
Jess knows what happens after the customer approves something.
Mike knows which department needs to be looped in next.
Someone in accounting knows the workaround for the issue that comes up every few months.
And you know which exceptions actually matter.
Nothing necessarily looks broken.
Until Jess takes vacation.
Mike leaves.
A new employee starts.
Volume increases.
Or something falls through the cracks because everyone assumed someone else knew what happened next.
That's when a company discovers something uncomfortable:
What looked like a process was actually a collection of people remembering what to do.
And the obvious response is usually:
We need better documentation.
Maybe.
But that may not actually be the problem.
You can have SOPs and still run on tribal knowledge
Growing companies accumulate tribal knowledge naturally.
Someone figures something out.
It works.
They repeat it.
Other people learn who to ask and what normally happens.
Eventually, everyone says:
“That's just how we do it.”
The company may even have SOPs, checklists, training documents, SharePoint folders, spreadsheets, or project-management software.
But having those things doesn’t necessarily remove the dependency.
Because a document can tell someone what to do without showing how the work moves.
An SOP can be completely accurate and still leave the process dependent on one person
Imagine an SOP that says:
Send the monthly report to leadership.
Technically, that's documented.
But:
Who starts it?
Where do the numbers come from?
Who owns each input?
What happens when someone doesn't respond?
Who approves the report?
Where does the final version go?
And what happens when something doesn't follow the normal path?
If one experienced employee still carries those answers around in their head, the process is documented—but it isn't operationalized.
The real test isn't whether you have SOPs
It’s this:
Could a capable new employee execute one of your critical processes without repeatedly finding someone to explain how it really works?
If not, the real process still lives somewhere outside the system.
Maybe it's:
an approval everyone knows to wait for;
an email that always gets sent but isn't documented;
a spreadsheet leadership forgot was part of the workflow;
two longtime employees who know when to hand something off;
or an exception that happens often enough to be normal but has never been built into the process.
If your company has outgrown the way work currently gets done, the Digital Operations Assessment is designed to identify where the biggest operational dependencies are and what should be systematized first.
Getting information out of people's heads starts with understanding what actually happens
Asking everyone to write more SOPs won't surface everything you need to know.
You have to understand the work as it actually happens.
Where does it begin?
Who owns it?
What has to happen before the next person can move?
Where does it usually stall?
What requires a decision?
What happens when the normal path breaks?
And what does leadership actually need visibility into?
That gives you enough context to decide what actually needs documentation, workflow structure, automation, clearer ownership—or a different process entirely.
A quick diagnostic for CEOs
If you're wondering how much of your company is still operating on tribal knowledge, start here:
1. If one key employee disappeared for 30 days, what would stop moving?
Not what would become inconvenient. What would actually stall because nobody else fully understands what happens next?
2. How often does someone have to ask, “Who handles this?” or “What happens next?”
Occasional questions are normal. Repeated questions about recurring work usually point to something that isn't sufficiently visible.
3. Do your SOPs describe tasks, or do they show how work moves between people and departments?
Knowing how to complete an individual task is useful. Knowing where that task fits into the larger workflow is what makes the process repeatable.
4. When something doesn't follow the normal process, is it clear who makes the decision?
Many processes work perfectly until an exception appears. If every exception has to travel back to one particular employee or the CEO, you've found another dependency.
5. Could a capable new employee follow your critical workflows without repeatedly asking someone how things are really done?
If not, there is probably still important operational knowledge living outside the system.
If several of these questions are difficult to answer, you may not have a documentation problem.
You may have an operationalization problem.
That means identifying the processes the business depends on, understanding how work actually moves today, and turning the right knowledge into systems the team can reliably execute tomorrow.
That's how a business moves from:
“Ask Mike. He knows how we do that.”
to:
“This is how the company works.”
Jane knows what happens after the customer approves something.
Mike knows which department needs to be looped in next.
Someone in accounting knows the workaround for the issue that comes up every few months.
And you know which exceptions actually matter.
Nothing necessarily looks broken.
Until Jane takes vacation.
Mike leaves.
A new employee starts.
Volume increases.
Or something falls through the cracks because everyone assumed someone else knew what happened next.
That's when a company discovers something uncomfortable:
What looked like a process was actually a collection of people remembering what to do.
And the obvious response is usually:
We need better documentation.
Maybe.
But that may not actually be the problem.
You can have SOPs and still run on tribal knowledge
Growing companies accumulate tribal knowledge naturally.
Someone figures something out.
It works.
They repeat it.
Other people learn who to ask and what normally happens.
Eventually, everyone says:
“That's just how we do it.”
The company may even have SOPs, checklists, training documents, SharePoint folders, spreadsheets, or project-management software.
But having those things doesn’t necessarily remove the dependency.
Because a document can tell someone what to do without showing how the work moves.