Have you heard from the recruiters or internet memes, talking about a special kind of engineer, called 10x engineer?
Rumor says those engineers can write 10x more code than their coworkers, and get 10x more jobs done. At the same time, they are only working at midnight,
using only command-line and vim, and perform every task by automation scripts.

Where is the 10x engineer name coming from? How do they know and evaluate people can achieve 10x more jobs than others? Turns out the origin of this is from a study in 1968, Exploratory experimental studies comparing online and offline programming performance. The study has a total of 24 engineers, group them into 2 groups and try to solve algorithm problems like Maze and Algebra. Afterward compare the time they spend on the task, debugging time, and program runtime. Turns out there is a huge difference between the best and the worst engineer, all of those differences can be approximated with a ratio of 10:1. This means the best engineer performs 10 times better than the worst engineer.

This study certainly doesn’t mean the engineer can perform 10x better in real-life jobs. First, this is using algorithm problems but not real engineering problems. Second, it is comparing the worst to the best, but not median or average, I can find a high school student and compete on algorithm problems, but that doesn’t make me perform 10x better than the average engineer. Third, it is a limited experiment that is only performed with small samples and fixed tasks, doesn’t have enough presence to the whole group.

However, we all know some brilliant engineers that can solve the problems that we can’t solve, know a lot more things than us, and create outstanding projects. In this perspective, the study is not completely wrong. After all, the whole industry is built up by some genius engineers like Linus Torvalds, DHH, Matz, Steve Wozniak, Guido van Rossum… We can undoubtedly say they have more than 10x impact on the industry than average engineers.

So the real problem is not that some engineers perform much more than others, but is when seeking those performances, people evaluate the wrong things and accidentally encourage the toxic traits.

Toxic traits

In a series of tweets by @skirani, he described the 10x engineers as the person who “hate meetings”, “working at night”, “poor mentors” and “use black desktop background” (this is real). Of course, this got bashed hard on the internet. Some of the traits are full of bias and problematic behaviors, but it is also an iceberg on people’s impression about 10x engineers, they are smart but hard to manage, have strong passion but also lose interest in tasks if they get bored, doesn’t like rules, often go rouge on their things but working even in off-hours, having a strong opinion about things, will spend hours to debate on small issues, doesn’t like other people changing or having an opinion about their code.

Of course, lots of smart engineers act in this way. Partly is because being smart and passionate about programming enhances people’s ego. Combine with those images about genius engineers make people think it is okay to follow the passion, avoid meetings and communications to get things done, work on other parts of the system, read through the legacy source codes to refactors and get annoyed when people doubt the obvious things or having “stupid” questions. They think they are contributing more compare to other coworkers until they wonder why they got a really bad review at the end of the year.

The first thing is those 10x engineer traits are wrong about causality, some genius engineers might act in this way, but acting like genius engineers doesn’t make you a genius, it just gives people an excuse to act like this. There is a tendency for engineers to lack socialization and have a strong ego, but it is not an excuse to not learn to avoid those behaviors. A good engineer should be and only be decided by the overall performance, but not about those toxic traits.

Although it might be partially true, they contribute more depending on the way people measure performance. They finished more tickets, write more code than others. But at the same time, the reality is more complicated. In the end, it is people reviewing the performance. So if the manager or coworker doesn’t recognize the things they are working on, it doesn’t mean too much to the performance. And most of the time the manager won’t read every line of code they wrote. Also changes and refactoring the code unavoidably create more bugs and issues, giving a bad impression that they are bringing troubles if they are also working in their project. Moreover, is it really benefit the company? Because personal interest doesn’t necessarily align with the company’s interest. They might create a self-made framework just for fun when there are existing choices, which in the end brings more troubles to the people who have to maintain it.

Definition of outstanding / 10x

If writing more code, finishing more tickets, and following the passion doesn’t make you the 10x engineer, what should you do? People need to think inversely about the definition of outstanding. The outstanding is a comparison standard, the point of 10x engineer is not getting 10x things done, but is not acting like a 1x engineer. There is no need to become a rockstar in the team, but just don’t be the asshole in the team.

