10x (engineer, context) pairs

People have big arguments over whether “10x engineers” exist or not. Pro:

The differences are not minor—it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.

Contra:

There is no conclusive body of scientific research to suggest that the 10x engineer is in fact a real phenomenon, much less one that provides us with a deep and actionable understanding of the factors, conditions and stipulations of their existence. Yet we continue to regurgitate the mythology, over and over again.

The “anti 10x engineer” crowd is right that the quality of the cited research is highly dubious. It’s especially dubious if you imagine that these supposed 10x engineers are literally writing the same code 10x faster, as many non-technical people seem to think. (“Their keyboard keys such as i, f, x are usually worn out than of [sic] a, s, and e (email senders).” Come on, really?!)

On the other hand, you don’t need studies to know that engineers do vary by orders of magnitude in their output of all-things-considered usefulness. Compare say, my output with that of Jeff Dean and Sanjay Ghemawat: they’ve clearly been at least 10x more productive, probably more like 100x. But that’s not just because Jeff and Sanjay can solve individual problems 100x faster than I can. Instead, they gave themselves leverage by choosing the right problems to solve:

For those who work inside Google, it’s well worth it to look at Jeff & Sanjay’s commit history and code review dashboard. They aren’t actually all that much more productive in terms of code written than a decent SWE3 who knows his codebase.

The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they’re able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote.

Most importantly, Jeff and Sanjay also found the right context—a hypergrowth company blocked on infrastructure scaling problems—where the things they were great at building were extremely useful.

Posts on topics like “how to find a 10x engineer” encode the assumption that “10x-ness” is some immutable trait of a person. But in reality, that type of leverage can be incredibly specific to one particular set of circumstances. Jeff and Sanjay weren’t 100x more productive than average at their previous companies; there was something about the Google environment that worked particularly well for them. Anecdotally, I’ve seen many people go through similar swings in productivity at different times:

The common thread in these examples is that your actual output depends on a lot more than just how quickly you finish a given programming task. It also requires you to:

All the other non-programming tasks on this list depend deeply on the way you interact with the organization around you:

These factors can vary hugely between different roles, even within the same team and company. The “10x more productive” people I’ve seen have been both (a) very conscious of the above factors, and (b) adept at navigating towards situations where those factors push them towards success rather than failure. Similarly, as a manager I view one of my most important jobs as helping people find the role and environment that works the best for them.


  1. You could argue that the failed social mobile apps were equally productive in expected-value terms, but I actually don’t think that’s true; consumer apps are underrepresented in the top YC companies and the pivot to doing something “real” increased productivity in two ways: it improved morale, and it helped the founders navigate more effectively towards a business with high potential. ↩︎

Comments

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.