Delegation

Introduction#

Delegation is handing responsibility for achieving an outcome to someone else while keeping accountability for that outcome yourself. It is one of the most important skills for a team lead, and one of the hardest to do well.

Delegation is not abdication.

You still own the outcome.

Delegation is how leaders scale so they succeed in their current role and lay a path towards future roles. A lead who holds every decision and every important piece of work limits the team’s output to their own capacity and becomes a bottleneck. And it is how team members grow: individuals develop by owning outcomes, not by carrying out instructions. As team members become more capable, this gives the leader space to take on new challenges, rather than getting stuck.

When delegation goes wrong, it is rarely because of a lack of ability in the person being delegated to. Usually, it is because there was never a shared understanding of what was being asked. The objectives may have been fuzzy or the constraints unstated, and this is often not discovered until the work has deviated far from what is needed.

This page explains why and when to delegate, how to set clear objectives and guardrails, how to verify that they have been understood, how to run checkpoints without taking the work back, and what to do when things drift.

Why delegate#

For the leader, delegation is how you avoid becoming the bottleneck that limits your team’s performance. If every decision must pass through you, you will be very busy and you won’t be harnessing your team’s full abilities or capacity. Every piece of work only you can do is a single point of failure. Delegating well frees you to work on the things that genuinely need you, and stops you getting stuck in your current role because you appear to be indispensable. One measure of a leader’s success is growing the team to the point where they are no longer needed and can move on to a new role.
For the individual, being given real responsibility is one of the most rewarding and effective development experiences there is. People learn far more from owning an outcome, including the uncomfortable parts, than from executing a well-specified task.
For the team, decisions get made faster with fewer frustrating hold-ups. Everyone is more engaged and able to contribute. The work flows more smoothly and the team is more resilient to any individual’s absence. Decisions made closer to the work by the people with the most context are usually better, as well as faster. A team that expects to own things behaves differently from a team that expects to be told what to do.

You can delegate responsibility for the work but not accountability for the outcome. If it goes wrong, “I delegated it” is not a defence, and nor is it a reason to blame the person you delegated to.

Levels of delegation#

Delegation is not all or nothing. There is a spectrum, and much of the friction around delegation comes from the two parties assuming different points on it. Management 3.0 describes seven levels of delegation, seen from the leader’s side.

Level	What it means
1 Tell	I make the decision and tell you.
2 Sell	I make the decision and try to convince you it’s right.
3 Consult	I ask for your input, then I decide.
4 Agree	We decide together.
5 Advise	I offer my view, then you decide.
6 Inquire	You decide, and I ask afterwards what you decided and why.
7 Delegate	You decide. I don’t need the details.

Every level is useful in some situations. Level 1 is appropriate in an emergency, or where a decision is genuinely not yours to give away. Level 7 is right where the person has the capability and context, and the consequences of a poor decision are recoverable. Agreeing the level you are working to avoids surprises.

Be explicit about the level for each thing you delegate, and expect it to move over time. As trust and capability grow, the same kind of decision can move from consult to advise to delegate. Making that movement explicit is itself a powerful development signal.

Management 3.0 uses these levels in a practice called Delegation Poker ↗, where an individual and their lead compare views on the delegation level for a set of decision areas and discuss the differences. It is a good way to surface mismatched assumptions.

Who to delegate to#

It’s fine to delegate some of your routine work to share the load, but delegation has more impact when you delegate things that are not routine. Used this way, delegation develops people, so pick someone for whom the work is a useful stretch rather than always the safest pair of hands. Some things to consider:

Capability and stretch. The work should require the person to grow, but not so far that they cannot succeed even with support. If the gap is large, you may be able to adjust the delegation level rather than not delegating: consult or agree rather than delegate outright. But if the gap is too big, the experience will be a disheartening failure for both parties, so be realistic.
Interest. People bring far more energy to things they want to do. If someone has expressed interest in a particular area in their one-to-ones, that is a strong signal.
Capacity. Delegating to someone who is already overloaded sets them up to fail. Check, and if necessary take something else off them.
Stakes and reversibility. The more costly and less reversible a poor outcome, the more you should favour experience, add support, or choose a lower delegation level. You can and should delegate some higher-risk things, but make sure to provide the appropriate structure and guidance.
Spread it around. The interesting work shouldn’t always go to the same people. And delegating only the dull work lightens your load but doesn’t develop your team.

The three parts of a good delegation#

A good delegation has three parts.

