Situational Leadership
The Situational Leadership model helps leaders adapt their approach based on the capabilities of their team and the demands of the situation. By understanding when to provide direction, motivation, support, or autonomy, leaders can create an environment where people feel valued, grow continuously, and stay engaged. Originally developed by Paul Hersey and Ken Blanchard. Our summary is below.
Want a downloadable PDF instead? Click here!
What is it and why do it?
A leader's effectiveness is dramatically increased by their ability to match their approach to the capabilities of the individual (or team), combined with the particular situation. The ability to do this creates an environment where people feel valued and supported, can continuously grow, and are more engaged. The Situational Leadership model provides guidance for leaders to identify how much direction or autonomy they should give, and whether they should work more closely or stay more at arms length.
The model describes four styles according to the level of support and direction a leader might provide:
Telling: Provide clear, specific instructions that explain not just what to do, but how to do it; closely monitor performance.
Selling: Give guidance but also seek to motivate and support.
Participating: Encourage independent decision-making, build confidence, and provide emotional encouragement.
Delegating: Offer strategic challenges; allow independent decision-making and execution, and provide minimal direction and support.
Factors to consider
A leader needs to continuously assess which leadership style to adopt, depending on a few factors which will vary with tasks and over time.
Complexity. Simple and/or well-documented activities might allow delegation even if knowledge is low.
Impact. Stakeholders / optics might require your participation even if the person / team is fully able and willing. Business risk could be higher or lower.
Urgency. When timelines are tight you might need to choose a more directive style. When they’re not there is more room to coach, participate or delegate.
Capability. Do they have the technical skill/ability? A newer or more junior person might need more direction. Are they willing/motivated? A skilled person might need convincing that it should be a priority for them. Are they confident? A willing person might still need support to deal with higher level stakeholders. Are they psychologically (emotionally) able? Humans are emotional beings, and can need different levels of support depending on what’s happening around them.
Tips
There is no ‘best’ style. Flexibility and self-awareness are more important than aiming to default to a particular style. Ask yourself: What is needed now? Do I default to one style more than I should?
Communicate expectations based on your approach. Applying different leadership styles may be confusing, or perceived as unfair, if you aren’t clear about why you are changing style. For example, you would usually delegate, but stakeholder expectations are requiring you to be more participatory.
It’s not set and forget. Motivation can fluctuate, transitions happen, emotions are present. For example: a senior developer assigned to a project they find uninteresting might need more directive leadership despite participating or delegating usually being appropriate. A high-performing engineering manager might need more participative or even selling styles during organizational change. A technically competent developer experiencing personal challenges might require more support (Style 3: Participative) or coaching (Style 2: Selling) than usual.
Check your assumptions. What are you seeing and hearing that leads you to believe a particular style is needed? How are your own biases and preferences swaying you? You can ask others what they see, or use pull influencing skills to gather more information directly from the person.
Master push and pull influencing skills. Notice whether you default to more of a push or pull influencing style. Leaning more towards push will mean you are less likely to use Style 3: Participating, and Style 4: Delegating, and might inadvertently micro-manage. Pull influencing builds necessary intrinsic motivation and promotes psychological safety. Conversely, defaulting towards pull influencing will mean you are less likely to use be directive when it is necessary.
Scenarios
So how does this actually play out? What does it look like to do this well, versus well-intentioned but incorrectly?
1. A new engineer working in a complex codebase
The engineer is enthusiastic but risks being overwhelmed or not knowing where to start due to lack of experience.
Right Style: Telling, Guiding, Directing, Instructing
Well-Intentioned but Wrong Style: Participating, Encouraging, Problem-solving, Facilitating
The engineer has low competence but is eager to learn. They need clear instructions and close supervision to build confidence.
Assign a simple, manageable task to build familiarity.
Break the task into smaller, manageable steps. “These are the steps; let’s walk through them together.”
Provide documentation, code examples, and check in frequently to ensure understanding.
Set clear expectations and timelines.
Offer frequent, direct feedback.
Say "Take your time, I’m here if you need help," and avoid giving specific instructions to avoid micromanaging.
This could lead to the engineer feeling lost and unsure where to start, delaying progress.
2. A mid-level engineer frequently asking for clarification on minor decisions
The engineer is capable but hesitates to act independently.
Right Style:
Well-Intentioned but Wrong Style:
Participating, Encouraging, Problem-solving, Facilitating
Telling, Guiding, Directing, Instructing
The engineer has technical competence but lacks confidence. Providing encouragement and fostering autonomy helps them build trust in their own decision-making.
Reassure them about their skills: "You’ve got the expertise—what do you think would work best?"
Offer a safe space to make decisions and assure them that mistakes are part of learning.
Step back slightly while remaining available for guidance.
Say "Here’s exactly what you should do," solving problems for them.
This stifles their growth and reinforces their hesitation to make independent decisions.
3. An engineer leading a cross-functional team but struggling with time management
The engineer is capable but overwhelmed by the complexity of managing priorities.
Right Style:
Well-Intentioned but Wrong Style:
Selling, Explaining, Persuading, Coaching
Delegating, Observing, Monitoring, Empowering
The engineer has competence but needs help refining their planning and balancing tasks. Combining guidance and encouragement helps them regain control.
Provide guidance, and the reasoning behind it.
Help them prioritize tasks and set realistic goals.
Provide resources and strategies for time management, delegation, and collaboration.
Offer regular feedback and coaching: "You’re doing well; let’s focus on improving this area.”
Say "You’re doing great—just let me know when it’s done," and give them full trust and control.
This adds to their stress as they feel unsupported in managing their workload.
4. A senior engineer trusted with a critical project
The engineer is capable and motivated but risks being micromanaged.
Right Style:
Well-Intentioned but Wrong Style:
Delegating, Observing, Monitoring, Empowering
Telling, Guiding, Directing, Instructing
The engineer has high competence and commitment. Giving them full autonomy maximizes efficiency and trust.
Share the big picture and key outcomes, then step back.
Check in only occasionally to offer support but avoid frequent interventions.
Celebrate their success after delivery.
Say "Let’s review your plan step by step," and provide unnecessary oversight.
This leads them to believe you want more information and involvement than you might need and will undermine the engineer’s autonomy.
5. A staff engineer managing a highly complex technical decision
The engineer is highly skilled and confident but risks unnecessary oversight.
Right Style:
Well-Intentioned but Wrong Style:
Delegating, Observing, Monitoring, Empowering
Selling, Explaining, Persuading, Coaching
The engineer has high competence and commitment. Giving them full autonomy shows trust and maximizes their effectiveness.
Clearly define the outcomes and organizational goals: "We need a solution that balances scalability and performance."
Step back and let them execute independently.
Check in at milestones to ensure alignment without micromanaging.
Say "Let’s discuss your approach in detail before moving forward," and try to provide additional guidance.
This frustrates the engineer, who doesn’t need additional input and feels their expertise is being questioned.
6. A senior engineer misaligned with the product manager’s vision
The engineer struggles to reconcile technical implementation with unclear product priorities.
Right Style:
Well-Intentioned but Wrong Style:
Telling, Guiding, Directing, Instructing
Delegating, Observing, Monitoring, Empowering
The engineer has strong technical competence but needs guidance in navigating product requirements and alignment. A balance of support and direction helps them succeed.
Facilitate a meeting with the PM to clarify expectations.
Suggest approaches to align technical solutions with the product vision.
Offer encouragement: "You’re on the right track; let’s refine the details together."
Say "You’ve got this, I trust your judgment completely," and step back to give them autonomy.
This leaves the engineer frustrated because they need guidance to reconcile the misalignment.