Speaking for myself, I'm done with primadonna developers who think they can shut the door and code alone while running roughshod over their colleagues, then after a couple of years take off and leave behind their mess for others to sort out.
Development is a team sport. If you don't buy into that you won't be working at my company.
Meanwhile, management should provide opportunities for training and so forth to develop their talent.
BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else.
It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others.
In computer engineering terms, you have to balance your control path as well as your data path.
But not to the exclusion of all else.
Again: a team is a team. I, as a manager, need the team to functional optimally. If one developer is a 10x hotshot, but she makes the lives of everyone else substantially worse, I don't give a crap how much code she can write, she can find another team.
The top developer doesn't get to be a silo, a dictator, or a troublemaker. As a high-skilled individual, they are expected to produce code, collaborate with team members effectively, provide mentoring and training, and generally lead by example.
Again, if they can't handle that, they can find a company where their style is a better fit.
No, that's where you're wrong. If that developer is really your top producer, the bottleneck of production, you isolate and protect her exactly to the exclusion of all else. She becomes the worker that cannot, will not, be bothered. It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.
To get your team to function optimally, you must protect the core assets. And given that those assets are people, they have to feel protected. In the end, the rest of your team exists to support whatever it is that actually creates value. If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Ideally, though, no team is so one sided. There are no true 10x developers. And those that exist utterly fail at the rest of team management. At the end of the day, give your workers work they can actually do.
Development isn't an assembly line, and the fact you'd use that analogy says a lot...
If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Oh heck no.
If one person or only a few people are creating most of the value on the team, the team is dysfunctional and you've exposed yourself to enormous risk. If those people leave, fall ill, get injured, or go on vacation, you and the team are screwed. If you, as a manager, have put yourself in that situation, you have failed.
You're talking about risk management, not individual worker ability. Yes, it is a poor idea to have any one portion of a system maintained by only one person. So don't. It is a poor idea to have only one person who understands the system architecture. So don't. It's a poor idea to not recognize the different strengths and weaknesses of all your workers regardless of context. So don't.
Just because I label development an assembly line doesn't mean treat your developers like machines. They are machines, human machines. Meaning they have feelings and a whole host of things that must be managed in addition to keeping them well oiled.
"They are machines, human machines."
Contradiction.