III. We Will Not Recruit 10x Developers

It’s become conventional wisdom that you should only hire “10x developers.” If you try to do this, you’re setting yourself up for failure. If you have an investor or other executive pushing you to hire 10x developers, politely thank them for their input and then ignore everything else they say about recruiting and managing software engineers.

Are 10x developers a myth? Short answer: yes. The longer answer is more complicated, but it doesn’t change much.

The concept originates in a study from the 1960s that indicated there are developers who can perform coding tasks 10 times faster than peers with comparable experience and salary. If you take this at face value (and you shouldn’t), it’s understandable that you’d prefer to get 10x the benefit at no additional cost. But there are several reasons why you shouldn’t get your hopes up.

To get a sense of what programming was like at the time, here’s a quote from the study: “TSS utilizes an IBM AN/FSQ-32 computer. User programs are stored on magnetic tape or in disk file memory. When a user wishes to operate his program, he goes to one of several teletype consoles; these consoles are direct input/output devices to the Q-32. He instructs the computer, through the teletype, to load and activate his program. The system then loads the program either from the disk file or from magnetic tape into active storage (drum memory).”

And for a sense of scale: This Q-32 computer weighed up to 90 tons and occupied nearly an entire floor of a large office building. All this for a jawdropping-at-the-time 1.5 megabytes of memory. I’ll leave you to decide how smart it is to make hiring assumptions based on a five-decade-old study of 12 programmers working with a computer like this.

When people think of a 10x developer they think of 10x the average developer. The fastest developers in this study are an order of magnitude faster than the worst developers, not the average developer. In fact, average scores in the study were much closer to the best scores than the worst. This means that slow developers have outsized influence on this metric. I’m surprised we don’t hear just as many people dispensing sage advice to avoid 0.1x developers.

Second, this whole concept rests on the premise that these more productive developers are no more costly to hire than average developers. If we think about this for more than a minute, it can’t be true if the performance difference is obvious to the business.

Let’s pretend that there are engineers out there who can complete any given task 10 times faster than their teammates. How long could that continue? Any manager in their right mind would not let this miracle engineer sit idle for 90% of the week. However, if they didn’t, this 10x dev would be doing 10x the work of everyone else. This would be very noticeable.

Any manager who sees this productivity would worry about losing this superstar. How long would that dev be making the same salary? Considering how productive they are, the most rational thing to do would be to fire the weakest engineer and give their salary as a raise to the 10x dev. Paying double would be a bargain for such an effective pair of golden handcuffs. Sadly, this wrecks the foundation of the concept. If 10x developers don’t make more than their peers, it’s because the business doesn’t notice. And if the business doesn’t notice, are they really 10x developers?

At this point we could probably stop, but I’d like to share the simple reason why that study’s large differences in programmer ability doesn’t translate to working teams. Studies evaluate multiple programmers on the same task and then draw conclusions. If, instead of attributing the increased performance to the developer, we attribute it to the combination of developer and task, things make more sense.

A developer who has worked on UI rendering problems before will solve a similar UI rendering problem way faster than a developer who hasn’t. This doesn’t mean that the same speedy developer will knock a database query optimization problem out of the park. In other words, the 10x developer mantle is situational, and it will only show up when the stars of talent and task align. Therefore, it’s no surprise that over the course of a year, you don’t have devs that are doing 10x the work of everyone else. They will crush some projects, but not all of them.

Am I telling you this because I think that one dev can’t do the work of 10 in the same amount of time? Of course not. I know that it’s possible. In fact, I’m a 20x dev.

As a test, I recently showed a project manager a video editing app that I built, and I asked him to estimate how long it would take a team of his devs to re-create it. He came back with an estimate of 200 hours (5 devs * 40 hours each). I built that app in less than 10 hours. Therefore, in this case I’m a 20x developer.

So why not just hire a bunch of developers like me? I’m not going to be nearly that fast on 99% of the work teams need to accomplish. If I cherry-pick projects that particularly suit my skills, I’m going to be way faster than most teams. However, even that app wasn’t a fully-fledged money-making product. If I were to race a team to build out user accounts and payment and terms of service and logging and backups and admin tools and everything else that real products need, I would lose. Badly.

In fact, most of my speed came from knowing what I wanted to build and how ahead of time. If I had written down how I wanted to build the app and given that to the team, they too would have been able to build the app quickly. We’d get a much better result if I spent an hour documenting how the project should be built and letting the team do the actual coding.

In other words, my true value here was not being a developer. It was being a commando.

One of my favorite models for software development is Commandos, Infantry, and Police. When people think of 10x developers, they’re thinking of commandos. Commandos love coming up with novel approaches to hard problems. When people fawn over the idea of the 10x developer, they recount stories of clever solutions that normal developers couldn’t duplicate even if they were given 1,000x more people or time, let alone 10x.

This is what commandos do. They can establish a beachhead with astounding speed. Other engineers would never even think to parachute behind enemy lines or swim ashore at night.

If your business is R&D, constantly creating new proofs of concept, or rapid prototyping, commandos are valuable. Outside these types of organizations, you’ll want creativity and novel approaches, and even in more traditional environments, you’ll want to innovate. However, 99.9% of software development does not need commandos.

Having too many commandos is a problem. For each clever idea, there are countless hours of boring work. Most software engineering is executing proven designs. You don’t want all your bridges to be wacky one-of-a-kind designs.

Commandos don’t want to do the routine work. They prefer to only do what only they can do. Using them for routine building creates more problems than it solves. Even the most novel products in Al, AAA games, still need “boring” build tools, admin dashboards, and basic sign-up forms. Commandos won’t do any of those things more quickly. They will just cause drama.

Commandos get bored and chew the furniture. They want to write their own frameworks. They want to try brand-new databases, and they want to rewrite entire parts of your app. If you don’t have big enough problems for them, they will create them for you.

If you want someone like that, you don’t need them to write your production code. Nor do you need many of them. Each commando will create mountains of work—work that should be done by engineers who can get things done.

You want solid team players. You want infantry.

Optimize for predictability, not the extremes. The devs you hire should be able to work with product to understand the desired outcome. Whether it’s a feature or a fix, they can plan out multiple approaches to make it happen, evaluate tradeoffs, document the changes, and do it all again. Sometimes when planning they’ll find something that can benefit from refactoring or optimization, and they’ll either build that time into the estimate or handle it after the feature is shipped. Sometimes they’ll tell product that if the outcome is tweaked, they can ship faster (relaxing constraints).

Depending on what you’re doing, you may even want police instead of infantry. They’re adept at routine maintenance and tasks that follow a checklist. This is the absolute worst fit for a 10x engineer. Applying security patches and going through to update all the places it affects is not creative or exciting. The commando’s tendency to improvise is not helpful.

If you have a single thing that is difficult, teams may not help. Teams are good with problems that are parallelizable. In business, one-off, never-been-done-before problems are rare. Don’t optimize for or have too many people for that purpose.

Enlist a good manager, CTO, architect, or consultant when issues arise. Ask this person to create a novel proof of concept, write up a design doc based on their previous experience, or lead conversations with the devs that force them to think creatively and to be proactive about likely issues.