Process capture

Applies to work the firm repeats and has never written down. Produces the process document, plus a list of the judgment calls that could not be articulated yet.

The play

1. Collect several finished examples of what this process produces before interviewing anyone. The standard is visible in the outputs and describable only vaguely in conversation. Three real examples teach more than an hour of the senior person explaining their method.

2. Get the sequence by walking through the last real instance, start to finish, rather than asking how the process works in general. Asked in general, people describe the version in the handbook. Asked about last Tuesday, they describe the version that happens.

3. Note the steps people skip when busy, and sort them: the skips that are fine, and the skips that cause the problems. This distinction is most of the value, and it never appears in a process written top-down.

4. Split the mechanical steps from the decisions. Mechanical steps get instructions and can be handed over tomorrow. Decisions get criteria, and they are the reason the work cannot be delegated yet.

5. For each decision, get the criteria out. If the senior person cannot state the rule, have them talk through two past instances where they chose differently, and derive it from the contrast. "It depends" is the start of the answer, not the end of it.

6. Write the quality bar as things a reviewer actually checks, pulled from the examples. Not that it should be good, but the five specific things looked at before it goes to a client.

7. Mark which steps genuinely need the senior person and which do not. This is the line the owner is really buying: it tells them what they could hand off this week.

8. Note what the process needs from upstream and hands off downstream, so it connects to the rest of how the firm runs instead of sitting in isolation.

9. Surface any contradiction between what the person described and what the examples show. That gap is where the written process and the real one have drifted, and it is usually the most useful finding in the document.

What good looks like

• First thing I check that most people skip: the finished outputs, before I talk to anybody. People describe the process they believe they follow. The artifacts show the one they actually followed, and the gap between those two is the whole job.
• The mediocre version: a numbered list of the happy path, with every real decision collapsed into "review and approve". It documents the parts nobody needed written down.
• I know it is right when somebody who has never done the work produces something the reviewer does not have to rebuild.
• Second test: every decision has criteria underneath it. "It depends" is where the knowledge is, not where the document stops.
• Red flag: the written process and the examples disagree and nobody had noticed. The real process has drifted, and writing up the old one just makes the wrong version official.

Rules

• MUST work from several real examples of the output, not only a description.
• MUST derive the sequence from the last real instance, not from how it is supposed to go.
• MUST separate mechanical steps from decisions, and give every decision its criteria.
• MUST write the quality bar as items a reviewer can check.
• MUST mark which steps require the senior person.
• MUST surface contradictions between the description and the examples.
• NEVER leave a decision as "use your judgment". That is the thing being captured.
• NEVER write a generic version of the process. With nothing firm-specific to work from, produce the interview questions instead.