The 10x Engineer

What truly sets a 10x engineer apart in the software world? It’s not just technical proficiency, but a unique mindset and approach to decision-making. For this post, let’s assume we’re talking about a technically competent individual. While my perspective is primarily informed by my work at startups, these principles can likely be applied to various types of companies.

One of the most uncomfortable parts of a startup is the sheer number of choices available. From selecting the right tech stack to use, to determining which features to build and how to structure the engineering organization. It’s critical to learn and practice getting good at prioritization to be going in the right direction, while also focusing on speed. This is velocity, which can only really be measured with a vibes-based approach.

At the genesis of a startup, the engineer thinks from the user’s perspective. What is the ideal platform (e.g. iOS) to use the product? If the current skillset doesn’t align with this ideal platform, alternative platforms (e.g. a website) should be considered that can sufficiently test the startup’s core hypothesis. It’s often wise that the engineer build what they’re most familiar with because at the end of the day learning a lot of new tech is a side quest. Undoubtedly learning new things will occur, especially if they’re building something interesting.

Stability in the development process is enhanced by avoiding using new frameworks or packages, and particularly steering clear of beta releases.

Given a small team at a startup, it’s impactful for the teams’ velocity to keep everything minimal. This engineer knows that writing less code is a good thing. This means frequently using publicly available APIs (e.g. Stripe, OpenAI). In many cases, the only infra required at a startup are platforms like Cloudflare Pages, Vercel, or Render. Most of these platforms integrate seamlessly into GitHub Actions. There’s your continuous deployment in a nutshell. It’s unlikely that the entire product can be built this way. There will be something that needs to be specialized that will require a lot of customization. This will form part of the value of the startup itself.

This one might be a bit controversial, but this engineer doesn’t write many tests. At least at the early stages of the startup. The best use case for writing tests is to increase the confidence at making changes to a codebase. This could for example be a complex algorithm or an SQL query that uses a lot of aggregations.

A broader concept that needs to be considered is cognitive load. How much cognitive load is required when dealing with the codebase? The higher it is, the slower work will get done, and the more pain will be felt. One of the best ways to reduce cognitive load is to be consistent. Where this falls apart most often is when building new features and deciding to build them in a new way that is thought of as better. Unless this new way is superior (e.g. latency), or there’s a plan to migrate the rest of the codebase to this new way, then it’s not a good idea. The other way is to design systems to have few moving pieces or to isolate the use of many pieces to a single place in the codebase. Isolating complexity can be just as good as removing the complexity entirely. Examples of decisions that minimize cognitive load include using a somewhat denormalized database schema or adopting a monorepo that deploys one or two workloads instead of a microservice design.

“An idiot admires complexity, a genius admires simplicity” — Terry A. Davis.

Prioritization is about choosing what to work on, and focus is about not getting distracted. It’s a requirement to first understand what it means to work at a startup. Think top-down. The startup needs to provide value to its users. Work backward from there, what experiments can be executed that provide the most confidence in the least amount of time? Instead of having an obsession with the tech, there is an obsession with what the tech does for the end user.

When deciding what to work on, alternatives are always considered. It is very easy to have an idea that is perceived as great and to start working on it immediately. This is vulnerable to confirmation bias in that the engineer will gather the information that serves that initial idea without realizing that the engineer was going in the wrong direction from the start. In practice, this leads to rewriting a lot of code because, in the process of implementing the idea, a realization happens that there’s a better way. This is also peak tunnel vision.

To sustain focus on your priorities, it helps to have weekly meetings that start by reviewing the current goals. On top of this, it’s much easier to sustain focus by having one core thing to get done in a week, in addition to many smaller things. By having many things to work on at once, it’s easy to take a temporary break from the core thing being worked on and work on something else. This can happen when feeling overwhelmed with a task, feeling stuck, or waiting for a code review. Regardless of what the engineer does in a week, momentum is maintained. A good amount of productive work happens asynchronously to other people. Being at the mercy of other people will fuck the engineer’s productivity.

The 10x engineer has a deep understanding of their own time management. They thrive on back-to-back hours of uninterrupted work and minimal context-switching. If a colleague interrupts, the engineer isn’t afraid to ask for 5 more minutes to wrap up, or to tell them they’ll tackle the request later that day or tomorrow. They also make decisions fast. Assuming it’s reversible, a decision made now versus in an hour can be pivotal.

There is one more aspect that isn’t so much about what makes a 10x engineer, as it is about what makes an exceptional team player. That is EQ and the synergistic ability of the team. As negativity is felt immensely more than positivity, how well a team works together can be seen more when things go wrong.

It is critical to always assume positive intent. No one purposefully didn’t get their work done when they said they would, no one intentionally forgets to test a feature and subsequently breaks production. Understand that most things that go wrong are because of a process, and not an individual. So build a better process (but not too many).

It’s important to have strong individual ownership as an organization and strong accountability as an individual. It shouldn’t be a surprise that most software engineers have high egos. Therefore it’s so important to have a blameless culture. No one wins by hurting someone’s ego, but everyone wins if you feed it. Let individuals be accountable. There should never be any accusatory “you did this”, or “why would you do that”.

Most people will have to initially be told about this way of working. It’s only a natural defense for individuals to lean on the negative blameful side of all this.