Delegation, ownership, and decision rights

Delegation is how a manager's output stops being limited by their own hours, and how the people around them grow into work they have not done before. It involves three linked acts. The manager hands someone an outcome rather than a set of steps, gives them the authority to reach it, and leaves the work with them when it gets hard. Ownership is what the person on the receiving end has once all three have happened. Decision rights are the explicit statement of who may decide what; most managers leave them implicit, and most organisations pay for that. The competency matters because almost every other one depends on it. A manager who cannot delegate cannot coach, cannot lead through other managers, cannot make time for strategy and cannot be away for a week. The examinations test it because its failure modes are so recognisable: the task handed over and then quietly taken back, the authority granted and then overridden, the decision nobody knew was theirs to make.

1. Delegate the outcome, and be explicit about three things. A delegation is complete when the person knows the result wanted, the constraints they are working within (time, budget, what not to touch), and the level of authority they hold: decide and proceed, decide and tell me, or recommend and check. Leaving any of the three unsaid leaves a gap the person will fill by guessing, and that is no form of trust.
2. Match scope to capability on this kind of work, plus a deliberate stretch. The guide is the person's experience with this specific task, whatever their seniority. Give enough challenge that they grow, and stop short of the point where they fail without support.
3. Delegated authority is real or it is nothing. If you grant someone the right to decide and then quietly reverse them, you have taught them, and everyone watching, that the grant was theatre. Overrule rarely, openly, and with the reason.
4. Accountability does not transfer. You hand over the work and the decisions and keep the answerability for the result. That is what separates delegation from abdication, and it holds whether the thing delegated is a task, a team or a division.
5. Do not take it back. When delegated work wobbles, the manager can support, coach or rescue. Rescue feels responsible and is usually the mistake. It ends the growth and teaches the team that ownership is provisional.
6. Decision rights are designed, not discovered. Wherever more than one person could reasonably think a decision is theirs, write down whose it is before the disagreement arrives rather than in the middle of it.

Delegation is among the most written-about subjects in management and among the least studied empirically. The models below are practitioner models with clear provenance. None of them has the large-sample evidence that sits behind psychological safety or the DORA findings, and this unit does not pretend otherwise.

Task-relevant maturity practice

In Andrew S. Grove, High Output Management (1983), Andrew Grove observes that how much direction a person needs depends on their experience with this particular kind of work rather than on their general seniority. A senior engineer commanding their first incident has low task-relevant maturity at incident command and needs close support there, while needing none on system design. A strong engineer newly promoted into management has low task-relevant maturity at management itself, however senior they are technically. In practice, delegation scope and support level are set per task and per person and reassessed as the work changes, because yesterday's calibration drifts into today's mismatch without anyone noticing.

Situational leadership practice

This model grew from Paul Hersey and Kenneth H. Blanchard, Management of Organizational Behavior: Utilizing Human Resources (1969). It treats leadership style as a variable, flexed between directing, coaching, supporting and delegating according to the person's competence and confidence on the task in front of them. Its lasting insight is that a manager's style should follow the task, and should not be set by the manager's personality or the report's title. Misread it one way and you micromanage experts; misread it the other and you abandon novices. The model has been reworked many times since it was first published and its predictive claims are thin. This unit uses it as a vocabulary for calibrating support and makes no use of it as a theory.

Levels of authority and intent-based leadership practice

The most useful single mechanism for making authority explicit comes from L. David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders (2012). The person stops asking "may I…" and starts saying "I intend to…", stating what they are about to do and why. The manager's silence counts as consent, and an objection has to be spoken. Decisions move to where the information is, the manager stays informed, and the level of authority shows in every exchange. Formalised, the same idea becomes a ladder of authority levels agreed for each kind of decision: recommend, decide and inform, decide alone.

One-way and two-way doors practice

Jeff Bezos sorts decisions into two kinds in Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016). Most are reversible two-way doors and should be made quickly by the people closest to them. A few are one-way doors that deserve deliberation and senior involvement. For delegation, this answers the question every manager asks about which decisions can be handed over. Most of them can. The manager's job is to name the few one-way doors and keep those, and to stop hovering over all the rest. Reversibility is often misjudged, so when in doubt treat a door as one-way until it is shown to be otherwise.

Managerial leverage practice

Grove also argues, in Andrew S. Grove, High Output Management (1983), that a manager's output is the output of the organisation under them, and that some activities return far more of that output than others. An hour spent making a delegation clear pays back across every hour the delegate then spends on it. This is the economic case for the explicitness in principle 1. The brief that feels slow to write is the part of the delegation that returns the most.

The delegation brief

