Situational Leadership II

Situational Leadership II (SLII) is a framework that says there is no one best leadership style — the right style depends on the development level of the person being led on a specific task. A new engineer on their first production deploy needs directive guidance; the same engineer leading a migration they've done twice needs delegation. Leaders who apply the same style to everyone fail the people who need something different. SLII gives leaders a diagnostic vocabulary for reading the person and the task, and a prescription for how to adjust.

Situational Leadership II: D1-D4 development levels matched to S1-S4 leadership styles

Origin

Paul Hersey and Ken Blanchard developed the original Situational Leadership model at Ohio State University in the late 1960s. The two later split: Hersey kept the name "Situational Leadership" (now called Situational Leadership Model by the Center for Leadership Studies), while Blanchard developed "Situational Leadership II" (SLII) in the 1980s, which added the "commitment" dimension to the "competence" dimension. SLII is what most modern corporate training means when they say "Situational Leadership" and is the version taught at companies like Oracle, IBM, Boeing, and most Fortune 500 leadership programs.

The Framework

SLII maps two dimensions:

COMPETENCE:   How skilled is the person at this specific task?
COMMITMENT:  How motivated, engaged, and confident are they on it?

The interaction produces four development levels:

D1 - Enthusiastic Beginner:  Low competence, high commitment
                             "Excited to learn, doesn't know yet"

D2 - Disillusioned Learner:  Low/some competence, low commitment
                             "Hitting the wall of how hard it really is"

D3 - Capable but Cautious:   Moderate-high competence, variable commitment
                             "Can do it but still unsure"

D4 - Self-Reliant Achiever:   High competence, high commitment
                             "Fully owns it"

For each development level, SLII prescribes a matching leadership style:

S1 - Directing:  High directive, low supportive
                 "Here's what, how, when. Let me know when it's done."

S2 - Coaching:   High directive, high supportive
                 "Here's what we're doing and why. Let me know what
                  you're thinking."

S3 - Supporting: Low directive, high supportive
                 "You know how. What do you need from me?"

S4 - Delegating: Low directive, low supportive
                 "It's yours. Let me know if you need me."

The core claim: match the style to the development level. Mismatches are the most common leadership failure.

The Matching Rule

D1 (Enthusiastic Beginner)   -> S1 (Directing)
D2 (Disillusioned Learner)   -> S2 (Coaching)
D3 (Capable but Cautious)    -> S3 (Supporting)
D4 (Self-Reliant Achiever)   -> S4 (Delegating)

This is the diagonal through the matrix. Leadership style should move down the diagonal as the person develops, and move back up when new tasks or contexts reduce their development level.

Task-Specific

SLII is explicitly task-specific. The same person can be D4 on one task and D1 on another. A senior engineer is D4 on backend architecture but possibly D1 on public speaking. The manager who delegates both because the engineer is "senior" fails them on the one they are new to.

How to Use It

Diagnostic Steps

1. Name the task: "This conversation is about you leading the platform
   migration." Be specific.

2. Diagnose competence:
   - Have they done this before?
   - Do they know how?
   - What is their track record on similar tasks?

3. Diagnose commitment:
   - Are they motivated to do this?
   - Are they confident they can?
   - Has anything recently eroded their engagement?

4. Determine development level (D1-D4) based on the combination.

5. Match your style:
   - D1: Direct. Give clear instructions and close check-ins.
   - D2: Coach. Explain why, not just what. Build confidence.
   - D3: Support. Step back on "how"; offer encouragement and
         sounding-board help.
   - D4: Delegate. Get out of the way.

Common Diagnostic Mistakes

- Confusing tenure with competence:
  "They've been here 5 years, they should be D4" — ignores that
  the task may be new.

- Confusing enthusiasm with competence:
  "They're excited, they must be ready" — enthusiasm is commitment,
  not skill.

- Confusing reluctance with low competence:
  "They're hesitating, they must not know how" — sometimes they know
  how perfectly well, they just lack confidence (D3) or have a valid
  concern they haven't surfaced yet.

- Confusing anxiety with disengagement:
  "They seem checked out" — might be D2 (hitting the wall) rather
  than genuinely disengaged.

Tech & Company Example

A tech lead has two engineers assigned to a database migration.

Engineer A: Senior engineer, 8 years experience, has led 3 previous
            migrations at past companies.

  Task: Lead the migration.
  Competence: High (extensive prior experience).
  Commitment: High (excited about the opportunity).
  Development level: D4.
  Leadership style: S4 Delegating.
  What the tech lead does:
    - "It's yours. Send me your plan when it's ready."
    - Does not review daily.
    - Available when asked.

