[jasonpeacock]

Similarly, learn how to be a "force multiplier". Don't be the 10x engineer, but instead be the 10x multiplier.

How do you increase the quality & output of your entire team/org/company? Better features, fewer bugs, faster releases, etc. Learn what it takes to effect that change, and then learn how to make that impact wherever you are.

[1091298301]

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

[jknoepfler]

Not a sustainable model, or a formula for growth. If you genuinely think this fire your time wasters and raise your hiring bar.

If you don't invest a piece of your work week mentoring juniors, you're a lot less productive than you could be.

[candiodari]

Have you ever seen a product manager or "the meeting guy" train juniors ? That doesn't even make sense, as you haven't hired those juniors to do either product management or "stakeholder management" or ... whatever the next fashionable term will be, so they simply can't provide the training that is needed.

At least where I work, the "workhorses" are the ones training the new guys.

[aries1980]

I did and I was one of the mentee as an engineering lead. All I needed is to attend on meeting and listen or support the PM, but it was invaluable to see how to reason, convince stakeholders, gather requirements and objective feedback, and how not to give a fig to the emotions.

[aries1980]

Not every problem has to be solved in team fashion and not every member of an organisation has to fit in a hiring pattern. Also there are “brilliant jerks” or people with out-of-fashion worldview. These people could have their place in an organisation. Clearly this is a leadership challenge, but hey, leaders should learn hard and be great as much as their engineers.

[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

[olavk]

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

[clumsysmurf]

Sound like a 'distinguished engineer'. Some good thoughts about there here:

"On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer"

http://redmonk.com/fryan/2016/12/12/on-the-myth-of-the-10x-e...

[avaer]

If you really _are_ a 10x multiplier on a team, you should immediately quit and run your own show, because there's otherwise no chance you're being compensated remotely fairly -- nine times the sum of everyone else's wage.

[groby_b]

If money were the only meaningful thing in life, you might have a point.

In the meantime, many of us are happy enabling other people to be more productive and making an amount of money that can certainly be described as satisfactory.

But even if you want to maximize salary, being a 10x multiplier on a team in a large company is a very different thing from running a company. (And running a company is a very different thing from necessarily making insane amounts of money)

[mahyarm]

So you mean join the developer tooling & infra team?