What to Do Before You Hire: Write the SOP Before the Job Post

Last December, a company brought me on to systemize their operations. On the very first call, with two of their team leads on the screen, I laid out what I'd be doing in the first few weeks: documenting four or five core SOPs, then looking at their project management tools, then getting a feel for how the team actually worked day to day.

A month later, with a different client, I did it again. The first three weeks of a new engagement went to writing down their delivery process, before I asked a single person to change how they tracked a job. And when a salesperson approached that same client wanting to come on board, my advice was the same idea turned around: before you say yes, ask them for a written plan. Their sales process, their call strategy, how they'd report to you. On paper, before anyone starts.

Most owners, when they're drowning, do the opposite. They hire first and figure out the process with the new person in the room. I want to talk about why that's so expensive, and what to do before you hire instead.

Hiring is the right instinct and the wrong first move

Don't get me wrong, hiring IS what you should do when you're feeling overwhelmed, when you need that help to come in and take your time back. But a lot of the time, people don't really have a clear understanding of all the things they're about to hand off. They feel something's broken (onboarding is inconsistent, delivery is slow, the team keeps doing the same thing wrong) and the instinct is to fix it. Rewrite the SOP. Add a step. Hire someone.

What they haven't done is look at the process. Actually looked at it, start to finish, the way a stranger would.

In 1975, a computer scientist named Fred Brooks, who had managed IBM's OS/360 project a decade earlier, wrote down an observation that became known as Brooks's Law: "Adding manpower to a late software project makes it later." His reasoning in The Mythical Man-Month had very little to do with software. Every new person has to learn the work before they can do it, and every new person adds to the amount of talking the team has to do to stay coordinated. If the work only lives in one person's head, the one person doing the teaching is you. So the hire that was supposed to give you your time back spends its first stretch taking it.

The new person is not the problem here. What they got was a Loom and a verbal walkthrough of whatever you remembered to say that day, and a recording of one person doing the thing once can't tell anyone what the standard is, who's accountable, or what to do when it breaks. You've added a person to a process that was never written down, and now you're teaching it out loud, over and over, and calling that onboarding.

Gallup, by the way, found that only 12% of employees strongly agree their organization does a great job of onboarding new hires. Only 12%! I don't think the other 88% just missed a welcome email. I think most of them walked into a job where nothing was written down to hand over.

Checklists, cockpits, and a hospital in Michigan

Two stories from outside the service business world, because the pattern is so much easier to see from a distance.

On October 30, 1935, at Wright Field in Ohio, Boeing flew its new Model 299 (the plane that became the B-17) for the Army Air Corps. The men at the controls were the Air Corps' chief of flight testing and Boeing's own chief test pilot. These were people who tested aircraft for a living. The plane climbed, stalled and crashed, because nobody had released the gust locks on the tail surfaces. Both pilots died, one at the scene and one of his injuries weeks later. The 299 needed something like thirty steps to prepare for takeoff, and the conclusion afterward was NOT "find better pilots." It was a checklist, and the Air Corps and the airlines adopted it.

Seventy years later, a critical care doctor named Peter Pronovost tried the same idea in intensive care units across Michigan: a written, five-item checklist for putting in a central line. Wash your hands, clean the skin, use full sterile barriers, avoid the femoral site, pull the line as soon as it isn't needed. Nothing on that list was new. Within three months, the median infection rate across 105 ICUs went from 2.7 per 1,000 catheter-days to zero! And 18 months later it was still down by as much as 66%.

Look at what happened in both cases. The people in that cockpit and the people in those ICUs already had the expertise, and what was missing was the standard, written down where the whole team could see it and act on it. That's the thing I keep trying to get owners to notice about their own businesses: your standards are fine. Your systems are missing.

You're not the bottleneck because you're controlling

A LOT of the founders I work with have been told (or have told themselves) that they're control freaks. They tried to "let go" once, it went badly, a client was unhappy or a deliverable stalled, and they concluded that they can't delegate because their standards are too high.

I don't buy it. The founder who is the routing bottleneck in her business isn't a micromanager. She's the only available infrastructure in a business that hasn't documented its decisions yet. Every time the team asks her a question, it's because the answer lives in her and nowhere else. That's a documentation gap, and a documentation gap has a structural fix, which is a very different thing to work on than your personality.

