10x developers are a risk I’m not willing to take. They are not a sustainable rock to build your team on.
We are still talking about 10x developers, rockstars, and ninjas. If you find one, you can keep them.
Rockstars are notoriously well known for their egotistical diva-like expectations, throwing TVs out of windows, and driving cars into swimming pools. Ninjas are famed for their solo stealth murdering skills.
I don’t want either of these things in my teams.
A while ago (this post has been in draft for ages), an unintentionally funny 10x developer tweet thread blew up on twitter. The thread outlines 11 top tips on how to spot a 10x developers.
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
The points outlined in this tweet sounds precisely like the 11 things to try and avoid when hiring someone.
Guilty as charged.
I’ve worked with 10x developers before, higher-level beings who can deliver ten times the work of their teammates in terms of velocity. If you ask some people, I might have even been considered by others as something similar; a 6.5x developer maybe.
On several occasions, I have been parachuted into failing projects. Stuck my head in my development environment, and managed to get projects over the line with sheer will power and coding.
It was my specialty for some time. In only about 50% of the projects were the initial catastrophes my fault in the first place!
So if these mythical creatures do exists, what is my problem with them?
It’s simple; they kill teams.
I have one main problem with the revered 10x developers. They are a single point of failure.
Single Point of Failure.
If you were to architect a software system, you would pay close attention to avoiding a single point of failure. You would make sure that the load was balanced equally across any machines bearing any burden.
With a 10x developer in your team, you’re unlikely to be doing this. If the 10x developer is truly capable of doing the work of 10 developers, it would be impossible not to have them cover that workload. You are leaving your self with one node in your system, taking up significant capacity.
So what happens when this overloaded node in your system fails? Can the rest of your system pick up the load, or will your system fail?
You can model work flowing through your team in the same way as a software system processing work. Your 10x developers are likely to be a single point of failure in your group. Even if they aren’t, they will cause significant workload issues if they leave, and you can’t replace them with ten other developers.
Multiply the rest of the team instead.
I would rather have a team of 1.5x developers and add my 2x team lead multiplier. We’ll be a more robust, happier team with built-in redundancy and disaster recovery.
Be wary of the fabled 10x developers; they’re an architectural anti-pattern.
