Everybody wants to hire, or to be, a 10x software engineer at the company. The engineer who can get far more done than their peers at about the same price. I have witnessed a few 10x engineers, and on certain teams I've even been the 10x engineer, and the reality is that a 10x engineer comes in a few forms. Some forms of a 10x engineer are actually detrimental to the company, and are also unfortunately some of the most common. The only thing that is constant about a 10x engineer is that they produce 10x the percieved work relative to their peers.
Note that I highlight perceived work to differentiate between actual work. I think the best way to think of the difference is in terms of the physics definition of "work." A person carrying a rock can walk around in a circle all day, but they have done very little work on the rock. Whereas another person can carry that rock to another position in an hour, and then sit around all day, and they've done more work than the first person. However, as perceived by their superiors, one person was active and "working" all day while the other slacked. Similarly, one person continuously redoing a piece of work ("refactoring") will look like they are doing more work than someone who gets it right in the first place.
I also highlight relative to the peers because there is no fundamental baseline for how much work an engineer can do. Everything measured about a 10x engineer is in relation to their peers. This is important, because some of the most common 10x engineers are 10x as productive as their peers, but they do so by limiting the productivity of their peers (almost always inadvertently).
Additionally, I would like to point out that while there is clearly a difference between a very good engineer and a merely competent one, this post is entirely concerned with the "10x" engineer. Someone who seemingly produces ten times the amount of work on average than their peers. I firmly believe that any two people who are similarly knowledgeable and competent in a language and codebase will on average produce the same amount of perceived work, regardless of their engineering chops. One may produce sub-par code that needs to be fixed later, but that is irrelevant when measuring a 10x engineer. So in sum, this is about engineers who produce a lot more code than their peers, regardless of "quality" (which is too subjective).
With all that out of the way, I want to go through the many faces of a 10x engineer. There are two primary categories to consider. The 10x engineer who does so by limiting their peers, and the 10x engineer who does so by being surrounded by limited peers.
10x Engineers via Limiting Peers🔗
This is arguably the more common situation I have found for a 10x engineer, and I want to state that this is rarely done maliciously. I have never worked with an engineer who actively and purposefully limits their teammates with malicious intent, but I am not going to say that there are no such engineers. In any case, here is the list of some traits I've found for 10x engineers, which I will describe in more detail below.
- Refactoring incessantly
- Constantly new projects with no docs until it "stabilizes"
- Answers all questions
- Excessively clever/flexible solutions
Refactoring Incessantly🔗
The first trait, refactoring incessantly, is my favorite because it is not only the most common, but also the trickiest to deal with. This engineer is making incrementally good progress on parts of the code that are a little messy and could be cleaned up. However most of the refactoring in this type of situation is only perceived work and not actual work. Sure, the code is in a better spot than it was, but usually not by a significant amount to actually justify the work. Most of the time this is like the person carrying a rock in a circle all day and placing it a few inches left of where it started -- very little actual work was done, but a ton of perceived work was done.
Perhaps more insidious is the cost this has on their fellow peers. Code that they had once understood now has to be re-parsed and grokked. This can be a minor or major slowdown for each new task or project they take on, which adds up quickly! The peer's mental model of the code and system has to constantly remain in flux, which increases the amount of work they have to do per task. Of course, the refactorer does not have this issue, because they created the new model, and can work as fast as if the refactor did not happen.
Dealing with the situation is not easy either, because "work" is being done and it is arguably making the code "better." Getting someone to fully understand the cost of refactoring can be difficult. Additionally, there are situations where refactoring is an absolute necessity and can speed up the whole team. However, if you see a 10x engineer who seems to be refactoring constantly, maybe take some time to think if they are 10x because they are actually slowing down everyone else. Maybe try to come up with a system to evaluate whether a refactor is actually worthwhile to do that factors in peer's input.
Always New Projects, Never Docs🔗
Greenfield development is arguably everyone's favorite type of work. It is also, usually, the fastest work because there is no legacy system to grok or deal with and everything starts from scratch. If your peers are adding features on legacy codebases and you get to work on greenfield projects, it is pretty easy to be seen as the 10x engineer. This is also a positive feedback loop -- the upper management wants the best on the greenfield work, and who looks better than the people currently working on greenfield projects?
Where things get tricky, and where a 10x engineer can truly solidify their position as a 10x engineer, is when they refuse to write docs until the code "stabilizes." And funnily enough, this 10x engineer is usually onto the next greenfield project right as this one gets "stable" and is passed off to another team to maintain. The new team might write some docs about what they can from a surface-level view, but they will never be as fleshed out as if the original developer had written them. This drastically limits the effectiveness of anyone who tries to add features or fix issues, as they have sub-par docs, and thus further cementing the 10x engineer's position at the top.
At the beginning of a greenfield project, writing and maintaining docs can be more trouble than it is worth. However, if your 10x engineer has not written up good docs for some project before moving on to the next one then this is a clear sign that what you have is not a 10x engineer, you have an engineer slowing everyone else down. Maybe create a plan for how docs will be written for a project before anyone is allowed to transition to a new project, and have these docs reviewed and vetted by the peers. Additionally, consider giving other engineers a shot at greenfield projects and you might be surprised at how many "10x" engineers you actually have!
Answers All the Questions🔗
Having a single 10x engineer that answers all the questions is less of a trait and more of a symptom of something wrong. Answering questions is great, and having your senior engineers helping junior engineers or just each other is always a great thing. But if a single person seems to always be the person to answer, even if that question was asked a while ago (or everyone points to one person for the answers), then take a second to consider what is actually going on. Either nobody feels comfortable answering a question or nobody knows the answers to certain questions.
This has been most common at places with atrocious documentation, where all of the knowledge is held in effectively one or two people. It is easy to be seen as a 10x engineer when everything has to go through you -- you get to be the bottleneck for everyone else!
The easiest solution here is getting the 10x engineer to write some documentation, and spread the knowledge. Maybe have knowledge shares, or lunch-and-learns. Having a "10x" engineer who just happens to hold all the knowledge is not a sustainable situation.
Excessively Clever or Flexible Solutions🔗
There are times when having a clever solution is absolutely crucial for having something work. For instance, the infamous fast inverse square root comes to mind as a necessary and clever solution. Most of the time, however, there is absolutely no need to be clever.
Similarly with flexibility, there are times where a flexible system is required. Certain enterprise applications have business clients with convoluted requirements, and a flexible system to handle multiple varying requirements can be necessary. However, most of the time flexibility is not needed and oftentimes it is prematurely put in "just in case" (especially in enterprise products).
In both of these cases there are times where these solutions are required, and there just isn't a way around it. Unfortunately, many times there is just a "10x" engineer who has put in excessively clever or flexible solutions where there isn't a real requirement for it. In an isolated system, this might not have any real impact. Problems arise when this excessively clever or flexible solution is in the direct path of the work of all of their peers, because now everyone has to do the extra mental gymnastics to get their work done.
From what I have seen, the 10x engineer usually has to do fewer mental gymnastics to get their work done -- simply because they were the ones to come up with the clever or flexible solution and intimately know the constraints of it. This allows them to get more work done than their peers and oftentimes this comes with the additional demotivational thought for the peers that maybe they just aren't smart enough to keep up.
Fortunately this is fairly easy to detect -- just ask people! Is everyone complaining about some X system being convoluted, and is that system required to be that convoluted? Maybe better documented or training is needed, or maybe that system needs to be ripped out and replaced with something simpler. Cleverness and flexibility come at a cost -- and this cost is slowing engineers down.
10x Engineers via Limited Peers🔗
At this point it might seem that every 10x engineer is actually just a fraud, even if they don't mean to be. But there are certainly some cases where there is a 10x engineer and they aren't just slowing down their peers. However, things being relative, this usually says more about the peers than the 10x engineer. Below are some cases that I've noticed:
- Vast Domain specific knowledge
- Junior or Incompetent peers
Domain Specific Knowledge🔗
I'd argue this is the only situation I've seen of a 10x engineer that truly deserves the title. This is an engineer who simply has a crazy amount of domain-specific knowledge. Perhaps it is about a specification they have essentially memorized, or they have been at the company so long they know the ins-and-outs of a multitude of systems and don't have to hunt through the documentation to make some changes.
In any case, a 10x engineer with vast domain-specific knowledge is able to be significantly better than their peers because where a peer has to dive into a detailed spec or documentation to find some answer, this engineer can just pull it off the top of their head. This reduces the effort required per task, and therefore they can get more tasks done!
This type of 10x engineer is exceedingly rare, and can be fairly niche in application. Nobody knows every spec or all the documentation, so this 10x engineer tends to only shine in specific cases. Additionally, it is important to make sure that this is a 10x engineer because they have effectively memorized specs and documentation and that that documentation does exist, otherwise this is just another "10x" engineer who hasn't written any docs and is holding their peers back.
Junior or Incompetent Peers🔗
One of the easiest ways to be seen as a 10x engineer is to be surrounded by peers who just don't seem to be able to get anything done. Perhaps all of their peers are fresh new-grads (because why hire one senior engineer when you can get two new grads?) or are simply incompetent.
Unfortunately this can oftentimes be the hardest to detect or even just admit. But if you've ruled out all of the other situations, maybe you didn't find a diamond in the rough with your 10x engineer, maybe you just found a smooth and shiny rock and your comparison points are really rough.
Perhaps even more unfortunate, usually this engineer will leave pretty quickly. I don't have too much justification for this point other than my own experience where I've joined a team and after a few short weeks decided it wasn't a good fit!
I don't know of a good fix for this at an organization level other than investing in training. However, if you are a newish engineer and find yourself as a 10x engineer without any of the traits above, then it is time to find a new team or company.
Conclusion🔗
The idea of a 10x engineer is really enticing for many businesses. And oftentimes I've seen (or heard stories from friends and peers) about the hoops companies will go through to keep their "10x" engineers happy. But the reality is that the only 10x engineer you want to keep at your company is very rare and very niche (at least at the 10x level). Most likely the 10x engineer you have is actually holding the team back, not on purpose, but by trying to do what they think is right. I think it is important to be able to identify these situations and promote corrective actions as quickly as possible.
Of course there exist 10x engineers who don't have any peer-hurting traits, and whose domain-specific knowledge seems to cover a lot of domains. However, it might be more worthwhile finding non-"10x" engineers who are extremely competent and produce above-average work, although this is much harder to measure.