I've been chewing on that phrase for a few weeks. It started as a way to describe what happens when an owner systematizes a piece of the business that used to live only in someone's head, theirs or a key employee's. But the more deals I sit on the buyer's side of, the more I think it's the cleanest description of what transferability actually is.
The first payment is obvious. You do the work of documenting, standardizing, and installing a process, and the company starts paying you back immediately. Things go faster. Errors drop. The 6am firefighting gets rarer. If you replace a manual function with a system, labor gets cheaper or the labor gets redirected to work that actually needs a human.
Most owners stop counting there. They treat the second payment, the one that arrives at the transaction, as a bonus. It isn't. It's the bigger one. And it's the one most owners never collect.
What a buyer is actually buying
When a buyer prices your company, they are not pricing your revenue. Revenue with the owner welded to it is worth less than the same revenue that runs without you. Every buyer knows how to find the difference.
They look for the functions that only exist because a specific person shows up. The estimator who quotes from memory. The operations manager whose routing decisions live in his head. The owner who is the only one who knows which customers are solid and which are one bad quarter from gone.
From the buyer's chair, every one of those is a liability with a name attached. The discount doesn't come from the risk that the person leaves. The person leaving is often part of the deal. The discount comes from the risk that the knowledge leaves with them, and nobody in the building can reconstruct it.
A process that's written down, that someone else can run, that survives the person who built it, converts that liability into an asset. That conversion is the second payment. It shows up in the multiple.
The digital employee changes the math
Here's what's new in the last couple of years, and why I think the gap between owners who get this and owners who don't is about to get wider.
Software can now carry a function the way a good employee does: by following rules. Not just a checklist pinned to a wall, but the real rules, including the exceptions and the quality checks, written down and enforced every time. The term I use is digital employee. It runs the function every day, at scale, without getting sick or quitting or hoarding the knowledge. From the outside it can look like judgment. It's discipline, written down so completely that it performs.
Here's what it's actually worth.
The first payment is the operating one. A function that took twenty hours a week of a key person's time now takes two hours of review. That key person goes back to work only they can do. Errors stop repeating because the system catches them the same way every time. The business runs lighter, and it runs the same on the day you're at the beach as it does on the day you're at your desk.
The second payment is the one at the table. A function that lives in a system, with its decisions documented and its exceptions handled, is a function a buyer can diligence. They can see how it works. They can test it. They can imagine owning it. A function that lives in one person's head cannot be diligenced, and buyers price what they cannot see as risk, and risk as a discount.
The work pays you twice: once in the operation, once in the multiple.
The trap worth naming
There's a version of this that fails, and it fails quietly, so it's worth naming.
Building the system can become a new dependency. If you install a digital employee and you are the only person who understands its instructions, its integrations, and its failure modes, you haven't removed a key-person risk. You've built a new one, except now it's you, and it's harder to replace than the estimator ever was.
The test is the same one I apply to any system: can another capable person take it over, understand its decisions, handle its exceptions, and keep it running without calling the person who built it? If the answer is no, the second payment never arrives. You did the work once and got paid once, in efficiency, while quietly doubling your own importance to the company.
Documentation isn't the boring part of the project. It is the part that gets you paid at the end.
Where to start
Not with the most important function, and not with the hardest one. Start with an easy one that people will notice.
The first system you install is a proof, not a project. It has to work, and the people around it have to see it work. So pick a function that's contained, repeated often, and currently handled by one person whose method lives mostly in memory. Customer follow-up after a service call. The weekly inventory order. The first-pass quote on routine jobs. Something where the rules are knowable and the stakes of a mistake are small.
Write down how it actually works, not how the manual says it works. Include the exceptions, because the exceptions are where the knowledge hides. Then decide what part of it a system can carry and what part still needs a person.
Run it for ninety days. Measure whether the interruptions actually dropped. When the team trusts it, you'll know, because they'll stop working around it.
Then, and only then, take on a bigger function. By the second or third one, you're no longer proving anything. You're compounding. And the loudest, most tangled function in the company, the one you were tempted to start with, turns out to be easier because every documented process around it taught the business how this works.
Steve Duke spent about 30 years learning both sides of this problem. In his corporate career, he worked for Fortune 100 aerospace companies, including GE Aerospace, Lockheed Martin, and General Dynamics. At one of these companies, he ran a multimillion-dollar business unit with full P&L responsibility. He then left to run his own company and discovered that decades of training don't protect you from becoming the business yourself. A serious health event ended it. He exited, recovered, and built Lucensys™ Group around one idea: every owner exits eventually, and the only question that matters is whether they built something that can fund what comes next.
He wrote Failure to Exit about why most owners arrive unprepared.
His next book carries an old warning for owners: the best time to plant the tree was 20 years ago. The second best time is now.
Lucensys™ Group works with owner-operated manufacturers, distributors, and industrial-services companies doing $2M–$50M, reducing owner dependence and the risk discounts that cost owners at the table. Charlotte, NC · steve@lucensys.io · (704) 953-5608