How to delegate tasks to your team: a practical guide

Most delegation advice focuses on the psychology of letting go: trust your team, embrace mistakes, do not micromanage. Useful advice, but written for office managers handing projects to direct reports.

This is for managers running operational teams (events, catering, hospitality, volunteer coordination, on-demand staffing) where delegation looks less like handing someone a quarterly objective and more like assigning twelve tasks to seven people across the next two days. The hard questions are practical: do these tasks make sense at all, where do they come from, who does what, what goes in the brief, and how do you support and close out the work without hovering.

Tasks need a why before they need a who

A task list is only useful if it moves the team toward something specific: this event runs well, this shift covers the schedule, this season hits its targets. Without that anchor, the list is busywork. People work harder and choose better when they can see the goal behind the next thing in front of them.

Most ops managers know this. The check is whether the team knows it too. If you find yourself making a list and cannot say, for each task, how it connects to a goal the team has agreed on, fix that before you delegate. No distribution tactic will save you from the wrong tasks getting done well.

Where the task list comes from

Before you delegate, someone has to decide what the tasks are. Three common ways teams generate their working list, each with its own trade-off.

Team meeting. Everyone gets a voice on what needs to happen and what the priorities are. The benefit is buy-in: people who helped build the list feel ownership of it, and the conversation surfaces dependencies and conflicts you would not have caught on your own. The cost is time. A 60-minute meeting for an 8-person team costs 8 hours of staff time per week, and most of that time is spent listening to things that do not affect any given individual. Useful for setting the major priorities at the start of a shift, week, or season. Less useful for the day-to-day list.

Manager-built list. You sit down, look at what is in motion, and write the list yourself. Faster than a meeting, and the priorities are coherent because one brain ordered them. The cost is that the team did not see the inputs you saw and may not understand why some things rank above others. Mitigate by sharing the reasoning, not just the list. “These three are top because the launch date is fixed” travels with the work and prevents quiet resentment.

Templates for repeating work. If the work is broadly similar each time (onboarding a new client, running a recurring event, executing a familiar service), the task list is largely the same every time. Build it once, save it as a template, and reuse. Most of the time normally spent on the list is then gone. The risk is that templates rust: if the work shifts and the template does not, you are running last year’s playbook. Review templates regularly and update when reality changes.

Most teams use a combination. The major priorities come from a meeting at the start of a shift, week, or season. The day-to-day list comes from the manager or from templates. The mix is fine; the mistake is using one method for everything.

How tasks actually get distributed

Two separate questions sit underneath every delegation decision, and most managers conflate them. The first is who makes the assignment. The second is what criterion the decision uses.

Who makes the assignment

Three options, each with a real trade-off.

The manager assigns. You pick who does what, task by task. Stuff gets done because you choose competent people for each task. The cost is that people complain about the assignments they got, the assignments they did not get, or both, and you spend a lot of time deciding.

The team member self-assigns. You post the open tasks and the team picks what works for them from a shared queue. Everyone feels in charge of their work, which is the strongest motivator on this list. The catch is that the least appealing tasks sit on the table waiting for someone to claim them. Self-assignment only works with serious priority enforcement: house rules requiring unappealing tasks to be picked up by certain deadlines, manager-initiated reassignment of the leftovers, or incentives applied to the harder tasks. For shifts specifically, self-scheduling has its own infrastructure around availability rules, swap mechanics, and constraints on who can claim what.

A system assigns. Rules or an algorithm allocate tasks based on whatever data is available: skills, current workload, recent assignments, fairness over time, deadlines. The advantage is that the system can hold more variables in mind than a human manager and apply them consistently. The disadvantages: it only works if the underlying data is actually there, and people still complain, because the system did not understand their specific situation today.

What criterion the decision uses

Whichever method makes the assignment, it has to decide on some basis. Three common criteria, each with a known failure mode:

Who does it best. Skill matching. The cleanest person tidies the kitchen. Excellent for the work that gets done. Less excellent for the cleanest person, who now does the kitchen forever and stops being available for anything else. Skill matching overburdens your strong performers if it becomes the default.

Whose turn it is. Rotation. Fairness across the team, with everyone taking the desirable and undesirable tasks in proportion. Produces uneven quality, which the strong performers notice. “Your turn to clean the kitchen, but it is not clean by my standards” is the recognisable form of this complaint. Tasks where quality matters more than fairness are not great rotation candidates.

Who is available right now. Whoever has the bandwidth gets the task. The person currently free is sometimes the one with the wrong skills for it. Sometimes they are the one who was actually on time with their other work, which means they get punished with extra tasks while a less organised teammate avoids them. Availability is the criterion that most damages morale when used as a default.

