Documentation your team will read and trust

Background

Ask anyone in an organisation where the answer to a process question is, and you'll get one of four replies. "Ask Sam." "It's in a document somewhere." "There's probably a version on the shared drive." Or, "I think that changed."

That last one does the damage. The moment someone gets caught out by an out-of-date page, they stop trusting every page. People go back to asking Sam, and Sam stops getting anything else done.

Trust is the thing to protect. A small set of documents that are correct and current is worth more than a big library that's mostly right.

Setup

Habit 1: one home

Pick a single place for team documents, and say what it is. Links to it go in the welcome note and pinned in the team channel. If there are three places, two of them will be wrong.

Habit 2: every page has an owner and a date

At the top of each page:

• Owner: a named person, not a team
• Last checked: a date
• Next review: a date

If an owner leaves, their pages get reassigned as part of the leaving checklist. Otherwise they become orphans.

Habit 3: write for the person in a hurry

Most readers are in the middle of something else. So:

• Put the answer or the action in the first two lines.
• Use headings that are questions people really ask, like "How do I request a laptop?".
• Number the steps for things that happen in order, with one action per step.
• Use screenshots only where words won't do, and not for anything that changes monthly.
• Say what to do when it doesn't work, and who to ask.

Habit 4: write it when you've just done the job

The best time to document something is straight after you've done it. Keep a doc open as you work and paste in the steps as you take them. There's a method for this in an SOP from how the task is really done, and one for a team's own working rules in a one-page "how we work".

Habit 5: delete things

Retire pages that nobody owns. Mark them "archived" with a date, or remove them.

Let an AI tool do the first draft

Below are my rough notes on how we do [TASK]. Turn them into a short
how-to page with: a one-line summary, who it's for, numbered steps (one
action each), what to do if it goes wrong, and who to ask.
If the notes mention a common mistake, put it at the top in bold.
If a step is unclear or missing, list it at the end as "Questions".
Don't invent steps.

Notes: [PASTE]

Then follow the steps yourself, or get a colleague to. That test finds the gaps every time.