My changing view on 10X Engineers
Throughout my life, I’ve had the opportunity to witness a few 10x engineers — both early in life and also while running my own company. It was initially my perception that a Rockstar engineer was doing 80% of all the work anyway. So, in essence, following the Pareto rule, I needed to change my perception about this. However, the statement below stands true (for me):
If you have a 10x engineer as part of your initial engineer team, cut from the right stuff, I strongly believe it significantly increases the odds of your startup’s success.
Concluding that Rockstar engineers do 80% of all the work is a blunt statement, and my initial perception was overtaken. They could be capable of doing this; however, you build a non-scalable and sustainable company. I have a natural attraction to these one-person teams, but today I think, I fully understand the potential downside.
And here’s why:
There is No Me in Team
It’s my personal belief that the definition of this concept changes over the lifetime of a company. When you have a tight budget, time is working against you (startup dynamics), and you to demonstrate product-market fit before you run out of money, you need a couple of engineers that are super extremely smart, know their limits, can work vigorously independently, they can accomplish the work of a team of 10 at the cost of one! This is my definition of a 10x engineer in a startup setup. If this concept would scale linearly within a company’s scale, we could conclude these Rockstar engineers do 80% of all the work following the Pareto principle. I'm afraid I have to disagree. In a scale-up, Rockstars can have a negative connotation and create a negative toxic culture for some logical reasons because there is no Me in Team.
The more you grow, the more important the team becomes — and it matters way more than individuals. It’s like any team sport. The team that plays together with the best wins, not the team with the most talented individuals. A famous analog from sports (I am not a fan) is the impact of Kobe Bryant (†) playing for the Lakers versus Michael Jordan playing for the Bulls. They built the team around Kobe. He was, admittedly, very talented, but the team fell apart every time he got hurt. Jordan was an incredible player, too; however, their dominance in the 90s was a team effort. Same in the military. Navy seals recruit to survive BUD/S training (24 weeks) when they move and think like a team. And a team is only as strong as its weakest link.
In the military, they call this ‘force multiplier.’ This term refers to a factor or a combination of factors that gives personnel or weapons the ability to accomplish greater feats than without it. For example, having access to satellite navigation can make a small force as effective as, say, a force 5x larger one that doesn’t have it. In the case of a software engineering team in scale-up mode, a great developer acts as a force multiplier for the team. They don’t increase productivity by doing more themselves; they help everyone else become more productive. So, it’s not that same person that did 10x more work. That’s not a sustainable solution and would be a TERRIBLE person to build a codebase around.
Becoming a True 10x Engineer
Being a real colleague is the starting point for being a 10x engineer/developer — thinking alongside someone who is stuck, being respectful, and helping people grow. Instead of purely evaluating “productivity” (which is vague at best: Is that Lines of Code? Completed stories? Impact to team velocity? Speed at solving bugs?), there are other non-technical and leadership aspects to the 10x engineer that pushes the whole team forward rather than based on an individual contributor divorced from their team.
According to one of my former (and current) 10x engineers, two things ensure that one is more productive than the other in the long term:
· A problem-solving way of thinking (‘debugging’): the cycle of hypothesis, validation of theory, and a formulate a new hypothesis. You can only do this well if you have broad enough knowledge to know which hypothesis you can make. To have that, you need to have your own way of building knowledge
· The ability to put ‘simple made easy’ into practice (thinking in small increments). This provides a basis to build on.
If you want to know how to detect 10X engineers in your team, here’s what to look for:
· Humble to the core, extremely smart, and understanding
· Independent but also leading a team in silence (lead by example)
· A natural go-to person, willing to help everyone
· Don’t overcomplicate problems. New and shiny isn’t the solution for everything.
· You actually want to work with them
Caveat
The caveat of true 10x engineers is somewhat related to the Peter principle: Having that 10x status and performance dilutes the more you are involved in helping others rather than building up knowledge yourself — and you only do that by achieving enough yourself and avoiding the ivory tower.
You have to protect these 10X engineers from being too much of a 10x player contradictory. As with everything in life, it boils down to balance, which can be extremely difficult.
My advice to all entrepreneurs is to create environments where true talent can grow and where a 10x mentality is rewarded. You’ll never achieve this by putting people in a box. Short term productivity goals can jeopardize long-term sustainability.
