Write the SOP Before You Need to Hire Someone to Follow It

There's a predictable moment when most real estate teams finally write down how something works: the week before a new hire starts.

Suddenly there's urgency. Someone sits down to document a process they've done so many times it's become instinct — and tries to reconstruct it from memory, under a deadline, for a task they no longer consciously think about. What comes out is usually incomplete. Steps get skipped because they felt too obvious to mention. Edge cases get left out because nobody thought of them until the new hire hit one.

That's the hardest possible way to write a standard operating procedure. And it's also the most common.

Why hiring pressure produces bad documentation

When you write an SOP because you're desperate for someone to be productive fast, you're solving two problems at once: capturing a process, and training a person — usually in the same week, usually while everything else is still moving. Neither gets done well under those conditions.

The new hire ends up learning from an incomplete document, filling in the gaps by interrupting whoever's already stretched thin. That person hired specifically to reduce the load spends their first few weeks adding to it instead, not because they're not capable, but because the documentation they were handed was built in a rush, for the first time, under pressure.

None of this is really about the hire. It's about when the SOP got written.

What "documenting as you go" actually looks like

The alternative isn't a big project. It's a habit: every time you do something you know you'll do again, take two minutes at the end and write down what you just did. Not a polished manual. Not something that needs formatting or approval. Just the bones — what you did, in what order, and anything you'd want someone else to know before they tried it themselves.

Do this consistently, even loosely, and something changes: by the time you actually need to hire, the documentation already exists. You're not building it and training someone on it simultaneously. You're handing over something real, built when there was no pressure attached to getting it right the first time.

This is the same principle behind a friction log, just pointed at a different moment. A friction log catches what's going wrong in real time so patterns don't repeat. Documenting as you go catches what's working in real time, so it doesn't live only in your head.

What actually changes when the SOP exists first

Picture two versions of the same hire.

In the first, a team lead is drowning, brings someone on out of necessity, and spends the first two weeks answering questions in between everything else they're already behind on. The new hire is cautious, unsure what they're allowed to decide on their own, and the team lead is too underwater to notice where the confusion actually is.

In the second, the documentation already exists — built a few minutes at a time, months before anyone needed it. The new hire gets a real document on day one. They can move at their own pace, make decisions with something to reference, and ask questions that are actually specific instead of "wait, what do I even do here." The team lead's job shifts from "explain everything from scratch" to "check in and course-correct," which takes a fraction of the time.

Same hire. Same role. Completely different experience for everyone involved — and the only variable that changed was when the documentation got written.

Where to start

Pick one task you did this week that you know you'll do again. Not the biggest, most complicated one — the most repeatable one. Spend two minutes writing down what you did, in order. That's the whole first step.

Do that consistently, even imperfectly, and you'll have a real head start by the time hiring stops being optional and starts being necessary. The goal isn't a complete operations manual. It's not needing to write one under pressure when it matters most.

If your team has a process that only works because it lives in someone's head, that's usually the first thing I look at when I start a project — and it's exactly the kind of gap that gets harder to close the longer you wait. I'd love to talk about what documenting as you go could look like for your team.