Objectives: what we are trying to achieve, and why.
Guardrails: the constraints within which the person is free to act.
Checkpoints: pre-agreed points at which you confirm together that the work is still aimed at the objectives and still within the guardrails.

The most critical thing is to ensure that you have a shared understanding, and these parts aim to achieve and maintain that. Objectives and guardrails only work if the other person has understood them the way you meant them, and checkpoints are where you find out whether that is still true and address any drift.

Set clear objectives#

An objective describes the outcome and why it matters. It does not describe the activity or the solution. If you find yourself specifying how something should be done, you are not delegating. Instead, focus on clearly describing the objective and guardrails.

A good objective is:

Specific enough that it’s easy to agree on whether it has been met.
Outcome-focused, describing the destination and why it matters, not the path to get there.
Explained, so the person understands why it matters and can make good trade-offs when the situation changes.
Time-bounded, either explicitly or by reference to something that is.
Few in number, and prioritised if there is more than one.

Example objectives#

Objectives to avoid	Better alternatives
“Improve the deployment process” is vague. There is no way to know when it’s done, or whether any particular change counts.	“Reduce the time from merge to production from two days to under two hours by the end of the quarter, without increasing the rate of failed deployments” is specific, measurable, and time-bounded.
“Run a spike on event sourcing” describes an activity, not an outcome. What do we want to learn?	“Give us enough evidence to decide by the end of the sprint whether event sourcing is the right fit for the orders service” describes what a good result looks like. Running a spike may be part of how the person chooses to deliver this outcome, but they are clearer on what they’re aiming to achieve.
“Migrate the platform to Kubernetes” is a solution dressed as an objective. It may be the right solution, but stating it as the goal removes the freedom to find a better one.	“Get us to a position where we can deploy any service independently, several times a day, safely” opens the door to a range of possible solutions. If Kubernetes is the answer, they will find it. If it isn’t, they aren’t locked in.
“Sort out the flaky tests” has no success criterion, and the timescale you have in your head is unstated.	“Get the main pipeline to a point where a red build means a real failure, within the next two sprints” makes clear what success looks like.

A particularly common failure is the moving target: the objective changes in the lead’s head, perhaps because of a conversation elsewhere, but is never restated. The person keeps working towards the objective they were given and is then judged against a different one.

Restate objectives often

Objectives fade and shift. Repeat them at the start of every checkpoint, be clear about any changes, and use them as the reference point for every conversation about the work.

Clarify the guardrails#

Guardrails are the constraints within which the person is free to make their own decisions. They mark out the edges of the space, not the route through it. Good guardrails give freedom, because the person knows exactly where the boundaries are and can move confidently within them.

Common guardrails include:

Time: a hard deadline, a fixed cadence, or a point by which a decision must be made.
Money: a budget, a spending approval threshold, or a cost that must not increase.
Regulation and compliance: data protection, industry regulation, audit requirements.
Security: standards that must be met.
Technology: platforms or languages that must be used, or must not be.
Scope: what is explicitly in or out.
Quality: test coverage, accessibility standards, the definition of done.
Reversibility: decisions that are expensive to undo and should be brought back to you before they are made.

Hard and negotiable#

Not every guardrail is fixed. Some are immovable, such as a regulatory deadline. Others are your current best judgement and have room in them: a preferred technology, a rough budget, a target date that could slip a week if the reason were good enough. Say which is which.

Example: being explicit about negotiability

The go-live date is immovable because of the contract. The choice of queueing technology is your call, but talk to me before you commit to anything we don’t already run. The budget is a guide; if you need more, tell me early and tell me why.

When negotiability is unstated, one of two things happens. Either the person treats everything as hard and is paralysed by a constraint you would willingly have relaxed, or they treat everything as soft and you get a nasty surprise.

Examples of guardrails#

Guardrails to avoid	Better alternatives
“Keep the costs reasonable” is unclear. Reasonable to whom?	“Stay under £2,000 a month in additional cloud spend. If you think it needs more, come to me with the numbers” is explicit both about the limit and that it is open to negotiation.
“Oh, I assumed you knew we can’t use that vendor” is a hidden guardrail, discovered after effort has been sunk in an unacceptable approach.	“We can’t use vendor X for anything touching customer data because of the terms of our contract with them” is stated up front, with the reason.
Twenty guardrails covering every decision leave no space in which to operate. This is micromanagement by constraint.	Five guardrails covering the things that actually matter are proportionate.
“Fixed scope, fixed date, same team” leaves no room to manoeuvre. Something will give, and the person will have to guess what.	“The date and team size are fixed. Scope is negotiable, and here is the priority order” is explicit.
“Don’t use anything new” is vague, and probably not what you mean.	“Don’t introduce a new language or datastore without agreeing it with me first” makes clear what you do want to fix, subject to negotiation, and leaves other decisions like introducing new libraries open.

