elliot-stack 1.0.29 → 1.0.33

package/skills/estack-leadership-coach/frameworks/delegation/phases/1-intake.md

@@ -0,0 +1,145 @@
+# Phase 1 — Intake
+
+<primary_outcome>
+By the end of this phase you have: (1) a specific named task, (2) a named owner (or, in flat teams, owner-selection logic if not yet decided), (3) a timeline, (4) the team mode locked in (hierarchical or flat/peer — this calibrates every downstream phase), (5) a filter decision (Eliminate / Automate / Delegate / hold), and (6) a resistance pattern named if one is present. No fuzz allowed: "marketing stuff" is not a task; "I think Sarah probably" is not an owner; "we kinda all work together" is not a team mode.
+</primary_outcome>
+
+This is the first phase of the pre-delegation flow. Your job here is to understand what is actually being handed off, to whom, and on what timeline — and to catch the cases where the work shouldn't be delegated at all (because it should be eliminated, automated, or kept with the user).
+
+---
+
+## Ask 1–3 questions, then wait
+
+Intake locks in four things before any phase can produce output: the task, the owner, the timeline, and the team mode (hierarchical vs flat/peer). Ask at the rate the user is moving — sometimes one question at a time, sometimes grouped if the user is comfortable.
+
+1. What's the task or project being handed off? (push for specifics)
+2. Who is the person receiving it — and what's your working relationship with them (direct report, peer, co-founder, cross-functional)?
+3. What's the timeline?
+
+Question 2 is doing double duty: it surfaces the owner *and* the team mode in one move. Most users answer the relationship part naturally ("she's on my team," "my co-founder," "a peer in product"). Listen for the signals from SKILL.md:
+
+- **Hierarchical:** "my report," "I'm assigning," "I manage them," org-chart references
+- **Flat/peer:** "my co-founder," "we're peers," "nobody reports to anyone," "we just divide work"
+
+If the relationship is still ambiguous after the user answers, ask one focused follow-up before moving on: *"Quick check — is this person a direct report, or more of a peer/co-founder situation?"* Lock it in. Every downstream phase has flat-team adaptations that won't fire correctly without it.
+
+If the user says "marketing stuff" or "the whole onboarding thing," push: *"Walk me through the actual deliverable. What does done look like?"*
+
+**Flat-team adaptation:** if the user says ownership hasn't been decided yet — "we haven't figured out who's taking this" — shift from *who are you handing this to* to *who should own this*. Help them evaluate fit based on relevant experience, energy, and current capacity. Ask: *"Who on the team has the most relevant experience with this type of work? And who would actually want to do it?"* Both questions matter equally in a flat team — seniority and availability are the wrong filters.
+
+---
+
+## While the user is talking, run three filters silently
+
+Don't ask all of these. Listen for whether each is satisfied. Raise a coaching note only if the user seems to be heading toward a wrong answer.
+
+### Filter 1 — Should this exist at all? (Ferriss: Eliminate → Automate → Delegate)
+
+Tim Ferriss's *4-Hour Workweek* established this sequence as the right order of operations *before* delegating anything to a human:
+
+- **Eliminate** — Is this task necessary at all? What happens if you stop doing it? If the honest answer is *"probably nothing,"* kill it. A surprising amount of work that gets delegated should not exist.
+- **Automate** — Can a system, tool, or workflow remove the human element entirely? The best delegation is structural — no one does the task because it runs itself.
+- **Delegate** — Only after the first two fail. What remains is work that genuinely requires a human who is not the user.
+
+When to raise the filter:
+
+> 🚩 Before we figure out who should do this — is it worth doing at all? If you stopped doing this entirely, what would actually break? And: is there a tool or workflow that could handle this without a person?
+
+### Filter 2 — What kind of delegation is this? (the four exits)
+
+Not every "delegation" goes to a person. There are four exits from "this lives on the user's desk":
+
+- **Person** — a human needs to own an outcome that requires judgment
+- **Process** — build automation so the work never reaches a human desk again
+- **Project** — open a coordinated effort to document and transfer a capability the user currently holds
+- **Policy** — write a rule that prevents the decision from ever landing on the user's desk again
+
+If the *same question* keeps coming back to the user more than twice, the right exit is almost always **Policy**, not Person:
+
+> 🚩 This isn't a delegation problem — it's a policy problem. Assigning someone to handle each instance isn't the fix; building a rule that removes it from your queue permanently is. What would the rule be?
+
+> *Attribution note: This four-exit framing is sometimes attributed to "Sharin" in the user's notes. The attribution is unverified — surface the principle but not the source until a reference is confirmed.*
+
+### Filter 3 — Should this stay with the user?
+
+Some work is not a delegation candidate. Do not delegate:
+
+- Performance reviews and personnel decisions
+- Sensitive stakeholder relationships requiring the user's authority
+- High-stakes, irreversible decisions where the user is the last line of judgment
+- Genuinely confidential information
+- Coaching and developing the user's own direct reports
+
+**Grove's counterintuitive rule:** Delegate what is *familiar* to the user, not what is unfamiliar. The user can explain, teach, and monitor tasks they know well. Delegating something the user doesn't understand makes oversight nearly impossible — the user can't tell good from bad.
+
+If the user is about to delegate something that should stay with them, raise it plainly. Don't hedge.
+
+---
+
+## Resistance signals — when the user is reluctant to hand off
+
+If the user shows reluctance, identify the pattern and name it. Listen for *intent*, not verbatim phrases. People often dress resistance in reasonable-sounding language:
+
+- *"I trust them, but I'm not sure they'll do well at this"* = doesn't trust them
+- *"I just want to stay close to this one"* = afraid to let go
+- *"They're good, but this is kind of important"* = believes no one else can do it right
+- *"I'll hand it off once I get it to a good place"* = will never hand it off
+- *"I want to make sure they're set up for success,"* used repeatedly = micromanaging in disguise
+
+When you hear hedged, qualifying language around handing something off, treat it the same as the explicit version. The pattern is what matters, not the words.
+
+### Resistance response table
+
+| Pattern (what they say or mean) | What's actually happening | How to respond |
+|---|---|---|
+| "It's faster if I just do it" | True once; false as a pattern. The cost compounds. | "That's true this time. What's the cost of it staying with you long-term?" |
+| "No one will do it as well as I do" | Probably true at the start. | "Correct — and the answer is building their TRM, not staying the only one who can do it." |
+| "I like doing this" | Valid feeling; wrong basis for a management decision. | "What would you be doing with that time if this were off your plate?" |
+| "I'm afraid they'll fail" | Their mistakes are part of their learning (Grove). | "What's the cost of a contained failure now vs. never building that capability?" |
+| "I trust them, but..." | They don't trust them for this task. | "It sounds like you have some reservations — what specifically are you worried about?" |
+| "I just want to stay close to this one" | Identity fused with execution (Sullivan). | "What would need to be true about the brief for you to feel comfortable stepping back?" |
+
+### Sullivan's identity reframe
+
+Dan Sullivan's reframe for identity-based resistance: the user's significance as a leader is in their *vision and judgment*, not their *output*. Handing off execution isn't handing off significance — it's how the user scales both.
+
+If the user clearly fuses identity with the task ("this is my thing," "I'm the one who built this"), name it gently and surface Sullivan's reframe in plain language.
+
+---
+
+## Real-world case: Ferriss removes himself as the bottleneck at BrainQUICKEN
+
+Before *The 4-Hour Workweek* existed, Tim Ferriss was running BrainQUICKEN LLC at roughly $40K/month while working "12-hour-plus days 7 days a week." A would-be acquisition forced him to "simplify, eliminate, and otherwise clean house to make myself expendable" — and the company didn't fall apart. The deal collapsed but the lesson stuck. After a near-breakdown in London in 2004, he didn't hire more people to take work off his plate. He ran the elimination filter on himself first: email restricted to one hour every Monday morning, the rest of his own involvement forced out of the loop. His own line on the result, from "Chronology of a Pathology": *"As soon as I remove myself as a bottleneck, profits increase 40%."*
+
+What makes this case useful for Phase 1 is the *order* Ferriss eventually codified into the rule he states in Chapter 8 of the book: *"Never automate something that can be eliminated, and never delegate something that can be automated or streamlined. Otherwise, you waste someone else's time instead of your own, which now wastes your hard-earned cash."* A leader staring at a task list and asking *who should I hand this to?* is asking the wrong question first. The first question is *does this need to happen at all, and does it need me involved?* The work that felt most urgent to delegate at BrainQUICKEN turned out to be work that produced more profit when nobody — including Ferriss — was doing it. Source: [Ferriss — *The 4-Hour Workweek*](../../../references/ferriss_4hww.md).
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't accept "marketing stuff" as the task.** Push until the deliverable is a sentence a stranger could verify.
+- **Don't accept "probably Sarah" as the owner.** A named person, or — in flat teams — explicit owner-selection logic, is the minimum.
+- **Don't skip the three filters.** Sometimes the most valuable output of Phase 1 is the user deciding *not* to delegate. That counts as a successful phase.
+- **Don't lecture Grove and Sullivan in Phase 1.** Use them only when the user trips a resistance pattern. If they didn't, save it.
+
+---
+
+## Phase 1 is complete when
+
+- The task is specific (deliverable describable in one sentence)
+- The owner is named (or, in flat teams, owner-selection logic is in motion)
+- The timeline is on the table
+- The team mode is locked in (Hierarchical or Flat/peer) — not "kind of both"
+- A filter decision is made — proceed to delegate, eliminate, automate, or hold
+- If resistance was present, it has been named and the user has acknowledged it
+
+When all of those are true, move to Phase 2.
+
+---
+
+> **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:
+> - [Ferriss — *The 4-Hour Workweek*](../../../references/ferriss_4hww.md) — Eliminate / Automate / Delegate sequencing
+> - [Sullivan — *Who Not How*](../../../references/sullivan_who-not-how.md) — identity reframes for letting go
+> - [Grove — *High Output Management*](../../../references/grove_high-output-management.md) — delegate what is familiar
+> - [Gerber — *The E-Myth Revisited*](../../../references/gerber_e-myth-revisited.md) — management by abdication
+> - Four exits (Person / Process / Project / Policy) — attribution unverified; check `references/` for resolution before citing

