How to delegate tasks: the handover that sticks — brief, owner, deadline, and a record both sides can read (2026)

To delegate a task is to hand someone an outcome and the room to reach it: what done looks like, by when, within which limits, and how you will hear about progress. "Mateusz — the client proposal for Aster, signed-off draft to me by Thursday, within the standard terms, tell me Tuesday if the price is in doubt" is a delegated task. "Can you take a look at the Aster proposal?" is a wish, and the person who received it will do the wrong thing on time or the right thing late.

Most leads of a team between ten and two hundred people delegate less than they intend to, for one arithmetical reason: the first handover of a task costs more than doing the task. The brief takes twenty minutes to write, the questions take another twenty, and the result comes back different from what you would have done. The arithmetic turns around the second time the same kind of task comes up — if the first handover was written down, so the second one is a link instead of a conversation. That is why this guide spends as much time on the record of the handover as on the handover itself.

The craft first: what delegation is and what it isn't, what to delegate and what to keep, the six steps of a handover that sticks, with a brief template and a RACI chart you can copy. Then the mechanics: where the handover lives in the tools your team already uses, and how the task comes back — done or not — without anyone chasing it.

What delegation is — and what it isn't

Three things get called delegating, and only the middle one is:

Instruction is not wrong — a new hire's first week is mostly instructions — but it does not scale, because every step still passes through you. Abdication feels like trust and is usually the lead being too busy to write the brief; the owner discovers the limits by crossing one. Delegation is the middle: the outcome is fixed, the path is theirs, and both sides know when and how they will talk about it.

A delegated task is also not the same as an action item. An action item is one line born in a meeting — a verb, one owner, one date — and the meeting that produced it reviews it. A delegated task is usually bigger: it has a brief, it takes days or weeks, and it produces several action items along the way. The two meet in the recap: the delegated task is what the owner reports on, and the action items are the lines they report.

What to delegate — and what to keep

The question is not "what can I get off my plate" but "what will come back better, or at least as good, from someone else, now or after the second time". Four tests:

1. Someone else can do it 80% as well today. The missing 20% is what the brief and the check-in are for. If nobody on the team is at 80%, the task is a development task: delegate it with a closer check-in, and count the first round as training.
2. It repeats. A task that comes up monthly is worth a twenty-minute brief, because the brief is written once and reused twelve times. A task that comes up once and takes an hour is often cheaper to do than to hand over — unless somebody needs to learn it.
3. It has a definition of done you can write in one paragraph. If you cannot say what done looks like, you cannot delegate it yet; you can delegate the first step — "find out what done would look like and tell me by Friday" — which is a real task with a real day.
4. You are not the only person allowed to decide it. Some decisions are yours by role: hiring, pay, performance conversations, anything your own manager will ask you about by name, anything that commits the organization past a limit you were given. Those are kept. The preparation for them is delegated all the time.

What stays with you, as a rule: the decisions above, the conversations only you can have, and the one piece of work that is the reason you have the role. Everything else is a candidate, and the list of candidates is usually longer than a lead expects.

How to delegate a task: six steps

1. Write the brief before you speak. One paragraph: the outcome, why it matters, the deadline, the limits, and who else is involved. Writing it is the test from the previous section — if the paragraph will not come, the task is not ready to leave you. Writing it also means the handover exists in a form the owner can reread, which is the whole difference between a task that was delegated and a task that was mentioned.

2. Pick one owner, and get a yes out loud. One name, not a team, not two names. The owner is the person who will be asked about the task next week, so it has to be the person who agreed to it this week. Offer the task; let them say yes, say no, or say "yes if the deadline moves to Friday". A task someone was told about is not delegated. A task someone said yes to is.

3. Say what done looks like, and let them say it back. The owner repeats the outcome in their own words: "a signed-off draft of the Aster proposal, standard terms, to you by Thursday". This thirty-second read-back catches most of what goes wrong later, because the two of you usually mean slightly different things by "draft", "signed-off" and "Thursday".

4. Name the authority: what they may decide without you. Four levels cover almost every task. Tell me before you act. Decide and tell me. Decide; tell me only if it goes outside the limits. Decide, and I don't need to hear. Say which one applies, and name the limits — a price, a date, a list of people who must be consulted. An owner who does not know their level will come back to you for everything, or for nothing; both look like a delegation that failed, and both are a brief that left a line out.

5. Agree the check-in before the work starts, not when you get nervous. A date, a form and a length: "a three-line message in the channel on Tuesday — on track, not on track and why, decisions you need from me". The check-in is set now because setting it later is micromanagement, and the same check-in set in the brief is support. It also gives the owner a natural moment to ask for help without it looking like failure.

