Most of what discounts a business comes with someone assigned to fix it. Messy financials get a CPA. Legal exposure gets an attorney. A tax problem gets a tax advisor.
Owner dependency is different, and the operational kind most of all – the knowledge of how the work actually gets done, living in the heads of the owner and a few senior people. It rarely gets a person. It gets a line in the report. It reads something like document your key processes. Most have written that sentence into a plan. Fewer have seen it finished.
My version of the problem
Before QuicklyDoc, I ran a business that shipped lab testing supplies. Packing an order looked like the simplest job in the building. It wasn’t.
What went in the box, and how, depended on the carrier, the destination, the temperature requirements, the medium, and the service being performed. Each of those changed the materials and the packing. Combine them and you had a decision tree with a lot of branches, and I was the only person who carried the whole tree around. Every new hire meant weeks of me standing next to them, answering “it depends” and then explaining what it depended on.
I did what every owner is told to do. I tried to write it down. The document I produced described the common order perfectly. It barely touched the branches. And the branches were the job.
Why the recommendation dies
I’ve since watched this happen in a lot of other businesses, and it fails for the same handful of reasons almost every time.
It’s a branching problem that looks like a time management gap. A written procedure at work is a straight line: step one, step two, step three. Real expertise is “it depends.” Ask an expert to write down what they do and they write the trunk of the tree – the common case – because that’s what comes to mind sitting at a desk. The exceptions only surface when an exception is standing in front of them.
The people who know the work aren’t writers, and the owner is the busiest person in the building. The recommendation lands on exactly the people with the least time and the least inclination to sit down and type. It goes to the bottom of the list, behind every customer and every fire, which is where it stays.
The rare branches don’t come up while anyone’s paying attention. Some decisions happen weekly. Some happen twice a year. Nobody remembers the twice-a-year branch on a Tuesday afternoon when they’ve finally blocked an hour to write procedures.
Nobody owns it. “Document your processes” sits on an action plan. It doesn’t sit on anyone’s job description. The advisor recommended it, the owner agreed with it, and no one was assigned to do it.
None of this is a failure of discipline. Owners who can’t finish a procedure manual have usually built businesses that are hard to describe in a straight line. That’s often why they’re worth something.
What actually works
Three things change the outcome.
Capture the work from the people doing it, ideally while it’s being done. Not from memory at a desk – on the job, on their own phones, talking through what they’re doing and why. Every real job walks one path through the decision tree. Capture enough real jobs and the tree fills itself in, branches included, because each branch eventually shows up as an actual order, an actual repair, an actual customer.
Have someone other than the owner run the program. Somebody has to keep the list of what matters, notice which branches haven’t been captured yet, chase the gaps, turn recordings into usable procedures, and get the expert to confirm they’re right. That’s a job. When it’s added to the owner’s existing job, it doesn’t happen.
Keep an honest list of what’s covered and what isn’t. Not a “we documented our processes” checkbox, but a real list. Here’s what we’ve captured so far, versus here’s what’s still in one person’s head. That list is more useful to an advisor than a binder, and it’s what a careful buyer is trying to reconstruct in diligence anyway.
Where this sits next to your work
I’ve been lucky to meet some very skilled advisory professionals, far better than I am at diagnosing owner dependency and deciding what to do about it. My interest is narrower: what happens after “document your key processes” goes into the plan, and the work lands back on the owner’s desk.
What’s been missing is someone whose actual job is the doing: getting the knowledge out of people’s heads and into something the business owns, then handing the advisor a finished line item instead of a recommendation still waiting on the owner.
That’s the work QuicklyDoc does, and it’s why I joined XPX’s Advisor Resource Center. Over the next few months I’ll be writing here about the practical side of it: how to spot the work that only one or two people know how to do, how to make it worth a senior person’s time to teach it, and what buyers are really asking when they ask who runs things.
I think about the packing bench at my old business more than I’d like to admit. Every branch of that decision tree is captured somewhere now, and not one of them got there because I finally sat down to write it. They got there one order at a time, while someone was doing the work.
That’s most of what I’ve learned about this problem. The knowledge was never going to come out at a desk. It comes out on the job, a branch at a time, if someone’s there to catch it.
Originally published in QuicklyDoc Field Notes.
Neil Wood is founder and CEO of QuicklyDoc and an XPX Advisor Resource Center member, based in the Twin Cities. If you have a client where “document your processes” has been on the plan longer than anyone would like, I’m glad to look at it with you. neil@quicklydoc.com
