Every business has at least one person who just knows how things work.
They know which vendor needs a call instead of an email. They know the workaround for when the CRM doesn’t populate correctly. They know the three steps nobody bothered to write down because “it’s faster to just show you.” They’ve been asked to re-train two people who’ve been in the role for months, and will probably be asked to do it again for others.
This person is not a bottleneck. They’re a liability.
Not because they’re doing anything wrong — they’re usually the most competent person in the room. They’re a liability because when they go on PTO, get sick, or finally burn out from being the only one who can answer certain questions, everything they know walks out with them. And you won’t fully understand what’s missing until the thing they used to manage quietly starts breaking loudly.
This is tribal knowledge, and it is one of the most common and most expensive forms of operational risk in small and mid-size businesses.
Why it happens
Tribal knowledge accumulates in businesses that grow faster than their documentation does.
In the early days of any operation, documentation feels like overhead. The team is small, everyone talks to each other, and the process is simple enough that nobody needs to write it down. Then the business grows. New people join. The process gets more complicated. But the documentation habit never forms — because the person who knows the process is still there, and it’s always faster to ask them than to write it down.
Over time, that person becomes the single point of failure for a set of processes that the business now depends on. They answer the same questions repeatedly. They review work that doesn’t need their review — not because they’re a micromanager, but because nobody else knows how to do it correctly. They become expensive in two ways: in direct cost (their time spent on tasks that shouldn’t require their expertise) and in fragility (what happens when they’re not available).
The business never documents because it never has to — until it does.
What “the process” actually is
The first mistake most businesses make when they try to document a process is writing down what should happen instead of what does happen.
There’s always a gap between those two things.
What should happen is the clean version — the one that works when every input arrives on time, every system works correctly, and every person involved does exactly what’s expected. What does happen includes the workarounds, the exceptions, the judgment calls, the unofficial escalation path, the “we always do it this way on Fridays,” and the three checks that happen before anyone will approve the output.
Documenting the clean version is nearly useless. It describes a process that almost never runs as described. The first time something unexpected happens — which is most of the time — the person following the clean document hits a wall, and they’re back to asking the expert.
Documenting what actually happens requires a different approach.
How to extract a process from someone’s head
The goal is not to ask someone to write a document. That produces the clean version. The goal is to watch the process run, and then ask questions that surface the invisible logic.
Step 1 — Run it, don’t describe it. Ask the person to do the process while narrating what they’re doing and why. Not what the process is supposed to be — what they’re actually doing right now. This surfaces the real steps, the sequence, and the tools involved. Record it. Don’t take notes in real time — you’ll miss things.
Step 2 — Ask for the exceptions. Once you have the baseline, ask: “What do you do when X doesn’t work?” “What’s the most common thing that goes wrong?” “When does this take twice as long, and why?” The answers to these questions are the process. The baseline is just the frame.
Step 3 — Map the handoffs. Every process touches multiple systems and multiple people. Map exactly where the work goes when this person is done with their piece. Where does it land? Who picks it up? How do they know it’s ready? What do they do if it’s not? These are the integration points — and they’re where most of the breakdowns actually happen.
Step 4 — Test it without them. Give the documented process to someone who doesn’t know it, and have them run it without asking the expert any questions. Every place they get stuck is a gap in the documentation. Close the gaps, repeat. Two rounds of this usually produces something that actually works.
Why documentation alone isn’t enough
Most businesses that go through this exercise end up with a document in a shared folder that nobody reads.
The document exists. The process is “documented.” And three months later, the same person is still being asked the same questions, because the document is eight pages long, lives in a folder nobody remembers, and was last updated the week it was written.
Documentation that doesn’t connect to the actual workflow produces compliance theater — the appearance of a documented process without the operational benefit of one.
The step that most documentation projects skip is connecting the documented process to the systems that run it. A documented process tells someone what to do. An automated process does it — or at minimum, triggers the right person at the right step, routes the output to the right place, and flags exceptions before they become problems.
The difference is the difference between a recipe and a kitchen. The recipe tells you what to cook. The kitchen determines whether the meal actually gets made, on time, at the right quality, every day.
What automation has to do with it
Automation doesn’t replace documentation. It enforces it.
When a process runs in a system — even partially — it becomes observable, repeatable, and improvable in ways that a document never can be. You can see where it slows down. You can see which steps produce the most exceptions. You can see whether the handoffs are actually happening on the timeline the document says they should.
For most SMBs, the realistic path is not full automation of every process on day one. It’s identifying the one or two steps in a documented process that are highest-risk (most likely to be skipped, most likely to cause downstream problems, most likely to require the expert’s judgment), and automating those specific steps first. Trigger the right notification. Route the right data to the right system. Flag the exception before it becomes invisible.
That’s where the operational leverage lives — not in replacing the person who knows the process, but in making the process survivable if they’re not available.
Where WRA Fits
This is often where we start with new clients — not with automation, but with mapping. Before any workflow gets built, we document what’s actually happening: the steps, the systems, the handoffs, the exceptions. That mapping exercise almost always surfaces two or three places where a single automated step would eliminate the most fragile part of the process.
The result is a business that doesn’t depend on any single person’s availability to function correctly — and a process that can be handed off, scaled, or improved without starting from scratch every time.
Ready to Find Your Riskiest Process?
Pick the one process in your business that would cause the most disruption if the person who runs it was unavailable for two weeks.
Ask yourself: if that person had to walk someone through it right now, over the phone, while they were traveling — could they? Could the person on the other end execute it without calling back?
If the answer is no, that’s the first process to document. Not because documentation alone fixes it — but because you can’t automate, delegate, or scale something you haven’t mapped.