Turning 'ask Dave' into a runbook someone else can actually follow

Background

Every IT team has at least one process that lives entirely in someone's head - the monthly reconciliation that needs a specific spreadsheet opened in a specific order, the server restart that has to happen in a sequence nobody wrote down because the person who does it has done it forty times and doesn't think about it as steps any more. Asking that person to "write it up" produces a document missing exactly the parts that matter, because the parts that would surprise someone else are the same parts that feel too obvious to the expert to mention.

The fix isn't a better documentation template. It's treating the write-up as an interview transcript, not a first draft - get the expert talking through what they actually do, out loud, in whatever order it comes to them, and let the model do the work of noticing gaps and asking the follow-up questions a colleague would ask if they were shadowing.

Setup

The shape that gets tribal knowledge into a usable runbook:

• Role - an interviewer building a runbook for someone who's never done this task before.
• Context - a rough, spoken-style description of the process, not a tidy list.
• Inputs - the actual steps as the expert remembers them, including the "oh, and also" details.
• Task - structure it as a runbook and flag every place a newcomer would get stuck.
• Constraints - never fill a gap with an assumption; always ask.

Turning a rambling description into a first-draft runbook

You're turning a rough, spoken description of a process into a runbook a
colleague who's never done this could follow without help.

Context: I'll describe the process the way it actually happens in my head
- out of order, with asides, the way you'd explain it to someone standing
next to you. Structure it properly, and flag anything a first-timer would
get stuck on that I didn't mention.

Inputs:
- Process name and how often it runs: [NAME, FREQUENCY]
- What triggers it: [DESCRIBE]
- The steps, in whatever order you remember them, asides included:
  [DUMP IT ALL - DON'T TIDY IT FIRST]
- Tools/systems/logins involved: [LIST]
- What "done" looks like: [DESCRIBE]

Task: produce a numbered runbook - trigger, prerequisites, steps in the
correct order, what to check at each step to confirm it worked, and what
"done" looks like. Where my description skipped a step you'd expect
(a login, a wait, a confirmation check) - ask about it rather than
inventing it.

Constraints: every step must be something a specific tool/screen/command
does, not a vague instruction like "configure the settings". If a step is
genuinely vague in what I gave you, list it as an open question rather
than guessing at specifics.

The follow-up pass that catches the "oh, and also"

The first pass always misses something, because the expert remembers more detail once they see their own process written back to them as steps.

You're reviewing a first-draft runbook with the person who actually does
this process, looking specifically for the exceptions they didn't mention
the first time.

Context: here's the draft runbook. Ask me about the situations it doesn't
cover - what happens when a step fails, what happens on a day this
process doesn't apply, what the expert does automatically that isn't in
the steps.

Inputs:
- Draft runbook: [PASTE]
- Anything you already know doesn't always go to plan: [LIST IF YOU HAVE
  IT, OR LEAVE BLANK AND LET IT ASK]

Task: for each step, ask what happens if it fails or produces something
unexpected, and whether there's a special case (month-end, a particular
client, a particular error) the standard steps don't cover. Fold my
answers into an "If this doesn't go to plan" section under the relevant
step, not as one long appendix at the end.

Constraints: don't ask about failure modes for steps that are genuinely
trivial (opening a known URL) - focus the questions on steps that
actually branch or that the expert flagged as fiddly.

Testing the runbook on someone who's never done it

A runbook that reads clearly to the person who wrote it hasn't actually been tested. The real test is handing it to someone else and watching where they stop.

You're role-playing a competent colleague who has never done this specific
process before, following this runbook exactly as written, nothing assumed.

Context: I'll paste the runbook. Walk through it literally, step by step,
and stop at the first point where you genuinely wouldn't know what to do
next from the words on the page alone.

Inputs:
- Runbook: [PASTE]

Task: walk through it step by step. At each step, say what you'd actually
do based only on what's written. Stop and flag the exact wording that
would leave a first-timer stuck, rather than filling the gap with common
sense the document doesn't actually supply.

Constraints: don't be generous to the document - if a step assumes
knowledge it doesn't provide (which login, which environment, what
"normal" looks like on a screen), flag it even if you could reasonably
guess right.