Growing up, the only thing that put me off while learning software development, was the common occurrence of people who cared more about one upping others with their trivia knowledge rather than actually building things.
At the start of my career I had a difficult time differentiating between them and actual top performers because the industry still thought there was a strong correlation between jerks and highly productive people. Employers used to be afraid something will go wrong if they fired a mythical 10x engineer and no one else understood how to fix their systems.
After 15 years what I've learned is that engineers that produce orders of magnitude more than others exist1, but the way they are talked about is overly exaggerated. They’re usually not jerks either, at least not more than the rest of the population.
If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god.
One thing we don’t often consider is that you don’t have to hire the very top of the field to find people that are orders better than the industry average. Even more important than finding great engineers is to avoid bad ones2.
Being obsessed with finding a 10x engineer, is to be obsessed with shortcuts and Hail Marys. It will hurt you in the long run if you’re focusing on that instead of building solid fundamentals.
Ultimately I am convinced that focusing on building teams is more important than finding individual outliers. Of course the John Carmacks, the Jeff Deans, the Fabrice Bellards, of the industry exist, but your startup isn’t going to die if you don’t find one. It will die if you don’t build a good team.
Steve McConnell, has a great summary of existing studies that support the 10x theory in “Individual Productivity Variation in Software Development”.
McConnell also recognizes the aforementioned studies are not perfect in “Origins of 10X – How Valid is the Underlying Research?”. But the lack of studies contradicting the current findings and the abundance of anecdotal stories signals towards confirmation.
In “Leadership, Team Building, and Team Member Characteristics in High Performance Project Teams” the authors identify 9 themes3 as potential predictors of team performance.
In “Linking Project Team Performance with Team Health” the authors emphasize that team building is a long term strategy that does not happen overnight by itself. Organizations must invest if they want to build healthy, high performing teams.
In “An Empirical Study of the Relationship Between Team Performance and Team Maturity” the authors measure the impact of changes in team dynamics, and make a correlation of team maturity with high performance teams. They mention how persistance is required to move to higher performance.
In “Innovative Performance in Research, Development, and Engineering” the authors identify 12 factors4 that strongly influence innovative work environments:
Finding people that’s clearly better that you is unnerving, but it ultimately forces you to become better by sheer peer pressure.
“The Net Negative Producing Programmer” by Gordon Schulmeyer rightfully mentions that poor performers are likely bad fits.
The 9 themes: Sense of belonging to a team, Critical leader behaviors, Team communication, Ownership, Location, Team building, Competition, Rewards and High visibility of project.
The 12 factors: Personal work satisfaction, Clear objectives and plans, Technical direction and leadership, Organizational stability, Sufficient resources and autonomy, Project involvement and visibility, Low conflict, Involved and experienced management, Rewards and recognition, Good communication (mutual trust, team spirit), Stable goals and priorities and Risk-sharing with low penalties for failure.