elliot-stack 1.0.29 → 1.0.33

package/skills/estack-leadership-coach/frameworks/delegation/phases/5-monitoring.md

@@ -0,0 +1,134 @@
+# Phase 5 — Set Monitoring Checkpoints
+
+<primary_outcome>
+By the end of this phase you have a named check-in schedule on the user's calendar (or written down with specific dates) — calibrated to the TRM rating from Phase 2 — with each check-in saying what it covers. The schedule is in the brief artifact and the user knows what their *energy* in those check-ins should look like. "I'll check in when I need to" is not an output. Specific dates and named focus areas are.
+</primary_outcome>
+
+Monitoring is what separates delegation from abdication. Grove (Ch 12): *"The presence or absence of monitoring, as we've said before, is the difference between a supervisor's delegating a task and abdicating it."* The presence of agreed checkpoints — before the user walks away from the handoff — is what makes the difference.
+
+The user's instinct here often skews in one of two directions: either they hover anxiously (which signals distrust and erodes the ownership being built) or they go dark (which signals abandonment and produces drift). Neither is monitoring. Your job is to coach them into the third option: a calibrated schedule with intentional energy.
+
+---
+
+## Ask 1–3 questions, then wait
+
+1. When do you plan to check in?
+2. What will each check-in actually cover?
+3. *(If TRM is Low)* What's the earliest you can do an alignment check — within the first 20% of the timeline?
+
+If the user says "I'll check in when I need to" or "I'll let them figure it out":
+
+> 🚩 Agreed checkpoints *before you walk away* are what separate delegation from abdication. Without them, you either hover anxiously or go dark — both of which undermine the person doing the work. Set the schedule now, while you're both in the room.
+
+**Flat-team adaptation:** Reframe "monitoring" as "sync points." In flat teams, check-ins are bidirectional — the owner reports on progress, and the user reports on the status of reciprocal commitments from Phase 4 ⑥. Ask: *"When will you sync up, and what will each side report on?"* Each check-in covers both the work *and* the user's commitments back to the owner.
+
+---
+
+## The staged checkpoint model — calibrated to TRM
+
+Three touchpoints, with the cadence tuned to the TRM rating from Phase 2.
+
+| TRM | Checkpoint cadence |
+|---|---|
+| **Low** | Early (within ~20% of timeline) + midpoint + final |
+| **Medium** | Midpoint + final |
+| **High** | Single milestone touchpoint or just final delivery |
+
+Grove's rule (paraphrased from Ch 4 on one-on-one cadence): as task-relevant maturity goes up, you monitor less often. His direct framing is that one-on-ones should be frequent — *"once a week"* — with a subordinate inexperienced in a specific situation, and less frequent — *"perhaps once every few weeks"* — with an experienced veteran. The progression is the point: a Low-TRM owner who never moves to fewer check-ins is a signal that the user isn't actually developing them.
+
+### What each checkpoint is for
+
+**Early check-in** — *not to see output. To verify alignment.*
+
+Ask the owner: *"What's your approach? What decisions have you made? Where might you get stuck?"*
+
+Catching misalignment here is cheap. At delivery, it's expensive. The early check-in is the cheapest insurance against rework on the entire project.
+
+**Midpoint review** — *look at rough work-in-progress, not polished output.*
+
+Intervene at the lowest-value stage. Review drafts, not finals. Changes are cheapest before the most work has been invested. Asking to see a draft signals trust ("I'm not going to redo this — I want to course-correct early"). Waiting for the final signals either trust or absence — and the owner can't tell which.
+
+**Final delivery** — *evaluate against the success criteria defined in Phase 4.*
+
+Not against the user's gut feel in the moment. Against the externalized standard. If the standard is being moved at the final review, the standard was vague in Phase 4 — go back.
+
+---
+
+## The energy of check-ins matters (Van Edwards, *Cues*)
+
+Leaders who monitor anxiously — nervous questions, worst-case framing, micro-adjustments — signal that they don't believe the owner can handle it. This erodes the ownership being built in Phases 3 and 4. The owner reads the anxiety as evidence of being doubted, even if the user genuinely doesn't doubt them.
+
+Check-ins should project **calm confidence**. The user is gathering information, not managing their own anxiety. The distinction is felt by the owner, not described.
+
+**Trust is a cue, not a conclusion.** The user signals it deliberately *before* they feel it, not after the owner has earned it. The way the user shows up in check-ins tells the owner how much the user believes in them — before any result comes in. A Low-TRM owner needs the trust cue more, not less, because they have less evidence to draw on themselves.
+
+Practical applications:
+
+- Open the check-in by acknowledging what's going well, not what's missing
+- Ask open-ended questions ("How is it going?") before closed ones ("Did you hit the milestone?")
+- Don't open with the worst-case scenario the user is privately worried about
+- Don't end the check-in with "let me know if anything comes up" — that's an invitation to escalate everything. End with "next sync is [date], and I'll have [X] ready for you by then."
+
+---
+
+## Use monitoring as teaching — not as correction
+
+When work comes back below the bar, resist the urge to fix it. Fixing builds dependence, not capability. Be specific about the gap and explain *why*:
+
+> *"The summary leads with methodology — I'd rather it lead with the recommendation. Our audience is time-constrained and needs the conclusion first. Try it that way."*
+
+The structure of teaching feedback:
+
+1. **The specific gap** — what's actually different from the standard, not "this isn't quite there"
+2. **The principle behind it** — why the change matters, in business terms
+3. **The next move** — what to try, owned by the owner, not by the user
+
+This is the difference between *building taste* (which compounds over time, raises the owner's TRM, and reduces future check-ins) and *correcting output* (which produces this version but doesn't change the next one).
+
+---
+
+## Real-world case: the customer pays the tuition
+
+In the Foreword to *High Output Management*, Ben Horowitz recounts an exchange with an associate whose subordinate had turned in poor work. The associate's reaction was *"He has to make his own mistakes. That's how he learns!"* Horowitz's response, quoting Grove's logic back at him: *"The problem with this is that the subordinate's tuition is paid by his customers. And that is absolutely wrong."* The point is structural, not motivational — a leader who waits until final delivery to surface concerns has, by then, already forced the customer (internal or external) to absorb the cost of the gap.
+
+This is the same economic logic that makes the midpoint draft review cheaper than the final review. Grove's framing in Chapter 12 is direct: *"The presence or absence of monitoring, as we've said before, is the difference between a supervisor's delegating a task and abdicating it."* Intervening on a rough draft costs the owner a revision; intervening at the final costs the owner the project — and the customer pays the difference. Asking to see work-in-progress is the cheapest insurance the user has, and it signals trust ("I am invested early") rather than distrust ("I am inspecting at the end").
+
+Source: [Grove — *High Output Management*](../../../references/grove_high-output-management.md), Foreword (Horowitz) and Chapter 12.
+
+---
+
+## Real-world case: the first 15 seconds — the Shark Tank pitch study
+
+Van Edwards' team coded 495 Shark Tank pitches for entrance, first impression, eye contact, smiling, interactivity, and hand gestures, then mapped those cues against deal outcomes. The biggest differentiator between successful and unsuccessful pitches was the opening seconds: successful pitchers showed their hands and used a hand greeting on entry ("Hey sharks, good morning"); unsuccessful ones hid their hands in pockets, behind their backs, or behind props. Van Edwards' framing of why this matters: *"There are two questions that humans ask themselves about the person they're with, and this happens immediately in every interaction. … The first question they ask is, 'Can I trust you?'"* And: *"The very second question they ask is, 'Can I rely on you?'"* The cues sent in the first moments are how the other person answers both.
+
+The same dynamic governs a check-in. The owner is reading the user's opening cues — the hands, the greeting, the first sentence — to answer "Can I trust this person with my honest status?" before any feedback is given. A check-in opened with anxious eyes and a closed posture, even paired with warm words, signals doubt; an open greeting and a question about how it is going signals belief. The user is broadcasting the trust answer in the first 15 seconds whether they mean to or not.
+
+Source: [Van Edwards — *Cues*](../../../references/van-edwards_cues.md), drawn from the Shark Tank coding study and the two-question model (Lewis Howes Ep. 1231; Roger Dooley *Brainfluence* interview).
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't accept "I'll check in when I need to."** Calendar dates or written cadence. That's the bar.
+- **Don't recommend a cadence that doesn't match TRM.** A High-TRM owner with weekly micro-check-ins is being smothered. A Low-TRM owner with only a final review is being abandoned.
+- **Don't skip the energy conversation.** The cadence matters; the energy matters more. A weekly check-in with warm energy outperforms a monthly check-in with anxious energy.
+- **Don't structure check-ins around the user's anxiety.** If the user wants to check in three times a week because *they're* worried, that's the user's problem to manage — not the owner's calendar.
+
+---
+
+## Phase 5 is complete when
+
+- A specific cadence is named (Early + Midpoint + Final, or Midpoint + Final, or Single touchpoint)
+- Each check-in has a date (or a clear trigger — "after milestone X")
+- Each check-in has a named focus (alignment / draft review / final eval / reciprocal commitments)
+- The user has acknowledged the energy they want to bring to the check-ins
+- In a flat team: each check-in covers both the work *and* the user's reciprocal commitments
+
+When all of those are true, move to Phase 6.
+
+---
+
+> **Going deeper.** Everything you need to coach this section is above. If the user asks where this comes from, or you need a more detailed take, load:
+> - [Grove — *High Output Management*](../../../references/grove_high-output-management.md) — staged check-ins, midpoint review rule, monitoring frequency
+> - [Van Edwards — *Cues*](../../../references/van-edwards_cues.md) — warm cue research, "trust is a cue, not a conclusion"
+> - [Doerr — *Measure What Matters*](../../../references/doerr_measure-what-matters.md) — periodic OKR grading cadence and the 5-question CFR check-in script

