I’m sick of all of the whining and posturing in blog posts and comments about Microsoft’s curve (Dare, anonymous coward, Mini, also Mini). People - either ICs or leads in backwards organizations - have a belief about what review numbers and levels mean as well as how the curve influences those numbers. As a former lead who also served as a discipline manager for both test and development and who sat in on a lot of calibrations and career model discussions across the company, I’d like to clear the air a little. That said, I’m no longer managing folks, this post is my opinion, not official HR guidance, may vary from team to team and region to region, etc. However, who are you going to listen to: the IC on your team who conjures conspiracy theories, or the former manager who’s been through it and is willing to subject themselves to it again blind upon returning to the IC ranks?
On levels, scope, and ratingsBefore digging into the curve, let’s talk a little about levels and what it means to be doing work at a given level and scope. As you know, the career model is broken up into stages, each of which has a set of levels associated with it. Those stages (and, actually, the levels as well) have an associated scope. Those scopes generally move from individual features, to multiple features, to a feature area, to multiple feature areas, to part of the product unit, to the whole product units, to multiple product units, to lots of product units, to the whole division and some cross-division. If you noticed that the number of areas I mentioned just mapped to the same number of items as 59-67, that’s for a good reason: the scopes above are a good shorthand for each of the levels. There are exceptions, but they mainly happen at or above 65, and I’d be happy to talk about them some other time.
That’s all the basic stuff you probably already knew: but here’s where people get messed up. To be meeting expectations at a given scope means that you are acting as the sole, completely delegated authority with complete competence and independence at that scope. So, if you’re 61 SDE, primarily code-focused, you’re not hitting scope if your dev lead does most of the design for the area and you just write the code. As a 62 SDET, you’re not hitting scope if you’re writing test plans, automating tests, and investigating failures but aren’t starting to set the direction your areas are going in, making major decisions about the future of your areas, and acting as the leader of major work. In both cases, that’s textbook 3.0 work, no matter how many hours you put in or hats you are wearing.
People get very confused because they mistake doing larger and larger amounts of lower-scope work with doing work at the next larger scope. They also confuse impact with leadership. Just because the changes you made in your feature broke code across the division doesn’t mean you deserve to be a 65; nor does PM’ing a feature used by the whole company mean you’re a 67. Both are just part of the normal scope expectations of owning a feature. Fundamentally, you are not doing even 3.5 work (much less 4.0 or 4.5 work) unless you are exceeding the scope expectations of your current level.
What does this mean for how people fall into scores?It actually means that the curve works differently than you’d expect in practice. So, first there are the two easy groups. People who have consistently demonstrated the ability to work at a much greater scope and with independence get promos and great ratings. People who have consistently demonstrated the opposite fall into the other. But then… there’s the rest.
Speaking as a manager, I didn’t like the 3.5 score for the up-and-coming levels (below 63). Most people don’t just exceed level requirements. Folks seem to greatly exceed requirements, meet the requirements, barely miss them, or be off the deep end. Overachievers usually don’t half-do things. So, in practice, 3.5 seems (again, non-official, blah, blah) to mean that you basically were doing your job, but were doing more of your job than other people who were also basically just doing their job. And that’s where the contention comes in. Who’s to say who put in more hours? Or owned more unit features at a given scope? It’s just splitting hairs and, in my mind, results in a lot of arguments among leads and bad messages to people. If you get a 3.5 and are below about 63, you should be hearing “you did some good work, and we appreciate it, but you need to fundamentally increase your scope if you want to continue advancing.” Unfortunately, most people seem to hear “great job – improve a few little things, but keep it up!” Note that above 63, the world changes. It’s really hard for most engineers to succeed rapidly as they increase their scope from tens to hundreds of people, and even harder to prove they were successful (as things at that scope move at a slower timeframe).
I personally believe that most people – particularly at 3.5 - benefit from the curve. If people got the scores based on their impact and leadership at scope that they deserved, there’d be a lot of disappointed people out there. And don't give me the "grass is greener" theory that your group is somehow harder, filled with smarter people, etc. than other groups. Windows thinks DevDiv has it easy with scores and levels. DevDiv thinks the same of Office. Office thinks the same of MSN. MSN thinks the same of CDDG. I don't know lots of folks in CDDG, but I'd bet they think the same of Windows. A superiority complex should be listed as one of the core company values.
What about these ‘automatic’ scores?Automatic 3.0 after a promotion. Automatic 3.0 when you change groups. Automatic 3.0 when… that’s a load of hooey. Ignore what you’ve heard about the past: most general managers and above that I’ve talked to about this forbid the practice within their groups. And they’ll violently argue that it doesn’t happen. So what if it happens to you, and that’s the message you get from your lead? Don’t let your lead be lazy. It’s one thing to get a 3.0 and understand that you were either meeting or just under expectations in some way, clearly spell that out, and to understand what you need to do to excel in the next year. It’s another to get the “By Design” equivalent of review scores. I’m not implying you should challenge the review: just make them explain to you why you really got the 3.0. And if it truly seems to be policy, double-check with your discipline manager. If they concur, then find a new group. Taking on challenges and stretching your abilities is hard enough without being handicapped or under-rewarded by a lazy manager during one of the two times a year they’re expected to give you solid feedback and guidance.
Again, remember the caveat. This doesn’t apply to all people, is not “policy,” and should not be taken as official career guidance. But hopefully you’ll think a little more the next time you hear people ranting and raving about the curve, lack of promotions, and cruel managers. If I don't get fired or muted for this post, I'll follow up with some tips on how to take the reigns on your career at Microsoft and do great things for your division without getting bogged down by nay-sayers and coasters.