How to Be a 10% Engineer: Be a 10x Engineer First

Published in

Level Up Coding

11 min readNov 1, 2022

We probably will never know who first coined the term 10x engineers. But we sure know there are many definitions and memes around them. For example, one of the most popular discussions about 10x engineers was started by Shekhar Kirani back in July 2019.

You’d see few points which I agree with…

10x engineers can convert “thought” into “code” in their minds and write it in an iterative fashion.

…and I disagree with…

10x engineers hate meetings.
10x engineers know every line of the code that has gone into production.
Most of the 10x engineers are full-stack engineers.
10x engineers rarely look at help documentation of classes or methods.
10x engineers are poor mentors as they can’t teach others what to do OR parcel the work.
10x engineers don’t hack things.

…which signifies how many permutations of 10x engineer qualities, activities, and characteristics according to different professionals in the industry. This blog is focused on 10% engineers, so I am only going to discuss the 10x engineer definition that’s related to being a 10% engineer (and the best kind of 10x engineer you should consider to be a 10% engineer).

Rather than explaining what constitutes a 10x engineer, let me give an example of what a team without a 10x engineer looks like, and what happens with one.

A Team Without 10x Engineer

A team of 3 engineers (2 frontends and 1 backend engineer), 1 product manager, and 1 designer working on a car rental marketplace. The business premise is for an individual to be able to list their car(s) for rent while other people can search, browse, discover, rent, and pay for the car.

The PM started the requirement by asking the engineering team to build a listing website with their map and live location of the cars in 2 months. The engineers said making their map is unreasonable and pushed back the requirement, and asked for 6 months. The PM begrudgingly agreed to use Google Map instead but pushed back that everything needs to be done in 4 months. The team then invested all the 3 engineers in building this.

Two months in, and it seemed like the engineers thought we’d not get this done in time. The PM asked for more resources from leadership without asking the engineers. The original team somehow got another 1 backend and 1 frontend engineer to help but also wondered who will have the time to get these 2 new engineers on board. But at least now they had more people to drink with during happy hour.

Four months in, the project was “almost ready,” according to the most outspoken engineer. After user acceptance testing, seems like the map integration was flaky, the UI had some flickering issues, and the backend team insisted they want to add 100% test coverage to their code. The team agreed to add additional 2 months to get this project up and running.

Seven months in, after a minor delay here and there, the project is finally ready to launch. The marketing team was ready to start sending promotions, and the management team was super excited about the launch. “July 4th, that’s the best timing,” everyone agreed.

July 4th. The website is public. Marketing was massive. The website was down for a while due to traffic. The team doesn’t know how many people come to the website, but it was massive. The backend engineer increased their EC2 instance from small to large to help with the load. The team ended up with 100 signups and 0 transactions closed.

July 7th. The website is not crashing anymore. But the PM kept wondering why there were still 0 transactions. The PM asked the team to debug. Apparently, their payment integration was not working well, which was never tested before because none of the engineers want to test against their credit card. The team quickly fix this with PM’s credit card and they receive 2 transactions (where 1 of them was a test transaction).

July 20th. Seems like now the website is working well. But there were only 10 transactions closed so far. It seemed like people are using the website, and the demand was there, but they can’t close the transaction. The hypothesis was the website was too complex to navigate (one of the frontend engineers mumbled, “the customer is just too dumb”). Sadly, the team didn’t know where the customer got stuck. One of the engineers suggested that we put some tracking and logging into the website. He proposed the use of Firebase and Metabase to log and store the events (he heard that it’s the industry standard and it’s highly scalable). Since the team needed to research these new tools, they would need another 2 months and scaled down the team to just 1 backend and 1 frontend engineer (from 5 engineers).

September 1st. Somehow the team implemented the logging faster than expected (great job, team!). Now the team understood that there was an issue with the checkout page due to the number of drops off based on the logging. It was a simple 3-liner fix. The team pushed the code and eagerly looked at the transaction number. Though right now, the marketing team ran out of budget for this project, so they didn’t have enough traffic to test the transaction. They had to wait for 1 month to see if their fix actually improved business metrics.

October 1st. The website started closing consistently 10 transactions/day. But the management team thought this product was not worth the investment due to the amount of time (10 months) and people (7 people) wasted on this. They want the company to focus on upcoming Thanksgiving and Christmas-related products. The PM begged the management team and promised that the team will include Thanksgiving-related work in the project. Finally, he’s given 2 months and 2 engineers to prove that this can grow to 30 transactions/day.

A Team With 10x Engineer

The 10x engineer got the same requirement as above. She wondered why the live location is important since the car would be parked in the same place for a long time, emphasizing that they were on different business than Uber/Lyft. She also got on the same page with the PM that they’re building a marketplace product — which means there’s a supply and demand problem that needed to be solved, possibly separately. The PM and the 10x engineer agreed that solving the demand side was a more important problem to solve than the supply side. They needed to design a website that was as frictionless as possible and tested the demand.

The PM then went to ask all the team members for whoever wanted to rent their car since they agreed that they didn’t want to solve the supply side of the marketplace yet and thus would need some inventory to break the chicken-and-egg problem (no car inventory means no customer. No customer means no one wants to rent their car). Meanwhile, the 10x engineer consulted with the legal team about whether they can use a 3rd party tool to build the website. Upon approval, she gathered a team of 1 engineer and started building the website using a no-code tool like Bubble.io. After designing the database, her team went on to spend 2 hours manually inserting the car-to-be-rented into the database

Ten days into the project, the website was done. The 10x engineered prep the website to be able to handle 1,000 traffic based on marketing team estimation by upgrading the subscription plan from $25/month to $100/month. She also integrated Google Analytics into the website even though she didn’t know what they would use the tracking for (she only had a hunch the team would need it based on her experience). While the management team was disappointed that the website only contains a listing of cars (and no way to systematically supply new cars through the website), they’re excited to launch this to the public.

