Documenting how your team works

What it is good at

• Good at turning a spoken or messy explanation into a clean numbered process document.
• Can generate the follow-up questions that surface steps people forget to mention because they're automatic to them.
• Fast at producing a consistent document template across many different processes.
• Useful for spotting gaps, steps that only make sense if you already know the context.

Where it falls short

• It can only document what the person actually explains, it can't infer an unstated step.
• Documents need a real test run by someone unfamiliar with the process to catch remaining gaps.
• It doesn't know your specific tools' exact current interface unless described or shown to it.

How to use it for creative work

1. 01

   Have the model interview the expert

   Ask the model to interview the person who does the task, one question at a time, starting with 'walk me through this from the very first thing you do'. Structured questioning surfaces steps people skip when writing unprompted.

2. 02

   Push for the automatic steps

   Ask specific follow-ups like 'what do you check before you do that' and 'what would go wrong if you skipped this', these catch the steps experienced people do without thinking, which are usually the ones a new starter needs most.

3. 03

   Turn the transcript into a numbered document

   Once the interview is done, ask for a clean, numbered step-by-step document with a clear title, purpose statement, and any tools or access needed listed at the top.

4. 04

   Add the 'what could go wrong' section

   Ask for a short troubleshooting section listing common mistakes a new person makes and how to fix them, since this is what turns a basic process doc into one that actually reduces questions.

5. 05

   Test it on someone unfamiliar

   Have someone who's never done the task follow the document exactly and note anywhere they got stuck or had to guess, feed those gaps back into the model for a final revision.

Ready-to-use prompts

I'm going to describe a process I do at work: [name of process]. Interview me about it one question at a time, starting with 'walk me through this from the very first thing you do', and ask natural follow-ups until you fully understand it.

Based on what I've described so far: [paste], ask me specifically what I check before each major step and what would go wrong if that step were skipped. These are often the parts I forget to mention.

Here's the full interview transcript: [paste]. Turn it into a clean numbered process document with: a title, a one-line purpose, any tools or access needed, then the numbered steps.

Based on this process: [paste document], add a short troubleshooting section listing three or four common mistakes a new person might make at each risky step, and how to fix or avoid them.

Someone unfamiliar with this process followed this document: [paste] and got stuck at these points: [paste notes]. Revise the document to fill those specific gaps.

Questions people ask

Who should be interviewed for this to work well?

The person who actually does the task day to day, not their manager, the manager often misses the small practical steps the doer takes for granted.

How detailed should the final document be?

Detailed enough that someone new could follow it without asking a question at every step, but not so long it becomes unreadable, the test-run step is what calibrates this correctly.

How often do these documents need updating?

Whenever the underlying tool or process changes meaningfully; a quick quarterly check against reality is a reasonable habit for processes that change often.