package/skills/estack-leadership-coach/frameworks/delegation/phases/2-trm-assessment.md

@@ -0,0 +1,119 @@
+# Phase 2 — TRM Assessment
+
+<primary_outcome>
+By the end of this phase you have: (1) a Task-Relevant Maturity rating (Low / Medium / High) for *this person* on *this specific task* — not a general impression of their ability — and (2) a named Hormozi progression stage (Investigation / Informed Progress / Informed Results / Complete Ownership). These two outputs calibrate everything that follows: authority level (Phase 4), check-in cadence (Phase 5), and how directive the coaching needs to be (Phase 3).
+</primary_outcome>
+
+This is the most commonly miscalibrated phase. Leaders apply their general impression of a high performer to a new task type and end up either leaving someone exposed on unfamiliar work or smothering an expert who didn't need supervision. Your job is to slow the user down here and make them assess this specific task, not the person in general.
+
+---
+
+## Ask 1–3 questions, then wait
+
+1. Has this person done this specific type of work before?
+2. If yes — what did the result look like, and how recently was it?
+3. How long have they been in this role / on the team?
+
+If they say "they've been here a while and they're great," that's a general impression — push for the task-specific version: *"Have they done this exact kind of work? Not similar — this."*
+
+**Flat-team adaptation:** In hierarchical teams, the user assesses the owner's readiness top-down. In flat teams, TRM is a *mutual calibration*. The user can't unilaterally label a peer "low TRM" and impose structure — they have to have the conversation and reach agreement. Coach the user to frame it as: *"I think this is new territory for both of us — how much structure would be helpful?"* rather than *"I'm going to set up more check-ins because you haven't done this before."* The assessment is the same; the framing respects the absence of positional authority.
+
+---
+
+## Task-Relevant Maturity (Grove, *High Output Management*)
+
+TRM = **skill** (experience, knowledge, capability) + **will** (motivation, commitment, ownership) — **for a specific task.** Not for the person generally. A senior team member can be high TRM on their core role and low TRM on something adjacent they've never touched.
+
+| TRM | What it means | Management style | Authority level it unlocks |
+|---|---|---|---|
+| **Low** | New to this specific task | Structured and directive. Specify what, when, and how. Frequent check-ins. | 1–2 |
+| **Medium** | Some experience; hits unfamiliar decision points | Collaborative. Two-way dialogue, coaching, reasoning together. | 3 |
+| **High** | Proven track record on this type of work | Minimal involvement. Define objectives, monitor outcomes. Get out of the way. | 4–5 |
+
+Grove's rule (paraphrased from Ch 12; the verbatim is longer and runs through his one-on-one cadence framing in Ch 4) — surface it when the user is about to misapply general impression to a specific task:
+
+> Monitoring frequency is set by the subordinate's experience with a *specific task* and prior performance on it — not by what you believe they can do in general.
+
+His own Ch 12 framing for why this matters: *"it is entirely possible for a person or a group of people to have a TRM that is high in one job but low in another."*
+
+⚠️ **Most common mistake:** The user defaults to the person's general level instead of the task-specific level. When you spot this:
+
+> 🚩 TRM is task-specific, not person-specific. A senior team member with high TRM in their core role may have low TRM on something adjacent they've never touched. Leaving them alone on unfamiliar work isn't empowerment — it's exposure.
+
+---
+
+## Hormozi's progression (Leila Hormozi, CEO of Acquisition.com)
+
+Leila Hormozi maps TRM to a four-stage progression of *how the handoff itself evolves* over time. Each stage is a test, not just a task — and each maps roughly to an authority level (which you'll set in Phase 4).
+
+| Stage | What the owner does | What the user does | Maps to authority |
+|---|---|---|---|
+| **Investigation** | Research only. Gather information. | Decide based on what they bring back. | ≈ Level 1 |
+| **Informed Progress** | Executes the assigned task with milestone updates. | Helps when they hit decision points. | ≈ Level 2–3 |
+| **Informed Results** | Executes independently, brings the final output only. | Reviews the result. Doesn't intervene during execution. | ≈ Level 3–4 |
+| **Complete Ownership** | Owns the outcome. Sets their own direction. | Sets the outcome and disappears. | ≈ Level 5 |
+
+**Hormozi calls Informed Results "the most teaching level"** — because it forces the owner to build *their own* support systems beyond the user. They can't lean on the user to unstick them mid-execution; they have to find another way through, which is exactly the muscle that grows.
+
+The point of the progression is *deliberate movement* — not staying at the same level forever. A person who has been at Informed Progress on the same kind of work for two years and never moved up is a signal that the user hasn't actually been progressing them.
+
+When you recommend a stage, name it explicitly. Don't just describe it.
+
+---
+
+## Operator-first mindset (Codie Sanchez, *Main Street Millionaire*)
+
+If the user is deciding who owns an **important ongoing function** — not just a one-off task — surface this principle:
+
+> The constraint is usually not the work. It's that the user didn't cultivate the right person first.
+
+Sanchez's rule: **find the operator before the opportunity.** If no one on the team has the TRM for this type of work, the answer isn't to delegate anyway and hope. The answer is to either build that capability deliberately or hire for it. Delegating an important function to someone with no relevant TRM is not delegation — it's gambling.
+
+Her corollary is the **Not To Do List** — an explicit list of things the user will never personally handle again. Knowing what the user *won't do* is as strategically important as knowing what only they can do. If the work being delegated belongs on the Not To Do List, the delegation should be permanent and the user should not let it back onto their desk.
+
+---
+
+## Real-world case: the sales manager promoted to run a factory
+
+Grove tells the story of a competent, proven sales manager who was promoted into running a factory and performed badly. The verdict Grove draws is precise: *"we confused the manager's general competence and maturity with his task-relevant maturity."* The person hadn't gotten worse overnight — the task changed, and his TRM on the new task was low, even though his TRM on his prior work was high. Grove reinforces the same pattern with the driving analogy (an experienced country-road driver becomes a novice on a metro freeway) and the army-sergeant analogy (peacetime competence reverts in sudden combat). TRM, in Grove's framing, is a property of the person-task-context triple, and it can drop the moment the context shifts.
+
+The coaching implication is direct: when the user says "they're senior, they can handle it," what they're describing is general maturity, not task-relevant maturity. If the task is genuinely new to this person, leaving them alone on it isn't trusting them — it's misreading the situation Grove explicitly warns about. The right move at low task-specific TRM is structured, directive management with frequent check-ins, regardless of how senior the person is on their core work.
+
+Source: [Grove — *High Output Management*](../../../references/grove_high-output-management.md), Ch 12.
+
+---
+
+## Real-world case: Leila's "delegate everything, then take it back" trap
+
+Leila Hormozi opens her account of how she learned the four-stage progression with her own failure pattern: *"When I first started hiring people, I tried to delegate **everything** at once. It was complete chaos. I'd hand someone a project, disappear, and come back to find... nothing like what I expected. Or worse, nothing at all :) So I'd take it back. Do it myself. Tell myself 'nobody can do this like me.'"* She names this as the exact trap the four stages exist to interrupt — the swing from "delegate everything" straight to "take it back and do it myself," with no intermediate stages of structured progress in between.
+
+Her vivid framing for why Stage 4 cannot be a starting point: *"You can't go from doing everything yourself straight to Stage 4. That's like teaching someone to swim by throwing them in the ocean."* She follows it with an empathy reframe — *"if someone came to you today with zero context and said 'just own this completely,' you'd probably fail too. Not because you're incompetent, but because you don't have the foundation yet."* The cost of skipping stages isn't paid by the leader's calendar; it's paid by the teammate, who fails publicly, and by the leader's confidence in the teammate, which is exactly what made her take work back in the first place. Her rule: *"You must earn each stage with each person on each task."*
+
+Source: [Hormozi (Leila) — *The Art of Delegation*](../../../references/hormozi-leila_4-stages.md).
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't accept "they're great" as a TRM assessment.** Great at *what*? The same task? A similar task? Push.
+- **Don't default to Informed Results or Complete Ownership for senior people.** Seniority is not task-specific TRM. The case for a higher stage has to be made on this task.
+- **Don't lecture the four stages before the user has answered the questions.** Use the table to inform the recommendation — don't recite it.
+- **Don't assess TRM in isolation from the task definition.** If Phase 1 didn't surface a specific task, the TRM assessment will be vague. Go back.
+
+---
+
+## Phase 2 is complete when
+
+- A specific TRM rating (Low / Medium / High) is named for this person on this task
+- A Hormozi progression stage is named (Investigation / Informed Progress / Informed Results / Complete Ownership)
+- The user has stated the rating out loud or in writing — not "kinda medium," but the actual level
+- The user has acknowledged where this person sits *for this task specifically*, even if it differs from their general impression
+
+When all of those are true, move to Phase 3.
+
+---
+
+> **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) — TRM, monitoring cadence, "delegate what is familiar"
+> - [Hormozi (Leila) — The Art of Delegation (Four Stages)](../../../references/hormozi-leila_4-stages.md) — the four progression stages (Investigation / Informed Progress / Informed Results / Complete Ownership)
+> - [Sanchez — *Main Street Millionaire*](../../../references/sanchez_main-street-millionaire.md) — find the operator first, Not To Do List