package/skills/estack-leadership-coach/frameworks/delegation/phases/6-reverse-delegation.md

@@ -0,0 +1,118 @@
+# Phase 6 — Reverse Delegation Audit
+
+<primary_outcome>
+By the end of this phase you have a named protocol for what the owner does when they hit a roadblock — preventing the work (the "monkey") from quietly jumping back to the user's back. The protocol is specific: what the owner does *first*, what they bring to the user, what the user will and will not take back on. "They'll come to me if they get stuck" is not a protocol. A specific structure is.
+</primary_outcome>
+
+This is the shortest phase, and the most commonly skipped. It's also the phase that determines whether the delegation actually sticks once execution starts. Most delegations succeed at handoff and then quietly unravel in the first roadblock, because the user — being responsive, being helpful — takes the problem back the first time it surfaces. The work returns to the user's plate one piece at a time, until they're effectively doing it again.
+
+---
+
+## Ask 1–3 questions, then wait
+
+1. When they hit a roadblock, what do you want them to do?
+2. What's the first move the owner takes before bringing it to you?
+3. What will you say to them when they bring a problem instead of a proposed solution?
+
+If they describe a setup where they'll be the default next-move:
+
+> 🚩 Watch out for the monkey transfer. When they bring you a problem, your job is to help them find *their* next action — not to take the problem yourself. You can advise, coach, unlock resources — but keep ownership where it belongs.
+
+---
+
+## The monkey problem (Oncken & Wass, HBR 1974)
+
+The classic *Harvard Business Review* article by William Oncken Jr. and Donald Wass introduced the "monkey on the back" metaphor that still names the dynamic better than anything since.
+
+A **monkey** is the next move in any task. Every time someone brings the user a problem and the user responds with *"Let me think about that,"* the monkey jumps from the owner's back to the user's. The user becomes the bottleneck. The owner waits on the user. The work — which the user thought they'd delegated — is now sitting on the user's plate again.
+
+Multiply this by every person the user has delegated to, and the user's calendar fills with other people's monkeys. The user is busy, the owners are blocked, and the work isn't moving.
+
+### Warning signs the monkey has transferred
+
+These are diagnostic, not theoretical. If any of these are true, the user is collecting monkeys:
+
+- The user is following up on tasks they assigned (the owner should be following up)
+- People are "waiting on the user" before they can move
+- The user's calendar fills with other people's urgencies
+- The user is making decisions inside the scope of a delegated authority level
+- The user is the only person who knows the status of work the user delegated
+
+If the user says any of those during this phase, the protocol they're about to build *must* address the dynamic that produced them.
+
+---
+
+## The protocol for keeping monkeys where they belong
+
+Coach the user to define a specific structure for how roadblocks come back to them. The structure has three parts:
+
+### Part 1 — What the owner does first
+
+Before bringing anything to the user, the owner should do at least one of these:
+
+- Identify two options and a recommendation between them
+- State what they'd do if the user weren't available
+- Name the specific constraint they can't move on their own
+
+This converts the conversation from *"here's a problem"* to *"here's a decision I'd like your input on."* The first is a transfer. The second is a consultation.
+
+### Part 2 — What the user does in response
+
+When the owner brings the work-up, the user's response is structured. Three questions, in order:
+
+1. **What do you think the options are?**
+2. **What would you do if I weren't here?**
+3. **What do you need from me to make the call yourself?**
+
+These three questions are not rhetorical. They are the script. The user can advise, coach, unlock resources, share judgment — but the user does not take the next action. The next action stays with the owner.
+
+### Part 3 — What the user will not do
+
+The protocol works only if the user names — out loud, in advance — the moves they will *not* take. Specific examples:
+
+- *"I won't say 'let me think about it' — if I'm not ready to give input, I'll set a time to get back to you."*
+- *"I won't make the call myself unless the authority level explicitly requires it."*
+- *"I won't take the conversation to a stakeholder unless that's an agreed-upon reciprocal commitment."*
+
+These are the moves that *feel* helpful and *are* the mechanism by which the work returns to the user's plate.
+
+---
+
+## Real-world case: Jones in the hallway — how "let me think about it" transfers the monkey
+
+Oncken and Wass open the article with a deceptively ordinary scene. "Let us imagine that a manager is walking down the hall and that he notices one of his subordinates, Jones, coming his way. When the two meet, Jones greets the manager with, 'Good morning. By the way, we've got a problem.'" The manager knows enough to get involved but not enough to decide on the spot, so he says, "Let me think about it, and I'll let you know." The monkey leaps. From that moment on, as Oncken and Wass put it, "the manager has voluntarily assumed a position subordinate to his subordinate" — he has accepted a responsibility from Jones and promised her a progress report. Jones later "cheerily" asks, "How's it coming?" — which the authors label, drily, "supervision."
+
+The article catalogs three more parting lines that produce the same transfer: *"Fine. Send me a memo on that"* (the memo lands in the manager's in-basket — next move his), *"Just let me know how I can help"* (the subordinate can't proceed without approval — next move his), and *"I will draw up an initial draft for discussion with you"* (the subordinate is immobilized until the manager drafts). The structural fix is the test the authors install: after every encounter, ask whose move is next. If the answer is the manager's, the monkey has jumped. Source: [Oncken & Wass — HBR 1974](../../../references/oncken-wass_monkeys-hbr-1974.md)
+
+---
+
+## Real-world case: Sixty screaming monkeys and the Monday-morning hand-back
+
+Oncken and Wass describe what accumulation looks like for a responsive manager with four subordinates who each transfer three monkeys per day. By Friday he has acquired sixty. The article shows him closing his office door late Friday afternoon while subordinates wait outside, then arriving Saturday morning to catch up — only to see his subordinates playing golf across from his office window. As the authors put it, "He now sees, with the clarity of a revelation on a mountaintop, that the more he gets caught up, the more he will fall behind." He now knows who is really working for whom.
+
+The structural fix arrives Monday. The manager calls each subordinate in one by one. "The purpose of each interview is to take a monkey, place it on the desk between them, and figure out together how the next move might conceivably be the subordinate's." He installs the ground rule out loud: "At no time while I am helping you with this or any other problem will your problem become my problem. The instant your problem becomes mine, you no longer have a problem. I cannot help a person who hasn't got a problem." For monkeys where the subordinate's next move is elusive, he lets the monkey "sleep on the subordinate's back overnight." By 11 AM he realizes he doesn't have to close his door — the monkeys are gone, and will return "but by appointment only." The people didn't change; the routing did. Source: [Oncken & Wass — HBR 1974](../../../references/oncken-wass_monkeys-hbr-1974.md)
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't accept "they'll just come to me if they get stuck."** That's not a protocol — that's the absence of one. The work will come back to the user.
+- **Don't accept a protocol that doesn't include Part 3 (what the user won't do).** Without naming the user's non-moves, the helpful instincts will quietly recreate the bottleneck.
+- **Don't let the user write a protocol that contradicts the authority level from Phase 4 ⑤.** A Level 4 owner whose protocol says "bring everything ambiguous to me" is now operating at Level 2.
+- **Don't skip this phase because TRM is high.** High-TRM owners are *more* likely to transfer monkeys to a user who's responsive, because they trust the user's judgment and want to leverage it. Name the protocol anyway.
+
+---
+
+## Phase 6 is complete when
+
+- The user has named the three parts of the protocol: what the owner does first, what the user does in response, what the user will not do
+- The protocol is consistent with the authority level set in Phase 4 ⑤
+- The user can articulate, in plain language, the script they'll use the first time the owner brings a problem
+- The user has named at least one specific "I won't" move
+
+When all of those are true, the pre-delegation flow assembles the artifact.
+
+---
+
+> **Going deeper.** Everything you need to coach this section is above. If the user asks where this comes from, or you need a more detailed take, load:
+> - [Oncken & Wass — HBR 1974](../../../references/oncken-wass_monkeys-hbr-1974.md) — the original "Management Time: Who's Got the Monkey?" article

package/skills/estack-leadership-coach/frameworks/delegation/phases/7-diagnose.md

@@ -0,0 +1,200 @@
+# Phase 7 — Diagnose the Miss (post-mortem)
+
+<primary_outcome>
+By the end of this phase you have a written diagnosis: which of the five structural gaps caused the failure, the principle behind it, the specific moment in the prior handoff where the gap opened, the failure mode it maps to, and one corrective move. The diagnosis is delivered in the artifact template defined in the post-mortem flow file, followed by the offer to re-run the pre-delegation flow with the gap corrected.
+</primary_outcome>
+
+This phase runs when the user comes back after a delegation has already failed. The work came back broken, late, or off-target — or it never came back. The user is here for the diagnosis, not to recover the lost work.
+
+Your job is to find the *primary* structural gap that, if fixed, would have prevented the failure. Many failures have multiple co-occurring gaps; name them, but don't dilute the diagnosis by treating all of them as equal.
+
+---
+
+## Ask 1–3 questions, then wait
+
+Start with two or three of these, depending on what the user has already told you. Don't fire off all six in one turn.
+
+1. When did you first notice something was off?
+2. How did you present the work to them — did you explain the problem and why you chose them, or just hand over the task?
+3. Did they know what good looked like before they started?
+4. Did they have the authority to make the calls they needed to make?
+5. Were there checkpoints, or did you only see it at the end?
+6. *(Flat teams)* Was there one clear owner, or was it more of a shared effort?
+
+The order matters: by the time you've asked the first two or three, you usually already have a candidate gap. The rest confirm or rule it out.
+
+---
+
+## The five structural gaps — pick one as primary
+
+Map the user's answers to *one* of these. The primary gap is the one that, if fixed, would have prevented the failure. Secondary gaps may exist; surface them but don't make them the headline.
+
+### Enrollment gap
+
+The work was *assigned*, not *enrolled into*. The person did the job but didn't bring initiative, judgment, or ownership — because no one explained why it mattered or why they were chosen.
+
+**Signal phrases:**
+- "They did exactly what I asked, but they missed the spirit of it"
+- "They didn't push back on anything"
+- "They didn't bring me anything I didn't already know"
+- "They seemed like they were just executing"
+
+**Principle:** Self-determination theory (Deci & Ryan) — autonomy, competence, relatedness all need to be activated. Skipping enrollment means relatedness never landed.
+
+---
+
+### Authority gap
+
+Decision rights weren't transferred. Escalations piled up, or the owner made calls the user expected to be consulted on. Either way, the level was ambiguous.
+
+**Signal phrases:**
+- "They kept coming back to me for things I thought they could decide"
+- "They made a call I would not have made"
+- "I kept getting pulled in mid-execution"
+- "They were waiting on me for things I didn't know they were waiting on"
+
+**Principle:** Authority level needs to be named (Phase 4 ⑤). The owner assumed one level; the user assumed another. Unnamed authority is the most common source of mid-execution friction.
+
+---
+
+### Context gap
+
+The *why* was missing. The work was technically correct but strategically off. The owner couldn't make good tradeoffs when conditions shifted, because they didn't understand the purpose.
+
+**Signal phrases:**
+- "It's technically what I asked for but it's wrong"
+- "They didn't catch [something obvious to anyone who understood the situation]"
+- "It would have been right if [some context the owner didn't have]"
+
+**Principle:** Without context, people execute the letter and miss the spirit. The brief's ② (Why this matters) wasn't filled in, or wasn't delivered in the enrollment conversation.
+
+---
+
+### Success criteria gap
+
+The user knew what good looked like; the owner didn't. The standard lived in the user's head. The work came back below the bar — but the bar was never externalized.
+
+**Signal phrases:**
+- "I knew it when I saw it, but they couldn't have known"
+- "It's not bad, it's just not what I had in mind"
+- "I'd want it more [adjective] — but I never said that"
+- "The format/tone/length is wrong"
+
+**Principle:** Hormozi's STAR #2 ("define what done looks like by behavior or outcome") / Sullivan's Impact Filter. If the standard wasn't externalized as a specific behavior or outcome before work began, the user was the only one who knew it.
+
+---
+
+### Accountability diffusion *(flat teams only)*
+
+Nobody failed; the work just didn't get done. Or it got done by three people and none of them knew the other two were also doing it. Ownership was "shared" or informally understood rather than explicitly claimed by one person.
+
+**Signal phrases:**
+- "We were all pitching in on it"
+- "It was a team effort"
+- "I thought [other person] was handling that part"
+- "It just kind of fell through"
+
+**Principle:** Work that belongs to "everyone" belongs to no one. One person, one outcome, named out loud — even in flat teams. Diffusion is the most common flat-team failure mode, and it's structurally different from the other four because it predates the handoff entirely.
+
+---
+
+## Full failure mode reference table
+
+Once the primary gap is named, map it to one of these failure modes for the diagnosis artifact:
+
+| Failure mode | What it looks like | Root cause |
+|---|---|---|
+| **Abdication** | Handed off without structure; work comes back broken | Missing brief + no monitoring plan |
+| **Skipped enrollment** | Person executes competently but without initiative or ownership | Task was assigned, not enrolled — no purpose framing, no invitation |
+| **Accountability diffusion** | Work stalls or drifts; nobody dropped it but nobody drove it | Ownership was shared or informal — no single person explicitly claimed it |
+| **Micromanaging** | Hovering, re-doing work, daily updates untied to milestones | Vague success criteria upfront; the user is trying to fix at handoff what should have been fixed in the brief |
+| **Monkey transfer** | The user is following up on work they assigned | Didn't define the owner's next action when they escalated |
+| **Vague success criteria** | Deliverable clear; standard wasn't | Taste not externalized before work began |
+| **Wrong TRM calibration** | Over-trusted on unfamiliar task, or smothered an expert | Applied general impression to a task-specific decision |
+| **Implicit authority** | One party made a call the other expected to be consulted on | Authority level never named |
+| **Keeping interesting work** | Delegated routine; held strategic / creative | Identity fused with execution |
+
+When you write the diagnosis, name the failure mode by its row label. This gives the user a vocabulary for the pattern that they can use the next time.
+
+---
+
+## The corrective move — structural, not relational
+
+Once the primary gap is named, the corrective move is the structural fix. **Don't recommend "have a talk with them"** — that's a deflection, not a fix. The structural fixes that actually prevent recurrence:
+
+| Gap | Structural corrective move |
+|---|---|
+| Enrollment | Run the four-move enrollment conversation (Phase 3) before the brief is shared next time. Specifically, name "why you" with concrete evidence. |
+| Authority | Name the authority level explicitly using the 1–5 scale (Phase 4 ⑤). Write it in the brief. State it in the sit-down conversation. |
+| Context | Fill in the brief's ② (Why this matters) in writing. Deliver it as part of the enrollment conversation. |
+| Success criteria | Name the specific behavior or outcome that defines done (Hormozi STAR #2), or run the Sullivan Impact Filter. Externalize the standard *before* work begins. |
+| Accountability diffusion *(flat)* | One owner. One outcome. Stated out loud. Reciprocal commitments named (Phase 4 ⑥). |
+
+---
+
+## Real-world case: Nicole Wipp — the first-hire failure that was actually a clarity failure
+
+Attorney Nicole Wipp opened her own law firm during the 2008 recession and ran herself into the ground at 80–100 hours a week as a solo practitioner, still not clearing six figures. Her first attempt at hiring failed — the obvious read was "the hire didn't work out." Sullivan and Hardy's diagnosis was the opposite: the hire failed because *Nicole had not yet defined the role's specific results clearly enough for anyone to succeed in it*. The standard for "done" lived in her head; the new Who walked in blind. Only after that first painful miss did Nicole sharpen her vision precisely enough that subsequent hires could execute autonomously.
+
+The proof landed during COVID-19: with Nicole stranded in Hawaii and her team in Michigan, the firm completed a full operational transition for vulnerable elderly clients with Nicole only providing the vision — the team owned the how. The lesson for Phase 7: when a delegation fails and the first instinct is "they dropped the ball," run the diagnostic the other direction first. The bar usually wasn't externalized. Fixing the next handoff is a brief problem (write the Impact Filter's Success Criteria), not a personnel problem.
+
+Source: [Sullivan & Hardy — *Who Not How*](../../../references/sullivan_who-not-how.md)
+
+---
+
+## Real-world case: Sanchez — "raised dependents, not leaders" (Enrollment + decision-bottleneck failure)
+
+Codie Sanchez's most common diagnostic for delegation failure isn't that the work was wrong — it's that the founder accidentally trained the team to wait for them. Two of her framings, taken from her YouTube shorts, land directly on the Phase 7 *Enrollment gap* and on the broader pattern where the user becomes the bottleneck without realizing it.
+
+From *The 3 Jobs Of A CEO*: *"Your entire job is to hire people better than you at what they do, then get out of their way. And if you're still in the weeds doing everything, something is wrong. It's either A, you hired the wrong person, or B, you haven't set them up to actually do the job. As Warren Buffett says, don't get a dog and then do the barking."* And later in the same video: *"If everyone has to call you every time something small comes up, the vision isn't clear enough. And that means you kept the strategy in here instead of telling it to the company."* That second line is the Phase 7 *Context gap* in one sentence.
+
+The deeper Sanchez principle is from *Pay Won't Fix Performance*: when work comes back competent but soulless, the lever is not money — it is enrollment. *"Instead of when performance dips, reaching for money or perks, you just fire bad bosses. You tell your employee exactly why you they're your best. You give them ownership over something that matters. You let them make real decisions without somebody over their shoulder yapping. You show them where they're going next, because people don't just want to be paid, they want to matter."* That is the four-move enrollment conversation (Phase 3) restated as a post-mortem corrective.
+
+Use this case during coaching when the user's diagnostic answers point toward Enrollment gap or toward "they kept coming back to me for small things" — Sanchez's framing reframes the failure from a *team* problem ("they're dependent") to a *system* problem the user owns ("I either hired the wrong person or didn't set them up").
+
+Source: [Sanchez — *Main Street Millionaire* (and related video content)](../../../references/sanchez_main-street-millionaire.md), drawn from *The 3 Jobs Of A CEO* and *Pay Won't Fix Performance*.
+
+---
+
+## Source gap acknowledged: accountability diffusion in flat / co-founder teams
+
+The vault still does not hold a verified case study of accountability diffusion on a flat / co-founder team specifically. The Sanchez reference was substantially deepened in May 2026 with 11 YouTube short transcripts on hiring, vision, motivation, and decision-tiering — but none of those videos address flat-team, peer-level, or co-founder dynamics where no one has positional authority over anyone else.
+
+The structural illustration to use during coaching: when a flat team says "we were all pitching in on it" or "I thought [other person] was handling that part," the failure is not effort, skill, or motivation — it is that no single person had standing to make the in-flight calls. The corrective move is structural, not motivational: one named owner, one named outcome, reciprocal commitments stated out loud (Phase 4 ⑥). Acknowledge to the user that the vault is still being populated with flat-team case material; offer to coach from the principle and run the four-question diagnostic against their actual situation.
+
+Source gap: see [Sanchez — *Main Street Millionaire*](../../../references/sanchez_main-street-millionaire.md) "Known gaps" section, item 4 (co-founder / flat-team dynamics), for what is still missing and which additional sources would close it.
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't diagnose before asking the diagnostic questions.** It's tempting to pattern-match on the first sentence the user says. Run the questions — the surface story usually hides the actual gap.
+- **Don't pick the first gap that fits.** Multiple gaps often co-occur. Name the *primary* one — the one that, if fixed, would have prevented the failure.
+- **Don't recommend "talk to them" as the corrective move.** Structural fix only. Specific brief element, specific authority level, specific check-in.
+- **Don't make the diagnosis about the owner's character.** Almost every delegation failure is structural, not character-based. If you're building a case against the owner, you've drifted.
+- **Don't deliver the diagnosis without the offer to re-run pre-delegation.** The offer is the bridge from understanding-the-miss to actually-fixing-it.
+
+---
+
+## Phase 7 is complete when
+
+- One of the five structural gaps is named as the primary cause
+- A specific moment or omission in the prior handoff is identified as where the gap opened
+- The failure mode is named from the table
+- A structural corrective move is named — not "talk to them," but a specific brief element / authority level / check-in
+- Secondary gaps (if any) are noted but not made the headline
+- The diagnosis is delivered using the post-mortem artifact template
+- The offer to re-run the pre-delegation flow is made
+
+When all of those are true, the post-mortem flow assembles the artifact and delivers it.
+
+---
+
+> **Going deeper.** Everything you need to coach this section is above. If the user asks where this comes from, or you need a more detailed take, load:
+> - [Grove — *High Output Management*](../../../references/grove_high-output-management.md) — abdication, monitoring, TRM
+> - [Gerber — *The E-Myth Revisited*](../../../references/gerber_e-myth-revisited.md) — management by abdication
+> - [Hormozi (Alex) — Team Follow-Through (5 STAR)](../../../references/hormozi-alex_followthrough.md) — 5 reasons follow-through fails (STAR diagnostic ladder)
+> - [Sullivan — *Who Not How*](../../../references/sullivan_who-not-how.md) — Impact Filter for success criteria
+> - [Oncken & Wass — HBR 1974](../../../references/oncken-wass_monkeys-hbr-1974.md) — monkey transfer
+> - [Deci & Ryan — Self-Determination Theory](../../../references/deci-ryan_self-determination-theory.md) — enrollment as activating autonomy / competence / relatedness
+> - [Doerr — *Measure What Matters*](../../../references/doerr_measure-what-matters.md) — vague-success-criteria diagnosis; "Goals Gone Wild" failure mode