Stack ranking is a very bad idea. At MSFT, as I understand it, it led to some terrible dynamics, such as people not helping each other within teams, nor across teams, and no one wanting to stick their necks out.
Labor is the biggest cost at tech companies, so one can understand desperate attempts at getting a handle on that cost. As long as you don't throw the baby out with the bathwater...
I think stack ranking can work well when it's understood that the quality bar doesn't sit at a fixed place in the stack. Google promo committees afaik stack rank a batch of employees and then decide where in the stack to promote, and (in theory) it can be anywhere from the whole stack gets promoted to no one gets promoted.
Whether you explicitly stack rank or not, if you give some people promotions and not others, you're ranking people. Forcing you to see the whole ranking at once seems like a good way to be more objective and cut out bias.
1. Don't promote based on ranking in current role. The new roles that you are promoting into aren't the current role. Being a good X doesn't mean that you will be a good Y.
2. Organise your company around rewarding excellent work. Ranking systems reward being good at the ranking system. They rapidly become the whole focus of the organisation, I have seen >10% of an organisations time burned on simply running the system, the amount of time manipulating it was unmeasured but by observation probably greater than that.
3. What is the objective : reward great people, remove terrible ones. The latter must be done at any time, it must be fast, it must be transparent. If your system doesn't do that then it's a bad system. Stack ranking and all ranking/global performance management systems fail to do any of these. They introduce relative performance as the bar, they introduce admin. The former is potentially done by a stack ranking system, but if you are a star in such a system then seek not to work with other stars or you will descend the stack - this is bad.
4. Pay rises (not promotions) follow business performance - if the team's unit is winning the money for the team will be there. But the team might be poor compared to another team that is in a weak unit. This is natural for businesses and what should happen is that the talent from the good team should migrate to the winning unit. Businesses need to manage this with an eye to the future (building business) but stack rankings don't help this.
> 1. Don't promote based on ranking in current role. The new roles that you are promoting into aren't the current role. Being a good X doesn't mean that you will be a good Y.
Definitely some truth in this but one needs to be careful. I think the way to view it might be that being good at X is necessary but not sufficient to being good at Y (assuming Y is a promotion, more responsibility, etc.).
If you're not performing well with the level of responsibility you have at X nobody should promote you to Y. For one thing, if you perform poorly at Y you're going to do a lot more damage than at X and the only real evidence anyone has for promoting you to Y is how you've done at X.
Possibly you can (or you might think you can) test for proficiency at Y but you may well be overestimating your ability to do this, and you open yourself up to all kinds of accusations about artificiality. Not only this but high performing employees can and should legitimately question why you as a manager are unable to accurately assess their suitability based on their performance.
Finally, skills are learned. Python is a learned skill; systems architecture is a learned skill; management is a learned skill. Even bad managers can learn to be good managers, and almost everybody starts out being bad at it. The key is engagement: do you want to get better at it? Are you going to invest the time in learning the skills you need to be better? If you do then, whilst it might take a while, you'll do just fine. The point with high performing employees, and why you promote them, is that they've already demonstrated the engagement and the willingness to learn that they're going to need in order to successfully take the next step.
Not to say there won't be any mess on the way, and success is obviously not to be taken for granted. Also worth pointing out that even great managers encounter serious difficulties - it's somewhat in the nature of dealing with people.
> For one thing, if you perform poorly at Y you're going to do a lot more damage than at X and the only real evidence anyone has for promoting you to Y is how you've done at X
But X is not indicative of performance at Y, so that's irrelevant. Project management and software development aren't overlapping skill sets, so a poor developer might make a great manager.
> Finally, skills are learned. Python is a learned skill; systems architecture is a learned skill; management is a learned skill.
But like any skill, some people will need a lot more work before mastering it than others. Doubtful that this investment is always worth it.
> The point with high performing employees, and why you promote them, is that they've already demonstrated the engagement and the willingness to learn that they're going to need in order to successfully take the next step.
Or they've just demonstrated tremendous skill at their current job which may or may not reflect "engagement", drive, ambition, whatever you think it's measuring.
Some mathematical studies have actually demonstrated the truth of the Peter principle, and how many hierarchical organizations would actually improve efficiency if a certain subset of promotions were randomly selected.
> Ranking systems reward being good at the ranking system.
This is how most of the banking works, anywhere (in fact I think most big oldish corporations). Most people go to the work just for the money, the mission is usually pretty pathetic and/or amoral (get rich guys richer, take as many fees from customers as possible, rob other players on the market etc).
Tons of semi-competent folks, usually various managers playing their games of perception - how do I look to the guy/lady who will be distributing bonuses/promotions.
I don't blame them, this is how whole system is set from C-level all the way to the bottom. That's how the top of the pyramid got there, why would they change the game they excel at. Just pure excellence at your work is possible, but a very ineffective way of getting rewards.
The tricky bit for #4 is if you're, say, a high-performing engineer on a team that's being poorly mis-managed so as to create little business value, getting a disappointing performance review is far more likely to cause you to leave the organization entirely than to switch to a different team. Creating a company culture that engenders that sort of trust and loyalty is not impossible, but still non-trivial.
The parent seemed to be describing a situation where there was a market whereby good talent will inherently flow from bad projects to good projects within an organization. I think my point is they usually don't migrate to a new project within the company, they migrate to another company.
It's true that good IC-level work is often a waste in an organization whose management is too dysfunctional to be focusing on the right things, but an org where all the good people leave is going to find itself in trouble.
If you give some people promotions and not others, you're ranking people.
In an ideal world 'promotions' should be a) a completely separate discussion from pay rises (as in a promotion is not automatically connected with getting a pay rise and ideally you should have to prove yourself in your new position before you even get to discuss pay) and b) not based on how good you are at your current job, but how good someone thinks you might be at the job you're promoted into.
I've seen several cases where the best engineers get promoted into positions of greater responsibility simply because they're the best engineers and completely floundering in the new role because it's largely unrelated to what they're actually good at. On the same note I've also seen fairly mediocre engineers get promoted and excelling in their new role since the new role fit them a lot better.
If you're great software engineer you should be able to spend 20 years at a company as software engineer with the job title software engineer and still get regular pay rises and end up earning the same or more as the senior managers.
I really like the way it's commonly done in German industry. You will typically see a union negotiated compensation table with a very wide range of set pay grades. The entire table (i.e. ever employee) gets a raise every year to stay competitive with the labor market. When you enter the company, you get assigned a grade appropriate for the position (plus whatever additional pay you negotiated). As your value to the company rises, you advance to higher grades.
Actual promotions in the org chart are entirely seperate from that. This can and often does lead to situations where an average engineer makes more money than his team lead.
I think you have a slight misunderstanding of how Google promo committees work. Assuming you work there, please try and find a senior engineer or a manager you trust and get them to walk you through how it works.
Only if the average equals the median. There is a low probability that they are equal if you randomly pick a distribution from the set of all possible distributions (and round the percentages to the nearest integer).
Edit: I am not a statistician so maybe the above is totally incorrect. The myth half of a sample is below the average triggers me every time!! Sorry.
That's my point - it's a misleading statistic. If you have a cohort of geniuses, half of them are still going to be very smart. The premise of stack ranking is you fire the bottom tier.
Huh, interesting, I don't believe that's consistent with Google's use of the term from what I remember, but that does seem to be the meaning I'm finding now.
So yeah, fair enough, I do just mean "ranking" I guess.
It's my understanding that labor is not the biggest cost at netflix, compared to licensing and production, which is part of why they pay engineers so much.
Contrast with google where they consciously avoid anything like stack ranking. And incentivize helping (via peer review and peer bonus). If you ask a reasonable question people are happy to help and they genuinely try to help you succeed. (If you succeed they succeeded in helping you succeed)
Labor is the biggest cost at tech companies, so one can understand desperate attempts at getting a handle on that cost. As long as you don't throw the baby out with the bathwater...