Every firm I work with has at least one system nobody fully understands. The renewal spreadsheet with a macro somebody’s nephew wrote. The automation that moves a form fill into the CRM and drops half the fields without telling anyone. The invoice folder that only sorts correctly if you name the file a certain way. Key person risk in operations rarely arrives as a resignation letter. It arrives as a Tuesday where something stops working, and four people in a row say “I think Marcus set that up”.
The usual reaction is guilt. We should document everything. We should have a manual. Someone buys a wiki tool, three pages get written, and the wiki dies the same month.
That reflex aims at the wrong target. You are never going to have a firm where everyone understands everything. Nobody understands the whole payment network their card runs on either, and the card still works.
The person who knows everything does not exist
We like to believe there is an operations person somewhere who holds the entire business in their head. In small firms that person seems to exist, because for a while they do hold most of it. They built the spreadsheet, they wrote the email templates, they know which vendor portal needs the old password.
What they have is not total recall. It is a good instinct for where a thing would live. Ask them where the commission split for a specific carrier gets applied and they do not recite a cell reference. They think for a second and say “probably in the tab we use for month end”, and they are right most of the time.
That instinct is the real asset. It comes from the system being laid out in a way that matches how the business thinks about itself. You can build that on purpose, and once you have, it survives the person leaving.
Why does this get worse the more you automate?
Every tool you add takes work off someone’s plate and takes a little understanding with it. That trade is usually worth it. A rules engine that checks a submission for missing fields frees the coordinator from checking by hand, and she stops carrying that list in her head. She understands the process less and ships more work. Fine.
The problem is that the trade compounds, and nobody notices it compounding. Add a scheduler, a document generator, an AI drafter for follow-up, a sync between two systems, and the number of moving parts nobody has looked at in a year climbs. Each one made sense. Together they form a stack where the honest answer to “what happens after the form is submitted” is a shrug and a guess.
AI tools speed this up because they produce output faster than anyone reads it. A model can generate a follow-up sequence, a summary, a data mapping, a small script, in the time it takes to describe the task. That is why so many of them get abandoned, which we get into in why most AI agents burn money. The build was cheap. The understanding was not.
So the goal is not to keep understanding everything. The goal is to make the parts nobody understands safe to not understand.
What a findable system looks like
Good internal systems are not the ones where every employee knows every step. They are the ones where a person who knows nothing can find the right place within a few minutes and change one thing without breaking three others.
Name things the way the business names them
If your team says “renewals”, the folder is called renewals. Not a name stitched together from a quarter and a version number. Not an acronym one director invented. The cheapest thing you can do this month is rename files, folders, pipeline stages, and automation jobs to match the words people say out loud in meetings.
This sounds cosmetic. It is not. Naming is how someone with no context builds a map in their first hour instead of their first week.
Document one flow end to end, not everything at a shallow level
Most process documentation fails because it tries to cover the whole business at once and gets thin everywhere. Pick your highest-volume flow. New client onboarding, or quote to bind, or file to funding. Write down what happens at each hop, where it lives, and who or what performs it.
One flow described properly is worth more than a wiki full of stubs. It also teaches the person writing it where the seams are, because you cannot describe a hop you do not understand, so you will have to go and ask.
Make the black boxes announce themselves
You will have parts nobody understands. Accept it and contain them. Every automation should leave a trace a non-technical person can read: a log line in a channel, a row in a sheet, a status field that changes. When the sync breaks, someone should see it break rather than discover it three weeks later in a client complaint.
This is the piece firms skip, and it is the piece that turns key person risk into an actual outage. An undocumented process that reports its own failures is an annoyance. An undocumented process that fails without a sound is a liability.
Write down the weird cases
Every real system has quirks. The carrier that rejects PDFs over a certain size. The client who insists on being invoiced under a different entity. The state where a form needs a wet signature. These are not in anyone’s process doc because they feel too specific to write down.
They are the exact things that get lost when a person leaves, and the exact things a rebuild will fail to reproduce. Keep a plain running list of exceptions per flow. No format required. A shared doc where anyone can add a line beats a system nobody updates.
Should you rewrite the whole thing?
When a firm finally admits nobody understands the stack, the next instinct is to burn it down. New CRM. New everything. Clean slate.
I would push back on that almost every time. The mess encodes years of real decisions, and a fresh build reproduces the parts you remember while dropping the parts that only surface once a quarter. The rebuild goes live, and then for six months your team finds edge cases the old system handled and the new one does not.
The version that works is boring. Carve out one flow, replace that flow, run it in parallel until it holds, move to the next. You are making a series of changes to the existing system rather than replacing it. That approach looks slower on a slide and finishes sooner, and it is the sequence we describe in AI for operations for killing the spreadsheet that runs a company.
There is also a decent chance the stack is fine and the documentation is the only thing missing. Find out before you spend on a migration.
What should you actually do this week?
Start with a handover test. Pick your most important recurring process and ask someone who does not run it to run it, with the current documentation and no help from the usual owner. Watch where they stop. Every stop is a gap, and the list of stops is your real backlog.
Then fix the top three stops. Not with a project. With a rename, a written page, a status field, an alert. Cheap moves that make the next person’s first hour productive.
After that, take stock of what is running unattended. List every automation, sync, and AI-assisted step you can find, and mark each one as understood, contained, or unknown. Anything in the unknown column either gets a trace so it announces failures or gets turned off to see what breaks. How much checking each one still needs is its own question, and setting your trust bar covers where to draw that line.
If that audit turns into a build, the work belongs in the same place as the rest of your internal tools, designed so a new hire can find the right place in minutes rather than so the builder feels clever.
The firms that handle turnover well are not the ones with a genius who knows everything. They are the ones where losing that genius costs a week instead of a quarter.
Questions people are asking
What if the person who built our systems already left?
Start with one flow end to end rather than trying to reconstruct their whole mental model. Trace an actual record through the system, note every hop, and write it down as you go. The sheets, templates, and automation configs they left behind carry most of the logic even when the reasoning is gone.
Do we need a full process manual?
No, and chasing one is why most documentation efforts die. Cover your highest-volume flows, keep a running list of exceptions, and let the rest stay undocumented until it causes a problem. A short doc people update beats a long one nobody opens.
How do we stop this happening again as we add AI tools?
Require that every automated step leaves a visible trace and has a named owner before it goes live. If nobody in the firm can say what a tool does and where it reports its failures, it is not ready to run unattended. The test in where AI earns its place applies here too.
Is key person risk in operations really solvable at a small firm?
You cannot remove it, because a small team will always have specialists. You can shrink it. Make the system findable, make failures visible, write the quirks down, and the gap after a departure is measured in days of confusion rather than months of rebuilding.
