Delegation readiness

Suppose a PM is overloaded. Four signals compete for attention, and the activation decline is the one that keeps slipping. So the PM delegates it: "can you look into the activation drop and come back with what you find?"

Two weeks later a deck arrives. It is competent. It segments activation by platform, shows the decline is broadly distributed, and recommends improving onboarding copy. It answers a question the PM was not asking. The PM redoes the work in three days and concludes, privately, that this is not delegable.

That conclusion is wrong, and it is expensive, because the PM will now hold every consequential investigation personally and will keep being the constraint.

Look at what was actually handed over. A topic. Everything load-bearing stayed in the PM's head: which decision the work serves, which populations matter, which evidence would be sufficient, whether the delegate could talk to the support lead, and what would require coming back early. None of that was missing from the PM's thinking. It was missing from the handover.

The failure is hard to see because the delegate's output is competent. The gap does not look like a communication problem. It looks like a judgment gap in the other person.

Trace what actually crossed between the two people, and what did not:

sequenceDiagram
  participant PM
  participant D as Delegate
  participant S as Support lead
  PM->>D: "Look into the activation drop"
  Note over PM: Decision, populations, evidence bar<br/>and access all stay behind
  D->>D: Segments by platform, writes a deck
  D-->>PM: A competent answer to a question<br/>nobody asked
  PM->>PM: Redoes the work in three days
  Note over D,S: The recordings were never mentioned,<br/>so they were never asked for

One arrow crosses from the PM, and it carries a topic. Everything the delegate needed in order to aim is sitting in the note over the PM's own lane, and the support lead never enters the diagram at all.

Ask before handing anything over: could a competent person who was not in the room produce something I would act on? If not, the gap is in your handover, not in them.

Delegation readiness is a portability test. Five things must survive leaving your head.

Element	Portable when	Symptom when it stays behind
Intent	The decision it serves is written, with live alternatives	The delegate optimises the task rather than the decision
Constraints	Time, budget, population, and what must not change are stated	The delegate finds the constraints by violating one
Interfaces	Who they can talk to, what they can commit, what they cannot	Blocked for a week, or commits something you cannot honour
Evidence standard	What counts as sufficient for this decision	Anecdotes, or an over-built study nobody needed
Escalation conditions	Named observations that require coming back early	Escalates everything, or nothing until it is too late

PJ-02 and PJ-04 do most of the work here. The evidence standard is a definition of good applied to the answer rather than to the product. The escalation conditions and the decision rights come straight from your decision architecture. If you have both artifacts, you are most of the way to a delegation contract already. That is the point of writing them.

Delegate the work, or delegate the decision?

These are different, and confusing them is what makes handovers feel arbitrary.

Level	What the delegate does	What you keep
Execute	Produces a defined output to a defined standard	The decision, and the framing
Recommend	Frames options and argues for one; you decide	The decision
Decide	Chooses, inside stated boundaries, and informs you	The consequence

Say the level out loud, in the handover. Most delegation disappointment is a level mismatch: you thought you asked for a recommendation, they thought they were executing, or they decided something you had not authorised.

Here is the activation handover from the opening of this lesson, and the same handover made portable:

The second version is not longer because it is more thorough. It is longer because five things that were in the PM's head are now in the document — level, decision, evidence standard, interfaces, and one escalation condition.

It is still a fragment, not a contract. It has no time box, it does not say whether the inherited activation definition is the delegate's to challenge, and it carries one escalation condition where the Build asks for three. Do not copy it into the Build and call it done.

Accountability does not transfer with the work

You can move all three levels and still own the outcome in your area. This is the same rule as escalation in PJ-04, pointed downward. Delegating is not a way to stop carrying a consequence. It is a way to stop being the only person who can produce the reasoning.

Say this explicitly when you delegate. A delegate who believes they now own the consequence will either over-hedge or over-commit, and both are your doing.

The readiness test

Before handing over, read your own contract as if you had just joined the company. Three questions:

1. Could you say, in one sentence, what decision this changes?
2. Could you tell whether you had done enough?
3. Could you tell when you must come back early?

If any answer is no, the work is not ready. Fix your document, not the person.

Boundary

Not everything should be made portable before it is delegated.

Sometimes the whole point of handing work over is that the other person forms the frame themselves. That is how judgment develops, and it is the only way it develops. If you hand a fully specified contract to someone who is ready to frame the problem, you have given them execution work and told yourself you were growing them.

The dividing line is the one from PJ-04: consequence and reversibility. Delegate the framing when the consequence is small or reversible, and delegate execution with a full contract when it is not. When you deliberately leave the frame open, say so, so the delegate knows the ambiguity is the assignment rather than an oversight.

The same branch decides the level and what stays with you:

flowchart TD
  W["Work you are handing over"] --> C{"Consequence large,<br/>or hard to reverse?"}
  C -->|"no"| F["Delegate the framing<br/>say the ambiguity is the assignment"]
  C -->|"yes"| L{"Which level?"}
  L -->|"execute"| E["Full contract<br/>you keep the decision and the framing"]
  L -->|"recommend"| R["Full contract minus the choice<br/>you keep the decision"]
  L -->|"decide"| DD["Contract plus stated boundaries<br/>you keep the consequence"]

Every path on the right keeps something with you. That is the rule from the section above, drawn: no branch exists where the consequence leaves.

A second limit, stated plainly: a portable contract is not a substitute for competence. Perfect intent, constraints, interfaces, evidence standard, and escalation conditions handed to someone without the required skill produces a well-scoped failure. Portability makes delegation possible. It does not make it safe.

