Write down how it was done, once

The most expensive thing in a small company is a process that only works when one particular person runs it. Not because they are irreplaceable, but because the process was never written down, and reconstructing it from memory takes longer than doing it did.

The moment to capture it is immediately after it has been done, which is exactly when nobody wants to.

Get the process done once, properly

This playbook starts after something has already happened: a month-end close, a client onboarding, a report you assembled by hand for the first time.

That run is the material. What you are about to do is stop it being a one-off.

Ask it to write down what it just did

Write down the process you just ran, as instructions for someone who has
never done it.

Cover: what has to be true before you start, the steps in order, what each
step produces, and where you had to make a judgement call rather than
follow a rule.

Be specific about the judgement calls. Say what you decided and why, so
the next person can decide differently on purpose rather than by accident.

Do not tidy it into something cleaner than it was. If a step only worked
because of something odd, say so.

"Do not tidy it" is the instruction people leave out and then regret. A written-up process is always neater than the real one, and the parts that get smoothed away are precisely the awkward conditionals where the next person will get stuck. An honest, ugly procedure is worth three tidy ones.

Save it as a skill, not a document

A document is something people have to find. A skill is something every employee already has.

Save that as a skill so any employee can run this process. Name it for the
job it does, not for the department that owns it.

Once it is a skill, running the process is a sentence rather than a set of instructions you paste in, and it is the same process every time regardless of which employee does it.

Improve it where it breaks, not where it annoys you

The second and third runs will surface a step that was underspecified. Edit the skill then, while you can still remember what went wrong.

Resist rewriting it for elegance. The measure of a good procedure is that someone unfamiliar can follow it, not that it reads well.

What good looks like

A process that used to live in one person's head runs the same way when they are on holiday.

The honest test is to have someone else trigger it, without asking any questions, and see where they stop. Wherever they stop is the step you smoothed over.

Also covers

Turning tribal knowledge into a skill. Above, the source is a process an employee just ran. The other source is a person who knows something and has never written it down, and the approach is different: you interview rather than transcribe.

I want to capture how Priya scopes a retainer, which she has never written
down.

Ask me the questions you would need answered to run it yourself. One at a
time, and follow up when my answer is vague.

Do not write the procedure until you have enough to actually do it.

The one-at-a-time instruction is what makes it work. A list of fifteen questions gets answered in a paragraph that skips the interesting ones; a conversation gets to "what do you do when the client will not give you a budget", which is the knowledge you were trying to capture.

When it is done, save it the same way:

Save that as a skill, named for the job it does.

The reason to prefer a skill over a document is that a document is something people have to find and read. A skill is something every employee already has, which means the knowledge gets used by whoever happens to be doing the work rather than by whoever remembered it was written down.