Understanding the True Value of 10x Engineers

I've been reflecting on our engineers’ diverse impact on our projects and the true meaning behind labels like "10x engineer". Over the years, many articles have discussed this concept, some labeling it a myth and others saying you need to have at least one on your team. It’s a hot topic; understandably, this term often sparks debate. Still, I think it's essential to understand the real value a developer brings to the team beyond any numerical label and their leetCode score.

I’m part of the group that thinks 10x engineers are great, and no, it’s not a myth. But I have a more nuanced perspective — I don't think 10x engineer has anything to do with coding and more than that, I think anyone can be a 10x engineer. It’s not a personal quality; it’s a cumulative effect of all the small decisions you make as a software developer — the tools you choose, the way you debug, the way you act with your team mates.

In my early career, I witnessed first-hand how an average developer can turn into a 10x engineer overnight: We had a high-load project with thousands of requests per second that was developed by a small team — it was a search module that had to work fast, and scan a lot of data to match a multidimensional query. Everything was smooth at first glance; the code was running in production for some time, but some users complained that they randomly received no response.

Over time, the error rates kept climbing, but we had nobody to ask. The original development team had departed to another project and had zero time to help us. The product was live, and customers were justifiably upset due to the unpredictable behavior resulting from unresolved concurrency issues.

Then, our lead developer steps up. He spends a few days trying to zero down on the issue debugging every line of code. Was he the best engineer I’ve known? No, he wasn’t, but at that moment, his contribution to the project was 10x of anyone else on the team. He single-handedly solved the issue we had been battling for over half a year.

Reflecting on this, the term "10x developer" hardly does justice to the essential contributions made. It's not about being ten times faster than another engineer; it's about making the right decisions that lead to significant positive outcomes for the entire team. If you're fast, but everything else brakes, are you really a 10x or a 0.1x?

10x is skewed by perception biases

The 10x term is flashy. It grabs attention. Someone hacks a solution in a day, and boom — they’re labeled a 10x engineer. The problem is that the term is skewed by our perception biases. While we're all busy watching these stars, we often overlook the steady, reliable engineers who keep the engines running.

Why does this happen? Well, our brains love a hero story. We’re wired to admire outliers because they stand out. It’s a survival thing from way back. If someone’s dramatically better at something, we notice, even if it happens once every full moon. This heuristic, while useful in the wild, can skew our judgment.

One very common bias is the halo effect. This occurs when our overall impression of a person is skewed by one outstanding trait or achievement. For example, if a team member once solved a highly complicated bug in a short time, we might overlook their ongoing struggles with project deadlines, still viewing them as a top performer based on that one time they did something amazing. This can lead us to overestimate their abilities, potentially placing undue expectations on them.

The contrast effect can lead us to undervalue someone’s skills simply because they are less immediately noticeable than those of a more flashy colleague. This might cause us to overlook the steady contributions that are just as vital to our success but less visible. It also happens when we compare two engineers directly to each other instead of judging them on their own merits. Let's say one of our devs just did a killer feature demo right after another's demo didn’t go so well. The second might unfairly come off worse in everyone’s minds — not because their work was bad, but because it was overshadowed. Are they a 0.1x because they were overshadowed? I would disagree.

The next bias that contributes to a skewed perception of a 10x engineer is confirmation bias. This is when we saw them do something great once and start picking up on details that support our narrative and ignore the ones that don’t. If we, for example, label someone as 0.1x we might unconsciously overlook their successes and hyper-focus on any slip-ups, reinforcing our initial judgment.

“There’s a bug in production. It must be David again pushing something buggy.”

The issue here is that while we’re giving gold stars for flashiness, we might not see the team member who's quietly refactoring code to make it cleaner or the one spending hours mentoring a new colleague. These actions might not scream “10x engineer at work" but are crucial for the long-term success of any team.

Typical Scenarios and Behavior

As I mentioned before, 10x vs -10x Engineers debate is mostly related to countless daily decisions, how we react to different situations; it does not necessarily relate to writing code as fast as you can, nor to “how smart” the implemented algorithm is. Let’s explore a few scenarios that might better illustrate how easy it is to be perceived as a 10x engineer.

Handling Bugs in Production:
Imagine a situation where a client or a stakeholder found some inconsistencies in the application that are related to the functionality that you developed. Think of it as a general rule of thumb how to react when somebody says that your code doesn't work.

✅ 10x Engineer: “We’ll check it out and come back to you.” You quickly isolate the issue, fix the bug, notify the team, and share the fix in a post-mortem to prevent future hiccups.
❌ 0.1x Engineer: “It works on my machine.” Ignores initial reports, blames the environment or user error, and when they finally address it, applies a hot fix that doesn't solve the issue completely, but temporarily.

Responding to Code Reviews:
A more senior developer is scrutinizing your code, suggesting alternative implementation, and saying you should first refactor it according to the company-wide standards before the Pull Request will be approved.

✅ 10x Engineer: “Thanks for the feedback. I appreciate the suggestions!” You genuinely appreciate the feedback, try to integrate the suggestions, and thank your colleagues for their insights. Focus on what’s better for the product, without pushing their own agenda and ego.
❌ 0.1x Engineer: “You’re wrong; my code is perfect.” Reacts defensively to feedback and argues without justification, slowing down the review process. Focuses on ego — the code that they have written is more important than the overall product improvement.