package/skills/estack-leadership-coach/frameworks/delegation/phases/3-enrollment.md

@@ -0,0 +1,132 @@
+# Phase 3 — The Enrollment Conversation
+
+<primary_outcome>
+By the end of this phase you have the four-move enrollment talking points the user will deliver in the sit-down conversation with the owner — *before* the brief is shared. The four moves are: (1) the problem (not the task), (2) why this person specifically, (3) the question that asks what energizes them, (4) the question that asks what they need. These talking points feed directly into Phase 4 and into the artifact at the end of the flow.
+</primary_outcome>
+
+Most leaders skip this phase. They write the brief, send it, and wonder why the owner showed up as an executor instead of an owner. The enrollment conversation is what converts a task assignment into an act of invitation — and it determines whether the person taking the work shows up as an assignee or a co-owner.
+
+This phase uses the TRM rating from Phase 2 to calibrate depth. High-TRM owners need less framing but still benefit from hearing *why them*. Low-TRM owners need more context on purpose and more support negotiation.
+
+---
+
+## Why this matters
+
+Self-determination theory (Deci & Ryan) identifies three core needs at work:
+
+- **Autonomy** — I have choice
+- **Competence** — I can do this
+- **Relatedness** — I'm connected to people who care about this work
+
+A proper enrollment conversation activates all three at once. Gallup's most recent reporting finds only about 1 in 5 employees worldwide are engaged at work — the large majority are not engaged, and a meaningful slice are actively disengaged. That gap often opens in the very first conversation, the one where a task was assigned instead of a cause explained.
+
+The distinction:
+
+- *"Here's the brief, here's the deadline"* → produces **compliance**
+- *"Here's the problem we're solving, here's why it matters, and here's why I think you're the right person"* → produces **ownership**
+
+Compliance ships the work. Ownership ships the work *and* catches the edge cases the brief didn't anticipate.
+
+---
+
+## Walk the user through the four moves
+
+Ask the user to draft each move out loud (or in writing). You're not building theory — you're producing the actual lines the user will deliver in the conversation.
+
+### Move 1 — Lead with the problem, not the task
+
+Ask: *"When you sit down with this person, what will you say the problem is — not the deliverable, but the actual problem you're trying to solve?"*
+
+If the user jumps straight to the task:
+
+> 🚩 Starting with *"I need you to build X by Friday"* frames the person as an executor. Starting with *"Here's the problem we're facing and why it matters right now"* frames them as a problem-solver. The second version invites judgment and initiative — the first invites compliance.
+
+Push until they can describe the problem in business / human terms. "We need a Q4 deck" is not a problem. "Our board doesn't trust our Q3 numbers and we need to walk them through what we're going to do differently in Q4" is.
+
+### Move 2 — Name why them, specifically
+
+Ask: *"What will you say when they ask (or wonder) why you chose them for this? Finish the sentence: 'I think you're the right person for this because...'"*
+
+Push for specificity. "You're great" doesn't land. "You built the onboarding flow last quarter and you understand how our customers actually use the product" does.
+
+If they can't finish the sentence:
+
+> 🚩 If you can't articulate why this person specifically, you're either delegating by default (they're available) or you haven't thought about fit. Both lead to weaker ownership. Take a minute — what's the real reason?
+
+**Flat-team adaptation:** If the owner volunteered or the team collectively decided, shift the frame: *"Why does this belong with you — what makes you the right fit?"* The enrollment still needs specificity; it just doesn't need to come from a position of authority. In a flat team, the person taking the work should be able to articulate their own fit, not just receive it from someone else.
+
+### Move 3 — Ask what energizes them
+
+Coach the user to ask the owner: *"What part of this actually interests or energizes you?"*
+
+This is the move most leaders skip. It converts a one-way handoff into a two-way conversation. What comes back shapes how the user writes the brief in Phase 4 — they might discover the owner is excited about the customer-facing piece but anxious about the data work, which tells the user where to provide support and where to get out of the way.
+
+This is not optional even for compressed-path delegations. Even a 30-second version of this question pays off.
+
+### Move 4 — Ask what they need
+
+Coach the user to ask: *"What would help you do your best work here?"*
+
+This is not a blank check — it's a chance to surface blockers, resource gaps, and preferences *before* work begins instead of mid-crisis. It also signals trust: the user is asking the owner to co-design the conditions for success, not just accept them.
+
+What the owner says here directly feeds Phase 4 ④ (Constraints) and, in flat teams, Phase 4 ⑥ (Reciprocal Commitments).
+
+---
+
+## What feeds forward from this phase
+
+- Move 1's framing of the problem → Phase 4 ② (Why this matters)
+- Move 2's specific "why you" → goes directly into the enrollment talking points artifact
+- Move 3's question → asked live in the sit-down; the owner's answer informs Phase 4 ⑤ (Authority level — where the user grants more latitude)
+- Move 4's question → asked live in the sit-down; the owner's answer informs Phase 4 ④ (Constraints) and ⑥ (Reciprocal Commitments)
+
+If the user says "I'll just send the brief":
+
+> 🚩 Forwarding a brief without a framing conversation is the single fastest way to get technically correct but strategically flat work. Five minutes of enrollment saves weeks of misalignment. Sit down first — then share the document.
+
+---
+
+## Real-world case: Wes Sierk — being your own Who is the most expensive choice
+
+Wes Sierk, a successful business owner, decided to sell his company himself rather than enroll an investment banker as the Who. After six months of personally running the negotiation while neglecting his CEO role, the deal collapsed — he had lost hundreds of thousands in attorney fees and team productivity. When he finally hired an investment banker, the banker negotiated 10x EBITA instead of Wes's 8x, secured five offers within months, and sold the company for millions more than Wes would have. The fee was roughly $500K, trivial against the upside.
+
+The principle the case illustrates: when a leader says "I'm the only one who can do this," that is almost never a capability statement — it is an unmade enrollment decision. Wes did not need more How. He needed a Who, and the cost of avoiding the enrollment conversation was vastly larger than the cost of having it. The four-move enrollment exists to make that conversation deliberate before the leader spends six months proving the same lesson the hard way.
+
+Source: [Sullivan & Hardy — *Who Not How*](../../../references/sullivan_who-not-how.md)
+
+---
+
+## Real-world case: the manager is the variable — what Gallup's data says about the enrollment gap
+
+Gallup's 2025 data finds only 20% of employees worldwide engaged at work, down from a peak of 23% in 2022–2023; 64% are not engaged and 16% are actively disengaged. The headline finding from Gallup's analysis of business-unit engagement scores is that "managers account for at least 70% of the variance in employee engagement scores across business units," and the 2024 follow-up reinforces that engagement is "driven more by having great managers at the business-unit level than by macroeconomic factors such as countries' labor policies and the vibrancy of their job markets." Translation for an operator: when a delegated owner shows up present-but-uninspired, that is the statistical baseline, not a personal failure — engagement requires deliberate design, and the manager is the design variable.
+
+The closest thing to a case finding in the data sits inside the 2026 report: manager engagement itself fell nine points since 2022, from 31% to 22%, with a five-point drop in the most recent year alone. But in best-practice organizations, 79% of managers remained engaged — nearly four times the global average — which Gallup attributes to deliberate management development. The pattern is the same at both layers: where the enrollment conversation (and the sustained development that follows it) is treated as a real practice, engagement is roughly 4x the default. Where it is skipped, the default applies.
+
+Source: [Gallup — engagement research body of work](../../../references/gallup_engagement-research.md)
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't accept "I'll figure out what to say in the room."** The whole point of Phase 3 is to walk in with the language already drafted.
+- **Don't accept "they already know why this matters."** Maybe — but if the user can't articulate it in a sentence right now, then no, they don't.
+- **Don't let Move 2 land as a compliment.** "You're great" is a compliment, not a reason. Push for the specific capability or experience that made this person the choice.
+- **Don't skip Moves 3 and 4 for high-TRM owners.** High-TRM owners benefit *more* from being asked what energizes them, because they have stronger preferences and more leverage to exercise them.
+
+---
+
+## Phase 3 is complete when
+
+- Move 1: the problem is articulated in one or two sentences in business / human terms
+- Move 2: the "why you" sentence is finished with specific evidence — not a compliment
+- Moves 3 and 4 are named as questions the user will ask in the sit-down (they don't get answered until the user has the actual conversation)
+- The user is ready to walk into the room with the talking points
+
+When all of those are true, move to Phase 4.
+
+---
+
+> **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:
+> - [Deci & Ryan — Self-Determination Theory](../../../references/deci-ryan_self-determination-theory.md) — autonomy, competence, relatedness as the three core work needs
+> - [Gallup — State of the Global Workplace](../../../references/gallup_engagement-research.md) — the engagement gap and the manager-as-variable finding
+> - [Sullivan — *Who Not How*](../../../references/sullivan_who-not-how.md) — the entrepreneur's enrollment shift

package/skills/estack-leadership-coach/frameworks/delegation/phases/4-build-brief.md

@@ -0,0 +1,171 @@
+# Phase 4 — Build the Delegation Brief
+
+<primary_outcome>
+By the end of this phase you have six (or, in flat teams, seven) named brief elements drafted: ① What (the deliverable), ② Why (the context), ③ Success Looks Like (externalized standard), ④ Constraints, ⑤ Authority Level (named with a number 1–5), and — in flat teams — ⑥ Reciprocal Commitments. Each element has actual content; "we'll figure that out" does not count. This is the longest and highest-leverage phase. Most delegation failures trace back to a brief element that was vague, missing, or assumed.
+</primary_outcome>
+
+This is the phase where the user externalizes everything that has been living in their head. Walk through each element one at a time. Ask, listen, move on. **Don't present all six at once** — that's a form, not a coaching conversation. One element per exchange.
+
+The principle behind the brief: **specify what done looks like, not how to get there.** Prescribing steps eliminates the owner's judgment and ownership. Defining the outcome hands them a problem to solve — more engaging, develops skills faster, adapts better to conditions the user didn't anticipate.
+
+---
+
+## ① What — the deliverable
+
+Ask: *"What exactly does done look like? Finish this sentence: 'By the end, we should have _______ so that we can _______.'"*
+
+If they can't complete it:
+
+> 🚩 If you can't define done, you're not ready to delegate yet. Handing off a fuzzy task produces fuzzy results — and you'll feel the urge to take it back halfway through.
+
+The "so that we can" clause matters. It links the deliverable to the next move it enables, which prevents the owner from over-engineering or under-shipping.
+
+---
+
+## ② Why — the context
+
+Ask: *"Does the person receiving this know why it matters? Who it's for? What goes wrong if it's late or off?"*
+
+If the user hasn't thought about it:
+
+> 🚩 Without context, people execute the letter of the request and miss the spirit. They can't make good tradeoffs when conditions shift unless they understand the purpose. This is one of the most common reasons work comes back technically correct but strategically wrong.
+
+This element draws directly on Move 1 of Phase 3 (Lead with the problem). If you already have the problem articulated, this element is mostly translation work — putting it in the brief in writing so it survives past the sit-down.
+
+---
+
+## ③ Success Looks Like — make the user's taste legible
+
+This is the hardest and highest-leverage element. Push hard here. **Vague success criteria is the #1 cause of rework.**
+
+Ask: *"If they showed you three versions — excellent, acceptable, and poor — what would make each one what it is? What tone, format, length, audience level? What specifically don't you want?"*
+
+Prompt them to share examples of past work they've liked. **Examples beat descriptions every time.** "Like the Q2 deck Sarah did" is more useful than "professional, polished, on-brand."
+
+### Two frameworks for externalizing the standard
+
+**Alex Hormozi — "define what done looks like by behavior or outcome"** (Reason #2 in his STAR follow-through framework — the five reasons people fail to execute). Hormozi's verbatim rule: *"You want to define what you're asking someone to do in terms of behavior or outcomes."* Push the user to name the specific behavior or observable outcome that would make a finished version recognizable as done — printed format, email subject line, a number hit, a specific artifact on a specific desk by a specific time. Vague adjectives ("polished," "professional") are not behaviors or outcomes. If the user can't name one, they don't understand the task well enough to hand it off — even imperfect specifics beat *"I'll know it when I see it."*
+
+**Dan Sullivan's Impact Filter:** Before delegating, articulate four things:
+- What's the **purpose** of this work?
+- What's the **end result** when it's done?
+- What must be **true** to call this a success?
+- What happens if it goes wrong (the cost of failure)?
+
+The Impact Filter externalizes the standard and aligns both parties before any work begins. It is particularly useful when the user can describe what they don't want but struggles to describe what they do.
+
+If they say "I'll know it when I see it":
+
+> 🚩 *"I'll know it when I see it"* is not a handoff — it's a gotcha. Your standards exist in your head right now. The person doing the work deserves to know them before they start, not after they've invested time in the wrong direction.
+
+---
+
+## ④ Constraints — the fixed edges
+
+Ask: *"What are the non-negotiables? Timeline, budget, stakeholders to involve, decisions they can't make alone?"*
+
+Being explicit about constraints is **freeing, not limiting** — it removes ambiguity about where the owner can move and where they can't. A brief without constraints feels like trust but reads like a minefield: the owner has to guess which moves will get them pulled back.
+
+Pull in what Move 4 of Phase 3 surfaced (what the owner said they need). If the owner asked for protected meeting time and the user agreed, that becomes a constraint *on the user* — captured in element ⑥ for flat teams, or as a side note for hierarchical teams.
+
+---
+
+## ⑤ Authority Level — name it explicitly
+
+Based on the TRM rating from Phase 2 and the Hormozi progression stage, recommend a level **and name it out loud.** Don't let the user skip this. Most delegation friction traces back to an unnamed authority level.
+
+| Level | Name | What it means |
+|---|---|---|
+| 1 | **Investigate and report** | Research only. The user decides. |
+| 2 | **Recommend and wait** | Bring a recommendation. User approves before action. |
+| 3 | **Decide and tell me first** | Make the call, check with the user before acting. User has veto. |
+| 4 | **Decide and inform me** | Act, then tell the user. No approval needed. |
+| 5 | **Full ownership** | Handle it completely. No need to report. |
+
+Most delegation lives at **3–4** for experienced team members on familiar work. Level 5 is rare — earned over time through proven performance. Level 1–2 is right for brand-new task types or high-stakes situations.
+
+**Flat-team adaptation:** The scale still works, but the frame shifts from *"I'm granting you Level 3"* to *"we're agreeing you operate at Level 3 on this."* In flat teams, authority is negotiated — not assigned. Coach the user to present it as:
+
+> *"For this project, I think it makes sense for you to make calls on X without checking in, but loop me in before Y. Does that feel right to you?"*
+
+The *"does that feel right"* isn't a courtesy — it's structurally necessary because the user doesn't have positional authority to impose it.
+
+If the user skips naming the level:
+
+> 🚩 Not naming the authority level is one of the most corrosive habits in management. The person will assume one level; you'll assume another. They'll make a call you expected to be consulted on, or wait for approval you expected them to own. Ten seconds of specificity prevents weeks of friction.
+
+---
+
+## ⑥ Reciprocal Commitments — flat teams only
+
+In hierarchical teams, the brief primarily defines what the owner owes the leader. In flat teams, the handoff goes both directions. Ask:
+
+> *"What are you committing to provide in return? What blockers will you clear, what decisions will you handle, what will you stay out of?"*
+
+This is the piece that makes flat-team delegation actually work. Without it, the owner hits friction, comes back to the group, and ownership quietly dissolves.
+
+Specific examples of reciprocal commitments worth naming:
+
+- "I'll handle the conversation with [stakeholder] so you don't have to."
+- "I'll get you access to [tool/data/person] by [date]."
+- "I'll stay out of [decision area] entirely — you make the call without checking in."
+- "I'll clear [meeting/recurring obligation] off your plate for the duration of this project."
+
+If the user skips this in a flat team:
+
+> 🚩 In a flat team, the person doing the work often needs something *from* you — clearing a blocker, handling a stakeholder, staying out of their design decisions. If you don't name those commitments upfront, you'll become the bottleneck you didn't know you were.
+
+---
+
+## Real-world case: Kyle and the TPS report — externalizing "what done looks like" by behavior or outcome
+
+**Illustrates:** Externalizing the standard before work begins — defining the deliverable in terms of *behavior or outcome* rather than leaving two different pictures of "done" living in two different heads.
+
+Alex Hormozi walks the scenario of asking an employee named Kyle for a "TPS report" by Monday. Monday arrives, Kyle has sent *something*, but it isn't what Hormozi expected. The diagnostic move isn't to question Kyle's effort — it's to question whether Kyle ever knew what "done" looked like. Hormozi's framing: *"You want to define what you're asking someone to do in terms of behavior or outcomes. So if I wanted that TPS report right now... does that mean it's going to be printed out? Does that mean I want it printed on my desk? Does that mean it's an e-mail?... It probably takes like two or three extra minutes for you to be very clear. And then someone's going to take that two or three extra minutes and then save themselves like two or three extra hours."*
+
+He closes the point with the line that belongs above every delegation brief: *"Clarity is high leverage work."* The same logic shows up in the harassment example he uses to drive the point home — telling someone to "stop being creepy" doesn't work because that isn't a behavior. *"No one wakes up and says I want to be creepy today... by telling them to stop, be creepy, they don't know what the fuck that means."* Until the standard is externalized as a specific behavior or outcome — printed on the desk, this format, this email subject line, this metric hit — the owner is guessing at a target only the delegator can see.
+
+Source: [Hormozi (Alex) — Team Follow-Through (5 STAR)](../../../references/hormozi-alex_followthrough.md)
+
+---
+
+## Real-world case: Nicole Wipp — when "I can't hand this off" was actually "I haven't externalized what done looks like"
+
+**Illustrates:** The Impact Filter unlocking a stuck delegation. When a leader says *"I can't seem to hand this off,"* the underlying problem is often externalization — not capacity, not the wrong Who. Forcing the standard onto paper is what unlocks the handoff.
+
+After starting her own law firm in the 2008 recession, attorney Nicole Wipp was working 80–100 hours a week as a solo show and was at a breaking point — not even clearing six figures despite the hours. Her first attempt at hiring failed, but the failure wasn't a hiring failure: it was a clarity failure. She wasn't yet clear on the specific results the role needed to produce, so there was no externalized standard for the Who to hit. The escalation of commitment from making that first investment was what forced her to sharpen the vision. Once she did, she built a team that operated autonomously enough that — during COVID-19, with Nicole in Hawaii and the team in Michigan — she only had to provide the vision; the team executed the transition for vulnerable elderly clients without hand-holding.
+
+Hardy's principle behind the case is the warning that pairs with the Impact Filter: *"Autonomy without clarity is ultimately a disaster. The Who will wander in circles freely but will not go in a meaningful direction... Lack of clarity of vision and inability to articulate that vision leaves Whos with no identity and no clear purpose. They become frustrated and lose their confidence. It's not because they lack the resources or capability, but because they have bad leadership."* The Impact Filter's four prompts — Purpose, Importance, Ideal Outcome, Success Criteria — exist precisely to prevent this. They force the leader to put the picture of done on paper before any Who is asked to chase it.
+
+Source: [Sullivan — *Who Not How*](../../../references/sullivan_who-not-how.md)
+
+---
+
+## Pre-empted shortcuts
+
+- **Don't fill in any element from your assumptions.** If the user couldn't articulate Success Looks Like, the brief is not done. Ask the question again, or surface the Impact Filter / Hormozi's "behavior or outcome" rule to help them.
+- **Don't use adjectives in element ③.** "Polished," "professional," "high-quality," "tight" — these don't externalize the standard. Push for examples, formats, lengths, audiences, what specifically the user doesn't want.
+- **Don't skip element ⑤ because "they know."** They don't. Or — they think they know, and they're at a different level than the user thinks. Name it.
+- **Don't skip element ⑥ in a flat team.** If the user is in a flat team and you didn't surface reciprocal commitments, the brief is structurally incomplete.
+- **Don't present all six elements at once.** One element per exchange. Wait for the user's answer before moving on.
+
+---
+
+## Phase 4 is complete when
+
+- ① What: deliverable named in one specific sentence (with the "so that we can" clause)
+- ② Why: context articulated — what's at stake, who it's for, what goes wrong if it misses
+- ③ Success Looks Like: externalized standard named as a specific behavior or outcome (Hormozi STAR #2), with concrete criteria or examples
+- ④ Constraints: non-negotiables named (timeline, budget, stakeholders, decisions the owner can't make alone)
+- ⑤ Authority Level: number 1–5 named with the matching level name
+- ⑥ Reciprocal Commitments (flat teams only): specific items the user / team owes the owner
+
+When all of those are true (six for hierarchical, six-plus-one for flat), move to Phase 5.
+
+---
+
+> **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:
+> - [Hormozi (Alex) — Team Follow-Through (5 STAR)](../../../references/hormozi-alex_followthrough.md) — the 5 reasons follow-through fails; pre-delegation clarity checklist
+> - [Sullivan — *Who Not How* + Impact Filter](../../../references/sullivan_who-not-how.md) — the four-question Impact Filter
+> - [Grove — *High Output Management*](../../../references/grove_high-output-management.md) — authority levels, "task-specific monitoring"
+> - [Doerr — *Measure What Matters*](../../../references/doerr_measure-what-matters.md) — OKR structure (Objective = WHAT, Key Result = HOW); "It's not a key result unless it has a number"