A recent series of tweets about identifying 10x software engineers set off a lot of making fun of the author for perpetuating a myth. Given the wording of the tweets too they made a particularly easy target (I can’t actually find them right now or I would link to them). All that poking fun though obscures some interesting questions about individual and team productivity in software engineering.

Before getting to software though I want to point to a related interesting phenomenon. Just three players: Federer, Nadal and Djokovic have dominated men’s tennis over the last 15 or so years. Between the three of them they have won 53 of the last 64 grand slam tournaments. Each one of them has won roughly 10x as many grand slam tournaments as players in the next best group. There is a similar story on the women’s side. Serena Williams has won 23 grand slam titles and at one point was the number #1 ranked player for 186 consecutive weeks!

There are several things worth noting here. First, 10x outperformance is clearly observed in some domains. Second, 10x outperformance in tennis can’t be attributed to any one single factor. Federer doesn’t serve 10x as fast as other players. Serena doesn’t run 10x as fast as other players. And so on. In fact along many dimensions these players have only a slight edge. But when combined with tennis’s scoring mechanism that small edge translates into huge outperformance. All the points that someone won against a top player mean nothing when the match is over.

Writing software has some interesting parallels. You can feel like you are making a lot of progress (scoring points as it were), but eventually you run into a problem and you wind up having to rewrite a lot of what you did or discard it altogether. Worse yet, you may not be willing to admit to yourself that this is the case and double down on your flawed code, making it worse. This happens all the more when you have many people collaborating on a piece of software. Put differently, writing software is also a compounding process where small advantages at each stage can result in massive differences in total productivity.

A number of studies of open source projects have shown power law distributions in contributions. And many famous projects have been built by very few developers, with the first version often written by a single individual. I have also observed this in commercial contexts. For example, in the earliest version of the 10gen platform the database (which later became MongoDB)  and the application server were each written by a single engineer.

Now this doesn’t mean at all that you can or even should hire someone with that background to join your team. A lot depends on what stage you are and what you are building. As a first approximation having someone like this on your team works best when you are early and are building something technically complex (e.g. a database). And you better make sure you are really aligned on what you are building, ideally they are a co-founder. Or if you bring someone like this on later, they better work on the first version of a well defined sub system which they can own. 

In many other contexts, someone like this can be completely disruptive, annoying or even impossible to work with. And to come back to tennis, it has proven very difficult (impossible?) to build successful Davis Cup teams around some of these extraordinary individual players. So bottom line: individual 10x productivity can exist but can also be incredibly hard or impossible to harness for a team effort.

A recent series of tweets about identifying 10x software engineers set off a lot of making fun of the author for perpetuating a myth. Given the wording of the tweets too they made a particularly easy target (I can’t actually find them right now or I would link to them). All that poking fun though obscures some interesting questions about individual and team productivity in software engineering.

Before getting to software though I want to point to a related interesting phenomenon. Just three players: Federer, Nadal and Djokovic have dominated men’s tennis over the last 15 or so years. Between the three of them they have won 53 of the last 64 grand slam tournaments. Each one of them has won roughly 10x as many grand slam tournaments as players in the next best group. There is a similar story on the women’s side. Serena Williams has won 23 grand slam titles and at one point was the number #1 ranked player for 186 consecutive weeks!

There are several things worth noting here. First, 10x outperformance is clearly observed in some domains. Second, 10x outperformance in tennis can’t be attributed to any one single factor. Federer doesn’t serve 10x as fast as other players. Serena doesn’t run 10x as fast as other players. And so on. In fact along many dimensions these players have only a slight edge. But when combined with tennis’s scoring mechanism that small edge translates into huge outperformance. All the points that someone won against a top player mean nothing when the match is over.

Writing software has some interesting parallels. You can feel like you are making a lot of progress (scoring points as it were), but eventually you run into a problem and you wind up having to rewrite a lot of what you did or discard it altogether. Worse yet, you may not be willing to admit to yourself that this is the case and double down on your flawed code, making it worse. This happens all the more when you have many people collaborating on a piece of software. Put differently, writing software is also a compounding process where small advantages at each stage can result in massive differences in total productivity.

A number of studies of open source projects have shown power law distributions in contributions. And many famous projects have been built by very few developers, with the first version often written by a single individual. I have also observed this in commercial contexts. For example, in the earliest version of the 10gen platform the database (which later became MongoDB)  and the application server were each written by a single engineer.

Now this doesn’t mean at all that you can or even should hire someone with that background to join your team. A lot depends on what stage you are and what you are building. As a first approximation having someone like this on your team works best when you are early and are building something technically complex (e.g. a database). And you better make sure you are really aligned on what you are building, ideally they are a co-founder. Or if you bring someone like this on later, they better work on the first version of a well defined sub system which they can own. 

In many other contexts, someone like this can be completely disruptive, annoying or even impossible to work with. And to come back to tennis, it has proven very difficult (impossible?) to build successful Davis Cup teams around some of these extraordinary individual players. So bottom line: individual 10x productivity can exist but can also be incredibly hard or impossible to harness for a team effort.