On the myth of the "10x" engineer

A lot of people have been talking about "10x engineers" and how "important" they are to things like software development. People want to put forward the idea that hiring the "right" developers (almost always white or Asian, male, from specific colleges or with specific pedigrees) is the key to making your company successful. And yes, hiring good people is important, but this "10x" stuff is complete bullshit. Let me tell you why:

Teaching + Teamwork > Raw Productivity

Assume for a moment I can get 2 or 3 times the work done that an average employee can. That's great! Now what do you do with me? If you put me nose-down in code for 40 hours a week, it's like hiring an extra person. Still great! Except that I cost the company almost as much as two junior engineers - so... not so great.

Now, what if I spend half my time teaching, mentoring, reviewing code, working with the members of my team to make them better. Say that after a year I've boosted each of their performance by a mere 25%. But then I've still put in my 100% (instead of 200%) and on a team of five the other members have contributed another +100%. But if they've learned something, that's a permanent upgrade that doesn't go away if I stop mentoring! So next year, our team gets +300% if I just write code... but maybe also if I continue to help them improve, and then the following year it's 400% instead. So on, so forth, etc. - and the company still reaps the benefits if I leave!

Combine that with the dearth of minority mentors and role models in the industry and I am far more valuable as a force multiplier than I am as an extra-productive engineer. I say that the same goes for all of these "10x" or whatever people - the idea that people can be judged only on the volume of their work output is silly and counterproductive in the long term, both for the companies they work for and the industry as a whole. Better to judge them on how much more productive they can make the people around them.

Or to put it another way, a "1x" engineer is only a liability if you're not willing to help them grow in their career. I'll take a "1x" who's willing to learn and works well with others long before I'll hire an antisocial "pro" (and have, by the way - it was a good choice).

And now, a sportsball analogy:

Consider the Boston Red Sox and the New York Yankees. The Yankees have by far the highest budget in MLB. They can (and do) buy all of the "10x" players they want - guys like A-Rod and Clemens and Ichiro. The Red Sox have a pretty big budget, but not as high. When they were very successful in the '00s, they had maybe half what the Yankees had. They also routinely lost good players to teams who could pay more. How did they win? They had amazing farm teams. They bought up promising young players and taught them how to be major-leaguers - how to win. And you know what? It worked.

Companies awash in cash can afford to go out and head-hunt the big guns. The rest of us have to develop talent. In that atmosphere, a teacher is far more valuable than a big gun. And a team player who knows how to communicate and make a whole team more productive (even if they're not teaching) is still more valuable than a big gun who only works alone.

One thought on “On the myth of the "10x" engineer”

  1. In the main I think you've nailed it Dana. I just wanted to mention a few nuanced points based on my own experience.

    1. The concept of the 10x engineer has a long history, dating back to at least the 70's. Consider the perspective of a business executive in that time period. He is much less technical and much less likely to understand the practice of software engineering than a business executive today. Unlike say at a manufacturing business from that time period, there is a much greater variance in productivity between individual contributors in our field.

    2. Great mentors are force multipliers not only on their teams' productivity, but also force multipliers on their team members' market value. I would suggest that for companies to realize those productivity gains, it's in their interest to aggressively reward that productivity boost lest they risk training great engineers for their next company.

    3. Like anything, avoid extremes. Force multipliers on 0 productivity are still 0. I've been in 1 situation where the engineering culture placed an overwhelming amount of emphasis on the values of mentorship, leadership, creativity, and theoretical computer science. In this environment self directed time got spent giving talks, building prototypes of ideas that never shipped, authoring papers, or filing patents of negligible value. Meanwhile, there was a lot of low hanging fruit left unpicked in the nuts and bolts of the everyday engineering machinery. e.g. automating manual testing steps, speeding up slow build processes, refactoring similar code, etc. that aren't sexy but in their own right can be force multipliers.

Leave a Reply

Your email address will not be published. Required fields are marked *