In the world of software and web development, you might have heard of the term 10x engineer. It’s a term that refers to a person who can increase productivity and get work done faster on a team than other developers. It’s a term people often misuse to describe a team member who can do the work of ten people or work ten times faster.
In other words, someone with a rare set of skills and talents makes them more productive and makes them far more valuable to their employer.
The mere mention of the term conjures images of a lone wolf developer in a hoodie, working on complex problems by themselves at a stand-up desk. Left alone for days and weeks wallowing in their genius, to emerge from their darkened Apple store aesthetic office with a bug-free solution, appeases management and fills others with envy.
How do they do it? They’re so intelligent. They know everything.
Everyone has an opinion on this topic. Some believe 10x engineers exist. Others put them into the same category as ghosts and Big Foot.
I believe 10x engineers do exist, but not in the way you might think. I don’t believe some engineers can move between companies and instantly produce higher output than anyone else in the organisation. I also do not believe that a single developer can have ten times the output of other developers.
A 10x engineer is a combination of domain experience and business knowledge. Someone with 12 years of experience at the company for four years will be more efficient than someone with three years of experience who might have only been with the company for a few months or a year. That’s just a fact.
Let’s run with a fictional example to illustrate the point:
John works for Insurance Co and has been there for seven years as a developer. At Insurance Co, they build consumer insurance products. Think of a website where you can manage your policy, add additional items to your insurance policy and handle payment.
In that time, John has worked on a plethora of features. He knows the terms that are specific to insurance. He also is quite familiar with the codebases, able to find where particular features live quickly. If John were tasked with creating a new feature, he would know where it should go and what existing API’s and code already exist to reduce the amount of work.
Now, Tim joins the company. Tim is an experienced engineer who graduated at the top of his class and has worked for some prestigious tech companies. He has just as much experience as John. Still, he’s new and Tim has never worked in insurance before. Before Tim can be an efficient member of the team, he needs to understand the codebase and the business knowledge that has been instilled in others who have been at the company a lot longer.
The thing to note in this example is that his intelligence or skillset will not limit Tim. Tim is going to be hindered by his lack of business knowledge and familiarity with the codebase. By comparison, John and any other developer at Insurance Co will be more productive than Tim is, at least until he gets up to speed.
We have all worked with 10x engineers. They just might not fit the exact description of what you’ve been told they are. Not all 10x engineers are arrogant, self-entitled lone wolves that graduated top of their class, have worked for Google and write compilers for fun.
Every company usually has a 10x engineer. It might even be you. You know that one person (it’s commonly one person, in my experience) that everyone else in the company goes to when they get stuck on a problem or want to know where something is? That one person that the boss and management pull into a planning meeting when they want to build a new feature.
Except, I don’t call them 10x engineers. I call them office encyclopedias. Because that’s what they are. This person’s perceived intelligence and efficiency is because they have been with the company most likely for a long time. They know where everything lives.
This is not to say that a 10x engineer isn’t also intelligent. Knowing where things are and how to work with the codebase is one advantage, but you need exceptional problem-solving skills to be worthy of the title. These engineers are usually founding members (or early hires). They probably built a lot of the foundational code other developers are working with. Anyone who has ever worked for a small company or had to wear many hats will relate.
It is for this reason that recruiters and companies struggle whenever they try hiring 10x engineers. They are not born. They are created. All developers can become 10x engineers. Having fancy degrees or working for big tech companies is not a requirement, nor will they make you become one faster.