Engineer B: Mid-level engineer, 3 years experience, has never done
            a migration. Took it on because they want to grow.

  Task: Own the data-consistency verification stream.
  Competence: Low-moderate (knows databases, new to migration patterns).
  Commitment: High (excited, new challenge).
  Development level: D1.
  Leadership style: S1 Directing.
  What the tech lead does:
    - Provides a specific checklist of verification patterns.
    - Pairs with them on the first 3 verification implementations.
    - Reviews code daily until patterns solidify.

Two weeks later: Engineer B has done the first 5 verifications and
                 is hitting the wall. "This is way harder than I
                 thought. The data has edge cases nobody mentioned."

  Competence: Still low-moderate (they've learned some).
  Commitment: Dropped (frustrated, doubting themselves).
  Development level: D2.
  Leadership style: S2 Coaching.
  What the tech lead does now:
    - Shifts from checklists to dialogue: "Let's talk about what
      you've learned. What patterns are you seeing in the edge
      cases?"
    - Explains the why of migration complexity at this scale.
    - Normalizes the wall: "This is where everyone hits it. You're
      on track, not behind."
    - Reduces check-in pressure; increases emotional support.

Six weeks later: Engineer B is competent, delivering well, but still
                 checks in a lot before making decisions.

  Competence: High (they've got it).
  Commitment: Variable (confident when things work, doubtful when
              they don't).
  Development level: D3.
  Leadership style: S3 Supporting.
  What the tech lead does now:
    - Pulls back on directive guidance.
    - Asks "What do you think you should do?" when they ask for
      direction.
    - Celebrates their wins visibly.
    - Makes themselves available but doesn't proactively intervene.

Three months later: Engineer B is owning verification end-to-end,
                   making decisions, shipping without bottlenecks.

  Development level: D4.
  Leadership style: S4 Delegating.
  What the tech lead does now:
    - Gets out of the way.
    - Asks for status, not direction.
    - Starts considering them for the next stretch assignment.

Notice that the tech lead used four different leadership styles for the same engineer over the course of three months. Using S4 on day one would have been neglect. Using S1 at month three would have been micromanagement. Both would have damaged the engineer's trajectory.

When It Works

One-on-ones with direct reports at varying experience levels
Assigning stretch projects
Onboarding new hires
Cross-functional leadership where people have different expertise
Coaching early-career engineers on specific skill areas

When It Does Not Work

When the person is not in a traditional subordinate relationship — Peer-to-peer influence needs different frames. SLII assumes the leader has some authority.
When the diagnostic is impossible — If the leader does not know the person well enough to diagnose, SLII is a guess. Start by learning them.
When development levels shift rapidly — In fast-moving contexts, the diagnostic may be obsolete by the time you apply the style. Lightweight check-ins and fast adjustment.
When the person does not want the style — Some high-D people resent any directive style; some low-D people want more support than coaching models suggest. Calibrate to the individual.

Common Failure Modes

Diagnostic

Over-diagnosing competence — Believing people are more skilled than they are, usually because you want to delegate. Results in people drowning on tasks they can't handle.
Under-diagnosing competence — Believing people are less skilled than they are, often rooted in bias or lack of trust. Results in micromanagement and erosion of the person's ownership.
One-style-fits-all — Using your default style (often S2 Coaching or S4 Delegating) regardless of the person. Feels "consistent" to the leader; feels wrong to whoever needs something different.

Style Application

Under-directing D1s — "I don't want to micromanage." But D1 needs micromanaging — they want and need direction. Withholding it is not respect; it is abandonment.
Over-directing D4s — Continuing to give directions to people who have mastered the task. Reads as distrust; leads to disengagement and attrition.
Skipping S2 — Moving from S1 to S3 without the coaching step. The engineer hits the wall (D2) and the leader is not there to help them through it.
Misreading D3 as D2 — When someone is hesitant, it is often interpreted as disengaged rather than as lacking confidence. Very different prescriptions.

Cultural

Macho D4 preference — Culture that treats "needing support" as weakness. Everyone pretends to be D4. Actual development is suppressed.
Infantilizing S1 preference — Culture that never moves past directive leadership. Team never develops autonomous capability.
Misdiagnosis as Performance Issue — A D2 engineer (hit the wall, lost motivation) is treated as a performance problem rather than a normal development phase. Fired or pushed out when they were actually just days away from breakthrough.