{"id":"e3ce949a-a6ad-4869-8c7e-078fb894fd66","entityType":"agent","slug":"clawhub-deciqai-situational-leadership","name":"Situational Leadership","canonicalUrl":"https://www.xpersona.co/agent/clawhub-deciqai-situational-leadership","canonicalPath":"/agent/clawhub-deciqai-situational-leadership","generatedAt":"2026-10-11T21:00:23.984Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":null},"description":"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... Skill: Situational Leadership Owner: deciqai Summary: Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:16:09.293Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/situational-leadership.json) v1.0.4 | 2026-07-09T11:","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:situational-leadership","sourceUrl":"https://clawhub.ai/deciqai/situational-leadership","homepage":"https://clawhub.ai/deciqai/skills/situational-leadership","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/deciqai/situational-leadership","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/deciqai/skills/situational-leadership","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":null},"stars":null,"forks":null,"downloads":1017,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.0.5","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:36:31.476Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T17:36:31.539Z","lastCrawledAt":"2026-10-11T17:36:31.476Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T17:36:31.476Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.5","createdAt":"2026-07-16T18:16:09.293Z","changelog":"Description tail link + agents machine-readable metadata line (deciqai.com/s/situational-leadership.json)","fileCount":6,"zipByteSize":12699},{"version":"1.0.4","createdAt":"2026-07-09T11:21:58.176Z","changelog":"Refresh: 2024-2026 AI-era worked examples added (strategy/leadership + systems/game-theory batch)","fileCount":6,"zipByteSize":12746},{"version":"1.0.3","createdAt":"2026-07-08T11:19:33.362Z","changelog":"Footer now uses /c/<slug> short link (fixes UTM truncation when SKILL.md is read in a terminal)","fileCount":5,"zipByteSize":9031},{"version":"1.0.2","createdAt":"2026-07-08T01:04:22.276Z","changelog":"Refreshed content + GitHub star link in footer","fileCount":5,"zipByteSize":9103},{"version":"1.0.1","createdAt":"2026-07-07T22:33:24.047Z","changelog":"Add catalog categories and topics","fileCount":5,"zipByteSize":8885},{"version":"1.0.0","createdAt":"2026-07-02T14:17:32.534Z","changelog":"Initial publish","fileCount":5,"zipByteSize":9023}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:situational-leadership","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T21:00:23.981Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-situational-leadership/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":null},"readme":"Skill: Situational Leadership\n\nOwner: deciqai\n\nSummary: Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new...\n\nTags: latest:1.0.5\n\nVersion history:\n\nv1.0.5 | 2026-07-16T18:16:09.293Z | user\n\nDescription tail link + agents machine-readable metadata line (deciqai.com/s/situational-leadership.json)\n\nv1.0.4 | 2026-07-09T11:21:58.176Z | user\n\nRefresh: 2024-2026 AI-era worked examples added (strategy/leadership + systems/game-theory batch)\n\nv1.0.3 | 2026-07-08T11:19:33.362Z | user\n\nFooter now uses /c/<slug> short link (fixes UTM truncation when SKILL.md is read in a terminal)\n\nv1.0.2 | 2026-07-08T01:04:22.276Z | user\n\nRefreshed content + GitHub star link in footer\n\nv1.0.1 | 2026-07-07T22:33:24.047Z | user\n\nAdd catalog categories and topics\n\nv1.0.0 | 2026-07-02T14:17:32.534Z | user\n\nInitial publish\n\nArchive index:\n\nArchive v1.0.5: 6 files, 12699 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), examples/leading-ai-native-teams-2024-2026.md (5394b), references/sources.md (2873b), skill-card.md (2578b), SKILL.md (10866b), _meta.json (141b)\n\nFile v1.0.5:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended. More: deciqai.com/c/situational-leadership\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: `kotter-change` for org-level transformation (Kotter = org sequence; this = each individual relationship); `principal-agent` to rule out incentive problems first; `okr-goal-setting` to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- **AI adoption resets who's the expert** — after rolling out AI coding tools / AI-native workflows amid the 2024–2026 AI capex race, a senior person is D1/D2 on the new tool even while D4 on the core work\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n*→ 2026 lens: [Leading AI-native engineering teams (2024–2026)](examples/leading-ai-native-teams-2024-2026.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — 227 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/situational-leadership** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\n*Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/situational-leadership.json*\n\nFile v1.0.5:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.5\",\n  \"publishedAt\": 1784225769293\n}\n\nFile v1.0.5:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n- GitHub (2024–2025). \"GitHub Copilot\" product documentation and adoption announcements. github.com. Supports the 2024–2026 example: GitHub's public reporting that Copilot is among its most rapidly adopted developer products and reached broad use across professional development teams (GitHub reported ~20 million all-time users by mid-2025) — the industry shift that resets task-level development levels for experienced engineers. https://github.com/features/copilot\n- Stack Overflow (2024). *2024 Developer Survey* — AI section. survey.stackoverflow.co. Documents that a large majority of professional developers were using or planning to use AI coding tools in their workflow by 2024, corroborating the AI-native-team leadership context. https://survey.stackoverflow.co/2024\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.5:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.5:examples/leading-ai-native-teams-2024-2026.md\n\n# Method in Action: Leading AI-Native Engineering Teams (2024–2026)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nBetween 2024 and 2026, AI coding assistants (GitHub Copilot, Cursor, Anthropic's Claude Code, and similar tools) moved from novelty to a standard part of many software teams' daily workflow. GitHub has publicly described Copilot as one of its most rapidly adopted developer products, and by 2024–2025 it was in broad use across professional development teams (GitHub reported roughly 20 million all-time users by mid-2025). This created a leadership problem that Situational Leadership diagnoses cleanly: **the introduction of a fast-moving new tool resets development levels, so yesterday's expert becomes today's novice — even as the tool keeps changing under them.**\n\nA recurring 2024–2026 pattern: a senior engineer with a decade of experience is genuinely D4 on the team's core language and architecture, but D1 on \"getting reliable output from an AI agent on our codebase\" — a task that did not exist two years earlier and whose best practices shift with each model release. Managers who read seniority as a global development level (S4 everywhere, because \"she's senior\") watch strong engineers quietly struggle with the new tooling and blame themselves. The skill's own warning applies directly: *never assess development level globally — always for a specific named task.*\n\nWalking a concrete case through **The Process**:\n\n**1. Define the task precisely.** Not \"Priya's performance\" but: *Priya (staff engineer, 9 years, deep in the payments service) on the task of using an AI coding agent to ship features in that service — writing effective prompts, reviewing AI-generated diffs, and knowing when to abandon the agent and code by hand.*\n\n**2. Assess competence** on *this* task. Knowledge: low — she has read about the tools but has little hands-on model of where they fail. Skill: low — her first attempts produced plausible-looking but subtly wrong diffs she over-trusted. Track record: none on this specific task. **Overall: low.** (Note the split: on the payments service itself, her competence remains high. This is the engineering-team error the skill flags — treating technical seniority as a proxy for all tasks.)\n\n**3. Assess commitment** on this task — asked directly, not inferred. Motivation: mixed; she sees the upside but resents \"prompting a tool\" after a decade of hard-won mastery. Confidence: low, and privately worried the shift devalues her expertise. Engagement: variable. **Overall: variable-to-low.** Assessment method: conversation, not observation — because from the outside her frustration could be misread as disengagement or resistance.\n\n**4. Determine development level.** Low competence with low/wavering confidence and motivation is **D2** (the disillusioned learner), not D1. The commitment dip — driven by identity threat, not laziness — is the distinguishing signal. *Stop-rule reminder: had the assessment been ambiguous between D1 and D2, default to the lower level (more structure).*\n\n**5. Select and implement style.** D2 calls for **S2 Coaching — high directive + high supportive.** Concretely: (1) pair her with someone fluent in the agent workflow on a real payments ticket, giving explicit technique (how to scope a prompt, how to review a generated diff adversarially) rather than \"go figure it out.\" (2) Acknowledge the effort and name the identity issue out loud: her deep payments knowledge is exactly what makes her a *better* AI reviewer than a junior, because she can catch the subtle wrong diffs a novice would merge. (3) Set small, winnable milestones so competence and confidence rebuild together.\n\n**6. Monitor, reassess, shift.** The reassessment trigger here is unusually fast. Because model capabilities and tool ergonomics change every few months, a person who reached D4 on \"the June agent workflow\" can be knocked back to D2/D3 when a major new model or interface lands. The skill's move is to **name the shift explicitly**: *\"The tool changed, so we're all re-learning this part — that's about the tool, not your standing.\"* This reframes a capability reset as a shared, expected event rather than a personal failing, and prevents the most dangerous mismatch (D4+S1) from creeping in as managers over-correct with control when tools misbehave.\n\nThe broader 2024–2026 lesson mirrors the founding premise: with AI-native tooling, **development level has become a moving target measured in months, not years.** Leaders who hold a fixed picture of who is \"senior\" mis-assign style constantly. Leaders who run a task-level, frequently-updated development map — separating durable engineering judgment from the shifting skill of directing AI tools — match style to actual need and keep their strongest people engaged through repeated capability resets.\n\n*Sources: GitHub, \"GitHub Copilot\" product documentation and adoption announcements, github.com (2024–2025); Hersey, P. & Blanchard, K.H. (1969), \"Life Cycle Theory of Leadership,\" *Training and Development Journal* 23(5); Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985), *Leadership and the One Minute Manager*, William Morrow. The AI-native leadership case is an application of the SLII framework to a widely reported industry shift, not a claim about any specific named company or individual.*\n\nFile v1.0.5:skill-card.md\n\n## Description:\n\nGuides an agent to diagnose a person's task-specific competence and commitment, then recommend the matching situational leadership style for that person and task.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[deciqai](https://clawhub.ai/user/deciqai)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nManagers, leadership coaches, and workplace-support agents use this skill to choose how much direction, coaching, support, or delegation to apply for a specific person on a specific task. It is especially useful when delegation, new-hire support, disengagement, or task changes need a structured management diagnosis.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may be used with sensitive workplace situations or employee details.\n\nMitigation: Share only the details needed to assess the specific task, competence, commitment, and reassessment trigger; avoid unnecessary personal employee information.\n\nRisk: A diagnosis can be misleading if the user describes a person globally instead of naming a specific task.\n\nMitigation: Use the skill's task-specific stop rule and verification checklist before acting on the recommendation.\n\n## Reference(s):\n\n- [Sources - situational-leadership](references/sources.md)\n- [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)\n- [Leading AI-Native Engineering Teams (2024-2026)](examples/leading-ai-native-teams-2024-2026.md)\n- [Harvard Business Review: How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management)\n- [GitHub Copilot](https://github.com/features/copilot)\n- [Stack Overflow 2024 Developer Survey](https://survey.stackoverflow.co/2024)\n- [Skill page](https://clawhub.ai/deciqai/skills/situational-leadership)\n- [deciqAI skill metadata](https://www.deciqai.com/s/situational-leadership.json)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown development diagnosis and leadership recommendation]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May ask stepwise clarification questions before producing a diagnosis when the person or task is not specific enough.]\n\n## Skill Version(s):\n\n1.0.5 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.4: 6 files, 12746 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), examples/leading-ai-native-teams-2024-2026.md (5394b), references/sources.md (2873b), skill-card.md (2844b), SKILL.md (10711b), _meta.json (141b)\n\nFile v1.0.4:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended.\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: `kotter-change` for org-level transformation (Kotter = org sequence; this = each individual relationship); `principal-agent` to rule out incentive problems first; `okr-goal-setting` to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- **AI adoption resets who's the expert** — after rolling out AI coding tools / AI-native workflows amid the 2024–2026 AI capex race, a senior person is D1/D2 on the new tool even while D4 on the core work\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n*→ 2026 lens: [Leading AI-native engineering teams (2024–2026)](examples/leading-ai-native-teams-2024-2026.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — 189 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/situational-leadership** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.4:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.4\",\n  \"publishedAt\": 1783596118176\n}\n\nFile v1.0.4:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n- GitHub (2024–2025). \"GitHub Copilot\" product documentation and adoption announcements. github.com. Supports the 2024–2026 example: GitHub's public reporting that Copilot is among its most rapidly adopted developer products and reached broad use across professional development teams (GitHub reported ~20 million all-time users by mid-2025) — the industry shift that resets task-level development levels for experienced engineers. https://github.com/features/copilot\n- Stack Overflow (2024). *2024 Developer Survey* — AI section. survey.stackoverflow.co. Documents that a large majority of professional developers were using or planning to use AI coding tools in their workflow by 2024, corroborating the AI-native-team leadership context. https://survey.stackoverflow.co/2024\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.4:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.4:examples/leading-ai-native-teams-2024-2026.md\n\n# Method in Action: Leading AI-Native Engineering Teams (2024–2026)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nBetween 2024 and 2026, AI coding assistants (GitHub Copilot, Cursor, Anthropic's Claude Code, and similar tools) moved from novelty to a standard part of many software teams' daily workflow. GitHub has publicly described Copilot as one of its most rapidly adopted developer products, and by 2024–2025 it was in broad use across professional development teams (GitHub reported roughly 20 million all-time users by mid-2025). This created a leadership problem that Situational Leadership diagnoses cleanly: **the introduction of a fast-moving new tool resets development levels, so yesterday's expert becomes today's novice — even as the tool keeps changing under them.**\n\nA recurring 2024–2026 pattern: a senior engineer with a decade of experience is genuinely D4 on the team's core language and architecture, but D1 on \"getting reliable output from an AI agent on our codebase\" — a task that did not exist two years earlier and whose best practices shift with each model release. Managers who read seniority as a global development level (S4 everywhere, because \"she's senior\") watch strong engineers quietly struggle with the new tooling and blame themselves. The skill's own warning applies directly: *never assess development level globally — always for a specific named task.*\n\nWalking a concrete case through **The Process**:\n\n**1. Define the task precisely.** Not \"Priya's performance\" but: *Priya (staff engineer, 9 years, deep in the payments service) on the task of using an AI coding agent to ship features in that service — writing effective prompts, reviewing AI-generated diffs, and knowing when to abandon the agent and code by hand.*\n\n**2. Assess competence** on *this* task. Knowledge: low — she has read about the tools but has little hands-on model of where they fail. Skill: low — her first attempts produced plausible-looking but subtly wrong diffs she over-trusted. Track record: none on this specific task. **Overall: low.** (Note the split: on the payments service itself, her competence remains high. This is the engineering-team error the skill flags — treating technical seniority as a proxy for all tasks.)\n\n**3. Assess commitment** on this task — asked directly, not inferred. Motivation: mixed; she sees the upside but resents \"prompting a tool\" after a decade of hard-won mastery. Confidence: low, and privately worried the shift devalues her expertise. Engagement: variable. **Overall: variable-to-low.** Assessment method: conversation, not observation — because from the outside her frustration could be misread as disengagement or resistance.\n\n**4. Determine development level.** Low competence with low/wavering confidence and motivation is **D2** (the disillusioned learner), not D1. The commitment dip — driven by identity threat, not laziness — is the distinguishing signal. *Stop-rule reminder: had the assessment been ambiguous between D1 and D2, default to the lower level (more structure).*\n\n**5. Select and implement style.** D2 calls for **S2 Coaching — high directive + high supportive.** Concretely: (1) pair her with someone fluent in the agent workflow on a real payments ticket, giving explicit technique (how to scope a prompt, how to review a generated diff adversarially) rather than \"go figure it out.\" (2) Acknowledge the effort and name the identity issue out loud: her deep payments knowledge is exactly what makes her a *better* AI reviewer than a junior, because she can catch the subtle wrong diffs a novice would merge. (3) Set small, winnable milestones so competence and confidence rebuild together.\n\n**6. Monitor, reassess, shift.** The reassessment trigger here is unusually fast. Because model capabilities and tool ergonomics change every few months, a person who reached D4 on \"the June agent workflow\" can be knocked back to D2/D3 when a major new model or interface lands. The skill's move is to **name the shift explicitly**: *\"The tool changed, so we're all re-learning this part — that's about the tool, not your standing.\"* This reframes a capability reset as a shared, expected event rather than a personal failing, and prevents the most dangerous mismatch (D4+S1) from creeping in as managers over-correct with control when tools misbehave.\n\nThe broader 2024–2026 lesson mirrors the founding premise: with AI-native tooling, **development level has become a moving target measured in months, not years.** Leaders who hold a fixed picture of who is \"senior\" mis-assign style constantly. Leaders who run a task-level, frequently-updated development map — separating durable engineering judgment from the shifting skill of directing AI tools — match style to actual need and keep their strongest people engaged through repeated capability resets.\n\n*Sources: GitHub, \"GitHub Copilot\" product documentation and adoption announcements, github.com (2024–2025); Hersey, P. & Blanchard, K.H. (1969), \"Life Cycle Theory of Leadership,\" *Training and Development Journal* 23(5); Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985), *Leadership and the One Minute Manager*, William Morrow. The AI-native leadership case is an application of the SLII framework to a widely reported industry shift, not a claim about any specific named company or individual.*\n\nFile v1.0.4:skill-card.md\n\n## Description: <br>\nHelps managers diagnose a person's task-specific competence and commitment, then choose Directing, Coaching, Supporting, or Delegating behavior. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nEmployees, managers, and leadership coaches use this skill to diagnose manager-report friction, delegation decisions, new-role struggles, and disengaged high performers for a specific person on a specific task. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can produce misleading management guidance if the person, task, competence, or commitment evidence is vague or inferred too broadly. <br>\nMitigation: Require a specific person-task framing, ask directly about commitment, and use the skill's lower-structure stop rule when the development level is ambiguous. <br>\nRisk: Advice may be misapplied to incentive misalignment or acute crisis situations that the skill explicitly excludes. <br>\nMitigation: Screen for incentive problems and crisis conditions before using the situational leadership process. <br>\nRisk: The release evidence notes no hidden execution or destructive behavior, but users may combine the guidance with external operational workflows. <br>\nMitigation: Review any connected workflow permissions and use least-privilege credentials for tools or services invoked outside this skill. <br>\n\n\n## Reference(s): <br>\n- [Sources - situational-leadership](references/sources.md) <br>\n- [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md) <br>\n- [Leading AI-Native Engineering Teams (2024-2026)](examples/leading-ai-native-teams-2024-2026.md) <br>\n- [deciqAI ClawHub skill page](https://clawhub.ai/deciqai/skills/situational-leadership) <br>\n- [Harvard Business Review: How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management) <br>\n- [GitHub Copilot](https://github.com/features/copilot) <br>\n- [Stack Overflow 2024 Developer Survey](https://survey.stackoverflow.co/2024) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown diagnostic guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May pause for user input during step-by-step coaching before completing a diagnosis.] <br>\n\n## Skill Version(s): <br>\n1.0.4 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.3: 5 files, 9031 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), references/sources.md (2086b), skill-card.md (2327b), SKILL.md (10385b), _meta.json (141b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended.\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: `kotter-change` for org-level transformation (Kotter = org sequence; this = each individual relationship); `principal-agent` to rule out incentive problems first; `okr-goal-setting` to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — 164 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/situational-leadership** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.3:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1783509573362\n}\n\nFile v1.0.3:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.3:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.3:skill-card.md\n\n## Description: <br>\nSituational Leadership helps an agent coach managers to match direction, coaching, support, or delegation to a person's competence and commitment on a specific task. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nManagers, founders, and leadership coaches use this skill to diagnose manager-report friction, delegation decisions, new-hire struggles, and disengaged high performers by assessing a specific person's development level on a specific task. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may lead an agent to discuss workplace performance or management style using sensitive employee details. <br>\nMitigation: Share only the employee context needed for the coaching task, avoid unnecessary personal or confidential details, and review the resulting guidance before acting on it. <br>\nRisk: A leadership diagnosis may be wrong if the task is vague or competence and commitment are inferred without enough evidence. <br>\nMitigation: Use the skill's verification checks: define the task precisely, assess competence and commitment separately, ask direct questions where possible, and reassess when conditions change. <br>\n\n\n## Reference(s): <br>\n- [Sources - situational-leadership](references/sources.md) <br>\n- [Method in Action: Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md) <br>\n- [How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown diagnosis or step-by-step coaching guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May ask follow-up questions before producing a development diagnosis.] <br>\n\n## Skill Version(s): <br>\n1.0.3 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 5 files, 9103 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), references/sources.md (2086b), skill-card.md (2508b), SKILL.md (10497b), _meta.json (141b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended.\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: `kotter-change` for org-level transformation (Kotter = org sequence; this = each individual relationship); `principal-agent` to rule out incentive problems first; `okr-goal-setting` to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — 163 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/skills/situational-leadership?utm_source=clawhub&utm_medium=marketplace&utm_campaign=knowledge-skills&utm_content=situational-leadership** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1783472662276\n}\n\nFile v1.0.2:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.2:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nHelps managers match their leadership style to a person's development level on a specific task, then produce a practical development diagnosis and style recommendation. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nManagers, founders, and team leads use this skill to diagnose how much direction and support a specific person needs for a specific task. It helps produce a development-level assessment, matching leadership style, immediate behavior changes, and reassessment trigger. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Users may discuss employee performance, motivation, management concerns, or other sensitive workplace details while using the skill. <br>\nMitigation: Avoid entering sensitive HR, legal, or personal details unless doing so is appropriate under the user's workspace policies. <br>\nRisk: The skill can produce management guidance that may be incomplete if the task, competence, or commitment assessment is vague or inferred. <br>\nMitigation: Use the skill's verification checks: define the task precisely, assess competence and commitment directly, state reasoning, and reassess when conditions change. <br>\n\n\n## Reference(s): <br>\n- [Primary sources for situational leadership](references/sources.md) <br>\n- [Google Project Oxygen example](examples/google-project-oxygen-2009.md) <br>\n- [How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management) <br>\n- [Situational Leadership on ClawHub](https://clawhub.ai/deciqai/skills/situational-leadership) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Analysis, Markdown, Guidance] <br>\n**Output Format:** [Markdown with structured diagnosis sections] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces task-specific competence and commitment assessment, D1-D4 development level, S1-S4 style recommendation, immediate behavior changes, and reassessment trigger.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 8885 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), references/sources.md (2086b), skill-card.md (2090b), SKILL.md (10317b), _meta.json (141b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended.\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: [`kotter-change`](../kotter-change/SKILL.md) for org-level transformation (Kotter = org sequence; this = each individual relationship); [`principal-agent`](../principal-agent/SKILL.md) to rule out incentive problems first; [`okr-goal-setting`](../okr-goal-setting/SKILL.md) to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1783463604047\n}\n\nFile v1.0.1:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.1:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.1:skill-card.md\n\n## Description: <br>\nGuides managers through diagnosing a person's task-specific competence and commitment, then matching support with directing, coaching, supporting, or delegating behavior. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nManagers and workplace coaches use this skill to diagnose friction or underperformance for a specific person on a specific task and choose an appropriate leadership style. It is intended for management coaching guidance, delegation decisions, and reassessment as employee competence or commitment changes. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Users may include identifying or confidential employee details when describing workplace performance issues. <br>\nMitigation: Limit prompts and outputs to details needed for the management diagnosis, and avoid unnecessary names, private personnel information, or confidential business context. <br>\n\n\n## Reference(s): <br>\n- [Situational Leadership Sources](references/sources.md) <br>\n- [Google Project Oxygen example](examples/google-project-oxygen-2009.md) <br>\n- [How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown guidance with a development diagnosis template] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Text-only management coaching output; no executable code, credential handling, or tool use is indicated by the evidence.] <br>\n\n## Skill Version(s): <br>\n1.0.1 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.0: 5 files, 9023 bytes\n\nFiles: examples/google-project-oxygen-2009.md (2819b), references/sources.md (2086b), skill-card.md (2416b), SKILL.md (10317b), _meta.json (141b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended.\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: [`kotter-change`](../kotter-change/SKILL.md) for org-level transformation (Kotter = org sequence; this = each individual relationship); [`principal-agent`](../principal-agent/SKILL.md) to rule out incentive problems first; [`okr-goal-setting`](../okr-goal-setting/SKILL.md) to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and specific task where management is stuck? If the issue is incentives not capability, point to principal-agent.\n3. Elicit the real case — get the specific task and specific person. Never assess development level for \"the employee in general.\"\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time: start with competence — \"Describe 2–3 things this person has done on this task. What was the quality?\"\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the insight: which development level, which style, and one specific behavior the manager should change immediately.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Development Diagnosis**, then select and implement the **Leadership Style**.\n\n1. **Define the task precisely.** State: \"[Person] on [specific task].\" If the task cannot be named, the diagnosis cannot run.\n2. **Assess competence** on this specific task — Knowledge / Skill / Track record. Rate: Low / Medium / High.\n3. **Assess commitment** on this specific task — Motivation / Confidence / Engagement. Rate: High / Variable / Low. Do not infer from behavior alone — ask directly.\n4. **Determine development level:** D1 = Low competence + High commitment; D2 = Low-medium competence + Low commitment; D3 = Medium-high competence + Variable commitment; D4 = High competence + High commitment. *Stop-rule: ambiguous level → default to lower (more structure).*\n5. **Select and implement style:** S1 Directing (D1) — clear steps, specific check-ins, no open-ended \"how do you think?\"; S2 Coaching (D2) — high directive + high supportive, acknowledge effort + give guidance; S3 Supporting (D3) — ask questions, explore confidence barriers, avoid deciding for them; S4 Delegating (D4) — assign outcomes not methods, check in periodically, express trust through reduced supervision.\n6. **Monitor, reassess, shift.** Reassess when new responsibilities arrive, performance drops, or disengagement signals appear. Name style shifts explicitly: \"I'm adding more structure on this new task — that's about the task, not my confidence in you.\"\n\n### Output: Development Diagnosis\n\n```\n# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>\n```\n\n*→ Method in Action: [Google's Project Oxygen (2009)](examples/google-project-oxygen-2009.md)*\n\n## Style Packs\n\n**Engineering teams:** Most common error — treating technical seniority as a proxy for all tasks. A senior engineer may be D4 on Python and D1 on AI deployment. Maintain a task-level development map; separate legacy skills from AI-assisted tasks.\n\n**Startup scaling:** Most dangerous failure — founder default to S4 as company grows, continuing S4 with incoming D1/D2 hires and producing confused new-hire failures. Reverse error: staying S1 with D4 executives who should be released.\n\n## Applying It Well\n\n- Never assess development level globally — always for a specific named task. \"She's a D4\" is meaningless; \"D4 on client management, D1 on data analysis\" is actionable.\n- Most dangerous mismatch: D4+S1. Symptoms: person stops raising ideas, stops initiating, starts mentioning other opportunities. When shifting S4→S1 on a new task, name the shift explicitly.\n- Commitment is harder to assess than competence. Ask: \"On a scale of 1–10, how confident do you feel?\" The gap between inferred and stated confidence is the coaching starting point.\n- Development arc (D1→D4) is not linear in time. Apply the style the current level calls for — don't rush the levels.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n| Fake move | Reality |\n|---|---|\n| [D] \"I treat everyone the same — it's fair\" | Applying S1 to a D4 and S4 to a D1 simultaneously is uniform — and both are harmful. Fairness means matching the response to the actual need. |\n| [D] \"He's been here 5 years, so I delegate everything to him\" | Tenure is not development level. A 5-year employee on a new task type is D1 on that task. Assign by task, not tenure. |\n| [D] \"She's technically strong, so she doesn't need much management\" | Technical competence is one dimension. A technically strong person who has lost motivation (D3) needs S3, not S4. Ignoring commitment produces the disengaged high performer. |\n| [D] \"I gave him full autonomy and he failed — he's not as capable as I thought\" | This is D1+S4 failure. The error is in the style assignment, not the person's capability. |\n| [D] \"I can't give her S1 treatment — she'll think I don't trust her\" | S1 for a D1 is appropriate support, not distrust. Name the rationale: \"You're new to this task; I'll give you structure and pull back as you develop.\" |\n| [D] \"We're a high-autonomy culture — everyone operates independently\" | Culture-level autonomy doesn't substitute for task-level assessment. High-autonomy culture extends trust to people ready for it — it does not mean ignoring D1 new hires or D3 people needing coaching. |\n| [D] \"My style is coaching — I do S2 with everyone\" | A fixed coaching style is as rigid as any other. D1 needs direction before coaching; D4 needs space, not coaching. |\n| [D] \"I don't have time for 1:1s — they're not productive\" | S2 and S3 require individual conversation to assess commitment and explore barriers. Skipping 1:1s forces drift to uniform S1 or S4 — both produce predictable failure. |\n| [D] \"The person needs to step up — that's on them\" | Prior question: did they have competence and commitment, and did they receive the matching style? Blaming the person before checking style match is diagnostic failure. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- Development level was assessed for a person overall, not for a specific task\n- Commitment was inferred from behavior without direct conversation\n- Manager has not changed style for a long-tenured member even as responsibilities evolved\n- High performer is disengaging or citing \"no growth opportunities\" — likely D4+S1\n- New hire is repeatedly failing — likely D1+S4\n- Development level not updated after new tasks were assigned\n\n## Verification\n\n- [ ] Task is precisely stated — not \"her performance\" but \"her performance on [specific named task]\"\n- [ ] Competence assessed on all three dimensions: knowledge, skill, track record\n- [ ] Commitment assessed through direct conversation, not only inferred\n- [ ] Development level (D1–D4) stated with reasoning, not just the label\n- [ ] Leadership style (S1–S4) matched to development level, with three specific behavior changes named\n- [ ] Stop-rule applied: ambiguous level defaults to lower (more structure)\n- [ ] Reassessment trigger defined\n\n---\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1783001852534\n}\n\nFile v1.0.0:references/sources.md\n\n# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims.\n\nFile v1.0.0:examples/google-project-oxygen-2009.md\n\n# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n\nFile v1.0.0:skill-card.md\n\n## Description: <br>\nHelps managers match Directing, Coaching, Supporting, or Delegating leadership styles to a person's development level on a specific task. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nManagers, team leads, and leadership coaches use this skill to diagnose a person's competence and commitment on a named task, then choose a matching leadership style and concrete behavior changes. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Users may enter sensitive HR, performance, confidence, motivation, or management details while applying the coaching workflow. <br>\nMitigation: Ask for only the details needed to diagnose the task-level situation and avoid unnecessary personal or sensitive HR information. <br>\nRisk: Leadership recommendations may be mistaken for formal HR, legal, or employment advice. <br>\nMitigation: Frame outputs as management guidance and consult appropriate HR or legal processes before making consequential personnel decisions. <br>\n\n\n## Reference(s): <br>\n- [Primary sources for situational leadership](artifact/references/sources.md) <br>\n- [Google's Project Oxygen example](artifact/examples/google-project-oxygen-2009.md) <br>\n- [Harvard Business Review: How Google Sold Its Engineers on Management](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management) <br>\n- [Situational Leadership on ClawHub](https://clawhub.ai/deciqai/skills/situational-leadership) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown development diagnosis with recommended leadership style, behavior changes, reassessment trigger, and staged coaching questions when needed] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May ask one question at a time and stop at explicit WAIT points until the user provides the needed case details.] <br>\n\n## Skill Version(s): <br>\n1.0.0 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: Situational Leadership Owner: deciqai Summary: Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:16:09.293Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/situational-leadership.json) v1.0.4 | 2026-07-09T11:","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"},{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"},{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"},{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"},{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"},{"language":"text","snippet":"# Development Diagnosis: <person> on <task>\nTask: <precisely stated>\nCompetence: Knowledge / Skill / Track record → Overall: low/medium/high\nCommitment: Motivation / Confidence / Engagement → Overall: high/variable/low\n  (Assessment method: observation / conversation / inference)\nDevelopment level: D1/D2/D3/D4 — reasoning\nStyle recommendation: S1/S2/S3/S4\nImmediate behavior changes: (1) (2) (3)\nReassessment trigger: <signal>"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: situational-leadership\ndescription: \"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new hire is struggling without guidance', 'should I give him more autonomy?', or asks how to lead/manage a specific person on a specific task.\n  Do NOT activate when: the performance issue is an incentive misalignment (reward structure is wrong — use principal-agent instead); the organization is in acute crisis requiring uniform command and all debate is suspended. More: deciqai.com/c/situational-leadership\"\n---\n\n# Situational Leadership\n\n## Overview\n\nMatch your leadership style to each person's development level on each specific task — cycling through four styles (Directing, Coaching, Supporting, Delegating) as competence and commitment evolve. Introduced by Hersey & Blanchard (1969); formalized as SLII by Blanchard, Zigarmi & Zigarmi (1985).\n\nCore diagnostic: instead of \"what kind of leader should I be?\" ask \"what does this person need from me on *this task* right now?\" Failure to update style as the person grows is the most common cause of high performers disengaging.\n\nComposes with: `kotter-change` for org-level transformation (Kotter = org sequence; this = each individual relationship); `principal-agent` to rule out incentive problems first; `okr-goal-setting` to set goals (OKR) then govern how to support each person toward them.\n\n## When to Use\n\n- A manager-report relationship has **friction or underperformance** and root cause is undiagnosed\n- A **high performer is disengaging** (\"I'm being micromanaged\", \"no room to grow\") — signature of D4 receiving S1\n- A **new hire or person in a new role** is struggling despite effort — signature of D1/D2 receiving insufficient structure\n- A **task or technology change** resets development levels for experienced people\n- **AI adoption resets who's the expert** — after rolling out AI coding tools / AI-native workflows amid the 2024–2026 AI capex race, a senior person is D1/D2 on the new tool even while D4 on the core work\n- You are making a **delegation decision** for a specific person on a specific task\n\n**When NOT to use:** incentive misalignment (principal-agent problem); acute crisis requiring uniform command; task is too vague to name (diagnosis requires a specific task).\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a specific person and task → run The Process directly.\n- **Coach mode:** user is unfamiliar or asks \"what is situational leadership?\" → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: there's no single best management style — what works depends on how much the person knows and how confident/motivated they feel on *this task*. The manager's job is to match style to that, and update as the person grows.\n2. Check fit: is there a specific person and spec"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"situational-leadership\",\n  \"version\": \"1.0.5\",\n  \"publishedAt\": 1784225769293\n}"},{"path":"references/sources.md","content":"# Sources — situational-leadership\n\n> *Primary sources for the [situational-leadership](../SKILL.md) skill.*\n\n- Hersey, P. & Blanchard, K.H. (1969). \"Life Cycle Theory of Leadership.\" *Training and Development Journal*, 23(5), 26-34. The original publication introducing the situational leadership framework with the foundational claim that no single style is universally effective.\n- Blanchard, K., Zigarmi, P., & Zigarmi, D. (1985). *Leadership and the One Minute Manager.* William Morrow. The SLII formalization with the four development levels and four leadership styles; the \"unequal treatment of unequals\" formulation. ISBN 978-0688038250.\n- Hersey, P., Blanchard, K.H., & Johnson, D.E. (2012). *Management of Organizational Behavior: Leading Human Resources.* 10th ed. Pearson. The comprehensive academic treatment of situational leadership including the empirical basis and cross-cultural applications. ISBN 978-0132556408.\n- Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. Documents Project Oxygen's empirical findings — the behavioral evidence that style flexibility produces better team outcomes than style consistency. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management\n- Blanchard, K. & Johnson, S. (1981). *The One Minute Manager.* William Morrow. The popular companion to SLII; provides accessible descriptions of the three tools (goal setting, praising, redirecting) that implement S1/S2/S3/S4 behavior. ISBN 978-0688014292.\n\n- GitHub (2024–2025). \"GitHub Copilot\" product documentation and adoption announcements. github.com. Supports the 2024–2026 example: GitHub's public reporting that Copilot is among its most rapidly adopted developer products and reached broad use across professional development teams (GitHub reported ~20 million all-time users by mid-2025) — the industry shift that resets task-level development levels for experienced engineers. https://github.com/features/copilot\n- Stack Overflow (2024). *2024 Developer Survey* — AI section. survey.stackoverflow.co. Documents that a large majority of professional developers were using or planning to use AI coding tools in their workflow by 2024, corroborating the AI-native-team leadership context. https://survey.stackoverflow.co/2024\n\n**What is not cited and why:** The frequently cited claim that \"SLII has trained over 15 million managers\" comes from the Ken Blanchard Companies' marketing materials, not from independently verified research. Claims about specific percentage improvements in retention or performance in SLII-trained teams are from corporate training evaluations without peer review. This skill grounds its empirical support in Google's Project Oxygen (Garvin 2013), which is documented in a peer-reviewed academic outlet, rather than in training vendor effectiveness claims."},{"path":"examples/google-project-oxygen-2009.md","content":"# Method in Action: Google's Project Oxygen (2009)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nIn 2008, Google's People Analytics team launched Project Oxygen to answer a question the company's engineering culture resisted: do managers matter? The initial hypothesis among many Google engineers was that technical skill was sufficient and management was unnecessary overhead.\n\nProject Oxygen analyzed performance data, feedback surveys, and management behavior data from more than 10,000 Google manager-employee pairs. The result — published internally in 2009 and referenced in Garvin (2013) — identified eight behaviors that distinguished the highest-rated managers from the lowest.\n\nThe alignment between Project Oxygen's findings and Situational Leadership is striking:\n\n**Oxygen Behavior 1: \"Be a good coach.\"** In Situational Leadership terms: apply S2 behavior (high directive + high supportive) to people in the D2 development state. The Oxygen analysis found that the highest-rated managers invested in explaining the \"why\" and building skills — not just assigning tasks.\n\n**Oxygen Behavior 2: \"Empower your team and don't micromanage.\"** In Situational Leadership terms: apply S4 behavior (delegating) to D4 individuals. The failure mode Project Oxygen found: senior engineers receiving S1 behavior from managers who either didn't trust them or defaulted to directive behavior out of habit.\n\n**Oxygen Behavior 7: \"Have a clear vision and strategy for the team.\"** In Situational Leadership terms: S1 behavior applied at the strategic level, ensuring D1 individuals (new hires, new role assignments) have clear direction.\n\n**Oxygen Behavior 8: \"Have key technical skills so you can help advise the team.\"** In Situational Leadership terms: competency as the foundation for credible S2 coaching — a manager cannot coach what they do not understand.\n\nThe Project Oxygen findings confirmed Situational Leadership's core premise empirically: the managers who produced the best team outcomes were not those who used one style consistently, but those who adapted their behavior to what each team member needed. The lowest-performing managers showed two failure modes: uniform S1 (micromanagement regardless of competence) or uniform S4 (abandonment of people who needed support).\n\nResults documented in Garvin (2013): teams with the highest-quality managers (top quartile) showed approximately 20% lower turnover, approximately 30% higher performance ratings, and approximately 27% higher employee satisfaction scores compared to teams with the lowest-quality managers (bottom quartile).\n\nPrimary source: Garvin, D.A. (2013). \"How Google Sold Its Engineers on Management.\" *Harvard Business Review*, 91(12), 74–82. https://hbr.org/2013/12/how-google-sold-its-engineers-on-management"},{"path":"examples/leading-ai-native-teams-2024-2026.md","content":"# Method in Action: Leading AI-Native Engineering Teams (2024–2026)\n\n> *Example for the [situational-leadership](../SKILL.md) skill.*\n\nBetween 2024 and 2026, AI coding assistants (GitHub Copilot, Cursor, Anthropic's Claude Code, and similar tools) moved from novelty to a standard part of many software teams' daily workflow. GitHub has publicly described Copilot as one of its most rapidly adopted developer products, and by 2024–2025 it was in broad use across professional development teams (GitHub reported roughly 20 million all-time users by mid-2025). This created a leadership problem that Situational Leadership diagnoses cleanly: **the introduction of a fast-moving new tool resets development levels, so yesterday's expert becomes today's novice — even as the tool keeps changing under them.**\n\nA recurring 2024–2026 pattern: a senior engineer with a decade of experience is genuinely D4 on the team's core language and architecture, but D1 on \"getting reliable output from an AI agent on our codebase\" — a task that did not exist two years earlier and whose best practices shift with each model release. Managers who read seniority as a global development level (S4 everywhere, because \"she's senior\") watch strong engineers quietly struggle with the new tooling and blame themselves. The skill's own warning applies directly: *never assess development level globally — always for a specific named task.*\n\nWalking a concrete case through **The Process**:\n\n**1. Define the task precisely.** Not \"Priya's performance\" but: *Priya (staff engineer, 9 years, deep in the payments service) on the task of using an AI coding agent to ship features in that service — writing effective prompts, reviewing AI-generated diffs, and knowing when to abandon the agent and code by hand.*\n\n**2. Assess competence** on *this* task. Knowledge: low — she has read about the tools but has little hands-on model of where they fail. Skill: low — her first attempts produced plausible-looking but subtly wrong diffs she over-trusted. Track record: none on this specific task. **Overall: low.** (Note the split: on the payments service itself, her competence remains high. This is the engineering-team error the skill flags — treating technical seniority as a proxy for all tasks.)\n\n**3. Assess commitment** on this task — asked directly, not inferred. Motivation: mixed; she sees the upside but resents \"prompting a tool\" after a decade of hard-won mastery. Confidence: low, and privately worried the shift devalues her expertise. Engagement: variable. **Overall: variable-to-low.** Assessment method: conversation, not observation — because from the outside her frustration could be misread as disengagement or resistance.\n\n**4. Determine development level.** Low competence with low/wavering confidence and motivation is **D2** (the disillusioned learner), not D1. The commitment dip — driven by identity threat, not laziness — is the distinguishing signal. *Stop-rule reminder: had the assessment been ambigu"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... Skill: Situational Leadership Owner: deciqai Summary: Activate when: user says 'my management style isn't working for this person', 'I don't know how much to delegate', 'my top performer is disengaged', 'my new... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T18:16:09.293Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/situational-leadership.json) v1.0.4 | 2026-07-09T11:","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2110,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:36:31.539Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T21:00:23.984Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}