Hacker News new | ask | show | jobs
by 1091298301 3398 days ago
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).
2 comments

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.

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.

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

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.

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

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?

Make a 10x engineer help everyone else be more productive all day? Sounds like an effective way to lose that engineer.
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

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.

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