So for being a 10x engineer, people need to first avoid making mistakes. Although everybody is saying you have to be courageous and make mistakes. But it is different to make “calculated” mistakes and “avoidable” mistakes. It is like taking bets, even you are making the bets that have higher than average odds, there are still chance to fail, this is essentially different than just taking a bet with low odds and expecting it to work out. For not being a 1x engineer, you need to avoid those careless mistakes, careful about what you are writing, don’t write bad code, don’t create bugs, don’t work on the things that no one asks you to do, focus on the project, ask people if you don’t know things, make sure the thing you do is correct, meet the expectation of delivery time and don’t overpromise. At the same time, listen to other people’s opinions, be nice to coworkers, avoid having an ego in meeting and code. By achieving those, you can have a good review and happily avoid being a 1x engineer in the team.

After that, you can finally consider how to be more productive and increase the impact on the team and company. Increasing the technical ability is one thing, read source code, create side projects, learning frameworks, use automation, tools, and IDE… etc, there are lots of ways to learn and to increase productivity. But essentially, from the company’s standpoint, it doesn’t matter how good you are, you need to deliver results to be actually productive. First you need to find out what is the right thing to do, deliver and take credit from it. You have limited time and focus, so it’s better not just randomly work on something that you feel is interesting, you need to find the right problem to solve by asking people, collecting opinions, and creating spikes to validate it. Afterward, you need to take credit for it. Because the manager will not recognize the code you wrote, even the coworker. Host a lunch to share the knowledge, do an announcement and presentation in a company meeting. It is not necessary for solving the problem, but it can build up the reputation, so the next time you can have more trust and freedom to work on things, and give you something to say in self-review.

And then you need to help the team because the performance is evaluated by the team. If the team does not perform well, you will not have a good performance too. The simple way is to do the same inverse thinking at the team level. Helping the team to deliver fewer bugs, write simple code and make sure it is implementing the feature that the user needs. For achieving that, code review is a good way to provide feedback and find potential bugs. Also asking the right questions in meetings to clarify the user needs. But also you need to understand team dynamics, sometimes saying things directly, pointing out mistakes does not work well if you did not build up trust with the team. Knowing the team and using the right approach to help the team, is one of the hardest things to learn, but also essential to the productivity of the team.

Finally, you need to manage the expectation from the manager, eventually, they are the ones to decide your performance. But the manager’s job is not to make your success, but to make sure you don’t mass up. So there is a conflict of interests, working on something cool that benefits the company, actually doesn’t align with the manager’s interest. Because the manager won’t get credit even if you achieve that but take the blame if you failed. That is why by research the middle manager is not as innovative as workers and executive officers. That is why you need to manage up to align the interests. One way is to ask the manager for a promotion, career development, or interesting projects to work on. Having discussions and setup clear expectations about success. Review the progress together, let the manager solve the problem for you, and also take credit for your success.

Given 10x impact

But even though you matched the expectation and deliver results, that will still not make you a 10x engineer. So we are going back to the same question: how to become a 10x engineer?

If you review the examples of those genius engineers, like Linus Torvalds, did he write the whole Linux kernel by himself? Obvious not. Software is a team sport, a successful software involves a lot of people’s contributions and efforts. The iconic genius engineers usually are the ones who start the project and get credits from the later success. Eventually, the engineer can give more than 10x impacts is the leader of the successful project and team.

For leading the project to success, having good communication skills is important. Only the person who can communicate well, mentor, and share knowledge with others, can lead other talented engineers contribute to the project. On the other hand, having good technical skills can help, but more important is to learn from others. The project will always have unknowns, so it is more important to be able to quickly learn what you don’t know and connect that knowledge to solve the problem. Last is the execution, it might sound cliche but eventually, the leader needs to work hard to make the project successful. Eventually, how focus the leader on the project, is one of the most important factors for success.

Conclusion

Therefore, for being a 10x engineer, you need to be able to lead the project to success. Avoid making avoidable mistakes, help and mentor others, manage the expectation from management, and finally work hard to execute the project to success. Forgot about those specific traits or toxic traits, it only creates more engineers that are an asshole, and given the excuse to not be a nice person to work with.