The True 10x Engineer
July 17, 2019
[This article is a work in progress.]
In the profession of software engineering, there is a legendary creature who inhabits the labyrinthine corridors of office buildings, subsisting on energy drinks and the glow of dual monitors, and avoiding interaction with other humans by any means necessary. Many tales are told of this creature’s prodigious industry, and how he—always a he, in the lore—transcends his lowly peers by a monumental factor, putting them all to shame. I refer, of course, to the fabled 10x Engineer.
Many developers, managers, executives, and industry commentators have reported sightings of the 10x Engineer. The 10x Engineer is usually found in a dank corner of the office, lights low, headphones on, hoodie up, jamming away incessantly at the code, often late into the night, producing ten times as much work as his peers. Many guides—and many tweets—have been made about discovering, recruiting, and retaining this 10x Engineer. After all, if you have one person who can do the work of ten people in isolation, your company can develop its product faster, spend less money doing it, and get to that next funding round—and that lucrative IPO—with greater confidence. Who wouldn’t want their own 10x Engineer?
There’s only one problem. That engineer is not a 10x contributor. That engineer is a ticking time bomb.
The Toxic 10x Engineer
In reality, the person who is touted—and often self-styled—as a “10x Engineer” is usually just a brilliant jerk who looks and acts the part of a superhuman developer, but underneath carries huge liabilities for your engineering team and your business.
The Toxic 10x Engineer would rather hoard knowledge and credit to boost their own ego and bolster their own reputation. Most often, they prefer to operate only in code and outside of reality. They’re assumed to skip meetings, disregard non-technical context, disrespect the contribution and opinion of teammates, and generally be difficult for others to work with.
Somehow, that sort of tech machismo became a desirable trait for engineers, and became a sought-after persona for engineering teams. I’m sure that this has worked for some companies in the past, and it may even work in some companies today. But we shouldn’t lean on this harmful stereotype if we want to find engineers that help businesses succeed. There’s a breed of engineer who is more valuable than the aforementioned Toxic 10x Engineer, one who can have an even larger impact, and who can more consistently guarantee the success of your engineering team, and ultimately, your business. This is the True 10x Engineer.
Who is the True 10x Engineer?
The True 10x Engineer is a developer who leverages their impact through others to create ten times the influence that they could have exerted on their own. That’s it. The True 10x Engineer may not be any more adroit at programming than their peers, may not be any more cognizant of trends in the technology landscape than their peers, and might not be a huge personality or enigmatic jerk in the eyes of the team. The True 10x Engineer is an empathic, collaborative engineer who understands that helping others doesn’t come at the expense of their own achievement or professional development. In fact, it’s the richest way to augment it.
So how do True 10x Engineers get to producing 1,000%? It’s all about the scope of their influence, the magnitude of their contribution, and simple math.
The Engineer who makes 10 teammates 100% better
A tech lead or manager has an opportunity to be a True 10x Engineer by enabling 10 of their teammates to be 100% better. 100% seems like a pretty high bar to hit, but if you are sharing the context around the work you’re doing with the team, reviewing their code, unblocking them technically by answering questions or pair programming, counseling them when they’re discouraged, adrift, or burned out, it’s easy to see how you can double their output. These are just some of the hallmarks of fantastic engineering managers and tech leads.
A tech lead or manager has an opportunity to be a True 10x Engineer by enabling 10 of their teammates to be 100% better.
Engineers want to understand why they are doing something. No amount of technical specification can fill in the gaps in code that are naturally filled by understanding what it is you’re building, who you’re building it for, and why it’s important and valuable to build. Even engineers who seldom exhibit curiosity about the business benefit greatly from the product and business context, so share that context when you have it. Furthermore, it’s especially important in this role to communicate and celebrate the accomplishment of shipping with them when the code they’ve written hits end users and advances the vision and mission of the company.
Engineers need someone to review their code, unblock them when they’re stuck, and act as a sounding board for tough technical problems. Software engineering is incredibly complex, and it’s easy to get mired in your own thoughts when trying to solve something. When unblocking, reviewing, or pairing, great tech leads and managers listen and observe for as long as their teammates need, then respond. It’s always best to let your teammates get it all out there. Sometimes, you end up just needing to be a duck, and the mere act of being a sounding board for them will help them solve the problem. Other times, letting them speak at length will reveal some nuance that they may be missing or have misunderstood. And if they were entirely off base the entire time, listening will still convey the fact that you care about them and respect their views, and this will build trust.
The Engineer who makes 100 peers 10% better
In growing technology companies, pretty much everything imaginable becomes more complex at a rate that is hard to control. Your codebase is becoming more complex (or dividing into multiple codebases, as the case often is with companies that adopt or move further into microservices), your organization has more people and more relationships, your deploys take longer and have more targets, your documentation is harder to keep up to date, and your customers’ needs are more diverse. A great engineer on a growing technology team has an opportunity to be a 10x Engineer by contributing improvements to the organization that save 100 peers enough time to make them each 10% more productive.
A lot of engineering teams will see their build and deploy times balloon over time. Those times balloon for good reason—more things need to be tested, verified, and orchestrated as the product and technology footprint increases. But ultimately, ballooning build and deploy times can cause an organization to slow down. Beyond a certain point, that decrease in speed can deter engineers from shipping. An engineer who spends time improving the build and deploy pipeline for their organization can leverage that benefit across the whole team, and recoup time and energy for the team equal to 1000% of that developer’s own capacity.
A great engineer on a growing technology team has an opportunity to be a 10x Engineer by contributing improvements to the organization that save 100 peers enough time to make them each 10% more productive.
Every great engineer I know wants to improve the developer experience for their peers. It’s important to pair that desire with the perception of how many people will benefit from that improvement, and by how much. Just because something makes your own development experience better doesn’t mean that everyone will benefit from it. Poll your peers, ask around, and keep an open mind to unexpected improvements that can help your team excel.
The Engineer who makes 1,000 colleagues 1% better
In much larger companies, it’s nearly impossible to know everyone who is working on the technology team. It’s tough to wrap your head around the entire product and codebase, and it’s easy to retreat into the comfort of your silo and work on just the narrow part of the behemoth that you were hired to maintain.
It’s easy to think that in an organization like this, the only way to be a 10x Engineer is to rise to a senior or strategic role (CTO, senior architect, principal engineer, etc.) and exert your influence there. And while it’s true that those folks have many of the same aforementioned opportunities to create 10x productivity with their conferred authority, there are still opportuntities for rank-and-file engineers at these companies to leverage their contributions across the whole company to create a 10x influence.
Large companies have an impressive ability to tolerate inefficiency and technical debt, and they even develop perverse incentives to obfuscate the inner workings of individual components and systems. After all, BigCo can’t fire you if you’re the only one who knows how to fix that undocumented legacy system. But great engineers do not tolerate that kind of mediocrity, even if it’s easy for a large organization to abide. Working against the ingrained inefficiencies and perverse incentives of behemoth engineering teams, a True 10x Engineer can improve the productivity of coworkers they’ll never meet.
When working in large technology organizations, less and less knowledge of the code should be presumed on everyone’s part. Because of that, engineers can be impactful by making code clearer, better documented, and better organized. The means to accomplishing this vary from large organization to large organization, but it generally involves leaving code better than you found it, even if you ultimately aren’t changing it much, if at all. This kind of tenacity and dedication will save others time and effort when they come across this code next. In many cases, that next person to come along is you, and you’ll be grateful to yourself for making the code easier for posterity to understand.
Working against the ingrained inefficiencies and perverse incentives of behemoth engineering teams, a True 10x Engineer can improve the productivity of coworkers they’ll never meet.
Large organizations also develop weak spots in accountability with respect to unowned parts of the codebase, long-running organizational dysfunction, or seemingly insurmountable tech debt initiatives. It’s easy for anyone to look at the manifestation of any of these things in the codebase and say “not my problem.” But a True 10x Engineer can look at these problems and see an opportunity to have an enormous impact on the team by owning them and fixing them.
The Engineer who makes 10,000 strangers 0.1% better
By now, you realize that large organizations create economies of scale for the influence you can leverage through colleagues at your company. However, there are only a handful of companies out there that approach 10,000 engineers, and those companies can be famously tough to get into. So what’s a lowly (read: normal) developer to do?
Free, open source packages and libraries are increasingly powering the products and platforms of technology companies big and small. One glance through the reams of popular projects on NPM, GitHub, PyPI, or any language’s package repository will reveal exactly how popular community-maintained free software is. Many of these packages and libraries are open to contributions from the public and have inclusive, welcoming communities.
Any big or small contribution to these libraries can fix issues, improve usability, and enhance performance across thousands of deployments. The effect of a little bit of work on open source software can quickly compound to create an outsized impact, and this level of impact is available to all developers, new or experienced. Plus, open source contribution looks fantastic on a résumé.
The engineer who actually produces 10x their peers
Now, there are rare occasions where you may see an engineer who produces at a level far above their peers. Maybe you looked in Jira and realized that this person is shipping an order of magnitude more tickets. Or you checked their commits in GitHub and saw that they’ve committed ten times the number of lines of code. They are not obviously or outwardly a toxic presence on the team, and in fact, people might actually like them. Maybe this is the superhuman 10x Engineer everyone’s been raving about, and I’m just spewing hippie bullshit about developer altruism.
Alas! The individual contributor who produces a magnitude more work than their peers is not a bountiful aberration to be coddled and cherished. They simply represent the high water mark for productivity on your team. It is incumbent upon you to examine their situation to understand how they have avoided or hacked around the obstacles that hinder other members of the team. If this person really produces 10x more than their peers, what you really have is a productivity floor in your organization of 0.1x.
The individual contributor who produces a magnitude more work than their peers is not a bountiful aberration to be coddled and cherished. They simply represent the high water mark for productivity on your team.
The reasons for weakened productivity on your team span a plethora of possibilities, to the point where it would be impractical to enumerate them all in this article. But you can start by looking for some big-picture markers. Are people missing context? Are they not trained properly on the technology, tools, or existing codebase? Are requirements not clear to them? Are they burned out, professionally stagnating, or struggling personally? Do they not believe in what they’re building?
If you see an individual contributor who appears to be a 10x Engineer on your team, don’t deify them. Instead, treat their performance as a goal for everyone on the team, and work with individual underperformers on the team to build an actionable map to get there. And hey, if you can get 10 engineers from that 0.1x floor to that high water mark, you’ve multiplied 10 developers by 10x. You’re a 100x Engineer.
Conclusion
Outdated and harmful misconceptions about engineering excellence have given rise to the stereotype of a 10x Engineer who is standoffish, siloed, silent, and selfish. To the unenlightened, this engineer seems like an asset to your engineering team, but they’re really a ticking time bomb. Ultimately, the gains in productivity you get from this type of engineer will be wiped out by their organizational toxicity.
Software teams that are really looking to succeed should look for engineers that leverage their impact through other people. An organization full of these True 10x Engineers will create and sustain technological efficiency, support each other professionally, and help to drive up the productivity of everyone on the team through an empathic approach to collaborative software development.
When interviewing developers, ask how they have helped their peers and colleagues through their work. And if you’re the one being interviewed, tell a story about how the work you’ve done has benefitted the team. In your role now, actively inventory and quantify the outward influence that you create through your work, not just the features and lines of code you’ve shipped yourself.
Every engineer has the opportunity to be a 10x Engineer by leveraging their impact through others. This opportunity takes many forms as it affects greater magnitudes of people, and is available to any engineer regardless of position or experience. Engineering teams should foster cultures that reject toxic overperformers and reward engineers who demonstrate true value by supporting their colleagues. An engineering organization that values, attracts, and retains those True 10x Engineers will succeed at a greater rate than any team that relies on toxic overperformers.