Handling Overhead and Administration:
As you know, software engineering is not only about writing code; there’s a lot of overhead attached to releasing any feature. So, imagine a situation where during the daily meeting the managers start pushing for more transparency through project management tools. They say they lack context and have a hard time keeping the whole boat afloat.

✅ 10x Engineer: “Yeah, Jira is annoying, but I hear you, it keeps everyone updated and allows you to do your job.” You understand the importance of the balance between development and management and work with necessary administrative tasks, ensuring neither is neglected.
❌ 0.1x Engineer: “Jira sucks; nobody cares about it; it’s not even real work.” Gets annoyed at every presentation, diagram, and ticket work.

Introducing New Technologies:

It's been five years since your project was properly refactored. There have been a lot of changes to the business, a lot of hacks were added to the codebase to cover all the new edge cases that the business growth has introduced. It's about time to do it right, start from scratch to adapt to the evolving business needs.

✅ 10x Engineer: “Let’s do a proof of concept and see which technology suits us best before we decide which technology to commit to” You evaluate new frameworks thoughtfully, considering team capability and project needs. You address potential technical debt, and think of necessary refactoring.
❌ 0.1x Engineer: “We should go with angular, as it's the best, because that’s the only framework I worked with and I’m going to argue with you for the next 45 minutes” Pushes for the adoption of new technologies without proper evaluation. Allows technical debt to accumulate unchecked, prioritizes new feature development at the cost of long-term project health.

During Team Meetings:

You sit down with your team to discuss alternative ways to develop the requested feature. There's many different ways it can be implemented, some are suggesting going serverless, some suggest you should build it with Rust and on-premise. A lot of good ideas are being thrown back and forth.

✅10x Engineer: “Let’s hear everyone’s opinion” You contribute constructively, keeping discussions on track, and respecting the time limits. You encourage everyone to voice their opinion and the best course of action is selected based on the collective decision.
❌ 0.1x Engineer: “Let’s hear my opinion for 45 minutes.” Dominates conversations, derails topics to irrelevant subjects and argues emotionally. 

Handling Failed Projects

Not everything goes right. Sometimes you fail. How you act during failures can also separate you from a 0.1x Engineer. These small interactions matter a lot.

✅ 10x Engineer: “Okay, Team, let’s figure out what went wrong without blaming anyone and make sure this never happens.” You analyze what happened constructively, discuss in a blame-free environment to understand what can be improved to prevent such issues in the future.
❌ 0.1x Engineer: “It’s Jane’s fault; her code is always buggy.” Shifts blame to others and avoids taking shared responsibility, often obscuring the real reasons behind the project's failure to safeguard their own position/ego.

Minimum Viable Product (MVP) Development:

I you're a founding engineer or a newly minted technical co-founder, your CEO will go to your for advice on what to build an when to release. It's important to understand that the work fills the time allocated for it.

✅ 10x Engineer: “Let’s make it good enough and ship it” You focus on delivering an MVP with just enough features to satisfy early adopters and validate the product concept.
❌ 0.1x Engineer: “Let’s make it perfect and never ship” Aims for perfectness and feature-complete product at launch.

Feature Prioritization:

Every software engineer has managers they work with. Most of the time the managers discuss the prioritization with the team and the team gives their opinion what should be developed next.

✅ 10x Engineer: "So what do our customers say, what are their biggest pain points?" You work closely with product management to prioritize features that deliver the most value to customers.
❌ 0.1x Engineer: "I want to roll out Kubernetes" Insists on implementing complex, less impactful features that showcase technical prowess but do not align with user needs or business objectives.

I hope these scenarios served their purpose in showing that you don't have to pull all-nighters to deliver highly-complicated software to be considered a 10x engineer, you just have to choose the right way to act during routine tasks while committing solid code.

The average as the moving force

Big projects move because of the collective effort, not just because of one rockstar developer. Sure, having someone who can blast through problems and code like a machine is great. But one person can only do so much, even if they are a 10x or a 100x engineer. They get sick. They take vacations. They have off days. They can quit. Projects that rely too heavily on these superheroes can find themselves in a tough spot when the superhero needs a break.

As you can see from the scenarios above, stepping up with the right attitude is enough to be perceived as a 10x engineer relatively to your team. And if everyone steps up like that, then you have an amazing team that focuses on what's best and does their best. Isn't that what's most important, rather then celebrating someone who coded one very complicated feature in a day? Think about any major software update or product launch that went well. Was it just one person? Hardly ever. It was a team who handled thousands of small tasks/complaints/issues/tickets, to get everything right.

Let's aim to appreciate all spectrums of contribution equally. After all, it’s the combined efforts of all types that create truly successful projects—not just the moments of individual brilliance.

UPDATE 23rd April 2024: If you prefer watching videos rather than reading, or if you just want to see my face — I recorded a video about traits a 10x engineer should have. Watch until the end for my personal stories. Here's the link.

Other Newsletter Issues:

• Mental Health in Software Engineering
• Falsehoods Junior Developers believe about becoming Senior
• Habits of great software engineers
• Proper Software Development Estimations