I’m sitting here and I’m tired. It’s not long hours. It’s not a cold coming on. It’s not a lack of sleep. It’s the idea of explaining for the thousandth time how someone with three reports can be an individual contributor or why there isn’t a special Career Stage Profile for an architect. The answer to both questions is simple: role ¹ career stage. Get it? I didn’t think so. Darn, I’m tired.
Eric Aside Career Stage Profiles are detailed descriptions of the work expected of employees at different career stages for different disciplines. Generally, for each discipline there are three sets of stages: entry stages (for U.S. developers, that’s levels 59–62), technical leadership stages for individual contributors (levels 63–69), and organizational leadership stages for leads and managers (levels 63–69).
Look, you’re not dumb and neither are the other thousand people I’ve temporarily enlightened. There’s some subtlety to this; words get overloaded and confused. But it really isn’t complicated—role and career stage just aren’t the same thing.
One, in time, plays many parts
Perhaps some definitions will help. A role is like a part in a movie. Different people can play the same role. The same people can play more than one role. In fact, you can play multiple roles in the same meeting or conversation. It happens all the time.
For example, say you are a dev lead discussing a feature implementation with an old friend who happens to report to you and is also married to your cousin. In the same conversation, you could play the role of manager, friend, architect, relative, peer, mentor, and adversary. That’s an extreme case, but perfectly plausible.
Roles can change by the minute, but typically at work we have a primary role, perhaps a secondary role, and a handful of lesser roles. For instance, some architects have a small number of reports. Their primary role is architect. Their secondary role is lead. Their lesser work-related roles include Microsoft employee, peer, tester, designer, mentor, and subordinate.
Stage right
Career stage is quite different from role. Career stage doesn’t change by the minute. You don’t have multiple career stages—you’ve got one. You might reference a number of career stage profiles in your commitments because they help define the roles you play. However, you are still only residing in one stage at any given point in your career. (I’ll explain why later.)
So what is a career stage? A career stage defines your progress in your chosen growth path. Because you are only in one career stage, knowing which one is important. To validate your current career stage follow these steps:
- Select your discipline: dev, test, PM, UX, and so on.
Eric Aside UX stands for the User Experience discipline, mostly designers and usability experts.
- Select your career aspiration: technical leader (individual contributor stages) or organizational leader (manager stages).
- Review the career stage profiles with your manager to fit your skill set, discipline, and aspiration to a career stage. (Your current level and region often provide a clear starting point.)
I aspire, sir
Remember, it’s not your current role that matters. It’s your aspiration. Say you are in a dev lead role, but you want to be known for your technical leadership, not your management skills. If you are a developer at level 64 and work in Redmond, theoretically your career stage could be either Lead SDE or Senior SDE. However, because your aspiration is to be a technical leader your career stage should be Senior SDE.
“But I’m a dev lead,” you say. Yeah, if you want to stay a dev lead or perhaps one day become a dev manager, that’s fine. But if you want to become a technical leader, then either switch your career stage to Senior SDE or enjoy being dead-ended as a Lead SDE.
“But I have three reports,” you say. Yeah, so one of your roles is a lead. Big deal. That has little to do with your chosen career growth. If you want to grow as a technical leader, then you must choose that growth path. Sure, you still need to be a good manager in your lead role and many of your commitments will still come from the Lead SDE stage, but those won’t be your career development goals.
Overqualified
“But what if I’m a level 66 Principal SDE and I’m happy being a lead?” you say. Lead SDE tops out at level 64 in Redmond (level 65 is in the accepted range). At level 66, you are overqualified to be in the Lead SDE stage (though you certainly could still play the lead role).
Why does the Lead SDE stage top out at level 64? Because at Redmond level 64 you should have all the skills and scope the lead role requires. If you are level 66 or higher, you didn’t get there because you could manage a small set of individual contributors really well. You got there because of your technical leadership. If you stopped being a technical leader and played only the lead role, you’d be underperforming as a level 66. That’s why your career path is technical leader and your career stage is Principal SDE.
Eric Aside Leads topping out at level 64 was the biggest point of contention about this column. People, important people I respect, thought I was saying that dev leads can’t be above level 64. They misunderstood. My point is that if you are above level 64, you must have more going for you than managing a small team. It must be an important team, and you must be providing strong technical leadership. Thus, your continued growth isn’t the result of your small-team management skills, it’s the result of your technical insight and guidance. You want your career stage designation to match your source of growth, while maintaining your secondary role as dev lead.
I’m special
“So why is there no architect career stage?” you say. Being an architect is a role. You need different career stages for different growth paths, but not for different roles. The growth path for a highly technical specialist is the same as the growth path for an architect. Both are technical leaders, so they both share the same career stages.
Sure, the role of an architect is different from that of a world-renowned expert in database logging. But they must have similar skills and develop in similar ways to advance. Thus, they are both either Principal or Partner SDEs.
There can be only one
“Okay, fine, but why can you be in only one career stage?” you say. If you can play multiple roles, why not have multiple career stages? Because your career stage is tied to your growth path, which is tied to your aspiration.
Most healthy individuals with single personalities have one career aspiration at a time. Yes, it can change from time to time. But at any given point in your life, you have one primary career goal. That one goal determines your career stage uniquely.
Now you could conceivably aspire to be a major technical leader and organizational leader simultaneously, but you’d fail in a miserable way. The reason isn’t due to a lack of effort. Enough amphetamines could keep you working 24 hours a day for weeks at a time.
The problem is that being a leader means leading others. That means communicating with them, but not everyone is around all the time. At the end of the day, the availability of others constrains how much leading you can do in a day. To be a great leader, you must focus your efforts.
What do you want to be?
What do you want to be when you grow up? That’s the central question the career model asks. You don’t need to have the perfect answer. You just need an answer for now that can focus your efforts and allow you to make progress.
“Pick one and go with it” is the advice I prefer. You can switch later if your aspirations change, but meanwhile you’ll learn and grow. We don’t always become what we set out to be. It’s the journey that holds the interest. But you can’t just stand undecided at the fork in the road. Choose your path and enjoy the ride.
Eric Aside It’s been nearly five years since I wrote this column, and people still confuse roles and stages. To avoid confusion, Microsoft has considered adding a lead path to the engineering disciplines alongside the IC and manager paths. Personally, I’d drop the IC and manager paths altogether. I’d separate being a lead or manager as a role. All developers would be developers, but some would have management roles, architect roles, web service roles, and so on.
Be First to Comment