> 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.