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 considering it a myth and others believing that at least one should be present 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 a great person, and my view is not based on 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 team members.
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 multidimensional 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 initial development team had moved on to another project, and there was simply no time for them to assist us. The product was already live, and the unresolved concurrency issues were causing unpredictable behavior, leaving users frustrated.
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 knew? Not necessarily, but at that critical moment, his contribution to the project was ten times that of anyone else on the team. He single-handedly solved a problem that we had been struggling with for over six months.
Looking back, the term "10x engineer" falls short of acknowledging the necessary contributions. It is not about being ten times faster than other engineers, but rather 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 Distorted View of the 10x Engineer#
The term "10x engineer" is appealing. It grabs people's attention. Some people come up with solutions within a day and are immediately labeled as 10x engineers. However, the use of this term is filled with cognitive biases. We are naturally inclined to admire those who stand out due to their exceptional qualities 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, like on a full moon night. This heuristic thinking is useful in the wild, but it can lead to biases in our daily judgments.
For example, the image above is a terrible example of a 10x engineer and is completely wrong.
One 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 just as crucial to our success but are relatively hidden. This occurs when we directly compare the abilities of two engineers without considering their individual strengths. For example, if one developer has just completed an impressive feature demo, and the following demo by another developer is not as eye-catching, the second engineer may unfairly appear less competent - not because their work is inferior, 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 contradict it. 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 on the countless decisions we make daily and how we react to different situations. It is not just about how fast you write code or how "smart" your algorithms are. Let's go through some specific scenarios to demonstrate that becoming a 10x engineer is not as difficult as it seems.
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 get back to you 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, attributing the problem to the environment or user error, and ultimately applying temporary hotfixes that do not fully resolve the issue.
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 product's improvement rather than pushing personal agendas or ego.
❌ 0.1x engineer: "You're wrong. My code is already perfect." Being defensive, arguing unreasonably against the feedback, which not only slows down the review process but also focuses solely on the individual - considering their code more important than the overall improvement of the product.
Dealing with Management and Administrative Tasks#
It is well-known that software engineering is not just about writing code; releasing any feature involves a lot of additional work. Imagine in a regular meeting, managers start requesting increased transparency through project management tools. They express a lack of contextual understanding and difficulty in keeping the entire project on track.
✅ 10x engineer: "Yes, Jira can be frustrating at times, but I understand what you mean. It does help everyone stay in sync and perform their roles." You understand the importance of balancing development and management and make an effort to handle necessary administrative tasks, ensuring both aspects are given attention.
❌ 0.1x engineer: "Jira is terrible. No one cares about it, and 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 changes in the business, the codebase has accumulated numerous temporary solutions to address new edge cases introduced by business growth. It is time to do things right, starting from scratch to adapt to the 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 carefully 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 over the long-term health of the project.
Team Meetings#
You sit down with your team to discuss alternative development approaches for implementing a required feature. There can be many different ways to implement it, with suggestions ranging from going serverless to using the Rust language and building on local infrastructure. Numerous 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 conversation and adhering to time limits. You motivate each member to voice their opinions and select the most suitable course of action based on the team's collective decision.
❌ 0.1x engineer: "Here's my take, and everyone should listen for the next 45 minutes." Dominating the discussion, derailing the topic, and engaging in emotional arguments.
Dealing with Failed Projects#
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 are crucial.
✅ 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 avoids scapegoating, and understand what improvements are 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 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 adopters and validate the concept of the minimum viable product (MVP).
❌ 0.1x engineer: "We should make the product perfect before releasing it." Pursuing perfection, wanting the product to be fully functional upon release.
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 the team's input on what should be developed next.
✅ 10x engineer: "What feedback do we have from customers? What are their pain points?" You work 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 goals.
I hope these scenarios serve the purpose of revealing that you can become a 10x engineer without burning out or working overtime. The key is to make the right decisions in your daily work and deliver high-quality code.
Ordinary People as Driving Forces#
The success of large projects relies on the collective effort of the team, not solely on the efforts of a superstar developer. Of course, it is great to have someone in 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 vacation time, or sometimes not be in their best state. They may also leave the company. Relying solely on these "superheroes" for projects can lead to challenging situations when they need rest.
Hiring a 10x engineer. Source: workchronicles.com
As you can see from the scenarios above, having the right attitude is enough to stand out in a team and be seen as a 10x engineer. If everyone moves forward in this way, you will have an outstanding team focused on best practices and striving for excellence. Isn't that the most important thing? Isn't it more important than celebrating someone who writes a highly complex feature in a day? Think about smooth major software updates or product launches. Were those accomplished by a single person? Almost certainly not. It is the collective handling of thousands of small tasks, complaints, issues, and transactions that ensures everything goes 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 characteristics 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/