My title says Senior. I've been a software quality engineer for years. I know my domain — I know how to run a test strategy, how to build quality into a delivery cycle, how to advocate for the user when no one else is asking the question.
And then my role expanded.
Almost overnight, I went from leading quality for two engineering teams to four — and alongside that expansion came a whole new category of activity I had never done before. Monthly roadmap reviews. Leadership meetings. Goal readouts with the business leadership team. Monthly reports with financial data. I went from the testing lane to the room where strategy lives.
My title didn't change. But everything I was being asked to do in those new spaces? I had never done it before. I didn't know what to look for in a roadmap review. I didn't know what mattered in a financial report, or what questions I was supposed to be asking in a leadership meeting. I was enthusiastic — genuinely excited about the growth — but I was starting from zero on all of it.
I was, to use the language of a model I learned at Zillow, a D1. An Enthusiastic Beginner. Not in my career overall — but in this specific domain, right now. That distinction matters more than you might think.
Your development level isn't who you are. It's where you are — on this task, right now.
What my manager did next is what I want to talk about. He didn't look at my title and assume I had it handled. He didn't throw me into those rooms and wait to see what happened. He applied a framework — one I now carry with me everywhere — and gave me exactly the kind of support that matched where I actually was: structure, context, and a clear explanation of what was important and why. Not because he didn't trust me. Because he saw me accurately.
The model, in plain language
Situational Leadership is built on one core idea: there is no single best way to support someone. The right approach depends on where they are — their combination of competence (skill, knowledge, experience with a task) and commitment (confidence, motivation, enthusiasm for it).
The model describes four development levels, each with a matched leadership style. And the most important thing to understand before you read them is this: these levels are task-specific, not person-specific. A D4 engineer on backend architecture might be a D1 on their first technical presentation. A D4 presenter might be a D2 when they first move into a management role. You hold multiple levels at once, across different domains. So does everyone around you.
That means every time you're working with someone on something new, the first question to ask isn't "what level is this person?" — it's "what level is this person on this specific thing?"
The four development levels
What my manager got right
When my scope expanded, my manager didn't look at my years of experience and assume I'd figure it out. He also didn't swoop in and take over — which would have been equally unhelpful. He did something that required real attentiveness: he looked at what I was being asked to do in those new spaces, assessed where I was on that specific set of tasks, and matched his support accordingly.
He gave me context before I walked into rooms — what to pay attention to, what questions were worth asking, what the financial metrics actually meant in our context. He debriefed with me after. He told me what I was doing well before I could see it myself. He helped me build a mental model for spaces that were new to me, without making me feel like a beginner was a bad thing to be.
That's S1 and S2 applied well: directing and coaching, in the right sequence, fading as my competence grew. And here's what struck me most about it — it was one of the most respectful things anyone has done for me professionally. Not because it was easy or automatic, but because it required him to see me accurately instead of seeing what my title said I should already be able to do.
The mismatch that causes the most damage isn't treating a D1 like a D1. It's treating a D1 like a D4 — handing them autonomy they haven't built the foundation for yet, and then wondering why things aren't going well.
How to use this as an IC
Here's what Zillow's version of this training made clear: you don't have to be a manager to use this model. You can use it to understand yourself, to ask for the right kind of support, and to offer it to the people around you.
When you take on something new, ask yourself: where am I on this, really? Not where my title says I should be. Not where I wish I were. Where am I right now, on this specific task? Being honest about that is the starting point for getting the support that will actually help you.
When you're supporting a peer, ask the same question about them. Have they done this kind of work before, or is this genuinely new? Are they hesitating because they don't know how, or because they don't yet trust that they know how? Those are different problems with different solutions. The first one needs direction. The second one needs someone to ask them what they think.
Quick reference: what to ask for, what to offer
The thing that stays with me
You are never just one level. Right now, in your career, you're probably a D4 in some things and a D1 in others — and somewhere in between on everything else. That's not a contradiction. That's just what it means to keep growing.
The people who use this model well — the managers, the senior ICs, the team leads who have the most positive impact — aren't the ones who label people and stay fixed in those labels. They're the ones who stay curious about where someone actually is, stay willing to update their assessment as things change, and stay generous enough to match their approach to what the person in front of them genuinely needs.
That's what my manager did for me when my scope changed. He saw a Senior IC who was, in a very specific and legitimate way, a beginner. And he met me there — not with less respect, but with more. Because meeting someone where they are is not a concession. It's the job.
The most generous thing you can do for someone is to see where they actually are — not where you wish they were, not where their title suggests they should be.
I carry this model into every team I work with now. When I'm onboarding to something new, I name it: "I'm D1 here — I'm going to need some direction while I find my footing." When I'm working alongside a peer who's picking up a new skill, I ask what kind of support would actually be useful. When I see a mismatch — someone given full autonomy on something they just started, or someone over-directed on something they've long since mastered — I recognize it for what it is.
Situational Leadership gave me a language for something that was always true but hard to articulate. Where you are is not who you are. And the right response to where someone is — always — is to meet them there.
This piece was researched and shaped in genuine partnership with Claude, Anthropic’s AI. Tania names this collaboration intentionally — because meaningful AI partnership is worth acknowledging, not hiding.