Read the Noted case if you have not already.

Take Signal 1: activation fell 11% over six weeks.

You have your PJ-02 definition of good for activation. You are not going to run this investigation yourself, because your judgment is committed elsewhere this cycle. Assume you are handing it to one person who is capable, has not been in your meetings, and has access to the product's data.

The relevant facts are in the case: activation is defined as creating a document and returning within seven days, and nobody defends the definition. The decline has not been segmented. Two changes shipped inside the window. Actor identity is missing for about 18% of events. The support lead holds recordings of customer conversations.

Your task. Write a delegation contract that a competent stranger could act on.

1. State the level: execute, recommend, or decide. Defend the choice against the consequence and reversibility of what follows.
2. Write the intent as a decision with live alternatives, not as a topic. "Find out why activation dropped" fails this test.
3. Carry your PJ-02 definition of good across as the evidence standard: what answer would be sufficient, for which population, and what would be more work than this decision justifies.
4. State the constraints: the time box, and what must not change. Include whether the inherited activation definition is theirs to challenge. That single line changes the whole assignment.
5. State the interfaces: whether they can speak to the support lead, whether they can ask engineering for a query, and what they may not commit on your behalf.
6. Write three escalation conditions as observations, not feelings. "If it looks complicated" is not one. "If the decline concentrates in a single acquisition channel" is.
7. Say who still owns the consequence, in one sentence.
8. Run the readiness test on your own document. Answer the three questions as if you had just joined.

Expect to be pushed on: whether your intent is a decision or a topic; whether the escalation conditions are observable by the delegate with the access you actually gave them; and whether you said the level out loud or left it to be inferred.

Committed to a position? Check it against what a strong answer holds

• The level is said out loud — execute, recommend, or decide — and defended from the consequence and reversibility of what follows the answer, not from how busy you are.
• The intent is the PF-01 decision with its live alternatives. "Find out why activation dropped" fails, and so does any intent that names only one acceptable conclusion.
• The evidence standard is your PJ-02 definition of good pointed at the answer: which population, which split, what would be sufficient — and an explicit stopping rule for what would be more work than the decision justifies.
• Constraints include a time box and a one-line ruling on whether the inherited activation definition may be challenged. Interfaces name the support lead and engineering by role, and say what the delegate may not commit on your behalf.
• The three escalation conditions are things the delegate can actually observe with the access granted — a split that concentrates the decline, a data gap larger than the 18% already known, a shipped change that cannot be isolated — and the consequence stays with you in one sentence, with the readiness test run honestly, including any "no".
• The most common weak move is handing over a topic with a competent person attached. It is weak because every load-bearing choice then gets guessed, you will disagree with the guesses, and you will conclude the work was not delegable when it was the handover that was not ready.

Produce artifacts/PJ-06-delegation-contract.md using the template below.

Write it for someone who was not in any of your meetings. Then read it as that person. The contract is finished when a capable stranger could produce something you would act on without a follow-up conversation.

This closes your Product Judgment phase of the Product Decision Case. It is also the first artifact written for someone other than you, which is the real test of whether the earlier ones carried reasoning or only carried conclusions.

# Delegation contract · <short name of the work>

- **Date:** <YYYY-MM-DD>
- **Product:** <product>
- **Delegated to:** <name or role>
- **Delegated by:** <name or role>
- **Level:** <execute | recommend | decide>
- **Owner of the consequence:** <name or role — this does not change by delegating>
- **Due:** <date>

## Intent

**The decision this work changes:**

<One sentence, stated as a choice. "Find out why activation dropped" is a topic
and fails this test.>

**Live alternatives:**

1. <option>
2. <option>

**Why this decision matters now:** <one or two sentences, including what happens if it is not made>

## Level, and why

<Execute, recommend, or decide — and the reason, argued from consequence and
reversibility. If the frame is being left deliberately open so the delegate can
form it, say so here explicitly, so the ambiguity reads as the assignment rather
than an oversight.>

## Evidence standard

- **What a sufficient answer contains:** <the specific claims that must be supported>
- **Population it must cover:** <a behaviour-and-context boundary>
- **What would be more work than this decision justifies:** <name the over-build you are ruling out>
- **What counts as too thin:** <name the under-build you will send back>

## Constraints

| Constraint | Detail |
|---|---|
| **Time box** | <how long, and what happens at the end of it> |
| **What must not change** | <the floors — including anything downstream that depends on this> |
| **Definitions in scope to challenge** | <which inherited definitions they may question, and which are fixed> |
| **Budget or resource** | <what they may spend, in money or in other people's time> |

## Interfaces

| They may | Detail |
|---|---|
| **Talk to** | <named people, and for what> |
| **Request** | <queries, data access, design time — from whom> |
| **Commit** | <what they can agree to on your behalf> |
| **Not commit** | <what they must not agree to, including anything customer-facing> |

## Escalation conditions

Observations, not feelings. Each must be visible to the delegate with the access
listed above.

| # | Observation | What they should do | Who they come to |
|---|---|---|---|
| 1 | <observable> | <pause / flag / bring options> | <name or role> |
| 2 | <observable> | <…> | <…> |
| 3 | <observable> | <…> | <…> |

## Readiness test

Answered as if you had just joined the company and read only this document:

1. **What decision does this work change?** <one sentence>
2. **How would I know I had done enough?** <one sentence>
3. **When must I come back early?** <one sentence>

<If any of the three cannot be answered from the document alone, fix the
document before sending it.>

## Gaps

<Everything marked `<unknown>` above, listed as open questions with who could
close them. Most of these are yours to close, not the delegate's.>