The Secret to Being a 10x Engineer

- 3 minutes read - 503 words

Our industry has a concept of “10x engineers”, individual contributors who have the impact of ten colleagues. How can you become one? I’ll try to answer that in this post.

But first, here’s the price of admission: you first have to be both fast and competent. And that’s not enough.

What’s fast? Reducing waste in every part of your development process. Cutting to the bone the time it takes to type, save and share your work, communicate, and hack your way to something good enough to ship. “Fast” and “great” are tightly correlated in this field.

What’s competent? Being able to do anything in your domain. As a web developer, that means being an expert or at least dangerous in design, frontend, backend, scripting, project management, and infrastructure.

If you’re on this journey, keep going! And yet, it’s only half the battle. The second half is being able to prioritize.

The Secret to Being a 10x Engineer: Prioritization

The Pareto Principle states that 80% of the outcomes in a system come from 20% of the causes. Applied to this domain:

80% of the business value we create as engineers comes from 20% of the features we build.

The trick is figuring out which small sliver, of all the work you could be doing, creates that value. It’s a sense that takes years to develop.

When thinking about starting a ticket, consider if any of these are true:

  1. There’s a “why” behind it. “We can’t sell in South Dakota unless we collect sales tax on this form”
  2. The requester is someone who feels the pain. “We (customer service) can’t contact customers on Fridays until we fix this bug”
  3. The requester is a person who has used the software
  4. The feature supports core business functions (“checkout bug” beats “upgrade node”)

Any work that answers yes to one or more of these is work I want to do.

Our job as engineers is to be one of several voices fighting for the important stuff. We often get the last chance to say “This doesn’t make sense” and guide a ticket into the trash.

Reject busywork! Every team has a few “the backlog is empty, work on whatever you want” days, and I try to avoid them. Sure, it feels exhilarating for a moment… “I got to refactor our list libraries!” But soon I get that itch that what I’m doing isn’t important. Any change has risk, so I want each to have direct business value.

Working on my own startup for a year helped with this. When you are the person who picks and builds the next story, you start to cut through the fluff.

Summary: Fast, Competent, and Able to Prioritize

This is how I define a 10x engineer: they are fast and competent, and then, they get great at sensing what’s important work and doing mostly that. You need both: being effective doesn’t matter if you’re doing busywork, and knowing what isn’t busywork doesn’t matter if you can’t write and ship the code quickly.