Not all that glitters is gold: having a few 10X developers in your team could be very bad news
Introduction
Are you running a software development business that is struggling to stay afloat? Do you have one or more developers who seem to be outshining the rest of your team, but you are still unable to keep up?
If so, then this blog post is for you.
If you have one (or maybe two) 10X developers in your team, you may actually have a huge problem on your hands.
The problem is not that a 10X developer is “toxic” by himself. Not at all. The problem is that we tend to forget the observer and the context when we talk about “10X”.
The problem is that a “10X developer” may very well be an illusion masking a very deep and very costly problem.
The 10X developer is only a symptom (and a very easy one to misinterpret).
Part of the problem is that this developer is not really working in collaboration with the rest of your team, but not for a lack of want or ability. And another big part of it is that you are probably incentivizing a hustle-oriented culture of quantity over quantity, which are both deep and destructive problems in nature.
Optimize the whole before the parts
A 10X developer is someone who is 10 times more productive than an average developer. This seems like an impressive feat and one that should be celebrated. However, it’s important to remember that the 10X developer is just one part of a team. And so it generally means that one person is being able to deliver a lot more than the average person (in the team) can.
This does not mean that the 10X developer is actually an extraordinary developer, it means that -in your team and working on your code- he is 10 times more productive than the average developer.
Most of the time, at least in my experience, this “10X developer” is a normal developer (he may be an overworked and tired developer, but that is also a normal developer in a lot of places, to be honest).
What makes him go “fast” is that everyone else is going really slow. And that is not good.
Have you ever noticed how people who live in messy spaces seem to always be able to find their stuff among their mess? It’s because they are used to looking for it. They don’t have to search as hard because they know it is there. They can remember where they left it.
Think about hoarders and you will get the idea. They tend to know under what pile of things to find the thing that they are looking for.
In the same way, the 10X developer is used to finding the code that he needs very quickly. He is not fast, he is just used to his mess.
And it probably is also not his fault.
The 10X developer grew in a context where code was not treated as a valuable asset. It was not treated as something that needed to be well organized and well documented. In fact, most of the time, it was just thrown together and then left to rot, until it was necessary to make some changes to fit the client’s needs.
This tends to happen when the focus is only on the product and you forget about the code and the technology. The reasoning is usually that “the client is first”, but the result is generally that “quality is last”. This is not how you should be developing software.
If fact, the 10X developer thrives in conditions where there are a lot of extra hours and/or tight deadlines, which forces them to prioritize the number of tasks that they deliver instead of the quality with which they do those tasks. They tend to hoard tasks because it takes time for them to clean up their code and teach others what they know, which leads them to be chronically overworked.
When you are tired and want to go home every day, it is not easy to write great-quality code, even if you know how to do it.
When you optimize for the parts, you end up with a mess. When you optimize for the whole, you get a well-oiled machine.
It’s important to remember that a team is made up of many different parts and that they need to work together in order for the team to be successful. When building a software development team, you should optimize for the whole rather than any one individual, and even when optimizing the individual, you should always optimize for the whole first.
Think about it.
Not all that glitters is gold
A 10X developer gets a lot of tasks done every day and they work a lot faster than their peers. This is because they are used to the chaos of working in a messy environment and they know how to find the code that they need quickly.
That is not a good thing.
Writing clean high-quality code is generally a lot faster than writing bad-quality code, except maybe in the very short term.
And “weirdly” when you work on clean, high-quality code, there tends to be a lot less difference in speed between developers.
Not only that, but I have worked with some “10X developers” and I have never seen one who was able to maintain that level of productivity for very long. In fact, most of them eventually burn out and start to slow down. And they always have a messy codebase to show for it.
And what those “10X developers” have in common is their context.
In fact, in clean code bases, the difference between a Senior and a Junior is not so much in the speed of their development but in the quality of their code and the problems that they can tackle.
A senior developer is an experienced developer that knows how to solve a lot of problems and solve them correctly, not a code-writing machine (Github’s copilot is a code-writing machine if that is what you need).
So, as a software development business, if your senior developers seem to go a lot faster than the junior ones, that may be the symptom of a deep problem with your development process and standards.
I know this may sound weird at first, but maybe your 10X Developer is not the exceptional developer that you thought but the sign of a deep problem that could jump you in the face at any point without warning if you don’t do something about it.
Standards are called “standards” for a reason. If you have a 10X developer, do you really have standards, to begin with?
If it sounds too good to be true… maybe it is
People tend to talk about 10X developers “out of context” as if it made sense that people can be 10X faster than their peers without a specific context or an underlying reason for it.
You won’t frequently find 10X differences in the human capacity for anything.
For example, you won’t find 10X differences in the speed of a marathon runner or the speed of a sprinter. You won’t find 10X differences in reading speed or typing speed either.
It is just not “normal”.
So it would make sense to think that a 10X developer is more a sign of its context than they are really a developer who can produce 10X more than other “regular” developers.
From my experience, it is a lot more believable to think that there are 0.1X teams where only one or two of the team members are able to work at 1X. And that would look like a 10X developer to someone without a reference to compare.
Therefore, having a 10X developer might be an indicator of a team that is not working at its full potential. It also means that you are relying too much on one or two people and the rest of the team is left behind.
This also has a few consequences:
- The team might not be able to move forward if one of the “10X developers” leaves.
- The “10X developers” will usually be tired and overworked (more than regular developers). This makes them more prone to leave without notice. The fact that they are not complaining, even if you ask, does not mean that they are not being affected.
- The team might not be able to think outside the box and come up with innovative solutions because they are not used to working at a slower pace.
- Your team most certainly doesn’t have time to refactor code. It is always left for later and never really done. Same with testing, which in turn results in buggy code and extra workload for your developers (and complaints from your users and clients).
In a sense, having a 10X developer means that you have painted yourself into a corner.
Stop optimizing for quantity over quality
Let me say this directly: it is delusional to think that you can get high-quality work for 70 hours a week, consistently.
In fact, I would think that you cannot even do it inconsistently, you just sometimes accept the drop in quality because of a tight deadline, and then you pay back that technical debt on the following sprint or development effort.
I have had the director of a software development company tell me that even when they were leaving after midnight and starting at 10 am every day for months, and even when every day he received complaints from his clients and users, he told me that the problem with quality could not come from the excessive hours.
Yes, the team lacked training, and yes, they lacked standards and best practices, but they mostly lacked some rest.
In fact, when I first started helping them, they were literally berating developers for not delivering a higher quality without even giving them a clear definition of what quality means or how to know when their work is high-quality.
And the thing is that I have seen this time and again.
People (managers) have talked to me as if I was being revolutionary just because I was talking about limiting the work hours and focusing on delivering high-quality code fast, prioritizing instead of trying to overwork the developers to burnout.
Seriously, I have had the experience of talking to a manager and them having their mind blown by my “revolutionary” ideas like:
The only way to get high-quality work is by having a team that is rested, focused, and motivated. This is not possible by making developers work 60, 70, or even 80 hours a week.
In fact, you are already probably losing quality and speed by trying to conform to the “traditional” 8-hour work day.
But this problem won’t be solved soon, managers will keep making excuses for why they can’t do things correctly and why they need to keep prioritizing quality over quantity, and they will even deny that they are doing it while they are doing it.
Still, here I am adding my grain of sand to the right bucket in hopes that it will make a difference one day.
Let me be clear:
You go fast by doing things correctly, not by doing things until you are tired.
The easiest way to go really slow is to hurry.
The easiest way to make a mistake is to try to do too much.
Instead, make sure that you are working on the right things and that you are doing them correctly.
Work as fast and well as you can, and make sure to remain well-rested and happy, because that will influence the quality of your code.
And if you are the one running the team, then you need to manage the work instead of trying to get “the most” out of the workers.
Try fewer hours but higher quality hours.
Say it with me: “fewer hours but higher quality hours”.
Less work, but better work.
Conclusion
It is easy to think that “a 10X developer” is some sort of goal to achieve or a mythical creature to try to find when you forget about “context”.
Most of the time (or all of the time, in my experience, but maybe there is some exception out there), a “10X developer” is a 1X developer working in a 0.1X context. He is a “senior” developer in that context only because he knows his own mess well.
I have yet to find a “10X developer” working on a well-documented, clean code base with a well-defined CI/CD pipeline and good software architecture. It just doesn’t happen.
That reduces the concept to Cryptozoology (and no, that’s not an NFT game).
So, a 10X developer seems like a dream, on paper, but in reality, I have only seen managers who think that they have a 10X developer because they don’t have enough experience to be able to compare teams and organizations, and they can only compare team members among themselves.
The key to “10X development” is not to try to find a mythical creature, but to focus on delivering high-quality code quickly and efficiently in a well-defined context.
The key to “10X development” is to build a “10X team”.
Because if we are talking about context, then it makes a lot more sense to be building a team with a codebase and tools to allow them to work at 10X the speed of other development teams.
And you do that by creating a context that allows for high-quality work with focus, and rest.
You can achieve a lot more by trying to focus on working smarter and not harder, but you knew that already.
Seriously, how is this not just common sense?
