We are 10x engineers
A few weeks ago there was a heated Twitter discussion about how to spot a 10x engineer.
And Twitter was furious. Why?
Well, I believe mostly because of the characteristics that described this 10x engineer. It said a 10x engineer hates meetings, has a dark laptop screen background, works fueled by caffeine without breaks, is a full-stack engineer that seldom works on the UI, does not mentor others as mentoring slows down, does not document the code, and so on.
Here is the original tweet:
Stereotypical description and unhealthy advice
The description was stereotypical and had little to nothing to do with the abilities of an engineer. A lot of the advice, such as “a 10x engineer knows every line of the code that has gone in production” isn’t solid advice either.
For example, if that one is true, you probably have a tiny code base and in addition, a person that easily creates a bottleneck in your pipeline. But, I don’t want to discuss each of the statements. I want to look at the overall message of this thread.
Excluding a large part of the engineering population
One of the problems with this thread is that the description of such a 10x engineer excludes a large part of the engineering population. The bottom line, if you do not fit this narrow (and often ludicrous) description, you aren’t a top-notch developer. But engineers and also great ones come in all shapes and sizes. They have different colors of laptop screens, different skin colors, different hair, and different tastes and interest. Some even drink tea or water instead of coffee 😉
Don’t use genius as an excuse to behave like a jerk
But there was something else going on. The thread described a person that isn’t a good team player. And as many of us have already suffered from working with an anti-social person whose genius is used as an excuse to just behave like a jerk, I understand people did not take this tweet well.
It created this image of a superior person that supposedly knows everything better than her or his peers, and finds helping others a waste of time. And even though, for some engineers it might be indeed hard to socialize, mentor and work with others, we should detain ourselves from glorifying toxic behavior. We better use our time to think about how we can create a welcoming environment for all people, so they can grow and learn together.
Very fitting to this aspect of the discussion is this article that talks about how firing a 10x engineer actually saved a whole company.
But there was much more going on under the radar.
What exactly is a 10x engineer?
I think another aspect of why people were so furious is because nobody knows what a 10x engineer is. Supposedly, it is an engineer that is 10x better, faster or more productive than the rest of the engineers. But, does such an engineer even exist? And how would we measure those 10x achievements?
Well, the main problem is exactly how we measure 10x. Depending on how broad or narrow we scope the measurement we get different results.
Different in terms of who is how productive, but also different in terms of how valid or trustworthy this measurement is. The narrower the scope of the task that we measure, the more “solid” the comparison. But on the other hand, the more narrow the task, the more useless becomes the measurement.
Don’t compare apples with oranges
To give you an example, if we try to measure the work of a software engineer, we are not able to do so in a meaningful way. The range of tasks and the possibilities to measure the outcome (quality, speed, impact) is just too broad. It isn’t for no reason that we can’t and should not assess productivity by a single metric.
So, we must limit ourselves to a tiny unit, of say solving one specific problem, in a specific language, for example reversing a linked-list in C. Then, we might assess the performance of people by looking at the time to completion. But, what about the complexity of the solution? What about the readability of their solution?
Well, we could come up with measurements for each of those aspects, but the better question to ask is what does that tell us?
Some people are much better at a certain “thing” than others
In The Mythical 10x Programmer, you find a discussion of such a comparison. It nicely shows that the unit of measurement has to be indeed very narrow to allow us to compare the outcome. It also shows that there are 6x to 11x differences in how people solve one specific task. That’s not a surprise to me. Probably also not to you?!
But, again, what does that tell us?
My conclusion of these results differs from the conclusion of the original researchers.
For me, it simply means that one person can be much better at some specific things than another person. And that’s exactly why we must strive for an inclusive and diverse team. Great engineers come in all shapes and sizes. They also come with a lot of different strengths and weaknesses.
This “thing” that they are really good at might be reversing a linked list in C. Or maybe they excel when designing an architecture for a software system. But, it could also be that they are excellent in explaining complex problems to a non-technical audience. This “thing” could be that they are great listeners and know about problems customers or teammates experience before anybody else.
Let’s get a diverse team to be the best at a diverse set of “things”
Our work as software engineers is manifold, and to really succeed we need a diverse set of people with diverse skill sets, backgrounds, and experiences.
And we need environments where people can be their best selves and strive in the environments we create.
So, we shouldn’t focus on spotting that one genius engineer, as we do not have that one specific problem to solve.
We better use our time and resources to think about how we can enable all kinds of people to excel at what they are great at. Because even the best engineer can’t substitute a great team.
So, let’s focus on creating a 10x team! Or to create a 10x more inclusive environment. Well, let’s start by being 10x friendlier and more supportive of each other.
If you like this article, consider signing up for my mailing list, so I can notify you when I publish something new. I also prepared an exclusive Code Review e-Book for my email subscribers.
My newest project is a podcast called Software Engineering Unlocked. Here I talk with experienced developers from different companies, with different backgrounds and experiences on how they develop software. Sign-up today.