Verify shared understanding#

Just because a brief makes sense to you does not mean it has been understood by others. Do not assume shared understanding; verify it.

Ask for a playback. Have the person explain the objectives and guardrails back to you in their own words. This is not a test of memory, but a way to find out whether the mental model in their head matches the one in yours.

Example: asking for a playback

Before we finish, can you tell me how you’d describe what we’re aiming for here?

If you had to explain the constraints to someone joining tomorrow, what would you say?

Actively invite questions. Silence is not agreement. It may mean the person has understood, or that they have not yet realised what they don’t know, or that they are reluctant to look uncertain in front of you. Make it easy to ask.

Example: inviting questions

What’s unclear? There’s usually something I’ve assumed without saying.

What else would you want to know before you’d feel confident starting?

What’s worrying you?

What do you think the hardest part of this is going to be?

Example: a playback reveals a gap

Maya has delegated the migration of a reporting service to Tom. She asks him to play back the brief.

Tom: So we want the reporting service off the old database and onto the new platform. We’d like to hit the end of October, and I should keep the existing report formats.

Maya: Nearly. End of October isn’t a “we’d like to.” Finance closes the year in that system on the first of November and the old database licence ends the same week. That date is hard. I should have been clearer about that.

Tom: OK, that changes how I’d approach it. I’d probably want to cut some of the less-used reports rather than risk the date.

Maya: That’s exactly the kind of trade-off I want you making. Let’s list which reports are essential so you know where you’ve got room.

Without the playback, Tom would have planned around a soft date and Maya would have discovered the misunderstanding in October.

Repetition and diversity#

Expect to need to say the same thing many times, and in different ways. A single explanation, however clear, does not create shared understanding. People hear different parts of it, forget some of it, and reconstruct the rest from their own assumptions.

Repeat. Restate the objectives and guardrails at the start of each checkpoint. It will feel redundant to you long before it is redundant to them.
Use different forms. Explain it verbally, draw it, and give concrete examples of what would fall outside the guardrails or fail to meet the objective. Different people take in information differently, and each form catches something the others miss.
Anchor it in writing. A short written brief, shared with the person and referred to at every checkpoint, is the single source of truth. When anything changes, update the brief so that there is never a version in your head that differs from the version on the page.

A written brief needs only a few lines: the objectives and why they matter, the guardrails with their negotiability, the delegation level, and the checkpoint schedule. If it runs to pages, you are probably specifying the solution.

Checkpoints and course correction#

Checkpoints are regular, pre-planned reviews agreed at the point of delegation. They are not ad hoc interruptions whenever you get nervous, and they are not a licence to take the work back.

The focus of a checkpoint is narrow: are we still aiming at the objectives, and are we still within the guardrails? It is not a design review, and it is not “show me the code.” If those things are needed, they can happen separately. Keeping the checkpoint focused on direction rather than detail is what prevents delegation slipping into directing the solution.

A checkpoint is not a status update. Its purpose is to ensure the work is still aiming towards the right objective and staying within the guardrails.

Ask, don’t solutionise#

The most valuable thing you can do at a checkpoint is help the person find their own answers. The temptation will be to offer a solution, but every answer you give is a decision they did not make and a signal that you did not trust them to make it.

Ask open questions, and then wait. The best questions help the person think more clearly about their own situation.

Solutionising	Better alternatives
“I’d split that into two services” makes the decision for them.	“What would you do if it were entirely your call?” lets them take the lead. Very often they already have the answer and want a sanity check.
“You need to talk to the platform team” assigns an action rather than surfacing the obstacle.	“What’s getting in the way?” followed by “What would help?” helps them find an answer themselves.
“That won’t work because…” closes the conversation.	“What’s the risk with that approach?” engages them in solving the problem.

Powerful questions for checkpoints

What are you most worried about?

Which of the guardrails would you change if you could?

What would need to be true for this to work?

What are you assuming?

If we’re wrong about this, how would we find out?

What do you need from me?

Course-correcting#

