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 is three linked acts: handing someone an outcome rather than a set of steps, giving them the authority to reach it, and leaving the work with them when it gets hard. Ownership is what the person on the receiving end has when all three have happened, and decision rights are the explicit statement of who may decide what, which is the part most managers leave implicit and most organisations pay for. 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 that is handed over and then quietly taken back, the authority that is 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 is not trust; it is a gap the person will fill by guessing.
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, not their seniority. Enough challenge that they grow; not so much that they fail without support.
3. Delegated authority is real or it is nothing. If you grant someone the right to decide and then reverse them quietly, 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; you keep the answerability for the result. This is what distinguishes delegation from abdication, and it is true whether the object is a task, a team or a division.
5. Do not take it back. When delegated work wobbles, the choices are to support, to coach, or to rescue. Rescue is the one that feels responsible and is usually the mistake: it ends the growth, and it 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, not during 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 has the kind of large-sample evidence behind it that psychological safety or the DORA findings have, and this unit does not pretend otherwise.

Task-relevant maturity practice

Andrew Grove's observation, from Andrew S. Grove, High Output Management (1983), 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, though they need none on system design. A strong engineer newly promoted into management has low task-relevant maturity at management itself, however senior they are technically. The practical consequence is that delegation scope and support level are set per task and per person, and are reassessed as the work changes: yesterday's calibration quietly becomes today's mismatch.

Situational leadership practice

The model that grew from Paul Hersey and Kenneth H. Blanchard, Management of Organizational Behavior: Utilizing Human Resources (1969): leadership style is a variable, flexed between directing, coaching, supporting and delegating according to the person's competence and confidence on the task at hand. Its lasting insight is that a manager's style should track the task rather than the manager's personality or the report's title. Misread it in one direction and you micromanage experts; in the other and you abandon novices. The model has been reworked many times since its first publication and its predictive claims are thin; it is used here as a vocabulary for calibrating support, not 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): replace "may I…" with "I intend to…". The person states what they are about to do and why; the manager's silence is consent, and an objection has to be voiced. It pushes decisions to where the information is while keeping the manager informed, and it makes the level of authority visible in every exchange. The same idea, formalised, is a ladder of authority levels agreed per kind of decision: recommend, decide and inform, decide alone.

One-way and two-way doors practice

Jeff Bezos's classification in Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016): most decisions 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 it answers the question every manager asks — which decisions can I hand over? The answer is most of them, and the manager's job is to name the few that are one-way and keep those, rather than to hover over all of them. Reversibility is often misjudged, so when in doubt treat a door as one-way until it is shown otherwise.

Managerial leverage practice

Grove's framing, also from Andrew S. Grove, High Output Management (1983), that a manager's output is the output of the organisation under them, and that activities differ in leverage: an hour spent making a delegation clear pays back across every hour the delegate then spends. It is the economic argument for the explicitness in principle 1 — the brief that feels slow to write is the highest-leverage thing in the delegation.

The delegation brief

For anything larger than a day's work, the delegation is written, 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 decided. A brief that cannot be written is a delegation that is not ready.

A decision-rights register

For the team, a short living list of the recurring decisions — releases, architectural choices above a certain size, hiring decisions, on-call changes, scope trades — and who decides each, at what authority level. Most teams have never written it down and are surprised by how many entries are disputed. A register is also the artifact that makes principle 3 checkable: an override of a listed right is visible as one.

The check-in that is about the outcome

A scheduled conversation about delegated work asks about the outcome and the risks to it, not the steps. "What is the state of the migration and what could stop it?" rather than "Did you talk to the platform team yet?" The first keeps the 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: the person is not ready, the situation changed, the stakes rose. Doing it explicitly — "I am taking this back, here is why, here is what you keep" — preserves the person's standing and everyone else's belief that delegation means something. Doing it quietly, by fielding the decisions yourself while leaving the title with them, destroys both.

Onboarding a new mandate

When someone takes on a larger scope, the first weeks are spent making the authority level real: the manager routes questions back to them in front of others, declines to answer for them, and visibly accepts their decisions. Authority that is granted in private and undermined in public is not authority.

The object of delegation changes with scope while the discipline stays the same. 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 rather than 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 its own competency, PL-6 Leading through leaders, and designing ownership through structure is SV-6 Organisational design and leading change. The general pattern, and the table that places 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, not 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, which feels responsible and teaches the team that ownership is provisional.
• Hands each manager a genuine mandate with explicit decision rights between the two of you. 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 instead of developing the manager (see PL-6 Leading through leaders). org
• Delegates genuinely large mandates to senior leaders while keeping accountability undiluted. exec
• Failure mode — the hub-and-spoke bottleneck: an organisation in which every significant decision still routes through one person, because decision rights were never designed. exec
• Failure mode — confusing empowered leaders with nobody being accountable. exec

Stretch versus safety. Growth requires assignments a person has not done before, and every such assignment carries a risk to the outcome. The judgment is in the size of the stretch and the strength of the net: a stretch with no safety net is a gamble with someone else's reputation, and a net so tight there is no stretch is not delegation.

Speed versus development. The manager could often do it faster, and in a genuine emergency should. The tension is that "faster this once" compounds: every task the manager keeps is one the team does not learn, and the manager who is always faster has built 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. Resolving the discomfort by keeping the decisions is abdication of the development; resolving it by disclaiming the result is abdication of 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: it is the unwritten right that gets overridden, because nobody can point to it.

Autonomy versus consistency. The more decisions are pushed to the people closest to the work, the more those decisions diverge across people and teams. Some divergence is the point; some is a cost. Deciding which decisions must be consistent, and holding those centrally, is part of designing decision rights rather than an 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: 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 reveals 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 matters before the response. The engineer's task-relevant maturity at leading a multi-team change was low and the brief did not compensate: it named the outcome and the authority but said nothing about the dependencies, which is where an engineer who has only worked inside one team will not look. The failure so far is in the delegation, not the delegate.

The manager's call is 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, the dependent teams are the critical path — and 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 at the point of lowest maturity: sitting in on the first conversation with the dependent teams, as an observer, not the lead. They do not take over the plan, and they do not say "I'll handle the platform team." They also make the risk visible upward, because accountability has not moved: the launch owner hears now that the migration is behind and what is being done, rather than 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 has a second person who can lead a migration. If it is not, the manager withdraws the delegation explicitly, with the reason, and the engineer keeps a defined part of the work. What the manager does not do is 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; the organisational form of this competency.
• SV-6 Organisational design and leading change — ownership designed through structure, charters and reorganisation; 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, and its absence is what 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

   Because 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: it ends the person's growth and teaches the team that ownership is provisional. The exception is a genuine emergency, and 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

   Accept it, which teaches that authority is real; overrule it openly with the reason, which teaches that authority is real but bounded; or reverse it quietly, which teaches that the grant was theatre. The third is the one to avoid, and the second should be 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 while leaving them 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

   It moves the decision to the person with the information while keeping the manager informed, and it makes the authority level visible in every exchange: silence is consent, and an objection has to be voiced.
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

   Decision rights were never designed, 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 — not to work faster at the hub.

• 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.