10x engineering for the rest of us

The mythical 10x engineer is said to have the efficiency and output of 10 normal engineers. While their existence has been debated, I have actually worked with a couple 10xers over the course of my career.

As Santa Claus proclaimed in the undying M&Ms Christmas commercial: “They do exist!”

But before you get too exicted about their existence, I have some bad news to bear: working with this type of 10x engineer isn’t all that great. Who is going to review all the code this engineer just cranked out? All of a sudden you have an imbalance. You now either have team members spending much of their time reviewing a 10xer’s code (no fun) or you start piling up a backlog of pull requests authored by a single person.

So if this type of 10x engineer isn’t all that helpful, is there a type that is helpful? Yes! A looser definition of 10x engineering also includes engineers that are capable of technical depth and discovery very quickly. They can evaluate a complex feature for which there is no prior art in your code base and come up with an elegant solution quickly. The nuance here is about cognitive load rather than lines of code.

Now that I have described two types of 10x engineers, I have some more bad news: many of us, myself included, will never be 10x engineers by either of these definitions. But that’s okay! I think there’s actually another type of 10x engineering that’s attainable for the rest of us.

The third type of 10x engineer is one who works on the developer experience and health of the team. This engineer does their day job, but has an eye out for ways the team can run better. Here are some examples of improvements I have seen these kinds of 10x engineers make:

• Tightening the development feedback loop. This includes things like speeding up automated tests and adding pre-commit hooks so failures occur locally rather than in continuous integration.
• Implementing per-branch previews for design review (rather than having a limited number of preview environments).
• Periodically auditing/fixing development setup instructions.
• Adding caching to speed up continuous integration runs.

Think about the cumulative effects of these changes over time. That’s what makes this 10x work—it’s not that you yourself are doing 10x the work, but rather you’re improving the productivity of a bunch of engineers, resulting in a multiplying effect.

There are less technical ways to have this effect on teams as well. Consider doing glue work to keep the team running smoothly. One of my personal favorite contributions is being the engineer that sits down with product and design to make sure work is well-specified and ready to be estimated. Additionally, consider making a culture impact by approaching work with positivity, helping out junior engineers, and encouraging cross-discipline collaboration.

Maybe you find it a stretch to call this work 10x engineering—and that’s okay. It’s not important what we call it. What’s important is that focusing on improving the experience and productivity of your colleagues will make you an integral part of any team.