For anything larger than a day's work, the delegation is written down, even if only as a paragraph in a message. It states the outcome and how it will be recognised, the constraints, the authority level, who else is involved and in what role, and when the two of you will next look at it together. Writing it exposes what the manager has not yet decided. If the brief cannot be written, the delegation is not ready.

A decision-rights register

This is a short, living list of the team's recurring decisions (releases, architectural choices above a certain size, hiring decisions, on-call changes, scope trades) with who decides each and at what authority level. Most teams have never written one down, and they are surprised by how many entries turn out to be disputed. The register also makes principle 3 checkable, since an override of a listed right is visible as an override.

The check-in that is about the outcome

A scheduled conversation about delegated work asks about the outcome and the risks to it, and leaves the steps alone. Compare "What is the state of the migration and what could stop it?" with "Did you talk to the platform team yet?" The first keeps ownership with the delegate. The second takes the steering wheel back one question at a time.

Handing back, explicitly

Sometimes a delegation has to be withdrawn because the person is not ready, the situation has changed or the stakes have risen. Saying so plainly ("I am taking this back, here is why, here is what you keep") protects the person's standing and keeps everyone else believing that delegation means something. Withdrawing it quietly, by fielding the decisions yourself while the title stays with them, destroys both.

Onboarding a new mandate

When someone takes on a larger scope, the first weeks go on making their authority real. The manager routes questions back to them in front of others, declines to answer on their behalf and is seen to accept their decisions. Authority granted in private and undermined in public does not count as authority.

The thing being delegated changes with scope; the discipline does not. At team scope you delegate tasks and projects to engineers. At organisational scope you delegate whole teams to managers, and the characteristic failure becomes reaching around the manager to their engineers. At executive scope ownership is designed through structure, charters and decision rights instead of being assigned one conversation at a time, and the failure is becoming the decision bottleneck of a hub-and-spoke organisation. Leading the managers you delegate teams to is a competency of its own, PL-6 Leading through leaders, and designing ownership through structure is SV-6 Organisational design and leading change. The general pattern, with the table placing every competency at each scope, is in How Judgment Scales.

• Delegates outcomes and leaves the method to the person. team
• Gives a stretch assignment and stays close enough to make it survivable. team
• States the authority level in the delegation and honours it afterward.
• Resists the urge to take work back when it wobbles, and chooses support or coaching over rescue. team
• Delegates the interesting decisions as well as the routine work. A team that only ever receives the boring tasks learns that delegation is a chore, when it should be an investment. team
• Failure mode (the dump): an under-specified task handed over with no brief, no check-in and no authority, followed by disappointment. team
• Failure mode (the quiet override): authority granted, then reversed without saying so, usually because the manager would have decided differently. team org
• Failure mode (the rescue): stepping in at the first sign of struggle. It feels responsible, and it teaches the team that ownership is provisional.
• Hands each manager a real mandate, with the decision rights between the two of you made explicit. org
• Uses skip-level conversations for signal, never for decisions that belong to the manager. org
• Failure mode (reaching around): managing a manager's engineers directly, fixing their team's problems, or letting their escalations become your workload, because you used to do their job and could do it faster. org
• Failure mode (taking the team back): withdrawing a manager's mandate when their team struggles, when the job is to develop the manager (see PL-6 Leading through leaders). org
• Delegates large mandates to senior leaders and keeps accountability undiluted. exec
• Failure mode (the hub-and-spoke bottleneck): an organisation in which every significant decision still routes through one person, because nobody ever designed the decision rights. exec
• Failure mode: mistaking empowered leaders for a state in which nobody is accountable. exec

Stretch versus safety. People grow through assignments they have not done before, and every such assignment puts the outcome at some risk. The judgment lies in how big the stretch is and how strong the net is. A stretch with no safety net is a gamble with someone else's reputation, and a net so tight that nothing is stretched is no longer delegation.

Speed versus development. The manager could often do it faster, and in a real emergency should. The trouble is that "faster this once" compounds. Every task the manager keeps is one the team does not learn, and a manager who is always faster ends up with a team that cannot operate without them.

Authority versus accountability. Handing over the right to decide while keeping the answerability for the result is uncomfortable by design. Ease the discomfort by keeping the decisions and you abdicate the development; ease it by disclaiming the result and you abdicate the job.

Explicitness versus trust. Writing down decision rights and authority levels can feel like bureaucracy, or like a statement that people are not trusted. In practice the written form is what makes trust checkable. The right that gets overridden is the unwritten one, because nobody can point to it.

Autonomy versus consistency. The more decisions go to the people closest to the work, the more those decisions diverge across people and teams. Some of that divergence is the point and some is a cost. Deciding which decisions must be consistent, and holding those centrally, is part of designing decision rights and no exception to it.

