How do I know if we have a succession risk in operations?

Ask yourself: if the person who holds the operational knowledge took a two-week vacation starting tomorrow, what breaks? If the answer is nothing because the team can route around, you don't have the risk. If the answer is a specific list of things that will not get done, or will get done wrong, or will require the person on vacation to be called, you have the risk. The size of the list tells you how deep it goes.

How do I ask my operations person to document their job without making them feel replaceable?

Frame it as leverage, not documentation. The point isn't to write down what they know so someone else can do it. The point is to move the knowledge into the system so they can step away from the parts that aren't the real work and spend time on the parts that are. Most senior operations people secretly know which parts of their job they'd rather not do, and welcome the chance to hand those over to a system.

Should I just hire a second operations person as backup?

Usually no. A second ops person who shadows the first produces two people who both carry the undocumented knowledge, which doubles the salary cost without reducing the risk. The right move is to make the knowledge live in the system so the ops person's role becomes repeatable by someone with ordinary training, not years of institutional memory. Then a second hire backfills a defined job description instead of a person.

What belongs in SOPs and what should live in a system?

SOPs are good for stable procedures that change rarely and have no built-in enforcement, like onboarding checklists or quarterly compliance runs. Anything that happens frequently, must be enforced, or has exceptions should live in the system itself as workflow automation, required fields, approval steps, or scheduled triggers. If a procedure requires someone to remember to check an SOP, the SOP has already failed. The system should force the behavior, not describe it.

How much does it cost when a key operations person quits unexpectedly?

In a 10 to 30 person business, the typical cost of losing the sole holder of operational knowledge is six to twelve months of impaired performance plus two to four months of hiring and ramp. Measured in dollars, that's commonly six figures when you include the cost of workflows breaking, the backlog that accumulates, the overtime of people covering, and the one or two customers lost because something fell through the cracks. The ongoing cost of the risk is harder to see, which is why most founders don't price it until the person actually leaves.

Can AI replace the operational knowledge in a growing business?

Not the judgment part, and not for several more years. AI can replace the mechanical parts: data lookups, cross-system reconciliation, status updates, simple approvals. It cannot yet reliably handle the exception that comes up once a quarter and requires knowing why a particular customer is treated differently. The right use of AI in ops right now is to compress the mechanical work by 60 to 80 percent, leaving the senior ops person free to focus on the judgment work. That's valuable; it's not a replacement.

What to do when one person holds all the operational knowledge in your business

The direct answer In most 10-to-30 person businesses, one person — usually the operations director, the longest-tenured admin, or the founder's chief of staff — holds most of the operating knowledge. The workflows, the exceptions, the judgment calls. If they get sick, promoted, or quit, the business grinds. The fix isn't to replace them. It isn't to force them to document everything. It's to move the knowledge into the system so the person gets the leverage instead of the burden, and the business keeps running when they step away.

Written by Thelma Cardozo, operations systems architect at Pathana. 15+ years building ops systems from Qualcomm and Nasdaq to founder-run firms. Top 1% Expert-Vetted on Upwork. Pathana resells no tools and takes no referral fees, so the answer below is operational, not a vendor pitch.

Reading time: 9 min Best for: Founder or CEO of a 10–30 person business where one person is the single point of operational failure

Recognizing the pattern in your own business

You know who they are. They were the first operations hire, or they came in as an executive assistant and absorbed everything, or they built the current setup themselves. They've been with the business for three, five, maybe ten years. They know who the exceptions are and why. They remember the time a key customer got a special discount that still applies, and the time an integration broke and the workaround that was never really fixed. They know which of your tools are reliable and which ones require a weekly manual check nobody wrote down.

The team respects them. You respect them. They are, by every reasonable measure, excellent at their job. The problem is that the job they're excellent at only exists because they're the one doing it. If they weren't, the business would have had to engineer the knowledge into systems years ago.

You've probably named this out loud. "If [name] got hit by a bus, we'd be in trouble." Said quietly to a trusted peer, or to your spouse, or to yourself in a journal. The joke exists because the thing is real. The quiet word for it, when founders stop joking, is dangerous.

The question isn't whether to do something about it. It's how to do something about it without insulting the person who's been loyal to your business, without triggering the fear that they're being replaced, and without producing a stack of SOPs nobody will ever read.

Why "just document everything" always fails

The intuitive fix is documentation. Ask the person to write down what they know. Hire a consultant to interview them and produce SOPs. Make a Notion wiki. Record Loom videos. Get it out of their head and onto paper.

This doesn't work, for predictable reasons.

The first reason: a lot of what the person knows isn't documentable in isolation. It's conditional, context-dependent, built on five years of knowing which exceptions matter and which don't. "This customer always ships to a different address than the one on file" isn't a procedure — it's a judgment call that lives inside the context of knowing that customer. You can write it down, but the writing-down is a brittle snapshot that gets stale the moment the customer's situation changes.

The second reason: the people the documentation is supposedly for — new hires, backups, the team that would cover during a vacation — won't read it until they need it, and when they need it they won't know which document applies. SOPs that require a person to remember to look them up have already failed. If the process depends on the person checking a document, the process doesn't survive the stress of them not checking.

The third reason, and this is the one founders miss: documenting the person's job sends a signal to the person that they're being backed up because they might not be here much longer. Even when that's not the intention, the signal gets through. The person starts to hedge. They slow down the documentation. They become subtly less helpful. The documentation project stalls at thirty percent complete and the business is now in a worse position than before — the risk is unchanged and the trust is damaged.