The honest framing is that each criterion has a known failure mode, and the manager’s job is to balance across them rather than commit to one. Use skill matching for the work that matters most. Use rotation for the work that has to be shared. Use availability when the calendar dictates and nothing else works. And keep an eye on who is bearing the cost of whichever default you have chosen.

The standard brief

The point of a brief is not to explain everything. It is to give the person the minimum they need to execute. Everything else either lives in a reference document they can read if they need to, or comes from the support channel they can use if they get stuck.

Standardise this. When the same elements appear in the same order every time, people know where to look for what they need, and the cognitive overhead of receiving a new task drops to almost nothing.

The minimum elements:

• The outcome. What done looks like, stated as a result. “Head table set up for 6pm dinner service.” Not “set up the head table” (no time) or “help with dinner setup” (no specific task).
• The deadline. When it has to be done. Even if it is “as soon as you can” or “by end of shift,” say so. “Ongoing” is fine for tasks that genuinely are. “When you have a minute” is not.
• Background reference, if relevant. Where to find more detail if they need it. The standard setup diagram. The client’s preferences document. The previous version of this same task. The link, not the explanation.
• Support channel. How to reach you if something is unclear. “Message me if you have questions” works fine. So does “ask the floor lead.” The specific channel matters less than using the same one every time.

That is the whole brief. Four elements, none of which take long to write. If a task does not fit this template (if you cannot state the outcome, the deadline, or where help comes from) the task is not ready to be handed off, and writing more words will not fix that.

After you delegate

Two things matter after the handoff: clear support if the person needs it, and clean closure when the work is done.

Make the support channel standard, not bespoke. Pick one way for people to reach you when they need help, and use it consistently across tasks. “Message me if something is unclear.” “Ask Maria, she has done this setup before.” “Check the shared chat first, then call me.” The specific channel matters less than the consistency. People perform better when they know the rule without having to figure it out for each new task.

Have a deadline, not an open timeframe. Even if the deadline is “by end of shift” or “before the doors open at 6pm,” it needs to be a fixed point. “When you have a minute” sets nobody up for success, including you, because you do not know when to expect the work back.

Check in yourself at the deadline. When the time is up, you go to them. Do not make them come find you. “How did the head table setup go?” at 6

closes the loop cleanly. The person does not wait around to give you an update. The work moves on.

Stay out of the last 30 minutes before the deadline. The biggest temptation in operational delegation is to walk over at minute 90 of a two-hour task to check progress. That last stretch is when the person is concentrating hardest on getting the work done, and hovering at that moment makes the work worse, not better, even when you are trying to help. If something has gone wrong, they will message you. If they do not, trust the timeline you agreed on.

Where delegation goes wrong

Five operational patterns that recur on teams that delegate frequently:

Delegating to the same favourites. Maria is your best, so you give Maria everything. Maria burns out. The rest of the team never develops. Track who is getting which tasks across a week, not just a shift, and rotate intentionally even when it costs a bit of quality.

Skipping the brief because “they know what they’re doing.” Experienced team members get short-changed on briefing because you assume they will fill in the blanks themselves. They usually can. Sometimes they fill in the wrong blanks. The standard brief is fast enough that there is no reason to skip it, and skipping it for senior people teaches the whole team that briefs are optional.

Assigning without checking what the person is already doing. “Can you handle this?” gets a yes when the person is already on something else, because the yes-by-default is the team-friendly answer. The honest version of the question is “what are you in the middle of, and can you take this on too?” The reply tells you whether you are about to overload them.

Assigning verbally without recording it. In a quiet office this might be fine. In an operational environment with multiple people, multiple tasks, and a hectic shift, verbal-only assignments get forgotten or misremembered. Have a written record of who has what, even if it is just a note in the team app or a line in a shared sheet.

Forgetting to tell the rest of the team who is doing what. Someone on the floor needs to know who got the task. If guests, suppliers, or other staff cannot figure out who to ask about something, the work happens with extra friction and the person doing the task wastes time fielding queries that should have gone elsewhere.

Where most of the work actually happens

Delegation is not a single act but a sequence of decisions: whether the work is worth delegating at all, where the list comes from, who does what, on what criterion, what goes in the brief, and how you support and close out the work. The hardest part of any of them is the moment of letting go, but the others are where the avoidable mistakes happen, and they are mostly fixable with structure rather than willpower.

Zelos works for operational teams where the work shape is closer to shifts and individual tasks than projects: events, catering, hospitality, volunteer coordination, on-demand staffing. The platform stores skills profiles against team members, tracks who has picked up which tasks, and gives the team a shared view of who is doing what. The simple staffing software page explains how it works.