Define responsibility before listing tasks
Start by writing why the role exists and what should be ensured when it is performed well. Identify who receives the work, the boundaries of responsibility and how to recognise a complete delivery. Then organise the tasks that allow someone to reach that outcome consistently in everyday work.
Consider a hypothetical example involving client support. Answering messages, preparing meetings and updating information are tasks. Ensuring that the client understands progress, receives answers and knows the next step describes more clearly the responsibility another person will be taking on.
That distinction makes documentation useful when a new situation arises. If the document only says to send a message on Friday, someone could follow the schedule while leaving an urgent question unanswered. Understanding the objective helps them recognise when the routine needs to be adjusted.
Define what falls outside the role as well. Someone supporting a client may collect a change request without having authority to offer additional work free of charge. When considering growth, margins and the team, this distinction prevents delegation from creating commitments that nobody has assessed.
To prepare your next step, explore Delegation and processes for small teams.
Make your automatic decisions visible
A role contains choices that an experienced person already makes without explaining them. Record recurring decisions, the information used and the criteria for choosing. The document should help somebody else reason through similar situations, including recognising when they should stop and ask someone with greater authority to decide.
Observe an actual work cycle and note when you change priorities, request information or refuse to proceed. Recording your screen while clicking is insufficient. Explain why you chose that order and what would make you act differently when presented with the same information.
In the client support example, you might distinguish an ordinary question from a request that changes the contracted scope. The first can be handled by the person responsible; the second needs commercial or operational assessment. Write down the boundary and identify the decision maker instead of simply referring to vague “important cases”.
Apply the same clarity to deadlines and missing responses. If an essential input is absent, the document should explain whom to ask, where to record the outstanding item and when to communicate the impact. Otherwise, the person owns an outcome without knowing how to unblock the work.
Show examples and explain why they work
Examples turn abstract criteria into observable references. Include an acceptable delivery, a situation that needed correction and an explanation of the differences. Choose materials suitable for the people who will consult the document, removing unnecessary data while preserving the context needed to understand why a particular decision was made.
A message can be short yet still leave the client unsure what happens next. A report can look organised while omitting the decision that needs approval. Show these differences through examples prepared for training instead of expecting the person to discover the standard through trial and error.
You do not need dozens of cases before delegating. Start with examples representing the most frequent work and the exceptions with the greatest consequences. A small, annotated set can be more useful than an enormous folder in which nobody knows which version is valid.
When using a hypothetical case, label it as such within the material. The person should distinguish a training reference from commercial terms agreed with a real client. This also prevents illustrative figures or invented conditions from being copied into an actual client delivery.
Provide authority and the means to do the work
Delegation requires access to the information, tools and decisions needed to fulfil the role. Document what the person can decide independently, what needs validation and who provides each approval. Responsibility without the means to act preserves dependence on the person who is supposedly handing that responsibility to somebody else.
Prepare access according to the role and confirm that it works before expecting independence. Identify document locations, internal contacts and ways to consult relevant history. Do not put passwords in a shared manual; describe the authorised process for obtaining the access the person needs.
Specify who provides cover during an absence and who resolves questions when the usual responsible person is unavailable. A name in a document may be insufficient if the entire operation stops during a meeting. The handover should address continuity of work as well as an ordinary working day.
Defining who approves what in collaborative work helps organise these boundaries. Although contexts differ, the question remains concrete: which decision is actually delegated and which remains reserved? The team needs the same answer to avoid receiving contradictory instructions from different people involved in the work.
Test the handover with real work and clear limits
Validate documentation by asking the person to complete a work cycle with support proportionate to the consequences of an error. Observe where clarification is needed and update the document to address those gaps. The handover is working when the person can explain their decisions and fulfil the agreed responsibility.
Start with a representative task that can be reviewed before producing effects that are difficult to correct. Ask the person to explain their understanding, identify missing inputs and anticipate difficulties. This conversation exposes ambiguities that a silent reading can leave hidden from both of you.
Avoid immediately answering every question by doing the work yourself. Where the risk allows, help the person find the information and apply the criteria. The objective is to build decision-making ability while preserving the points at which review remains necessary.
If the same questions recur, investigate the cause before concluding that competence is missing. An example may be absent, a rule may be outdated or two people may be giving different instructions. Documentation makes those failures discussable by allowing work to be compared with a shared reference.
Keep the document aligned with the role
Documentation needs an owner, a known location and a review whenever the work changes. Add decisions learned through execution and remove instructions that no longer apply, preserving necessary history. Its usefulness is measured by its ability to guide actual work, rather than by the eventual length of the manual.
An initial document can bring together the objective, routine, decisions, examples, exceptions and contacts in a simple structure. Link additional material where needed instead of copying everything into several places. This reduces the chance of an update leaving contradictory versions scattered across the team.
Use the inventory of tasks, data and responsibilities to uncover dependencies even if the role remains entirely human. Mapping work does not require automating it. It may reveal that the most useful next step is to clarify an approval or improve the information received.
I would validate the handover with one final question: if I am unavailable, does the person know what to ensure, how far their authority extends and whom to approach? If the answer depends on guessing my intention, part of the role still needs documenting. That part deserves the next review.