Documenting a process so you can delegate it, without turning it into a project

Ask anyone why they do not delegate the task that eats their day and the answer is usually the same: «I would have to explain everything to them». They are right. The process exists, it works and it produces results, but it lives entirely in their head: forty small decisions nobody ever wrote down, because to the person making them they look obvious.

That is where most delegation gets stuck. Not on budget, not on finding the person: on the fact that nobody has the process written down, and writing it down looks like a project of its own.

Why writing it down looks like a project

Because when someone sits down to document, what they picture is a manual. A long, tidy document with an introduction and a scope, which has to be finished before it is any use. That document never gets written, and it is right not to: by the time it was ready, half of it would be out of date.

What is needed is the opposite. A short, ugly, incomplete document that is useful from its first paragraph. Its purpose is not to describe your operation: it is to let another person do one specific thing without asking you. That is how it is judged, and by nothing else.

You document while working, not before working

The only moment when documenting is cheap is while you are doing the task. You have the case in front of you, you remember why you decide what you decide, and the exceptions show up on their own.

In practice: the next time you do that task, open a document beside it and write down what you are doing in loose sentences. Do not organise it. Do not write it well. Two or three passes over different cases and you have the process, with its real exceptions instead of the ones you would have imagined in a meeting room.

This has a practical consequence: the new person is the best documenter. Someone who has done a thing for four years no longer sees the steps; someone four days in trips over all of them. Asking a newcomer to document what they have just learned — and correcting it yourself — produces a better document in two weeks than any manual written from above.

Start with what repeats

Do not document what is important: document what is frequent. The task that shows up five times a day in the same shape pays for itself in two days. The exceptional case that happens once a quarter does not, and besides, it is better explained by talking.

An order that works: take last week, look at where your time went and sort by number of times, not by importance. The top three on that list are the ones to document. Everything else can wait, and a good deal of it will never be needed.

In an online shop, for instance, that list almost always starts with the same things: what you reply to an order that has not arrived, when a return is accepted outside the window, and what you do when the carrier stops answering. They are all part of running an ecommerce operation and none of them is hard — what happens is that nobody has written them down, which is why only one person can answer them.

Write the decision, not just the step

This is where nearly every document that does exist falls down. They describe the sequence of clicks — go here, filter by this, tick this box — and say nothing about the criteria. And the criteria are the part that cannot be inferred.

Side by side:

• Step: «If the order is more than seven days late, open a claim with the carrier».
• Decision: «If the order is more than seven days late, open a claim with the carrier. If the customer has already written twice, refund the shipping as well without waiting for the carrier's answer: we would rather lose the cost of shipping than lose the customer».

The second one can be applied to a case that is not on the list. The first cannot. And that difference is exactly what separates a person who works on their own from a person who asks twenty questions a day.

The short rule: for every step where somebody could hesitate, one sentence starting with «because».

Canned replies are documentation

What you already have written counts, and it is usually more than you think. The canned replies in the helpdesk, the emails you forward always the same, the report template, the note you passed a colleague a year ago. All of that is documented process, just scattered.

Gathering it takes half an hour and has a useful side effect: read together, the contradictions show. Two canned replies saying different things about the same case mean the criteria were never settled, and that until now it was resolved by the instinct of whoever happened to answer. That cannot be delegated. It has to be decided first.

Where the document lives and who keeps it current

Two questions without which everything above spoils within three months.

Where. In the place where the work happens, not in a documentation folder. If the work happens in the helpdesk, the criteria go in the canned replies and the internal notes on the ticket. If it happens in the CRM, they go in the field itself and in the view that gets used every day. A document you have to go and look for is a document nobody reads.

Who. Whoever does the task, not whoever designed it. The person executing the process is the one who finds the missing case, and if they are allowed to add it, the document stays alive. If they have to ask permission, the document dies. One rule is enough: whoever runs into a new case writes it down the same day and marks it as pending validation.

Keeping the criteria written, cross-checked and current is in fact a role of its own once volume grows: it is what a data and process documentation role does, and it is usually the best value in the building, because what gets lost in a small company is almost never the data — it is the reason behind a decision nobody wrote down.

Why a half-finished onboarding sinks a remote hire

Someone new working remotely does not have the corridor. They do not hear how you answer the phone, they do not see the face you make when a case smells wrong, and they cannot turn around to ask something small. Everything that is learned by osmosis in an office is learned by reading or by asking when you are remote.

If nothing is written down, only asking is left. And asking costs twice over: it interrupts the person who delegated — which was the point of delegating — and it creates a feeling that the new person «is not autonomous», when what has happened is that nobody gave them the means to be. That is where most remote hires break: not in the selection, in the start.

That is why the list of what has to be in place before day 1 is short, and it is a condition rather than a recommendation: accesses created and tested, the incident policy written down even if it is one page, the canned replies you already use, and a single point of contact to ask. It is set out week by week in how a team works.

What to do this week

Pick one task: the one you do most often and like least. The next time you do it, write down what you do and why, roughly, while you do it. Keep that text where the work happens, not in a separate folder.

The time after that, hand it to someone else with the document in front of them and explain nothing out loud. Everything they ask is a hole in the document: note it and fill it. Two or three rounds and that task is no longer yours.

Delegating does not start with a hire. It starts with a one-page document that does not exist yet.