Write the SOP before you hire

A company reaches the point where the work exceeds the people, and the response is to add people. It is the obvious move and often the correct one. But there is a failure mode that shows up reliably about a quarter after the new hires start, and it looks like this: output went up less than headcount did, quality became inconsistent in ways nobody can pin down, and the senior people who were supposed to be freed up are now spending their days answering questions.

What happened is that the process was never written down. It lived in the working memory of two or three people who had been doing it long enough to have stopped noticing the judgment calls they make. Hiring did not scale that process. It created three new interpretations of it.

Undocumented process is a single point of failure with a salary

Every organization has at least one person who is the only one who knows how something works. Everyone knows who it is. It is treated as a quirk of the org chart rather than what it actually is: a critical dependency with no redundancy, no documentation, and the ability to resign.

The cost is not only the risk. It is that this person cannot be promoted without breaking the thing they hold, cannot take real time off, and cannot delegate, because delegating requires explaining, and explaining takes longer than doing. So they keep doing it, and the dependency deepens, and everyone continues to describe this as them being “indispensable” as though it were a compliment rather than an operational finding.

What a usable SOP actually is

Most SOP efforts fail because the documents produced are either too abstract to execute or too granular to maintain. A flowchart that says “Review submission” is not a procedure. A forty-page document describing every keystroke will be obsolete before it is approved and nobody will read it twice.

A usable SOP answers a specific set of questions:

• Trigger — what starts this process, and how does the person know it started?
• Owner — who is accountable for the outcome, by role rather than by name?
• Steps — what happens in sequence, at a level of detail a competent new hire could follow?
• Decisions — where does judgment enter, what are the criteria, and who has the authority to make the call?
• Exceptions — what are the known edge cases, and what happens when one appears?
• Done — what does completion look like, and how is it recorded?
• Escalation — who gets called when the procedure does not cover the situation?

The decisions and exceptions sections are where the real knowledge sits, and they are the two that get skipped. Steps are easy to write and nearly worthless on their own — anyone can be shown the steps by watching. What separates the experienced operator from the new one is knowing which cases are not normal and what to do about them. That is the content worth capturing.

Write it with the person who does the work

SOPs written by management about work they do not perform are consistently wrong in the same direction: they describe the process as designed rather than as executed. The gap between those two is where all the useful information lives.

The method that works is interview-based. Sit with the person doing the work and have them walk through it while you write. Then — and this is the part that catches things — hand the draft to someone who does not do this job and ask them to execute from it. Every question they ask is a defect in the document. Fix it and repeat once.

This takes hours, not weeks, per process. The reason it does not happen is not cost. It is that it never becomes anyone’s priority until something breaks.

Start with three

Do not attempt to document everything. Documentation efforts that begin comprehensively end abandoned, with a half-finished folder nobody trusts.

Pick three processes against these criteria: it is done frequently, errors in it are expensive, and exactly one person knows how. That intersection is where the risk concentrates and where the return on two days of work is highest. Finish those three completely — drafted, tested by a non-expert, corrected, and stored where people actually look — before starting a fourth.

Then hire

With the core processes written, hiring changes character. The job description can be built from a real procedure rather than a wish list. Onboarding has something to hand the new person on day one. The senior staff member is answering exceptions instead of narrating the basics for the fifth time. And you find out, before you have committed to a salary, whether the gap was genuinely capacity — or whether it was a process problem that would have consumed the new hire the way it was consuming everyone else.

Documentation is not bureaucracy. It is the difference between a business and a group of people who know things.

There is a secondary benefit worth naming. The organizations that get asked for documentation — by an acquirer in diligence, a funder in a grant review, an insurer, or a contracting officer — are rarely given notice. Having current written procedures is the difference between a two-week scramble and forwarding a folder. That moment arrives on someone else’s schedule, which is a good argument for not waiting for it.