Michael Gerber built an entire book on this, The E-Myth Revisited. His story is Ray Kroc, a milkshake machine salesman, walking into the McDonald brothers' restaurant in San Bernardino and watching teenagers turn out identical hamburgers, over and over, under a system the brothers had designed. Kroc's insight was that the business itself was the product. Gerber's argument is that most of us start businesses because we're good at the work (he calls that person the Technician), and then we keep doing the work instead of building the thing that lets the work happen without us. Take McDonald's own quality layers and hold them against your business as a gap map: ingredient specs, calibrated equipment, timing systems, station SOPs, a QA step before anything reaches the client. You find out very fast where the standard lives in someone's head instead of in the infrastructure.

What to do before you hire, in order

1. The Owner Swap. For every recurring task in your business, write down two names: who owns it now, and who ideally should. Not who you wish owned it. Who actually should, given the business you're running today. It's disarmingly simple! And it produces your real build list, which is almost never the same as your job description. If your name is in both columns for twenty tasks, you're not about to hire one person, you're about to hand twenty undocumented tasks to a stranger.

2. The audit. Mystery shop your own business, not as the founder, as a client. Follow one deliverable from brief to delivery and count how many times a decision gets made from memory instead of from a documented procedure. Count how many times someone improvises instead of referencing a standard. That number is your quality gap, and it's an infrastructure gap, not a team gap (they're improvising because nothing was written). Every improvised decision is a place where the standard hasn't been written yet, and that's your list of what to document first.

3. Write the SOP for the one process you're handing off. By hand. Before you post the job. Find it with the six boxes every business runs on (Attract, Inquire, Purchase, Onboard, Deliver, Repeat) and the three questions I use in what to automate first: which step pulls you out of flow the most, which one is repeatable and rule-based, and which one would lift the whole business if someone else owned it. Then write the full document: purpose, workflow diagram, the step by step with the tools and links, the RACI (Responsible, Accountable, Consulted, Informed), and the policy that keeps quality consistent. The full anatomy is in SOPs for small business. Writing it yourself is HOW you fully understand it. You find out what you actually know versus what you just remember. A recorder can supply the screenshots. It can't be the owner.

The human audit comes before the skills audit

Here's where I'll push back on the standard hiring advice a little. Most operators run a skills audit and call it onboarding. They tested the skills, checked the references, gave a structured trial, did everything "right," and three months in they're managing someone who feels unclear and high-maintenance and they can't work out why.

Skills can be trained. Energy, alignment and communication style are what decide whether a person integrates into your systems and your team at all, and those have to be understood BEFORE the workflow gets designed around them. Systems fail when they're designed for ideal behaviour instead of real behaviour. When a team member ignores your SOP, it's almost never laziness. The SOP was written for a generic person, not the specific human who has to follow it.

So the document you wrote in step 3 is version one. Version two gets written with the person you hire, in their first thirty days, once you know how they actually think and communicate. Le-An's session at Ops Ahoy on second brains and virtual assistance made the same point from the delegation side, and I wrote about it in Who Floats My Boat: the menu of ways to hand off a task has gotten long, and a longer menu makes the judgment call harder, not easier. It's a call you can only make well about work you understand, which is exactly what writing the SOP forces out of you.

What the hire looks like when the document exists

When the SOP exists and the process has a name next to it, "let me walk you through how I do this" turns into "here's the document, here's the RACI, here's who to call when it breaks." A new hire can follow it on day one. An AI agent trained on it can answer their procedural questions, so they're not pinging you between every task. They build fluency faster, and you stay in flow. In my masterclass I put a number on it: up to 100% less of your own time spent on that workflow, reliably, because the SOP is owned by someone who FULLY understands it.

And the RACI is what makes the ownership real. It tells the new person that they OWN this, not assist with it, not check in with you before every step. That ownership map is what I build across a whole business as a fractional COO, and it's the thing I'd want in place before the first job post goes up.

Run the vacation test before you write the job description

One last diagnostic, and you can run it in your head right now: if you disappeared for seven days, what would your business do? What would actually happen to the inbox, the deliverables, the decisions only you make? Seven days reveals what months of "everything's fine" conceals. The gut answer tells you whether your business runs on systems or on your presence, and it tells you whether the person you're about to hire is walking into a system or walking into you.

A fractional OBM comes in when the systems exist and need someone to run them well. A fractional COO comes in when the systems have to be built before anyone can be handed a thing. Both, with pricing, are in my free pricing guide.

Tell me in the comments: when you ran the Owner Swap, how many tasks had your name in both columns? Be honest.