Over the last few days there was a big discussion on Twitter about 10x developers. Shekhar Kirani claimed many things about what 10x developers do and how one shout accept their oddities because they are so much better than the other developers and that they single-handedly will solve all problems. If you did not already have read any of those ideas, you can find them here:
10x engineers
Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.
OK, here is a tough question.
How do you spot a 10x engineer?
— Shekhar Kirani (@skirani) July 11, 2019
Among the most disturbing ideas are the total absence of communication, the inability to mentor anyone and, to no surprise, the total lack of documentation. That combination alone is highly likely going to kill your project when this “unicorn” developer leaves your company – voluntarily or by burn-out.
What I find the most telling part of the whole 10x developer discussion (in general and not limited to the current one) is the missing definition of what those 10x should be and how they measure it. Therefore, I will use the rest of this post to deliver possible calculations in a rather satirical way. Be warned, the calculations I use may be flawed and this is more a rant than any serious consideration of facts.
If you are interested about the origin of the 10x claim you should read the book “The Leprechauns of Software Engineering” by Laurent Bossavit. He tracks down the different studies and explains how little they support that claim.
10x as good as the worst?
Whenever you work with a group of people, you will have some people who deliver a lot more work than most team members and a few ones who deliver a lot less. If you only look at the extremes, the difference is massive. If you take the worst one as your base line, you have some 2x, 5x and maybe even 10x developers right in your team. Does this mean anything? No.
The next sprint will change the performance, the calculation can be done again, and others are now on top or at the bottom. It is absolutely pointless and can easily be manipulated. All it takes is a bad performing base line and the worse their performance is, the better is everyone else.
As good as 10 other developers?
Having 1 developer that is as good as 10 other developers or gets as much work done is a lot more meaningful. At least when you don’t know anything about the work they do. In the best-case scenario, the other 10 developers are getting something important done. Then you gain something by one developer doing the same work alone.
However, if those other 10 developers only fix what their peers did and can’t create any value, then having a 10x developer is not hard. In this case, your company probably don’t need another developer, a change in how they organise their work may bring a much bigger benefit.
In the worst-case scenario, those other 10 developers destroy value and having a 10x developer will be a disaster.
10x as productive as the average developer
In most cases the 10x developer is used in combination with the average developer performance. That average can be created over the total population of developers or the ones in a company. If we try to figure out what this performance means, we need to know if the 10x developer is part of the average or not. If not, then it is the same problem as above where you just need bad performing developers as your base line. If they only get half a day’s work done in a week, your 10x can work a whole week and reach 10x without any extra effort.
The calculation gets interesting when you have a small group and the 10x developer is part of it. There we have a little problem, then the average is created by including the 10x developer’s performance. If we assume we have 10 developers in total, 9 do 1 unit of work per iteration and 1 gets 10 units done, we get this little list below:
The average of this team is 1.9 units of work per developer. The 10 units of work done by our unicorn developer is only 5x the average of the team, what gives us just a 5x developer. To reach 10x, 19 units of work would need to be done – but that again increases the average:
We can repeat this without ever reaching the 10x of the average. The fundamental problem with 10x the average of 10 developers is, that 10 times the average is equal to the total work done by the team. The only way we can get to a 10x developer is when the rest of the team does nothing:
As soon as only the unicorn developer works in a team of 10, he/she will be always 10x the average of the productivity of the team.
To complete this game of moving numbers, we only need to ensure that all other members of the team cancel each other out. We can even have a 100x developer, we just need enough people who bring a negative performance to the team:
Is that really the performance you are after when hunting for one of those “special” 10x developers?
Conclusion
Playing a bit with numbers leads me to one of 3 conclusions when companies brag about 10x developers:
- They have a really bad performer as a base line.
- They have an organisational problem that prevents the developers from creating any value.
- They have a toxic person that causes the rest of the team to do no work.
Neither of those is good and all are warnings that you do not want to work there as a developer. And that is probably the most useful point of the whole 10x developer debate: Run if they start talking about 10x developers…
If you want to increase the productivity, create great teams that can work together and not against each other. That is a lot more sustainable and you don’t need rock stars or ninjas or superheroes of any kind.