A version of this post originally appeared in Refactoring, a Substack offering advice for software engineers.
Most of us have encountered a few software engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.
I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The idea—which has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.
I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. The problems I do have are twofold.
Measuring productivity is fraught and imperfect
First, how are you measuring productivity? I have a problem with the implication that there is One True Metric of productivity that you can standardize and sort people by. Consider the magnitude of skills and experiences at play:
- Are you working on microprocessors, IoT, database internals, Web services, user experience, mobile apps—what?
- Are you using Golang, Python, Cobol, or Lisp? Which version, libraries, and frameworks? What other software must you have mastered?
- What adjacent skills, market segments, and product subject matter expertise are you drawing upon? Design, security, compliance, data visualization, marketing, finance?
- What stage of development? What scale of usage? Are you writing for a Mars rover, or shrink-wrapped software you can never change?
Also, people and their skills and abilities are not static. At one point, I was a pretty good database reliability engineer. Maybe I was even a 10x database engineer then, but certainly not now. I haven’t debugged a query plan in years.
“10x engineer” makes it sound like productivity is an immutable characteristic of a person. But someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are average (or below average). I know a lot of world-class engineers, but I’ve never met anyone who is 10 times better than everyone else across the board, in every situation.
Engineers don’t own software, teams own software
Second, and even more importantly: So what? Individual engineers don’t own software; engineering teams own software. It doesn’t matter how fast an individual engineer can write software. What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
Everyone uses the same software delivery pipeline. If it takes the slowest engineer at your company five hours to ship a single line of code, it’s going to take the fastest engineer at your company five hours to ship a single line of code. The time spent writing code is typically dwarfed by the time spent on every other part of the software development lifecycle.
If you have services or software components that are owned by a single engineer, that person is a single point of failure.
I’m not saying this should never happen. It’s quite normal at startups to have individuals owning software, because the biggest existential risk that you face is not moving fast enough and going out of business. But as you start to grow as a company, ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, and leave the company, and the business has to be resilient to that.
When a team owns the software, then the key job of any engineering leader is to craft a high-performing engineering team. If you must 10x something, build 10x engineering teams.
The best engineering organizations are the ones where normal engineers can do great work
When people talk about world-class engineering organizations, they often have in mind teams that are top-heavy with staff and principal engineers, or that recruit heavily from the ranks of former Big Tech employees and top universities. But I would argue that a truly great engineering org is one where you don’t have to be one of the “best” or most pedigreed engineers to have a lot of impact on the business. I think it’s actually the other way around. A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week.
Anyone can build an org where the most experienced, brilliant engineers in the world can create products and make progress. That’s not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook from doing their jobs. It is a huge competitive advantage if you can build systems where less experienced engineers can convert their effort and energy into product and business momentum. And the only meaningful measure of productivity is whether or not you are moving the business materially forward.
A truly great engineering org also happens to be one that mints world-class software engineers. But I’m getting ahead of myself here.
Let’s talk about “normal” engineers
A lot of technical people got really attached to our identities as smart kids. The software industry tends to reflect and reinforce this preoccupation at every turn, as seen in Netflix’s claim that “we look for the top 10 percent of global talent” or Coinbase’s desire to “hire the top 0.1 percent.” I would like to challenge us to set that baggage to the side and think about ourselves asnormal people.
It can be humbling to think of yourself as a normal person. But most of us are, and there is nothing wrong with that. Even those of us who are certified geniuses on certain criteria are likely quite normal in other ways—kinesthetic, emotional, spatial, musical, linguistic, and so on.
Software engineering both selects for and develops certain types of intelligence, particularly around abstract reasoning, but nobody is born a great software engineer. Great engineers are made, not born.
Build sociotechnical systems with “normal people” in mind
When it comes to hiring talent and building teams, yes, absolutely, we should focus on identifying the ways people are exceptional. But when it comes to building sociotechnical systems for software delivery, we should focus on all the ways people are normal.
Normal people have cognitive biases—confirmation bias, recency bias, hindsight bias. We work hard, we care, and we do our best; but we also forget things, get impatient, and zone out. Our eyes are inexorably drawn to the color red (unless we are colorblind). We develop habits and resist changing them. When we see the same text block repeatedly, we stop reading it.
We are embodied beings who can get overwhelmed and fatigued. If an alert wakes us up at 3 a.m., we are much more likely to make mistakes while responding to that alert than if we tried to do the same thing at 3 p.m. Our emotional state can affect the quality of our work.
When your systems are designed to be used by normal engineers, all that excess brilliance they have can get poured into the product itself, instead of wasting it on navigating the system.
Great engineering orgs mint world-class engineers
A great engineering organization is one where you don’t have to be one of the best engineers in the world to have a lot of impact. But—rather ironically—great engineering orgs mint world-class engineers like nobody’s business.
The best engineering orgs are not the ones with the smartest, most experienced people in the world. They’re the ones where normal software engineers can consistently make progress, deliver value to users, and move the business forward. Places where engineers can have a large impact are a magnet for top performers. Nothing makes engineers happier than building things, solving problems, and making progress.
If you’re lucky enough to have world-class engineers in your organization, good for you! Your role as a leader is to leverage their brilliance for the good of your customers and your other engineers, without coming to depend on their brilliance. After all, these people don’t belong to you. They may walk out the door at any moment, and that has to be okay.
These people can be phenomenal assets, assuming they can be team players and keep their egos in check. That’s probably why so many tech companies seem to obsess over identifying and hiring them, especially in Silicon Valley.
But companies attach too much importance to finding these people after they’ve already been minted, which ends up reinforcing and replicating all the prejudices and inequities of the world at large. Talent may be evenly distributed across populations, but opportunity is not.
Don’t hire the “best” people. Hire the right people
We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.
I believe a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, and more) would be improved simply by shifting the focus of hiring away from this inordinate emphasis on hiring the best people and realigning around the more reasonable and accurate right people.
It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what meritocracy depends on.
This is the kind of place that engineering talent is drawn to like a moth to a flame. It feels good to move the business forward, sharpen your skills, and improve your craft. It’s the kind of place that people go when they want to become world-class engineers. And it tends to be the kind of place where world-class engineers want to stick around and train the next generation.
From Your Site Articles
Related Articles Around the Web