I’ve lost count of the number of times I’ve heard a well-meaning engineering manager say “I treat all my team members the same way — that’s what fairness looks like.”
And every time, I think: that’s not fairness. That’s abdication.
Over 20 years working in regulated industries — healthcare, defence, government — I’ve led engineering teams ranging from five people to fifty. And here’s what I’ve learned: the engineer who can architect a multi-region AWS deployment without breaking a sweat might need close direction on Terraform. The senior developer who mentors juniors brilliantly might need coaching when they’re thrown into a legacy codebase they’ve never seen before.
Treating everyone the same isn’t fair. It’s lazy. And it holds teams back.
The Situational Leadership Framework
Paul Hersey and Ken Blanchard introduced Situational Leadership in 1969, and it remains one of the most practically useful leadership frameworks I’ve encountered. The core insight is simple: you don’t lead people the same way in every situation. You match your leadership style to their development level for the specific task they’re facing.
There are four styles:
Directing — you tell someone what to do and how to do it. High direction, low support.
Coaching — you still provide direction, but you’re also explaining why and inviting questions. High direction, high support.
Supporting — they’ve got the capability, but they might lack confidence or motivation. Low direction, high support.
Delegating — they’re competent and committed. You get out of the way. Low direction, low support.
The mistake most leaders make is treating these as personality types. “Sarah’s a delegator. James needs directing.” But development level isn’t fixed — it’s task-specific. Sarah might be brilliant at Go microservices and need zero oversight. Put her on a Kubernetes operator for the first time, and she’s an enthusiastic beginner who needs coaching.
Why This Matters in Engineering Teams
Here’s the thing about engineering teams: they’re never homogeneous. You’ve got people working across technologies, cloud platforms, regulatory frameworks, and business domains. The same person might be an expert in one area and a novice in another.
I’ve worked with brilliant engineers in defence who could architect secure multi-region deployments in their sleep but had never touched containerisation. I’ve worked with senior developers who knew the legacy estate inside out but were navigating their first encounter with infrastructure as code. Would you direct them the same way in both contexts? Of course not.
Let me give you an analogy from the Clipper Race. When you’re crossing an ocean with a crew, you don’t lead the watch captain the same way you lead someone on their first night watch in 40-knot winds. The watch captain gets a weather routing brief and a handover — then you delegate. The first-timer gets close direction: this is the sail trim, this is what you’re watching for, this is when you call me. Same boat, same conditions, completely different leadership approach.
What Good Looks Like
The organisations getting this right are doing four things:
First, they’re assessing development level for the task, not the person. When an engineer picks up something new — a technology, a domain, a regulatory context — leaders are asking: what’s their competence here? What’s their commitment? Then they’re matching their approach accordingly.
Second, they’re being explicit about it. I’ve sat in teams where the lead said to a senior engineer: “You know this codebase better than I do — I’m delegating this to you, tell me what you need.” And I’ve heard the same leader say to someone else: “This is new for you, so I’m going to be more hands-on for the first sprint.” No one’s guessing. No one’s feeling micromanaged or abandoned.
Third, they’re adjusting as development progresses. Directing doesn’t stay directing forever. As someone builds competence and confidence, you’re shifting to coaching, then supporting, then delegating. If you’re still directing someone six months in, either you’ve misjudged the task complexity or something’s gone wrong.
Fourth, they’re asking rather than assuming. The best leaders I’ve worked with don’t presume to know what someone needs — they ask. “How are you finding this? Do you need more context, or would you rather I step back?” That kind of humility — acknowledging you don’t have perfect visibility into someone else’s experience — builds trust.
The Temptation to Default
Here’s where it gets hard. Most of us have a default style. I know mine: I lean towards delegating because I trust people and I hate micromanagement. But that default can fail spectacularly when someone genuinely needs more direction, and I’ve left them floundering because I assumed they’d ask for help.
The discipline of Situational Leadership is recognising when your default isn’t serving the situation. And that requires humility — the willingness to admit that your instinct might be wrong, that your usual approach isn’t working, that you need to adjust. It’s noticing when someone who usually thrives is suddenly struggling, and shifting from delegating to supporting. It’s recognising when you’re coaching someone who’s ready to be trusted, and stepping back.
I won’t pretend this is easy. It requires you to pay attention. It requires you to know your team well enough to spot when someone’s moved from enthusiastic beginner to disillusioned learner — that moment when the initial excitement has worn off and the difficulty has set in. It requires you to have the conversation about what someone actually needs, rather than assuming.
But here’s what I’ve observed: teams where leaders adapt their approach to the situation are more resilient. They onboard faster. They handle complexity better. And crucially, people don’t leave because they felt either micromanaged or abandoned.
There’s something else, too. Teams trust leaders who are humble enough to adjust. When you’re willing to say “I got that wrong, let me change my approach,” you’re modelling the same adaptability you’re asking from your engineers. And that matters more than getting it right first time.
The alternative — treating everyone the same because it feels fair — isn’t fairness. It’s uniformity. And uniformity doesn’t serve anyone.
I’d be curious to hear how others approach this. Do you adapt your leadership style based on the task and the person’s development level? What’s worked — and where have you got it wrong?
#Leadership #EngineeringLeadership #SituationalLeadership #TechLeadership #PeopleManagement
Leave a Reply