The documentation approach fails because it treats the knowledge as something to be extracted and stored. The knowledge isn't the problem. The problem is that the business runs on remembering to do things instead of on systems that do things. The fix changes the second half, not the first.

What to do instead — three categories of knowledge, three different fixes

Most of what the person holds falls into one of three categories. Each category has a different fix. The categories are workflow, exception, and judgment.

1. Workflow — the day-to-day sequence

These are the regular, repeating sequences of steps that produce the business's output. New lead arrives, gets assigned, gets a sequence of touches, gets qualified, gets a proposal, gets a close. Customer onboarding, invoice generation, order fulfillment, payroll processing. The workflow is predictable; the person who holds it just happens to be the one carrying it today.

The fix: move the workflow into the system. If a new lead arrives, the CRM should assign it, the automation should kick off the first touch, the task should land in the right person's queue. The person who used to carry the workflow manually becomes the person who maintains the workflow and handles the handful of cases where it needs human judgment. Their job becomes smaller in volume and bigger in leverage.

Most workflow knowledge is 60-80 percent compressible this way. The remaining 20-40 percent is in the next two categories.

2. Exception — the "we always do it this way because" knowledge

These are the specific, named cases where the standard workflow doesn't apply. The customer who insists on net-45 because of a legacy agreement from year two. The district that bulk-orders in September so inventory has to be ready in August. The vendor you always pay early because they give you better terms for it. The product line that ships from a different warehouse. Dozens or hundreds of these, each one small, each one perfectly logical if you know the context.

The fix: encode the exceptions in the system as flagged attributes on the records they apply to. The customer who gets net-45 has a billing-terms flag on their record that drives the invoice behavior. The district that orders in September has an inventory-planning note on their account. The product line has a shipping-origin field. The exception becomes a property of the data, not something a person has to remember.

This is the real work of the Review. Interviewing the person who holds the exceptions, listing them, and designing where in the data they belong, is a two-to-four week engagement that produces a map of institutional knowledge the business can use even if the person steps away.

3. Judgment — the "I just have a feeling about this one" knowledge

This category is the smallest and the hardest to systematize. The person has been in the business long enough that they can tell, within fifteen seconds of looking at a new order or a new lead, whether something is off. That skill is real, it's valuable, and it genuinely can't be fully documented or automated.

The fix: preserve the judgment work for the person who holds it, and reduce the volume of judgment calls they have to make by handling the obvious cases automatically. If 80 percent of leads are routine and 20 percent require a judgment call, the system handles the 80 percent and routes the 20 percent to the person. Their day shifts from "process 100 leads" to "exercise judgment on 20." That's the leverage.

The business still depends on their judgment, but it depends on their judgment for the hard calls only. Vacations become possible because the easy 80 percent keeps moving without them. If they leave, the business still functions on the easy 80 percent while hiring and training a replacement for the judgment work — a much more hireable job than "replace the person who holds everything."

VerdictThe fix is not documentation. The fix is to move workflow into the system, encode exceptions as data attributes, and preserve judgment for the human — with the volume of judgment calls reduced by handling the routine automatically. The person gets smaller volume and higher leverage. The business gets a system that holds without them.

How to have the conversation with the person

This is the part most founders get wrong, and the reason most succession-risk projects stall before they start.

Don't frame the project as documentation. Don't frame it as backing them up. Don't frame it as succession planning. All three of those framings signal, to the person, that they're being prepared to be replaced.

Frame it as leverage. The real conversation is: "You're spending time on parts of your job that don't need your experience. I want to get you out of those so you can spend more time on the parts that do. Here's what I think can get moved into the system; what else do you wish you didn't have to do by hand?"

The person usually knows exactly which parts they'd like to hand over. Reconciling records across systems that should agree. Checking the same report every Monday. Chasing the same approvals every month. Reminding people to do things they should remember to do themselves. These are the parts that build frustration quietly over time, and the ops person will almost always volunteer them when asked honestly.

Starting with their list, not yours, changes the whole project. They become the person building the leverage, not the person being replaced. The documentation gets done — because the system needs it to work — but it's a byproduct of the real goal, which is their job getting smaller in volume.

A composite from one engagement

A founder-led education publishing company, about ten people. The operations director had been there seven years. She held the knowledge of every customer exception, every district's quirks, the manual spreadsheet that reconciled Shopify sales against district invoices, the weekly report that she generated by hand, the quarterly compliance filing she'd done since the beginning. The CEO's quiet word for her situation was dangerous. The director's own description, when I interviewed her, was that she was exhausted and secretly worried the business would collapse if she took more than a long weekend off.

We ran the Review. The output was that about 65 percent of her work was workflow that could be moved into the system, 25 percent was exceptions that could be encoded as data attributes, and about 10 percent was judgment that only she could do. The fix was a scoped project that automated the Shopify-to-QuickBooks reconciliation (killing the manual spreadsheet), flagged the exception customers directly on their records (reducing the "wait, don't do that with that customer" friction), and reshaped her weekly report into an auto-generated dashboard.

Six months later she took two weeks off and the business ran. The CEO got reports on demand instead of waiting for someone to pull them. The director herself started running a program the CEO had been trying to launch for two years but didn't have the operations capacity for. Both of them are more valuable now than before.

The person is still there. The dangerous feeling is gone. That's the shape of the fix.

If this pattern sounds like your business, the next step is a 30-minute first call. Leave knowing which leak to fix first — no sales pitch, no pre-reading, no commitment.

Book a first call — 30 min (opens Google Calendar in a new tab)