10x Engineers

20 April 2024 · 17,148 views · Updated 01 May 2024

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.

Such a bad examples of 10x engineer, and completely wrong as well.

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.

Hiring 10x engineers. Source: workchronicles.com

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:

  • 1.0x engineer

    Thank you for the post. It’s really inspiring! I come back to this blog from time to time and read it again to get a refreshed perspective.

    One or two typos that do not affect the reading, but it would be great to fix then so that future readers will have a even better experience.
    Original text:
    “`
    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.
    “`
    What I assumed you’d like to say:
    “`
    You’re a founding engineer or a newly minted technical co-founder, your CEO will go to you for advice on what to build and when to release.
    “`

  • Anton Kononenko

    Ok, that’s not 10x engineer. Maybe your lead was, but it doesn’t work like anyone can just become one. It’s extremely many hours spent on things no one can deliver/fix and delivering those, it’s understanding why a lot of best practices are overvalued, and throwing them away.

  • Anonymous

    so 10x is just being normal?

    1. Vadim Kravcenko

      Consistently

  • TheBoc

    One thing to watch out for in the 10x engineer mythos is the diving catch philosophy. Celebrating the recovery from a near-catastrophic disaster or deadline miss by a specific individual who dove in at 5 PM on a Friday night to save us all … from the the mounting disaster that all of us should have been preventing through smart planning and execution the entire time. Is that person a 10x engineer? Maybe. We wasted that person’s capabilities and effort by spending them on a thing management refused to focus efforts on earlier.

  • C-Reactive Protein

    I agree with your assessment, but not with your premise. Positive behaviors lead to positive outcomes and increased productivity. Asserting that these behaviors lead to a 10x difference from the average without any supporting data, weakens your narrative. I’ve read parts of this several times and feel like you are saying that 10x engineers both do and don’t exist. Like you want to believe in the myth but know it’s just a myth. It’s a wonderfully triggering term but it’s a myth. It’s like telling someone that the average walking speed is 3-4 MPH, but I know this guy that can walk 30-40 MPH. It doesn’t matter how good the training or how productive the group or individual, nature imposes limits. Confusion is inherit in these matters because a good team can (given the right parts and plans) built a machine that exceeds 40MPH in an afternoon. Better tools and greater knowledge of those tools can product faster results. The engineers didn’t learn to walk faster. They approached the problem differently and built on the countless hours of other people’s work (making screws and motors and wheels, etc.). Other teams will be able to use those tools with similar results. Don’t confuse the outcome, or the tools with the person or group.

    Whenever I’ve interacted with someone identified as a “10x engineer” outcomes have always been negative. Granted, my opinion is hardly comprehensive, but other comments I see suggested I’m not alone. Not only is this a myth but it’s an unfounded and counter-productive myth.

  • Alex

    I don’t believe in the 10x Engineer concept becuse it always refers to some speed and not true effectiveness, and this kind of decision making leads to project failure.
    The scenarios presented here have nothing to do with a 10x engineer, any responsable team member should behave the green way, while the people that not commited are toxic (the red way) should go away without measuring if they are 0.1x or 10x.
    This 10x evaluation sounds to me like finding out that I use an umbrella by assessing if it’s raining and I am not wet… a useless waste of time and focus …something what a 0.1x manager would do 🙂

  • Samar

    Honestly, the whole 10x engineer thing seems overstated. In my experience, what truly matters is the environment and how well the team works together. I’ve seen average developers outshine so-called 10x engineers simply because they consistently show up and do the work — no waiting for inspiration, motivation, drama, politics — show up and do some work.

  • Sven

    I once overhauled a legacy system that everyone avoided because it was written in Perl. Was I the best dev in the team? pff no, but, I managed to refactor it into a more manageable state, which benefit the team 10x. So I agree with the author, the 10x concept is relative to the output of the team.

  • Anonymous

    Given this criteria, I seem to be like… a 5-7x engineer. Lol.

    1. Vadim Kravcenko

      You might be surprised how good you really are if you just put a little extra effort than most 🙂

  • Mia

    Honestly, the whole 10x engineer debate misses the point if we don’t consider team dynamics. I’ve seen technically average devs turn projects around simply by improving how the team communicates and works together.

  • Lena Schmidt

    Encountered the ’10x engineer’ myth early in my career, chasing those unrealistic benchmarks set me up for disappointment. Quickly learned that writing code faster than my peers didn’t equate to better outcomes, just more burnout and technical debt. most ’10x engineers’ I’ve met are just regular devs with good work ethics, and they were not the magical solution to all the team’s problems.

  • SiliconSage

    I saw projects getting delayed or derailed not because we lacked superhero programmers, but because we failed at managing scope or communicating with stakeholders.