A first-line manager has delegated a database migration to an engineer with four years' experience who has never led a project of this size. The brief was reasonable. It gave the outcome, a two-month window, a weekly check-in, and authority to make design decisions within the existing platform. Three weeks in, the check-in shows that the engineer has spent most of the time on a schema redesign the migration did not require, has not yet spoken to the two teams whose services depend on the table, and is visibly anxious. The launch that depends on the migration is five weeks away.

The pull toward rescue is strong. The manager has done three migrations and could re-plan this one in an afternoon. The scope was a stretch and the wobble is real, but the diagnosis has to come before the response. The engineer's task-relevant maturity at leading a multi-team change was low, and the brief did not make up for it. It named the outcome and the authority and said nothing about the dependencies, which is exactly where an engineer who has only worked inside one team will not look. So far the failure lies in the delegation, not in the delegate.

The manager decides to keep the delegation and repair the brief. In the check-in they name what is now known: the schema redesign is out of scope, and the dependent teams are the critical path. They ask the engineer to bring a revised plan by the end of the week that starts with those conversations. They offer one concrete piece of support where maturity is lowest, sitting in on the first conversation with the dependent teams as an observer while the engineer leads. They do not take over the plan, and they do not say "I'll handle the platform team." Because accountability has not moved, they also make the risk visible upward. The launch owner hears now that the migration is behind and what is being done about it, instead of hearing it in five weeks.

If the revised plan is sound, the engineer finishes a project they could not have finished without the wobble, and the manager gains a second person who can lead a migration. If it is not, the manager withdraws the delegation explicitly, gives the reason, and leaves the engineer a defined part of the work. Either way, the manager does not do the thing that felt most responsible three weeks in.

• PL-6 Leading through leaders: the managers you delegate whole teams to, and what developing them requires. This is the organisational form of the competency.
• SV-6 Organisational design and leading change: ownership designed through structure, charters and reorganisation, which is the executive form.
• CC-2 Coaching versus directing: the coaching that replaces rescue when delegated work wobbles.
• PL-5 Career development and growth paths: delegation as the main instrument of growth, and the stretch assignment as a career move.
• TJ-4 Technical credibility and intervention: deciding which technical decisions are yours to keep and which to hand over.

1. An explicit delegation makes three things clear. What are they, and which one do managers most often leave out?
   Answer

   The outcome wanted, the constraints, and the level of authority. Authority is the one most often left implicit. Its absence produces both the delegate who checks everything and the delegate who oversteps.
2. Why is task-relevant maturity a better guide to delegation scope than seniority?
   Answer

   The support a person needs depends on their experience with this kind of work. A senior engineer can have low maturity at a task they have never done, and a junior one can be highly capable at a task they have done many times. Seniority predicts neither.
3. Delegated work is wobbling three weeks in. Name the three responses available and say which one usually feels most responsible and is usually wrong.
   Answer

   Support, coach, or rescue. Rescue feels most responsible and is usually wrong, because it ends the person's growth and teaches the team that ownership is provisional. The exception is a real emergency, and even then the withdrawal should be explicit.
4. You granted an engineer authority to decide the design of a feature and you disagree with what they chose. What are your options and what does each teach the team?
   Answer

   You can accept it, which teaches that authority is real. You can overrule it openly with the reason, which teaches that authority is real but bounded. Or you can reverse it quietly, which teaches that the grant was theatre. Avoid the third, and keep the second rare.
5. A manager who reports to you is drowning. What distinguishes coaching them from quietly doing their job? org
   Answer

   Coaching leaves the decisions and the team with the manager and develops their judgment about both. Doing their job takes the decisions back and leaves them only the title. The test is who is deciding at the end of the week.
6. What does "I intend to…" change about a delegation compared with "may I…"?
   Answer

   The decision moves to the person with the information and the manager stays informed. The authority level also becomes visible in every exchange, since silence is consent and an objection has to be spoken.
7. In an organisation you have just inherited, every significant decision still reaches you. What is the diagnosis, and what is the first repair? exec
   Answer

   Nobody designed the decision rights, so the structure routes everything to the hub. The first repair is to write down which recurring decisions are made where, push the reversible ones down explicitly and keep only the one-way doors. Working faster at the hub is no repair.

• Andrew S. Grove, High Output Management (1983): task-relevant maturity; managerial leverage.
• Paul Hersey and Kenneth H. Blanchard, Management of Organizational Behavior: Utilizing Human Resources (1969): the origin of situational leadership.
• L. David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders (2012): intent-based leadership and "I intend to".
• Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016): one-way and two-way doors.
• Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019): sizing mandates and spans; delegation as a system property at scale.