How to Write a Delegation Brief That Actually Works

Why a verbal handover usually isn't enough

A quick conversation feels efficient, and for very small, low-stakes tasks it often is. But for anything that will take more than an hour or two, or that recurs regularly, a verbal-only handover creates a specific problem: neither person has anything to refer back to when a question comes up midway through, so both sides end up relying on memory of a conversation that happened days earlier, and memories of the same conversation reliably diverge.

A written brief solves this without needing to be long or formal. It's simply a record of what was agreed, which both people can check against when something feels uncertain, and which prevents the founder from unconsciously moving the goalposts once the work is under way — a genuine risk, since founders often keep refining their own idea of 'good' after the brief was given, without realising the person doing the work is still working to the original version.

The five parts of a working brief

A brief that reliably prevents work bouncing back covers five things, in a fairly fixed order: the outcome, the constraints, the authority, the deadline, and the review point. Missing any one of these tends to produce a specific, predictable failure — missing the outcome produces work that technically got done but missed the point; missing authority produces constant check-ins; missing the review point produces either anxious founder check-ins or work that quietly slips.

1. Outcome: the result, stated as an end state, in the language you'd use to check it — not a list of steps
2. Constraints: budget, brand or tone rules, legal or safety boundaries that must not be crossed regardless of judgement
3. Authority: what they can decide alone, what they can decide and report, what needs sign-off first
4. Deadline: a specific date and time, not 'soon' or 'this week sometime'
5. Review point: the exact date, time and format of when you'll next look at the work together

If a brief is missing the review point, it isn't finished. Without it, either you'll interrupt anxiously before it's ready, or nobody will look at it until the deadline has already passed.

A worked example

Take a recurring task: managing the company's supplier orders. A weak, verbal-only handover might sound like 'can you take over ordering stock from now on, just keep an eye on levels'. It sounds reasonable, but it answers none of the five questions properly, and the person will either over-order out of caution or under-order and cause a stock-out, then get blamed for a standard nobody actually defined.

A working written brief for the same task might read: 'Outcome — we never run out of our top 10 SKUs, and stock value doesn't exceed £4,000 at any point. Constraints — only order from our three approved suppliers listed below; don't commit to any new supplier without checking with me. Authority — you can place any order under £500 without checking with me; above that, message me first and I'll usually confirm within a few hours. Deadline — this becomes your responsibility from Monday. Review — we'll go through stock levels together every Friday at 10am for the first month, then move to fortnightly.' Every one of the five questions is answered in under a hundred words, and both people now have something to point back to if a disagreement comes up.

Keeping briefs short

A brief that runs to several pages defeats its own purpose, because nobody re-reads a long document under time pressure, which means it stops functioning as the reference point it's meant to be. Aim for something that can be read fully in under two minutes. If a task genuinely needs more detail than that to describe, it's usually a sign the task should be broken into a standard operating procedure for the mechanical parts, with a short brief covering only the judgement calls layered on top.

Resist the temptation to pad a brief with context, background or justification for why the task matters. That's a useful thing to say out loud when you hand the brief over, but it doesn't need to live in the document itself — keep the written brief to the five operational elements and save the 'why' for the conversation.

Reusing briefs for recurring tasks

For any task that repeats — weekly reporting, supplier ordering, customer email handling, social media posting — write the brief once as a template and reuse it, updating only the specific numbers or dates each time. This saves you from re-deriving the same five answers from scratch every time you hand the task to someone new, and it means your standard for the task becomes more consistent over time rather than shifting slightly with each handover.

Keep a simple folder or shared document of brief templates for your recurring tasks. When someone new joins or takes over a task, you're handing over a tested document rather than trying to remember everything you've learned about the task since you last delegated it.

Updating the brief after the first review

The first version of a brief is rarely perfect, and that's fine — treat it as a working draft that gets refined at the first review point based on what actually came up. If the person hit a decision the brief didn't cover, add it to the authority section. If the outcome definition turned out to be ambiguous in practice, sharpen the wording. Feed these updates back into the template so the next person who's handed the same task starts from a better version than the last person did.

This turns delegation briefs into a genuinely improving asset over time, rather than a document written once and forgotten. Founders who keep their briefs current find that later handovers of the same task go noticeably more smoothly than the first ones did, simply because the brief has absorbed several rounds of real-world edge cases.