The $10M Business Running on Sarah

I put a one-word CTA at the bottom of a recent issue. Reply "orchestrate" if you need this in your business.

Someone did.

His note was short. His manager had just quit, and he wanted to know whether the right systems could soften the landing.

He wasn't asking about software features. He was realizing his business had been leaning on one person more than he'd ever put into words.

— & —

That manager wasn't just using the operating system. She was part of it.

She knew which customers paid late and needed a call before the due date. When the usual supplier was out, she knew who to phone instead. And she knew the twelve small things she did every morning that nobody had ever written down, because nobody had to.

Then she wasn't, and none of it was anywhere.

I spent my career in data engineering, and we call this a single point of failure. If only one engineer understands how a production system works, that engineer is a risk, not an asset.

Get hit by a bus, win the lottery, take a new job, and the system nobody else understands becomes the company's problem at the worst possible moment.

Unlock a focused set of AI strategies built to streamline your work and maximize impact. This guide delivers the practical tactics and tools marketers need to start seeing results right away:

Stay ahead of the curve with these top strategies AI helped develop for marketers, built for real-world results.

Download the Free Report

So we fight it on purpose. We write documentation, keep runbooks for the routine jobs and the emergencies, and map what depends on what. There's even a crude metric for it, the bus factor: how many people would have to disappear before a system nobody understands grinds to a halt.

A bus factor of one is an emergency you haven't had yet.

Small businesses tolerate a bus factor of one all the time. They just don't call it that. They call it Sarah, and they call her indispensable, and they mean it as a compliment.

Here's the part worth sitting with. Your most dangerous undocumented system might be a person.

I learned this the calm way, which is the good way to learn it. When we took over one of our storage facilities, Cara was running the site.

Our long-term model was remote operation, so we knew going in that her role would change. This was not a dramatic firing. She wasn't combative, we gave her time to line up other work, and the transition was as decent as these things get.

But the most important thing we did in that stretch had nothing to do with the exit. It was extracting what she knew.

Cara knew the operational texture that wasn't written anywhere. How certain situations got handled. Which tenants needed a particular touch, and which vendors actually showed up.

Those routines and exceptions make a facility run without anyone thinking about them. The knowledge was real, and it was valuable, and it lived entirely in her head.

The goal was to turn Cara's knowledge into company knowledge. Every question we could get answered before she left was a fire we wouldn't be fighting after.

And now I have to be honest and turn the same question on myself.

Today we have an operations VA who has become genuinely important to how we run. That's a good thing. It's also exactly the setup I just described.

If she disappeared tomorrow, what would we suddenly discover only she knew? I don't fully know the answer, and that's the point. The dependency is comfortable right up until it isn't.

Let me be clear about what this is not. Writing things down is not about making good employees disposable.

The opposite, actually. Great employees should become more valuable as the company becomes less dependent on the knowledge trapped in their heads. When the process is documented, your best person can train the next hire instead of being the only hire who can do the job.

They can improve the process instead of just running it. They can move up into work that actually needs their judgment, and leave a stronger company behind them. Tribal knowledge traps your best people at their current level, and documentation frees them.

This is where it connects to everything Exit & Equity is about.

A buyer is not just buying your earnings. A buyer is buying confidence that those earnings keep showing up after you, or your key people, are gone.

If an important part of the business only works because Sarah does twelve unwritten things every morning, that is key-person risk, and a serious buyer will find it and price it. The company can have software, employees, and real revenue, and still have part of its operating system stored in one person's brain.

Which brings up the distinction that matters most here. There's a difference between having software and having an operating system.

ServiceTitan, Jobber, QuickBooks, Slack, a stack of spreadsheets. All of it holds data and runs workflows. None of it holds the unwritten rules that connect one system to the next.

Think about the judgment call on when a late fee gets waived, the reason certain jobs quietly skip a step, or the sequence someone follows every morning that isn't in any manual. A company can have software everywhere and still run on tribal knowledge. The software is the tooling; the operating system is the part still living in people's heads, and that's the part that doesn't transfer.

So do this exercise this week. It takes ten minutes and it will make you a little uncomfortable.

Ask yourself: who could quit tomorrow and make you panic? Picture the actual person. Now, for them, answer honestly:

The length of that list is your key-person risk. Not a feeling about it. The actual list.

You don't have to fix all of it this quarter. You just have to stop pretending it isn't there, and start converting one person's knowledge into company knowledge, one answer at a time.

— & —

There's another reason to get the process out of Sarah's head now that didn't exist five years ago. Once you can teach the job to a new employee, you can start teaching pieces of it to software.

The point is not to replace the manager with AI. It's that you cannot build a useful AI employee around a process that only exists in someone's head. The documentation is what makes the automation possible, not the other way around.

Here's the progression, using a job that manager probably owned: chasing unpaid invoices.

Pick one narrow job. Not "run my office." Something specific and repetitive: check that completed jobs got invoiced, follow up on missing paperwork, prepare the morning report.

Write the SOP like you're training a new hire. What starts the job? What information does the person need, and which systems do they check? What decisions can they make on their own, and what weird case gets escalated to a human? If you can't explain the process, you aren't ready to automate it. That's the tell.

Give the software the same access a person would have. Read-only into the job system, the accounting tool, email, whatever the human uses. It works from the real source, not a guess.

Give it boundaries, not just instructions. What it can do alone, what needs your approval, when it has to stop and ask. A useful AI employee knows when it doesn't know.

Make its work visible. A Slack message, a draft, an exception list. Don't let real work vanish into an invisible automation you can't check.

Start it as an assistant. For the first few weeks it prepares the work and a human approves it. Once it proves reliable on the low-risk steps, you pull those approvals back one at a time.

Picture the owner who replied to me running that. Instead of discovering weeks after his manager left that invoices had quietly stopped going out, a documented process has software checking completed jobs each afternoon, comparing them against invoices, flagging what's missing, and drafting the follow-up. It hands a short exception list to whoever's covering the desk, a human takes the strange cases, and the routine stops depending on somebody remembering to do it.

The SOP is what makes the AI possible. AI doesn't remove the need for documentation. It makes good documentation far more valuable than it used to be.

The companies that get the most out of AI won't be the ones with the most AI tools. They'll be the ones that actually know how their own business works.

— & —

Run the five-question audit this week. If it makes you uncomfortable, that's the signal.

And if you already have a name in your head, the person whose exit would send you scrambling on Monday, that's exactly the conversation I want to have.

This is the work I do. I get the operating system out of one person's head and into the company, before you're forced to do it the hard way.

Reply "orchestrate" and tell me who your Sarah is and I'll tell you where I'd start.

— & —

No man is crushed by misfortune unless he has first been deceived by prosperity.

- Seneca