6. Put the handover where both sides will read it later. The brief, the yes, the authority level and the check-in date go into the place where the team already keeps its work — the channel, the tracker, the project's thread — not into a direct message that only the two of you can see and only one of you will find. When the task comes back, the result goes next to the brief, so the next person who takes the same kind of task starts from the record and not from a conversation. A handover made in a WhatsApp group is a record only as long as the group is; what Export chat does and does not produce is a text file of one conversation, and the option is not available everywhere.

Then one more thing, after the task lands: say what came back, in the same place, to the same people. "Mateusz's draft came in Wednesday, we changed two lines, it went to Aster Thursday." The owner hears that the work was seen; the team hears what a finished handover looks like; the record has its last line.

A delegation brief template

Task: [one line — the outcome, as a noun: "a signed-off proposal", "a shortlist of three suppliers"]
Owner: [name] · Delegated by: [name] · Agreed on: [date]
Why it matters: [one sentence — what it unblocks or who is waiting for it]
Done means: [two or three lines the owner can check off — what exists, in whose hands, in what shape]
Deadline: [day] · Check-in: [day, form — "three lines in the channel"]
You may decide: [the authority level, and the limits — a price, a date, a scope]
Ask before: [the one or two things that need a word from the delegating side first]
People to involve: [name — what for]
Starting points: [links — the last time this was done, the template, the client's file]

Result (filled in when the task comes back): [what landed, where, on which date — and the one thing to do differently next time]

The block is plain text: it pastes into a chat message, a canvas, a tracker ticket or an email without reformatting. The last line is the one most templates leave out, and it is the line that makes the second handover cheaper than the first.

A RACI chart template — when more than one person touches the task

A brief has one owner. When the task crosses several people — the proposal needs legal's redline, finance's price and the account lead's sign-off — the one-owner rule still holds, and a RACI chart is how you write it down so that nobody assumes someone else is doing it. Four letters per row:

• R — Responsible: does the work. One or more people.
• A — Accountable: owns the outcome and signs it off. Exactly one per row; this is the owner from the brief.
• C — Consulted: gives input before the work is done. Two-way.
• I — Informed: hears the result. One-way.

Three rules keep the chart honest. One A per row — two accountable people means none. Every row has at least one R — a task with an A and no R is a wish. And no column full of C and I — a person consulted on everything and responsible for nothing is in the chart because of their title, not their work, and will slow every row down. Build the chart in the first meeting of a task that spans people, read it aloud once, and put it next to the brief.

Three handovers, before and after

Notice what the right-hand column has: a name, an outcome as a noun, a day, an authority level, and a check-in. The left-hand column has a verb and a hope. The difference between them is about four sentences, written once.

Where the handover lives in the tools you already use

A handover needs a place where the brief, the yes and the result can be read later by both sides — and by the person who takes the same task next quarter. Each major platform has a place for a task born in a meeting, and each stops at a different point. Documented behaviour only, from the vendors' own pages; each cell names the month its fact was checked, and the pages are in the Sources footer:

Two things are the same everywhere. The handover is a document next to the meeting, written in the one language the room used; and whether the task came back is a question the document does not answer — a person opens it and asks. Where the delegating lead and the owner do not share a working language, the handover call itself is a separate question with documented answers: what Microsoft Teams does with a live meeting in two languages, and where it stops, and the same for Google Meet.

How the task comes back in the recap

InterMIND is a communication space where a team's meetings live in a channel, so the handover has one home: the channel's chat, where the brief is posted, the owner's "yes" is a reply under it, and the Tuesday check-in is three lines in the same thread. The whole of it stays in each member's language — the lead in Milan writes the brief in Italian, the owner in Bucharest reads it in Romanian and answers in Romanian, and each side has the original one toggle away. A brief drafted somewhere else, or a client's request that arrives as an email, lands in the channel by email: the channel's host gives it an address of its own, and a message sent there appears as a regular message, attributed to the sender, attachments kept, translated for each reader like any other.

If the handover happens in the channel's meeting, the brief goes on everyone's screen next to the video tiles with Share to conference: the sharer edits it live while the room watches — the deadline moves, the authority line is added — and every participant reads it in their own language. When the call ends, the recap is written from the meeting itself: a summary and the tasks that were taken on, each with its owner, each line keeping its timestamp. It arrives by email to each signed-in member, as a message in the channel and as a link in the calendar event, and every member reads it in their own language rather than the one the room happened to use. Any member can edit it; every edit keeps author and revision history. The channel keeps the recap of every past session, so the brief of three weeks ago and the result that came back are one search away. An ad-hoc meeting by link keeps only its latest recap and its chat is wiped when the call ends; a team's handovers belong in a channel.

In an organization with team status pages on, the task is also followed up. Every task a recap records joins the organization's task chain, and when the next recap of the channel's meeting is written, the open ones are judged against what was said: a task someone reported finished is marked done, a task discussed but not finished is marked not done with the reason in the words of the meeting, and a task nobody brought up stays open. The verdicts live on the organization's status page, each with its quote and the recap it rests on, and a member's own verdict beats the model's. At the start of the next session Mia names the open tasks and their owners, so the check-in happens even when nobody remembered to ask. Team status pages are a preview feature: an organization's admin switches them on under Settings → Advanced after accepting the alpha terms (the Preview features page describes each one).

Where the task has to end up in a system of record — the deal in the CRM, the ticket in the tracker — the host adds a recap copy to any address, and every recap of that meeting or channel is also sent there after a one-time confirmation of the address, on every plan, up to ten saved addresses; the mechanics are in a copy of every meeting recap in your CRM, by email.

A channel is members-only. A contractor, an agency or a client who owns a task in the team's record is added by email invitation onto a free account and reads the channel in their language from then on; channel participants outside your team are not billed. Someone who needs one meeting only — a supplier taking one brief, a candidate — joins an ad-hoc meeting by link, from a phone, without an account and at no cost, hears the meeting live in their own language and gets nothing afterwards: the account is free, and it is what makes the record reachable. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days — joined a meeting, wrote in a chat, asked Mia; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours, tasks and owners included.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Delegation as a craft survives every tool: somebody still has to write the brief, pick one name, and let that person say yes out loud. What doesn't have to survive is the second job — retyping the handover after the call, in one language, and opening the next meeting by asking whether anyone did what the last one agreed.

FAQ

How do you delegate tasks effectively?

Hand over an outcome, not a list of steps: write a one-paragraph brief with what done looks like, the deadline, the limits and who else is involved; pick one owner and get a yes out loud; let the owner repeat the outcome back in their own words; say what they may decide without you; agree the check-in — day, form, length — before the work starts; and keep the handover where both sides can read it later. When the task comes back, say so in the same place.

What are the steps of delegation?

Six, in order: the brief, the owner, the read-back, the authority level, the check-in, the record. The first three make sure both sides mean the same thing; the fourth stops the owner from either returning for every decision or making one they were not given; the fifth separates support from micromanagement by fixing the date in advance; the sixth is what makes the second handover of the same task cheaper than the first.

What tasks should not be delegated?

The decisions that are yours by role — hiring, pay, performance conversations, anything your own manager will ask you about by name, anything that commits the organization past a limit you were given — and the conversations only you can have. Everything that prepares those decisions can be delegated. A task you cannot describe as done in one paragraph is not ready to delegate either; the first step of finding out what done would look like can be.

What is the difference between delegating and assigning a task?

Assigning hands over a step and keeps the how: "call the supplier and ask for the new price list". Delegating hands over an outcome and leaves the how to the owner, within stated limits: "get us a supplier price we can sign by the 20th". Assigning is right for a new hire's first weeks and for emergencies; it does not scale, because every step still passes through the person assigning. Delegating scales, and costs a brief.

What is a RACI chart?

A table with the tasks as rows and the people as columns, where each cell holds one of four letters: R for the person who does the work, A for the one person who owns the outcome and signs it off, C for people consulted before the work is done, I for people informed of the result. The rule that makes it useful is one A per row — a task with two accountable people has none. A RACI chart is for work that several people touch; a single task with one owner needs only the brief.

How do you follow up on a delegated task without micromanaging?

Agree the check-in in the brief, before the work starts — a fixed day, a fixed form, a fixed length, such as three lines in the team's channel on Tuesday — and then do not ask between check-ins. The same question asked on the agreed day is support; asked on a random day it is micromanagement. If the check-in comes back "not on track", the conversation is about the obstacle, not the person. In a space where the recap of a recurring meeting reads back the open tasks at the next session, the follow-up happens on its own cadence rather than yours.

Why does delegation fail?

Almost always in the handover, not in the work: the outcome was not written down, so the owner built something else; nobody said yes, so nobody owned it; the authority level was not named, so the owner either stopped at every decision or made one they were not given; the check-in was set when the lead got nervous, so it landed as distrust; or the result was never acknowledged, so the next task was taken on with less care. Each of these is one line of the brief.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Workspace Updates — "Take notes for me" now captures "next steps"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template (canvas). Microsoft's notes page, Google's Meet help page and Slack's template checked October 2026; Microsoft's recap page and Zoom's meeting-summary page checked August 2026; Google's next-steps announcement checked September 2026. Vendors change plans, features and language lists over time; check their pages for the current state.