Leave them alone? I've always worked in "teams" where 1-3 workhorses made everything happen; the rest was talking, spinning intrigues and inventing new workflow procedures (which slowed down and annoyed the workhorses).
If you don't invest a piece of your work week mentoring juniors, you're a lot less productive than you could be.
At least where I work, the "workhorses" are the ones training the new guys.
That doesn't mean you have to eliminate the workhorses, but you need to convert them from being 10x engineers to being 10x multipliers.
This is the valuable and essential element of personal growth that I'm espousing - teach yourself how to multiply the team's output.
By stopping them from producing things of value? How does this make any sense. It's the peter principle all over again.
10x + 1x + 1x = 12x
Now you convert that 10x engineer into a 10x multiplier, and let's assume he doesn't actually do real work anymore because he's helping everyone else be more productive:
0x + 10x + 10x = 20x
He may no longer be doing any work, but the rest of his team is more productive and significantly outstrips his own individual output.
That's some very impressive made-up math!
Obviously the real world is not so simple, but the effect is the same. There's the engineer that cranks out a crazy amount of code and nobody can keep up, and then there's the engineer that helps everyone else crank out more code - now everyone is learning and increasing their output. Which would you rather have on your team?
6x + 3x + 3x
Where your 10x reduces their own output to help the others triple theirs. This:
- doesn't decrease overall productivity (still 12)
- probably increases consistency across your product (with workloads being spread more evenly)
- increases bus factor
- will lead to productivity gains as the team grows
Some people that you may be working with are simply resistant to actually expending a portion of their own day to learn/grow. Even if directed by others, or when you try to help. I do find that the best use of that bending of wills is participating in regular code reviews. Offer suggestions of things that should be changed before accepting, and other things that should be done differently in the future.
When you do that, you'll see your peers taking on more and growing over time. But it isn't easy, and will never be thatn 0x + 10x + 10x that was suggested upthread.
While my outsized code productivity was decreased to near zero, my team is moving faster, which benefits the company over the long term, as well as me being able to gain the skill s needed to help mentor people in concrete fashion to become better engineers.