As a bit of MSFT-specific advice, if you're in the dev/test/pm org and an IC and feel this way, you should make sure that you're having a regular (e.g. every six months) 1:1 with your manager's manager. During that, you should try to get a deeper understanding of what the next level means. There are certain levels (63, 65, 68) whose promotions are significantly different than the other levels and can be intimidating, particularly to first-time leads. For example, at 63, your lead might have to justify the promo to your PUM, and at 65, your lead has to convince your discipline manager to justify it not only to your PUM but has to provide enough info about your comparable work to have it justified with all the discipline managers across your division at the calibration meeting.
Unless you are in an extraordinarily technically deep area (e.g. compiler frontend, database internals), you should not expect your lead to be an amazing manager. If they were, they'd have left you behind and be a manager of managers within ~3 years because there aren't nearly enough of those to go around.
Granted the departments I worked at were sent off to India but I was basically triaging and routing tech support calls. What impressed me about the people I worked with was how underemployed they were. We had folks with masters degrees in math who were solid programmers, solid sysadmins, etc. in the team as FTE's, and people who worked there with similar credentials as temps tended to get good jobs at Microsoft elsewhere, but if you took an FTE position in that department you had a really hard time getting into something better.
In fact there was only one way to do it: get a job somewhere else, and then apply back. Things were so bad at one point that HR was actually recommending this as a career path.
I would certainly agree that the path from product support to any of the product development arms is not an easy one internally, particularly for an FTE role where it is generally expected that you would have a CS degree. Especially after the move to eliminate the software test engineer position in favor of software design engineer in test, which basically eliminated the career path for people who were solid developers or sysadmins but didn't also have a good theoretical CS background.
The temp positions are much more lax in almost all groups. The individual with budgetary authority has nearly complete control over the vendor choice and individual hires, so long as they don't do anything unethical. So, if you can sell to that person that you are qualified, smart, and motivated, they will probably give you a chance. It's typically only a 6-11 month commitment, anyway, and so many of the contractors are checked out that anybody with a spark of enthusiasm really shines in the interview process.
Maybe this explains why so many of the great open source software engineers I have worked with used to also work at Microsoft's Product Support Services ;-)
@larsberg's comment tells me (as an outsider) why Microsoft will die. It has the corporate equivalent of arteriosclerosis. Whether theirs products are good or not is beside the point.
All companies are both predator and prey. With inscrutable insider rules like this Microsoft cannot move fast enough to survive as either.
I was recently reading what I had written about Microsoft, Sun Microsystems, and Oracle in 2004 as part of a business plan. My outlook for Microsoft was simple: Painful days are ahead but Microsoft has what it takes to succeed. Sun, not so much. Oracle could go either way.
Seems I was right about Sun, not sure yet about Microsoft. I now think Oracle is in a better position than they used to be.
One of the major things I noted was that Microsoft, despite a major institutional aversion, has been slowly developing and expanding services businesses. They have continued to do this, for example now offering to host Linux VPS's via Azure. Their services offerings in 2003 were more anemic than they are today. They are on the right track to deal both with open source competition and long-extended upgrade cycles.
I don't think Microsoft is about to die. They may be cut down to size but I think their offerings are large and diverse enough that they are more likely to be pressured to evolve than disappear. Many businesses in fact do this, see IBM's transformation into one of the world's largest IT services firms in the world.
2) Healthy services business (customer satisfaction, etc) These are important because they are a hedge against open source software and upgrade cycles that extend as hardware matures.
3) Lack of vertical integration/insularity
4) Organizational awareness of issues.
Sun scored relatively low on these, Oracle depended on how heavily you rated customer satisfaction and customer perceptions, and Microsoft scored high on everything but healthy services businesses, but there they were growing and trying lots of things.
Realize that my info is ~10 years old. At the time I was leaving Microsoft, they were working on adding more transparency to the process since, as you'd guess, people wanted to know more. Part of that was explicit titles tied to levels; part was just informing people of the process.
And at least there _are_ guidelines. Have you ever worked at a small company? There are certainly exceptions (I'd gamble that Fog Creek is one), but most of the ones I've worked at or for have had salary and promotion schemes that basically came down to some mix of hiring manager's whim, highest priority for the company today, your public visibility before joining, and whether you have some family connection to the owners.
To be fair (and like others have said re: Amazon), this sounds pretty particular to a specific team. In other teams, it's pretty clear what you have to do in order to get promoted. I overheard from some employees that at the last meeting they had on the subject, management was very straightforward, saying that they had X spots available and Y people to consider. If you did the right things, they would consider you, and promote the best X people. I think this approach is about as good as it can be in a large org.
Comments
> I saw this at Microsoft
As a bit of MSFT-specific advice, if you're in the dev/test/pm org and an IC and feel this way, you should make sure that you're having a regular (e.g. every six months) 1:1 with your manager's manager. During that, you should try to get a deeper understanding of what the next level means. There are certain levels (63, 65, 68) whose promotions are significantly different than the other levels and can be intimidating, particularly to first-time leads. For example, at 63, your lead might have to justify the promo to your PUM, and at 65, your lead has to convince your discipline manager to justify it not only to your PUM but has to provide enough info about your comparable work to have it justified with all the discipline managers across your division at the calibration meeting.
Unless you are in an extraordinarily technically deep area (e.g. compiler frontend, database internals), you should not expect your lead to be an amazing manager. If they were, they'd have left you behind and be a manager of managers within ~3 years because there aren't nearly enough of those to go around.
Granted the departments I worked at were sent off to India but I was basically triaging and routing tech support calls. What impressed me about the people I worked with was how underemployed they were. We had folks with masters degrees in math who were solid programmers, solid sysadmins, etc. in the team as FTE's, and people who worked there with similar credentials as temps tended to get good jobs at Microsoft elsewhere, but if you took an FTE position in that department you had a really hard time getting into something better.
In fact there was only one way to do it: get a job somewhere else, and then apply back. Things were so bad at one point that HR was actually recommending this as a career path.
I would certainly agree that the path from product support to any of the product development arms is not an easy one internally, particularly for an FTE role where it is generally expected that you would have a CS degree. Especially after the move to eliminate the software test engineer position in favor of software design engineer in test, which basically eliminated the career path for people who were solid developers or sysadmins but didn't also have a good theoretical CS background.
The temp positions are much more lax in almost all groups. The individual with budgetary authority has nearly complete control over the vendor choice and individual hires, so long as they don't do anything unethical. So, if you can sell to that person that you are qualified, smart, and motivated, they will probably give you a chance. It's typically only a 6-11 month commitment, anyway, and so many of the contractors are checked out that anybody with a spark of enthusiasm really shines in the interview process.
Maybe this explains why so many of the great open source software engineers I have worked with used to also work at Microsoft's Product Support Services ;-)
@larsberg's comment tells me (as an outsider) why Microsoft will die. It has the corporate equivalent of arteriosclerosis. Whether theirs products are good or not is beside the point.
All companies are both predator and prey. With inscrutable insider rules like this Microsoft cannot move fast enough to survive as either.
I was recently reading what I had written about Microsoft, Sun Microsystems, and Oracle in 2004 as part of a business plan. My outlook for Microsoft was simple: Painful days are ahead but Microsoft has what it takes to succeed. Sun, not so much. Oracle could go either way.
Seems I was right about Sun, not sure yet about Microsoft. I now think Oracle is in a better position than they used to be.
One of the major things I noted was that Microsoft, despite a major institutional aversion, has been slowly developing and expanding services businesses. They have continued to do this, for example now offering to host Linux VPS's via Azure. Their services offerings in 2003 were more anemic than they are today. They are on the right track to deal both with open source competition and long-extended upgrade cycles.
I don't think Microsoft is about to die. They may be cut down to size but I think their offerings are large and diverse enough that they are more likely to be pressured to evolve than disappear. Many businesses in fact do this, see IBM's transformation into one of the world's largest IT services firms in the world.
Just as a note on the factors I looked at:
1) Cash positive operations and cash reserves
2) Healthy services business (customer satisfaction, etc) These are important because they are a hedge against open source software and upgrade cycles that extend as hardware matures.
3) Lack of vertical integration/insularity
4) Organizational awareness of issues.
Sun scored relatively low on these, Oracle depended on how heavily you rated customer satisfaction and customer perceptions, and Microsoft scored high on everything but healthy services businesses, but there they were growing and trying lots of things.
Realize that my info is ~10 years old. At the time I was leaving Microsoft, they were working on adding more transparency to the process since, as you'd guess, people wanted to know more. Part of that was explicit titles tied to levels; part was just informing people of the process.
And at least there _are_ guidelines. Have you ever worked at a small company? There are certainly exceptions (I'd gamble that Fog Creek is one), but most of the ones I've worked at or for have had salary and promotion schemes that basically came down to some mix of hiring manager's whim, highest priority for the company today, your public visibility before joining, and whether you have some family connection to the owners.
To be fair (and like others have said re: Amazon), this sounds pretty particular to a specific team. In other teams, it's pretty clear what you have to do in order to get promoted. I overheard from some employees that at the last meeting they had on the subject, management was very straightforward, saying that they had X spots available and Y people to consider. If you did the right things, they would consider you, and promote the best X people. I think this approach is about as good as it can be in a large org.
I haven't heard of any organization with ~100k+ people without rules like these.
Remember when Microsoft was a scrappy company who made fun of IBM for being so bureaucratic?