On the first day of launch, everything was good. Marketing was successful, and it was apparent that the website had more demand than the currently available supply. They received 80 signups and closed 40 transactions on the first day and 20 transactions on the 2nd day, and 30 transactions on the 3rd day. The 10x engineer and the PM immediately planned for the next iteration: how to solve the supply side by allowing people to upload and list their cars for rent.

Software Engineers are NOT Coders/Programmers

Something critical for us to be on the same page before we discuss about 10x engineers: software engineers are not coders/programmers.

The closest analogy for software engineers vs programmers I can think of is comparing doctors vs nurses.

Can doctors measure blood pressure? Sure they can!

Can doctors do an infusion? Sure they can!

Can doctors do daily follow up to make sure the patients are drinking their medicines on time? Sure they can!

But why do you rarely see doctors do anything mentioned above? Because of the following reasons:

Some things can only be done by them and can’t be done by nurses. For example: attaching your thumb back together, LASIK operation.
There are more important/high-level things to do to ensure the patient is well. For example: figuring out which part of the brain artery needs to be unclogged, how to do it while preventing future side impacts, and figuring out the right medication.
There is quite a bit of thing that needs to be done, and the doctor has to delegate some of the work to someone else as efficiently as possible. Theoretically, a doctor can delegate the work to another doctor, but it won’t be an efficient use of both of their time.

Similarly, not all software engineers need to code every day (or at all) to accomplish what’s expected of them and to deliver value to the company. You might’ve heard that some engineers on the principal level stop coding altogether and mainly contribute to software architecture and their tradeoffs.

Most software engineers started their career writing code. But sufficiently tenured engineers know that a successful project requires more than just code. To name a few, you’ll need monitoring, project management, cross-functional alignment, a design that works, project momentum, and prioritization. And later in their careers, software engineers are expected to deliver a good product, not just deliver a functional code that works according to the product manager’s specification.

Due to the non-trivial amount of things (and people involved) that need to happen for a (big) project to run smoothly, 10x engineers will fill a role within the project that fits their strengths and help drive the project to be successful as effectively and efficiently as possible. These roles vary across 10x engineers thus, it might be interesting to talk about the archetypes of 10x engineers.

The Archetypes of 10x Engineer

Describing a 10x engineer is tough because there are no one-fits-all activities they do day-to-day. And their qualities shine differently between individuals and teams they are in (or spotted in a team without them, as illustrated above). Here’re the archetypes of 10x engineers per my observation over the years:

Generalist is a 10x engineer who breaks down complex and ambiguous problems into digestible ones by their coworkers. Then they usually will work either on the hardest or the riskiest one (but not always the most impactful one). They are well-versed in multiple technologies, thus allowing them to apply themselves in the right place as needed.

Specialist is a 10x engineer who specializes in one platform or one technology that created an outsized impact. They are usually a renowned player in the industry, be they a creator/big contributors to widely used open-source projects (e.g. React Native) or creators of a platform (e.g. Android, Git). People join a company to be able to work with them.

Fixer is a 10x engineer with the special power to spot a problem (not necessarily complex) and make a sizable impact. They usually know (or know how to quickly know) a domain (source code, business vertical, platform) really well, thus knowing how things should work and what’s the delta between the current situation vs its most optimal version.

PM Hybrid is a 10x engineer who has great product sense and worked very closely with the product leader/PM to build a product strategy together. A PM Hybrid can often play a temporary product manager role in their absence. Their skillset is also wider (but more shallow) than Generalist, being savvier on data analysis and designs.

Coding Machine is a self-explanatory archetype. They output more code than any other engineers. A typical engineer would output 100 to 200 pull requests every 6 months (or an average of 1–2 PR/day). This person will output 1500–3000 pull requests every 6 months (or an average of 10–20 PR/day). Sadly, recurrently I’ve seen that they’re not the best teacher so the skill doesn’t seem to be replicable.

The Logistics to Become 10x Engineer

Then how to actually become a 10x engineer? Sure there are “keep coding”, “keep hustling”, and “go beyond your comfort zone” tips that I can give you. But let me give you some practical ones:

Choose a company. Do NOT jump between too many jobs if you really want to become a 10x engineer. The goal is to learn and then to earn (ideally both at the same time). Unless the company doesn’t have a good path to learn (performance review, mentorship, challenging projects, exposure) nor earn (promotion, credibility, bonuses), STAY.

Become a senior engineer. This is usually pretty straightforward. Most decent companies will have a path to becoming senior engineers (if they don’t, see points above). If you’re the founder of the company, then this is automatically achieved. The importance of becoming a senior engineer is not only about accumulating the skill, but also about social capital within the company, and reputation and opening you up to more staff-level project opportunities (yes, title matters here).

Spot and execute staff-level projects. According to staffeng.com, not all staff engineers need to execute staff-level projects. But to become a 10x engineer, you need to execute staff-level projects. There’s really no good way to spot a staff-level project (and a lot of time, you might need to spot the potential, not just how the project is right now). But usually, it has the 3 ingredients: complex and ambiguous, multiple divided stakeholders, and critical to company strategy/metrics.

Pick an archetype. It’s tempting to try every archetype. But usually, you’ll start out being good at one (due to there being only a limited amount of time a person can work in a day). Not only it’s going to be more efficient, but you’ll also get good at “how do I get good” at another archetype as well. It’s totally possible to exercise multiple archetypes in your day-to-day work (in fact, a 100x engineer will know what archetype he needs to play in a given project he’s in right now), so be flexible as well and spot the opportunities.