What Should You Document First Before Delegating Recurring Work?

Document the recurring work that creates the most risk when the person who knows it is unavailable.

That usually means work that happens often, affects customers or money, can be taught, and currently depends on somebody remembering what comes next. Handoffs are especially good places to start because they expose hidden knowledge. A lead becomes a customer. A sale becomes an onboarding task. A finished draft becomes an approval. A customer request becomes work for another team member. When information regularly gets lost at one of those transitions, documentation has an immediate job to do.

The first process to document should therefore be chosen by consequence, not by convenience.

A simple task that everybody already understands may be easy to write down, but documenting it first may change very little. A recurring handoff that creates rework, late delivery, customer confusion, or repeated founder intervention is usually more useful.

Use four questions to choose the first process

Before writing an SOP, rank recurring work against four questions.

Does it repeat? A one-off decision may deserve a note, but repeatable work gives documentation more chances to create value.

Does failure matter? Missing a formatting preference is different from missing a customer handoff, payment step, compliance requirement, or delivery deadline.

Can another capable person learn it? Some work depends heavily on judgment. It can still be documented, but the record may need decision rules and examples rather than a rigid sequence.

Is the process trapped in one person's memory? If work pauses whenever one person is unavailable, the dependency is visible.

Juliana Marulanda's Genius Talk discussion of project management is useful here. She connects workflow visibility with time, billing, profitability, capacity, and future hiring. Her wider point is that a growing business needs to see how work moves, not merely know that people are busy.

That makes a troubled handoff a strong documentation candidate. It sits where ownership, information, timing, and capacity meet.

A practical first-pass priority looks like this:

• high repetition plus high consequence: document first;
• low repetition plus high consequence: capture decision rules and escalation points;
• high repetition plus low consequence: standardize after the higher-risk work;
• low repetition plus low consequence: leave it alone unless confusion keeps recurring.

This is a prioritization tool, not a universal scoring system. The useful question is where missing knowledge currently costs the business the most.

Start where work changes hands

Growing companies often discover their operating gaps between roles rather than inside them.

A salesperson may know what was promised, while the delivery team receives only the contract. A project manager may understand a deadline, while the specialist doing the work does not know which dependency must clear first. A customer-success person may know a client is frustrated, while the person approving the fix sees an ordinary task.

David Carroll's Genius Talk discussion of onboarding illustrates the scaling problem. He describes how an onboarding approach that works at lower volume can become unreliable as customer volume increases, especially when different customers need different levels of support.

The lesson is broader than onboarding. A process can appear healthy while a knowledgeable person is manually compensating for its gaps. Volume reveals whether the handoff itself works.

So, before documenting an isolated task, look for repeated moments such as:

• sale to onboarding;
• onboarding to active delivery;
• project stage to project stage;
• specialist to reviewer;
• customer request to internal owner;
• completed work to billing;
• recurring issue to escalation.

Ask where people routinely chase context, redo work, wait for approval, or ask the same question again.

That is often the first process worth capturing.

A minimum useful process record has seven parts

The first version should be small enough to use.

A useful process record can usually begin with seven fields.

1. Trigger. What event starts the process?

The trigger might be a signed agreement, an approved brief, a customer request, a status change, or a scheduled date. Without a trigger, people may understand the steps but still disagree about when ownership begins.

2. Owner. Who is responsible for moving the process to completion?

Several people may contribute. One role should still be accountable for noticing that the process has started and that it reaches its done condition.

3. Inputs. What information, materials, permissions, or prior decisions must exist before work begins?

This is where hidden knowledge often appears. If the delegate has to message the founder for context every time, the process is not yet transferable.

4. Essential steps. What sequence matters?

Capture the steps that protect quality, timing, or decision quality. Avoid documenting every mouse click unless the exact action is important.

5. Handoffs. When does responsibility move, to whom, and with what information?

This is the part many process notes omit. A task list can explain one person's work while leaving the transition between people ambiguous.

6. Exceptions. What common situations require a different route or escalation?

Judgment-heavy work becomes more transferable when the record explains where the standard path stops being safe.

7. Done condition. What observable result means the process is complete?

"Onboarding finished" is vague. "Customer has supplied required inputs, access is confirmed, owner and next milestone are recorded, and the first delivery date is acknowledged" is easier to verify.

Those seven fields create a working record without turning the exercise into a company-wide documentation project.

Document decisions as well as steps

Vance Morris argues in his Genius Talk conversation that documented operations can create owner freedom. His emphasis is useful because founder dependence rarely comes from the absence of checklists alone.

It often comes from undocumented judgment.

A team member may know the mechanical steps but still need the founder to answer questions such as:

• Which customer request gets priority?
• When can scope be adjusted without approval?
• Which quality issue requires rework?
• What can be decided inside the role?
• When should a problem be escalated?
• Which customer promise cannot be changed?

A process becomes more delegable when it records the decision boundary around the work.

This does not mean turning judgment into hundreds of rules. Start with the exceptions that repeatedly bring work back to the same person.

If the delegate can complete the standard path but every unusual case returns to the founder, document the recurring unusual cases next.

Test the record with a real handoff

The person who created a process is a poor judge of whether the process is self-explanatory.

They can fill missing steps from memory without noticing.

The better test is to give the record to a capable person who did not create it and observe where they hesitate. Ask them to complete the next real instance, or a low-risk practice version, while recording:

• what was unclear;
• what information was missing;
• where ownership was ambiguous;
• which decision still required verbal explanation;
• which step seemed unnecessary;
• what "done" meant in practice.

Then revise the record.

This is where documentation becomes an operating tool rather than an archive.

Rahul Alim's broader systems perspective provides a useful guardrail. In the Genius Talk material, he argues that tools are useful when they support real work. The same principle applies to documentation. A polished process library that nobody uses is weaker than a short record that survives a handoff.

Do not confuse documentation with delegation

Documentation can make delegation safer, but it does not perform the delegation.

The receiving person still needs enough skill, context, authority, and capacity to own the work. The manager still needs to make expectations clear. Some processes need coaching before they can be handed over. Some need redesign because the existing sequence is inefficient. Some should remain with a specialist because the risk or judgment requirement is too high.

The goal of the document is narrower: make the work understandable enough that another capable person can execute the normal path and recognize when the normal path no longer applies.

That is why a giant SOP library is a poor first objective.

Start with one process where transfer matters now.

A quick documentation priority check

Use this sequence when choosing what to capture first:

1. List recurring work that currently depends on one person.
2. Mark the processes where failure affects customers, cash, deadlines, quality, or major rework.
3. Highlight the places where work changes hands.
4. Choose a process that another capable person could realistically own.
5. Capture its trigger, owner, inputs, steps, handoffs, exceptions, and done condition.
6. Let another person run it.
7. Revise what the test exposes.

If several processes qualify, choose the one that creates the most repeated operational friction.

Start by removing the most expensive knowledge dependency, then let each real handoff show what needs to be captured next.