How to Get the Processes Out of Your Head

Ask most founder-operators where their business actually runs and they'll tap the side of their head. The pricing logic, the way you handle the angry customer, the order the trucks get loaded, the thing you check before you sign off on a job. It's all up there. And it feels like control.

It's the opposite. A process that only lives in your head is a job, not a business. Steve Distante, who built Vanderbilt Financial Group, says it flat out: "If you can't take a six-month vacation, you don't have a business, you have a job." You can't sell what only you can run. You can't scale it, hand it to your kid, or take a week off without your phone lighting up. The single act that changes this is getting the processes out of your head and onto paper, as SOPs that people actually use.

Here's how to do it without disappearing into a documentation project that never ends.

Why "it's all in my head" is a liability, not a skill

The stuff in your head is exactly what a buyer, a successor, or a burned-out version of you six months from now needs, and can't reach. Ben puts it to the founders he coaches as a blunt question: "Is everything you just articulated actually written out? It should be written out." Excellence that lives in one person is fragile. Excellence embedded in a system is an asset.

That's not just a tidiness argument, it's a valuation argument. Ben uses a sourdough-starter image with his clients: the thing that adds zeros to what a business is worth isn't the daily workflow, it's the structure underneath it, how the work gets done, taught, and repeated without the owner. Two businesses with the same revenue sell for wildly different numbers, and the documented one wins, because the buyer is purchasing something that keeps running after you leave.

Document the process before you hire for it

Most owners try to fix a broken process by throwing a person at it. You hire someone, hand them the mess that lives in your head, and hope they sort it out. Ben's take on that is unprintable, but the clean version is this: hiring into an undocumented process is just guessing what sticks. You'll churn through people and blame them for a problem you never actually defined.

The order matters. Write down how the thing is supposed to go first, then hire someone to run it. The SOP is what turns a new hire from a six-month gamble into a two-week ramp. It's also how you find out your process was never that good to begin with, which is worth knowing before you pay someone to inherit it.

Start with the process that makes the money

You don't document everything. That's the trap that kills these projects: you try to write a manual for the whole company, it balloons, and you quit by week two.

Instead, Ben has founders run a quick revenue breakdown: what handful of activities drive the majority of the money? Start there. The sales handoff, the quote, the thing that has to be right or you lose the customer. Document the one process whose failure costs you the most, get it out of your head cleanly, and only then move to the next one. One high-value process on paper beats fifty half-written ones nobody reads.

The fast way to get it out of your head: get interviewed, don't write

Here's the part that unsticks everyone. The reason your processes are still in your head is that "sit down and write your SOPs" is a miserable task, so you never do it. The blank page wins.

So don't write. Talk. The method Ben uses with founders is to hand them a short list of questions and interview them one at a time: "Here are ten questions. I want you to interview me, one question at a time." You're not composing a document, you're just answering questions out loud about how you do the thing. Someone else (or a recorder, or an AI transcription tool) captures it, and the SOP gets assembled from your answers. It removes the writing entirely and turns documentation into a conversation.

Jeremy Bergeron, who talked his way into a chief-of-staff role for a serial founder, did a live version of this. His opening move: "I want you to give me 30 days. I don't want you to pay me anything. Just add me to all of your meetings because I have no clue, I want to audit everything you're up to." That's process extraction. Shadow the person who holds it in their head, ask what they're doing and why, and write down what you see. The expert doesn't have to author anything. They just have to be watched and questioned.

Write each step as something you could watch someone do

A useless SOP says "handle the intake properly." A useful one says exactly what "properly" looks like, step by step, concrete enough that a stranger could follow it.

Mike Williams, former CEO of the David Allen Company (the Getting Things Done people) and author of Doing to Done, has a test for this that's perfect for SOP writing. He asks: "If this is the only thing in your world to work on right now, and I said 'action,' and I watched you, the hero, do the thing, what would I see you do?" That's the standard for every step. Not the intention, the observable action. If you couldn't film it, it's not a step yet.

Williams also reframes why this is worth the effort: "Clarity is kind. If we get clear with ourselves, we can get clear with those around us." A vague process isn't you keeping standards high. It's you leaving your team to guess, then being disappointed when they guess wrong. Writing the steps down plainly is an act of care, not bureaucracy.

The real test: does anyone actually use it?

Most SOPs die in a drawer. Somebody documents a process, saves it to a folder nobody opens, and six months later everything's back in the owner's head. A written SOP that no one follows didn't get the process out of your head, it just made a copy.

Two moves make an SOP stick. First, test it cold: hand it to someone who's never done the task and have them run it without your help. Wherever they get confused or come ask you a question, that's a hole in the SOP, not a failure of the person. Fix the document, not the human. When someone new can follow it and get your result, it's real.

Second, make using it someone's job, with a number attached. Ben ties system adoption directly to a person's scoreboard: their responsibility isn't just to do the work, it's to keep the process current and get the team actually using it, measured (he'll set a target like a 90% usage rate). A system nobody owns is a system nobody maintains. Give it an owner and a number, and it stays alive instead of rotting in a folder.

What this is actually for

Getting your processes out of your head isn't an organizational hobby. It's the thing that converts a business that needs you into a business that owns itself. It's what lets you take the six-month vacation, hand the company to a successor who can actually run it, or sell to a buyer who's paying for a machine instead of a bottleneck.

You built the knowledge. Right now it's trapped in the one place nobody can access it or pay for it. Get it onto paper, in steps someone can follow, owned by someone who keeps it used, and you've turned the thing in your head into an asset you can hand to anyone.