Get It Out of Your Head

You wrote it down. They still ask you.

It’s in the shared drive, in a folder called Processes. Twenty-two steps, written on a Sunday when you were fed up. Someone opened it once, back in May. And they still message you at 4pm asking which supplier to use for the rush job, and you still answer in about eleven seconds, because you just know.

I think that gap is the whole problem. The document holds the steps. You hold the judgement. Only one of those got written down, and it’s the one that mattered least.

Nobody messages you about the steps

A process document that only lists steps is a bit like a recipe written for someone who already knows how to cook.

The steps are the stable, boring part. Open the file, fill in the fields, send it on Thursday. Anyone can follow that. The judgement is where the real work sits: which client gets a phone call instead of an email, when to push a deadline back rather than deliver something average, which invoice you chase on day three and which one you leave until day ten because chasing early would cost you the relationship.

Here’s a test worth trying. Next time you explain a job out loud, count how many times you say “it depends”. Every one of those is a rule you’ve never written down. A standard operating procedure (SOP) without any “it depends” in it is either covering something trivial, or it’s missing its more valuable half.

You’ve stopped noticing what you do

This is something teachers run into all the time. You explain a concept clearly, you know you explained it clearly, and a third of the room still can’t do it. Not because they weren’t listening, but because you skipped steps that stopped feeling like steps to you a long time ago.

Education researchers call this the expert blind spot. Once a skill becomes automatic, it slips below the level you can easily describe. The knowledge is still there and still correct, it just isn’t in words anymore. That’s why “write down how you do it” so often produces a thin, confident, slightly wrong document. You end up interviewing your memory of the job instead of the job itself.

So rather than asking yourself what the steps are, I’d catch yourself in the act of doing it.

Capture it out loud, while your hands are on the work

There are six moves. Do them in order, on one real piece of work.

1. Narrate a live one, recorded. Pick a job that’s in front of you this week. Open the voice memo app on your phone, put it face down, and talk the whole way through while you work. Include the muttering: “This one’s odd because they changed the brief in the email and not in the brief doc, so I’m going with the email.” Twenty minutes of messy narration will beat two hours of tidy writing. Don’t clean it up as you go. The mess is the useful bit.

2. Chase every “it depends”. Read the transcript and mark each one. Then answer the question it’s dodging: depends on what, and where’s the line? “Depends how urgent it is” isn’t a rule yet. “If they need it within 48 hours I ring them, otherwise it goes into the Thursday batch” is a rule. In a job you’ve done hundreds of times, you might find eight to fifteen of these. Keep the list. Turned into questions, it’s also the raw material for a lead magnet people actually finish.

3. Collect the mistakes you’d spot. Write down three mistakes you’d notice instantly in someone else’s version. These are non-examples, and they teach faster than good examples do. It’s the same reason a teacher might show a class something that’s nearly right and ask what’s wrong with it, rather than showing five perfect versions.

4. Write success criteria, not adjectives. What does “good” look like, in terms someone could tick off without you in the room?

What people write	What can be checked
Professional tone	Every question in their email answered. Client name spelled as it appears in the CRM. No more than one exclamation mark.
Thorough research	At least three sources, one of them from the last 12 months, each linked in the doc.
Sent promptly	Out the door before 4pm on the day the brief lands, or a holding note sent by 4pm.

5. Build one worked example, with notes. Take the real job you narrated and attach the finished version to the document. Then add comments in the margin explaining why, not what: “Dropped the third option here because they said in the call they hate long lists.” People tend to pick up a new process faster from one annotated example than from a page of correct instructions. It’s also the step people skip, because it can feel like showing off.

6. Hand it over in three passes. First, they watch you do one. Then you watch them do one, and say nothing until the end. Then they do one on their own, and you only check the result against the success criteria. Teachers call this gradual release: the responsibility moves from you to them in stages, and no stage gets skipped. A lot of handovers do the first pass, skip the second completely, and then treat the third going badly as a hiring problem. The Course Nobody Finishes uses the same three passes to get people through a course, and Why Your Team Won’t Use It uses them to roll out a new tool.

The prompt that turns your rambling into a usable document

Record the narration, transcribe it with whatever you already use, and then paste this in:

You are helping me turn a recorded narration of a real task into a working
process document for someone who has never done this job.

Below is a raw, unedited transcript of me talking through the task while
doing it. It is messy. Keep the mess useful.

Produce four sections, in this order:

1. THE STEPS: numbered, in the order they actually happened. Plain
   imperative sentences. No preamble.

2. THE JUDGEMENT RULES: every point where I made a decision rather than
   followed a step. Write each as "If [condition], then [action], because
   [reason]." Include the reason even if you have to infer it, and mark
   inferred reasons with [CHECK].

3. THE GAPS: every place I said "it depends", "usually", "normally",
   "most of the time", "you just know", or trailed off. List each as a
   direct question back to me. Do not answer these yourself.

4. THE MISSING BITS: steps a complete beginner would need that I never
   said out loud because they are automatic for me. Flag each [ASSUMED].

Rules: use my words and my terminology, not generic business language.
Do not invent thresholds, prices, names or timeframes. If a number is
missing, put [NUMBER?] and move on. Be specific over polished.

TRANSCRIPT:
[paste here]

Section 3 is where I’d spend your afternoon. That list of questions is the part of the job that has only ever existed inside your head. Answer them in writing, paste your answers back in, and ask for the document again.

When not to bother

If the task happens less than once a quarter and takes under ten minutes, skip all of this. Write a four-line checklist and move on.

Skip it if the process is about to change. Documenting something two weeks before you replace the system gives you a very accurate record of something nobody will ever do again.

Skip it if you’re the only person who’ll ever do this job, and you’re not selling, hiring, or planning a holiday where you’re uncontactable. Documentation is for handover, so no handover, no document.

And hold off if the process itself is bad. Writing it down makes a bad process official, with your name on it. It’s the same reason you fix a process before you automate it.

What you’ve got now

A way to get the judgement out of your head, not just the steps. A prompt that does the structuring while you do the thinking. And a way to tell whether a handover has actually landed: the result matches the criteria, and nobody had to ask you.

Try it on one job this week. I’d pick the one you get interrupted about the most.