When a checkpoint shows the work has drifted, there are two possibilities. Either the work needs to change, or the objective or guardrail was wrong or unclear. Consider both. It is surprisingly common for a checkpoint to reveal that a constraint you set no longer applies, or that the objective was never quite what the business needed.

If the work needs to change, help the person work out what to change by showing where it will fail to meet the objective or violate a constraint. Agree the correction, write it down, and revisit it at the next checkpoint.

There are times to step in more directly, such as when a hard guardrail is about to be breached, or a decision is about to be made that would be expensive to reverse. When that happens, be explicit that you are stepping in, say why, and say what happens next. Then step back out. Quietly taking over is the worst of both worlds.

Step back one style at a time#

The Situational Leadership ↗ model describes four leadership styles, in increasing order of the autonomy given to the other person. We call these:

Directing: telling the person what to do.
Mentoring: advising or recommending what the person should do based on your experience.
Coaching: helping the person find their own answers. This is not leading them to your answers (mentoring in disguise) but having a genuinely open mind to what the answer may be.
Delegating: supporting the person to make their own decisions without guidance on the how.

Delegating is a destination you reach by working through the other approaches, as the person builds the skill and confidence.

If a checkpoint shows the person needs more help than delegating provides, move back only as far as you need to. Usually that means stepping into coaching, where you listen, encourage, and help them think, or mentoring, where you give more guidance while still involving them in the decisions. Then, as soon as they are back on course, move forward again.

Don’t snap straight from delegating to directing. This is a common reaction when something goes wrong, and is damaging. It tells the person that the first wobble cost them your trust, undoes whatever development the delegation was meant to produce, and teaches the team that ownership is conditional on never needing help.

When it goes wrong, own the disconnect#

When the person you delegated to has gone in a direction you did not intend, the temptation is to be frustrated with them, but this is a misattribution. Misalignment with objectives or guardrails is almost always a communication failure, and the communication was yours.

If you find yourself saying “I’ve told you this before”, ask yourself what you told them, in what form, whether they played it back, and whether you have restated it since. Usually the honest answer reveals the gap.

Example: blaming versus fixing the brief

James asked Priya to lead the rebuild of the notifications service. At a checkpoint he discovers that she has chosen a managed messaging product from a cloud provider the company is trying to move away from.

A response that blames:

James: I don’t know why you picked that. You know we’re moving off that provider. This is going to have to be redone.

Instead, pause. It is unlikely the choice was made out of wilful disregard for the decision. When was this decision communicated? How could you have communicated it more clearly? Should you have stated this as a guardrail?

A response that owns the gap:

James: That’s my mistake. We’ve decided to move off that provider over the next year and I didn’t think to check that you were aware of it. Let me add it to the brief now. Given that, what are the options?

The second response costs James nothing, keeps Priya’s ownership intact, and leaves both of them with a better brief.

Owning the disconnect is not the same as never giving critical feedback. If there is a genuine performance issue underneath, address it through feedback in the right setting. But sort out the brief first, because until the objectives and guardrails are clear and understood, you cannot tell whether there is a performance issue at all.

When course correction keeps failing

If someone repeatedly drifts from clear objectives and guardrails, despite verified understanding and genuine support, that has become a performance conversation rather than a delegation problem. Address it through feedback and, if necessary, performance improvement.

Summary#

Do

Delegate outcomes, not tasks, and explain why they matter.
Be explicit about the level of delegation, and aim for it to increase over time.
Choose people for whom the work is a useful stretch, not always the safest pair of hands.
Write the objectives and guardrails down, and say which guardrails are negotiable.
Verify understanding by asking for a playback in their own words.
Restate the objectives and guardrails often, and in different forms.
Agree checkpoints up front, and keep them focused on direction rather than detail.
Ask questions before offering answers, and then wait.
Stay actively engaged and keep the accountability.

Don’t

Don’t confuse delegation with abdication. Handing something over and walking away is not delegation.
Don’t assume one explanation was enough. Repetition is key.
Don’t leave guardrails unstated and then be surprised when they are crossed.
Don’t specify the solution and call it an objective.
Don’t turn checkpoints into design reviews or status updates.
Don’t solutionise when a question would do.
Don’t quietly take the work back. If you need to step in, say so, say why, and step back out.
Don’t snap straight to directing. If more support is needed, step back one style at a time, to coaching or mentoring, and move forward again as soon as you can.
Don’t blame the team for gaps in your brief. Own the disconnect and fix it.