[jasonpeacock]

Those "workhorses" negatively contribute to your bus factor[1], they're a risk that needs to be eliminated.

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.

[1] https://en.wikipedia.org/wiki/Bus_factor

[Bahamut]

That effectively has happened at me at work - I volunteered to become a lead engineer, and have been thrust mostly into management. It has been a very enlightening experience, as I no longer am solving the difficult technical problems on a day to day basis (I maybe will solve one abnormally difficult problem every week), but I am now judged on the productivity of my team - I dropped my coding to near zero and focused on the soft skills & using my technical ability to help craft approaches for my team members to get to a more consistent level of productivity.

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.

[nvarsj]

> That doesn't mean you have to eliminate the workhorses, but you need to convert them from being 10x engineers to being 10x multipliers

By stopping them from producing things of value? How does this make any sense. It's the peter principle all over again.

[jasonpeacock]

Let's assume you have 3 engineers, one 10x and two 1x, their total output is:

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?

[loop22]

Make a 10x engineer help everyone else be more productive all day? Sounds like an effective way to lose that engineer.

[lucideer]

That's a very real possibility, so it's definitely something to be wary of and manage carefully, but if you adjust the made up math above to something more reasonable:

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

[tracker1]

That's probably a better example... I consider myself a high output person, but that's usually offset by helping others, and part of my day "growing"... Most days I spend my pre-lunch hours reviewing emails, in meetings or reading things like HN articles. Afternoons I try to stay head down (headphones on) from 1pm onward.

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.

[olavk]

So how do you turn a 10x engineer into a 10x multiplier?