Earlier quoted context omitted.
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 syst…
> 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 performi…
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.