Writing Down A Process When You Are The Only One Who Knows It

You are the only person who knows how the monthly close works, or how a client gets set up, or what to do when the export fails. Everyone agrees it should be written down. It has been on your list for a year.

The method that works when you have no time is this: do the job once while recording your screen, then write down only the decisions, not the clicks. Recording costs you nothing because you were doing the work anyway. Decisions are the short part, and they are the part that is actually hard to reconstruct. The clicks are visible in the recording and change every time the software updates.

Why the usual approach fails

The standard idea of documentation is a step by step guide. Open this, click that, enter the reference in this field.

Two things go wrong. It takes hours to write, because you have to slow down and describe every action. And it goes stale in weeks, because interfaces move. Six months later somebody follows it, hits a button that no longer exists, and gives up.

Meanwhile the thing they really needed was never in there: what to do when the number does not match, and how you decide which of two options applies.

Step one: record yourself doing it

Next time the task comes round, turn on screen recording and talk while you work. Do not prepare. Do not redo it if you fumble.

Talk about what you are thinking, not what you are clicking. "I am checking this against last month because it is usually out by a rounding difference and if it is more than that something is wrong." That sentence is worth more than a page of instructions.

If something goes wrong during the recording, that is a bonus, not a problem. Watching somebody recover from an error is the most useful footage there is.

Save the recording somewhere findable and name it properly.

Step two: write only the decisions

Now spend twenty minutes writing. Not a guide. A decision list.

For each point in the process where you had to choose, use a heading and three lines:

• The situation. When does this come up.
• The options. What could you do.
• How you choose. The rule you use, including the fuzzy bits. "If it is a long standing client I usually just fix it and mention it. If it is new, I ask first."

A typical process has somewhere between four and ten of these. That is a page or two, and it is the part that is genuinely in your head and nowhere else. It is also the material a good handover note is built from.

Step three: name what breaks and who to call

Add two short sections at the end.

Known failure points: the things that go wrong more than once a year, what they look like, and what you do. Be specific about symptoms. "The totals page shows zero" is more findable than "the report fails".

Who to call: the person for each kind of problem. Include how they prefer to be contacted, and anything about timing. A name and a quirk beats a support address.

Step four: let somebody else run it while you watch

The test is not whether the document reads well. It is whether another person can do the job with it.

Pick someone, give them the recording and the decision list, and have them run the process while you sit nearby saying nothing unless they are truly stuck. The same supervised run is how you hand a finished project to a client's own team. Write down every point where they hesitate. Those are your gaps, and you will find three or four.

Fix those and stop. Do not polish further. The document is now better than ninety percent of what exists in most companies, and it took you a recording, twenty minutes and one supervised run.

Where to keep it

Keep the decision list with the work, not in a separate documentation site that nobody opens. If the process runs off a recurring task, attach it there. If it belongs to a role, attach it to the role.

Tools where project work and people records sit together make this easier, because a process can hang off the role rather than the person. SicherOne is built that way, so when someone changes job the attached knowledge moves with the responsibility instead of leaving with the individual.

Do one this month

Pick the process where your absence would hurt most, which is usually the one carrying the highest cost of one person holding the knowledge, and record it the next time you run it. One process, one recording, one page of decisions. Then leave it alone until somebody needs it.