The Truth About the 10X Developer
I believe individuals do exist who can make their teams 10X more productive. But their areas of expertise are never entirely the same and vary widely across companies.
Join the DZone community and get the full member experience.Join For Free
We’ve all heard of the concept of a 10X Developer. Most likely, when you first encountered it, the context was that of a myth or urban legend. I don’t agree. As a reformed psychologist I’m fascinated by legends that are “sticky.” No story hangs around for as long as this unless it contains an element of truth. Or perhaps addresses some deep seated need. In this article I would like to convince you that the 10X Developer is a real, if very rare, individual. More like a Rhino than a Sasquatch.
The Really Real Developers
If I rate myself honestly as a developer, from a scale of one to ten, then I’m about a six. I peaked at seven in my mid-thirties and have been in gradual decline ever since.
I know this because I’ve been privileged to meet and collaborate with a number of nines. As an exercise in humility, I just wrote out a list of a dozen of them. I’m sure most people reading this article could come up with a similar list. If you can’t, then I hate you. :-)
It’s unclear whether the gap between six and nine equates to ten times greater proficiency. After all my personal scale of ‘makes me want to vomit with jealousy’ isn’t very scientific. But you could easily design a test where they would outperform me by a country mile.
Proficiency vs. Productivity
But is 10X proficiency the same as 10X productivity? Well, that depends. I’ve seen companies where one inspirational developer conceived, designed, and (mostly) implemented an entire product line from scratch. That certainly sounds like 10X to me.
On the other hand, I’ve seen cases where the “resident genius” imposed their arbitrary rules on an existing codebase and made the lives of other developers a misery. This ultimately led to people moving away from the project, stagnation, and the premature end of the product.
To switch domains let’s think about building a house. YouTube keeps trying to recommend Eddie Hall’s feed to me. As World’s Strongest Man we can confidently predict he will be 10X stronger than the average bloke. So if Eddie was on your crew to build a new house would you be 10X more productive?
Certainly there would be jobs where he would be uniquely helpful, but equally his carpentry or digger driving isn’t going to give you much of an advantage. As ever context is everything. You might have the right person, but are they in the right place at the right time?
Less Proficient, More Productive
As mentioned above, I’m a less proficient developer than I was in my thirties, but the decline from seven to six has not been without some compensations. Less proficient does not mean less productive. In fact in my current role the reverse applies.
As I spend more time on tenders, talks, and courses, my writing skills improve. The more time I spend organizing and presenting at events the better I understand the industry. Because I’m talking to clients all the time, my elevator pitch is much improved. Like a lot of developers my sales skills started out at the Captain Caveman level — “This good product. Many quality code. You buy!”
So from the point of view of my overall productivity, I’m a lot more valuable than I used to be. But a part of me doesn’t believe that. A part of me still looks at that slide from seven to six, with a five on the horizon, and cries. I’m sure it would still be the same if I was closing million dollar deals every day, whilst protecting my team from a zombie apocalypse.
Being a Force Multiplier
So, what does it take to be a 10X Developer? From what I’ve seen on my travels, it means setting aside purely individual goals, ignoring imposter syndrome, and working to become whatever your team needs. You become a 10X developer by making others in the team more productive, not by personal success. This article on Imposter Syndrome makes the point brilliantly.
In some circumstances, it could mean debugging an impossible issue or designing a revolutionary architecture. But it could also mean coaching new developers, talking the client out of an ill conceived feature, persuading Dave and Jane to give the industry another three months, spotting reuse opportunities across teams, etc. As a fitness coach I know likes to say, “It’s never just one thing.”
When it comes to enhancing the productivity of the team, coding brilliance isn’t sufficient in and of itself. Depending on the domain, it may not even be necessary. I believe individuals do exist who can make their teams 10X more productive. But their areas of expertise are never entirely the same and vary widely across companies. But when you find one, hold onto them. :-)
Published at DZone with permission of Garth Gilmour. See the original article here.
Opinions expressed by DZone contributors are their own.