The best developer on the team. The one who fixes the bugs nobody understands, the one everyone goes to, the one who knows where everything lives. Review time comes and the reward seems obvious: they get promoted to lead.
Six months later the team has lost its best developer and gained a leader who's having a hard time. They get into everyone else's code, can't find time for one-on-ones, miss programming and feel their job is now going from meeting to meeting.
Laurence J. Peter and Raymond Hull wrote about this in 1969, in a book with a good dose of satire, and named it the Peter principle: in a hierarchy, every person tends to rise to their level of incompetence. The logic is simple and a little cruel. If you get promoted every time you do your job well, the promotions stop right at the job you don't do well. And there you stay.
The promotion got used as a prize without asking what the new job was going to need.
Think of the best mechanic in the shop, the one who hears a noise and already knows what it is. One day the owner retires and they put him in charge of running the shop. Now he has to give quotes, deal with angry customers, organize schedules and fight with suppliers. Fixing cars and running a shop only look alike from the sidewalk.
In tech it goes from dev to tech lead, from tech lead to manager, from manager to director. With every jump the job changes more than it seems. Programming well helps you very little when it comes to having a difficult conversation, supporting someone who's struggling or negotiating priorities with another department, and almost nobody prepares you for that. They give you the title and you learn on the job with the team watching, which is the perfect recipe for impostor syndrome.
A couple of things change the outcome quite a bit. Separating growth from a change of role, to start with. If the only way to earn more and be recognized is to start managing people, we'll keep turning good devs into leaders who didn't want to be leaders. There has to be a way to earn more and have more influence without leaving technical work.
Treating the promotion as what it is, a new job. Trying it out first and gradually, with a small initiative or a temporary role, to see whether the person likes it and is good at it before it becomes permanent. Someone doing well where they are doesn't tell you how they'll do leading.
And making sure going back doesn't count as failure. Someone who tried leading and decided to go back to technical work made a mature decision. If the system punishes them, the next person won't even dare to try.
Sometimes someone's potential is in a place they haven't explored yet, and part of a leader's job is helping them find it. That place doesn't have to be higher up the org chart. Some mechanics are happy under a car until their last day, and there's nothing to fix there.