Tool 12 of 32 · an afternoon

Role-Deliverable Differential

A never-agreed role and a struggling person wear the same face. This tells them apart, and it tests the role's definition before any person is tested.

Stage 1 during Pattern, written separately by the person in the role and the person the role reports to. Stage 2 only after those sentences agree, on a request small enough to return inside the diagnosis window.

What it is for

To tell a role that was never defined the same way twice from a person who cannot deliver the role, by testing the definition before any person is tested.

The failure it catches

Two constraints wear the same face. A seat that cannot perform its role, and a role that was never defined the same way twice. No framework, incentive or process fixes the first. Only the first justifies putting the seat on the table. Testing the person first against a deliverable nobody agreed on measures nothing.

Why it works

A material gap between two privately written sentences is a definition problem, and it stops the probe. Only an agreed deliverable is a fair test. A clean, small request then classifies what comes back, so a redirect or an empty outsource can be read without seniority, stake or reputation talking over it.

How to run it

  1. Stage 1. The person in the role writes one sentence: the role's core deliverable, the thing that, if they stopped producing it, would be the gap everyone felt. The person the role reports to writes the same sentence about that role, separately.
  2. If the two sentences describe different jobs, stop. That is a definition problem. Write the role down properly, one page, and re-run later. There is no seat verdict, because there is nothing agreed to measure it against.
  3. Stage 2, only once the sentences agree. Hand the person a clean, small, unambiguous request for that agreed deliverable, something entirely theirs, with a clear shape and a fair date, sized so it can return inside the diagnosis window.
  4. Classify what comes back: delivery, even imperfect delivery; a redirect into someone else's deliverable; or work sent out with nothing coming back.
  5. Where an honest small request cannot return by decision day, do not stall the later verdict. Set the seat's line in the sand instead: written success and failure for the seat, a date, and next steps pre-agreed for both readings.

How to read the result

A Stage 1 gap is a system problem. No seat verdict is permitted. Delivery, even imperfect, tells you the role works and the system around it is the constraint. A redirect, or work sent out with nothing coming back, twice in a row against an agreed definition, tells you the role itself needs attention. Seniority, stake and reputation do not override the result. A role that needs attention is a starting point, not a verdict on a person. Most role problems resolve through clearer expectations, training, proper support, or moving responsibilities toward what the person is genuinely strong at. Replacing someone is a last resort, and in our experience it is rarely where these things land. A founder seat that fails Stage 2 and cannot be re-seated is a hard condition for the Savability Test.

How to run it well
  • Never run either stage as a public test. It is a private reading that informs how to help, not a trap.
  • If what came back is ambiguous, the first suspect is the request, not the seat. Rebuild the request once if it was not genuinely clean, small and theirs alone.
Where it breaks
  • The request must truly be clean, small and theirs alone, or a redirect is ambiguous and the reading is worthless.
  • Never run either stage as a public test.
  • Skipping the definition stage to reach a verdict faster is exactly the mistake the first version of this tool made. We rebuilt it because of that.
What would prove it wrong

A person who passes Stage 1, deflects twice at Stage 2, and then performs the role reliably under a changed system would mean the differential still under-detects system causes.

What we watch

Whether Stage 1 gaps that get a written role then clear at Stage 2, and whether twice-deflected seats against an agreed definition stay unable to produce the deliverable.

Ask yourself
  • If the person in the role and the person they report to each wrote the role's core deliverable in one sentence, would those sentences describe the same job?
  • Has that deliverable ever been written down on one page, or does it live only in conversation?
  • The last time a clean, small request for that agreed deliverable was made, what came back: the thing asked for, a redirect, or nothing?
  • Would you run that request in front of the person's team, or only as a private reading?

Feeds: Savability Test

Get the toolkit