I have been contemplating the diverse impact of engineers on projects and the true meaning behind evaluations like "10x engineer." In the past few years, many articles have discussed this concept, with some calling it a myth and others believing that you need at least one in your team. This is a highly debated topic; it is easy to understand why, as this term often sparks controversy. However, I believe it is crucial to understand the true value a developer brings to a team, beyond any numerical evaluation or their leetCode scores.
I am one of those who believe that a 10x engineer is one of the greats, and my viewpoint is not a fantasy. But I have a more nuanced perspective. I believe that being a 10x engineer has nothing to do with coding ability. What matters more is that anyone can become a 10x engineer. It is not about personal qualities, but rather the cumulative effect of the small decisions you make as a software developer - the tools you choose, the way you debug, and how you interact with your teammates.
In the early stages of my career, I witnessed firsthand how an ordinary developer became a 10x engineer overnight. We had a high-load project that had to handle thousands of requests per second, developed by a small team - a project that required quick work and scanning large amounts of data to match multi-dimensional queries in the search module. At first glance, everything seemed fine, as the code had been running in production for some time. However, some users complained that they randomly did not receive responses.
Over time, the error rate continued to rise, but we had no one to turn to for help. The original development team had moved on to another project, and we had no time to seek their assistance. The product was already live, and the unresolved concurrency issues were causing unpredictable behavior, which understandably frustrated the users.
Then, our main developer stepped up. He spent days trying to pinpoint the problem, debugging every line of code. Was he the best engineer I had ever known? No, but at that critical moment, his contribution to the project was ten times that of anyone else on the team. He single-handedly solved the problem that we had been struggling with for over six months.
Looking back, the term "10x engineer" falls short of doing justice to the necessary contributions. It is not about being ten times faster than other engineers; it is about making critical decisions that have a significant positive impact on the entire team. If you are faster but everything else goes wrong, are you truly a 10x engineer or a 0.1x engineer?
The Myth of the 10x Engineer: Distorted Perspectives#
The term "10x engineer" is appealing. It grabs people's attention dramatically. Some people come up with solutions within a day, and they are immediately hailed as 10x engineers. But the problem lies in the cognitive biases associated with this term. We tend to focus on those shining stars and often overlook the grounded, reliable engineers who quietly keep the system running smoothly.
Why is that? Well, our brains are wired for hero stories. We are naturally inclined to admire those who stand out due to their exceptional traits or achievements. This can be traced back to our early survival instincts. When someone excels at something, we take notice, even if it only happens occasionally on a full moon night. This heuristic thinking is useful in the wild, but it can lead to biases in our everyday judgments.
For example, the image above is a terrible example of a 10x engineer and is completely wrong.
One very common cognitive bias is the halo effect. When our overall impression of a person is influenced by a prominent trait or achievement, the halo effect occurs. For example, if a team member has solved a complex bug in a short period, we may overlook their continuous struggles with meeting project deadlines and still consider them highly efficient based on that one memorable feat. This can lead to an overestimation of their abilities and unreasonably high expectations.
The contrast effect can cause us to underestimate someone because their skills are not as flashy as those of their more prominent colleagues. This can lead us to overlook the stable contributions that are equally crucial to our success. This situation arises when we directly compare the abilities of two engineers instead of judging them based on their own merits. Imagine if one of our developers just completed an impressive feature demo, and the next one is not as eye-catching. The second engineer may unfairly appear less impressive in everyone's eyes - not because their work is subpar, but because they are overshadowed by someone else's brilliance. Just because they are overshadowed, does that make them a 0.1x engineer? I don't agree with that.
Another bias is confirmation bias. When we see someone who has done something great in the past, we start noticing details that support our view and ignore those that don't. For example, if we label someone as a 0.1x engineer, we may unconsciously overlook their successes and focus excessively on any minor mistakes, reinforcing our initial judgment.
"There's a bug in production. It must be David's faulty code again."
The problem here is that when we appreciate those standout behaviors, we may not see the team members who quietly refactor code to improve cleanliness or spend time mentoring new colleagues. These actions may not shout "10x engineer," but they are crucial for the long-term success of the team.
Typical Scenarios and Behaviors#
As I mentioned earlier, the debate about 10x engineers versus -10x engineers depends mainly on the countless decisions we make daily and how we react to different situations. It is not just about how fast or "smart" your code is. Let's illustrate what it takes to be a 10x engineer through some specific scenarios.
Handling Bugs in Production#
Imagine a client or stakeholder discovers inconsistencies in the application related to a feature you developed. When someone tells you that your code is causing issues, the following can serve as your basic guidelines for response.
✅ 10x Engineer: "We will investigate immediately and respond as soon as possible." You quickly identify the problem, fix the bug, notify the team, and share the solution in post-analysis to prevent future issues.
❌ 0.1x Engineer: "It works fine on my machine." Initially ignoring the report, blaming the environment or user error, and ultimately applying temporary hotfixes that do not fully resolve the problem.
Responding to Code Reviews#
A more experienced developer is reviewing your code and suggests an alternative implementation, stating that you should refactor according to the company's coding standards before the pull request is approved.
✅ 10x Engineer: "Thank you for your feedback. I really appreciate these suggestions!" You genuinely appreciate the feedback, strive to incorporate the suggestions, and thank your colleague for their insights. You focus on the betterment of the product rather than pushing personal agendas or ego.
❌ 0.1x Engineer: "You're wrong, my code is already perfect." Showing defensiveness, engaging in irrational arguments that slow down the review process, and focusing solely on personal achievements, believing that the code they wrote is more important than overall product improvement.
Dealing with Management and Administrative Tasks#
It is well-known that software engineering is not just about writing code; delivering any feature comes with a lot of additional work. Imagine in a regular meeting, managers start requesting increased transparency through project management tools. They express a lack of context and struggle to keep the project on track.
✅ 10x Engineer: "Yes, Jira can be annoying at times, but I understand what you mean. It does help everyone stay in sync and perform their roles effectively." You understand the importance of balancing development and management and strive to handle necessary administrative tasks, ensuring both are given due attention.
❌ 0.1x Engineer: "Jira is terrible, nobody cares about it, it's not even real work." Showing impatience with every demo, diagram, and ticketing work.
Introducing New Technologies#
It has been five years since your project was last properly refactored. With many business changes, the codebase has accumulated numerous temporary solutions to address new edge cases introduced by business growth. It's time to do things right from scratch to adapt to ever-changing business needs.
✅ 10x Engineer: "Let's do a proof of concept to see which technology suits us best, and then decide which one to invest in." You thoughtfully evaluate new frameworks, considering team capabilities and project requirements. You take into account potential technical debt and consider necessary refactoring.
❌ 0.1x Engineer: "We should choose Angular because it's the best, and it's the only framework I'm familiar with. I'm going to argue with you for the next 45 minutes." Pushing for the adoption of new technologies without consideration, allowing technical debt to accumulate, and prioritizing the development of complex features that may showcase technical prowess but do not align with user needs or business goals.
Team Meetings#
You sit down with your team to discuss alternative development approaches for implementing a requirement. There can be many different ways to achieve the same result, with suggestions ranging from going serverless to using the Rust language and building on-premises infrastructure. Many good ideas are exchanged among team members.
✅ 10x Engineer: "Let's hear what everyone has to say." You participate in the discussion constructively, ensuring orderly conversations and adhering to time limits. You encourage each member to voice their opinions and make decisions based on the collective wisdom of the team.
❌ 0.1x Engineer: "Here's my take, please listen for the next 45 minutes." Dominating the discussion, derailing the topic, and engaging in emotional arguments.
Facing a Failed Project#
Things don't always go smoothly, and sometimes you fail. How you react to failure also reflects the difference between being a 10x engineer and a 0.1x engineer. These small interactions matter greatly.
✅ 10x Engineer: "Okay, let's objectively analyze what went wrong, avoid blaming anyone, and ensure this doesn't happen again in the future." You analyze the problem constructively, discuss it in an environment that does not seek scapegoats, and understand the improvements needed to prevent similar issues in the future.
❌ 0.1x Engineer: "It's all because of someone's mistake, their code always causes problems." Shifting blame to others, avoiding shared responsibility, often obscuring the true reasons for project failure to protect one's position or ego.
Minimum Viable Product (MVP) Development#
If you are the main engineer in the team or just starting out as a technical co-founder, the CEO may come to you for advice on what to develop and when to release. It is important to understand that the workload will fill the time allocated to it.
✅ 10x Engineer: "Let's create a good enough product and get it out there." You focus on delivering a product with enough features to satisfy early users and validate the concept of the minimum viable product (MVP).
❌ 0.1x Engineer: "We should make the product perfect and never release it again." Pursuing perfection, aiming for a fully-featured product at launch.
Prioritizing Features#
Every software engineer needs to work closely with managers. Often, managers discuss with the team to determine the development order of features and seek input on what should be developed next.
✅ 10x Engineer: "What feedback do we have from customers? What are their pain points?" You collaborate closely with product management, prioritizing the development of features that bring the most value to customers.
❌ 0.1x Engineer: "I want to deploy Kubernetes." Insisting on developing complex features with high technical complexity but low impact, showcasing technical prowess but not meeting user needs or business objectives.
I hope these scenarios serve the purpose of revealing that you don't need to work late nights or overtime to deliver highly complex software and be recognized as a 10x engineer. The key is to make the right decisions in your daily work and submit high-quality code.
Ordinary People as Driving Forces#
The success of a large project relies on the collective effort of the team, not solely on the superstars' individual efforts. Of course, it is great to have someone on the team who can quickly solve problems and code like a printer. But even a 10x or 100x engineer has limitations. They may get sick, need time off, or sometimes not be in the best state of mind. They may also leave the company. Relying solely on projects that depend on these "superheroes" can lead to challenging situations when these "superheroes" need rest.
Hiring 10x Engineers. Source: workchronicles.com
As you can see from the scenarios mentioned earlier, maintaining the right attitude is enough to stand out in a team and be seen as a 10x engineer. If everyone moves forward this way, you will have an outstanding team focused on best practices and striving for excellence. Isn't that what matters most? Isn't it more important than celebrating someone who writes an extremely complex feature in a day? Think about those smooth major software updates or product launches. Were they accomplished by one person alone? Almost certainly not. It was the collective handling of thousands of small tasks, complaints, issues, and transactions that ensured everything went smoothly.
We should have a fair and appreciative view of contributions at all levels. After all, truly successful projects come from the collective efforts of various individuals, not just the moments of brilliance from individuals.
Updated on April 23, 2024: If you prefer watching videos instead of reading or just want to see me in action - I recorded a video sharing the traits a 10x engineer should have. Please watch until the end to hear about my personal experience. Click here to watch the video.
Original article link: https://vadimkravcenko.com/shorts/10x-engineers/