This idea of a "10x developer" has become a perceived truism in Silicon Valley. Famous talking heads of tech have popularized it, and now it feels like almost every startup should look to add one to their team. It has also become a central acquisition target for many of the tech giants.
For example, Facebook was willing to pay $47 million for FriendFeed, because, as Zuckerberg said in an interview, "We really wanted to get Bret [Taylor]," (one of FriendFeed’s founders). Now, Bret Taylor was more than just a developer, he served as Facebook’s CTO for 3 years, but that’s still $47 million to hire one person. And Zuckerberg is of course famous for saying the best aren’t just a little better but "100 times better" than everyone else.
Marc Andreessen, founder of Netscape, agrees with the idea of the 10x developer, having claimed that "five great programmers can completely outperform 1,000 mediocre programmers."
We got a chance to talk to another successful tech entrepreneur, Rand Fishkin, founder of the SEO software company Moz, which earned over $40 million in revenue in 2016, and he told us that he doesn’t buy into the 10x developer concept.
He shared stories of how Moz built multiple products (including their critical initial products) without ever looking for a 10X developer, and importantly, he gave four main reasons why, for the majority of companies, searching for the 10x developer is a bad idea -- and what he suggests you do, instead.
Looking for your own developer? Chat with a member of our team to help you find a high-quality developer for your project and budget (learn more).
Why the 10x engineer likely isn’t right for your company
1. You can’t afford the increased burn rate
The obvious reason that most companies shouldn’t be in search of a "10x developer" is that 99.99% of startups (or even bootstrapped small businesses) simply don’t have the same capital as Facebook to spend on catching one of these unicorn developers. As Rand jokingly told us, you just aren’t in a place to afford to hire someone who says, "I am a god, give me 50% of your company." If you know they are an elite developer, chances are they know that too, and they will expect a fitting salary.
Cash is always one of the most scarce resources for a startup so preserving it is critical. You might think "if they cost 2X more, but are 10X or 1000X more productive, then it makes sense," but that productivity may not be necessary or even attainable in your company, which brings us to the second reason.
2. You don’t need uber tech productivity at this stage
But beyond the issue of limited funds, Fishkin rightly points out that it simply doesn’t make sense for where most entrepreneurs are in the process of building their business: "if you’re seeking to build your first software tool, [the 1000x developer] is not who you’re recruiting and you shouldn’t try."
The majority of startups’ issues don’t begin and end with the code. The product may not fit the market, you may not be providing the tools that customers are asking for, you may have awful customer support -- there are numerous areas in which your company could be lacking that have nothing to do with the technology. Fishkin points out that "the quality of software isn’t what’s holding you back, so why expend every possible resource on just the speed, quality, or design of your software systems?"
Rand describes how, for years, it was just himself, his mom, and a developer tinkering and pivoting their business, from consulting to software, trying to find that product market fit. He argues that at that stage, it doesn’t make sense to hire the unicorn developer. Your focus should just be on making small iterations to the product to achieve product market fit.
This isn’t a unique story -- this is the story of most startups and small businesses. And if you follow the general progression of these companies, you will see that none of them go straight from this stage to tech giant overnight.
3. They can often create a big culture problem
Hiring a 10x engineer also runs the risk of fundamentally changing your company. Moz experienced this first hand when they prioritized hiring engineers over other roles by providing huge signing bonuses and referral rewards just to new engineering hires.
"That was really bad… totally wrong," says Fishkin.
Whilst spearheading Moz Analytics, Fishkin says there was an aggressive shift towards hiring as many developers as possible, almost at any cost, in order to get this project done in line with a rebrand they had been planning. This shift only hurt Moz’s culture by elevating the technical hires’ status over others -- in fact, it hurt their product as well.
In their mad dash to develop, they forgot about the tools that their customers really wanted. Fishkin referred us to his own personal blog post about this experience, which also describes how this overall cultural shift played a part in his own mental wellness. Today, he would suggest hiring a less-skilled engineer with humility over their 10x counterparts any day, because, simply, it’s a "pleasure working alongside them."
Moz team (back when the company was called SEOmoz) celebrating Movember.
4. "10x" may describe the person-role fit, not the person
Finally, Fishkin emphasizes that developers’ performance is subject to their working context:
I don’t think there are 10x and 100x people, I think there are great fits and poor fits... It’s insane to me that no one takes this stance because it’s true in every other possible setting of life.
The issue with the 10x developer idea is that it assumes that someone will perform at the same level, regardless of their working environment.
It assumes that "10x" describes the person.
And maybe this would be true if you also hold the assumption that developers work within a completely intimate and insular relationship with their computer code. But that doesn’t happen in the real world.
In reality, developers are integrated into teams, are part of the company culture, and just generally interact with other aspects and people of the company. So why wouldn’t their drive, motivation, and productivity be just as affected by these factors as a non-technical employee?
Fishkin has a prime example of how this dynamic played out within Moz. A couple of years back, engineers working on a number of teams were identified by their managers as underperforming, and told Fishkin as much. His response was unconventional: he rounded them up and placed them on a new team for a tool he wanted to develop. In 9 months, this "ragtag bunch" produced what Fishkin considers to be one of the best products on Moz’s arsenal -- their Keyword Explorer. Those who were once considered underperformers had now become elite developers, and all it took was a change of context.
Moz’s Keyword Explorer tool: Built by a team of developers initially thought to be a poor fit in other projects
What to do, instead
So, Fishkin doesn’t believe in the 10x engineer. They are impractical acquisition targets for the majority of businesses, they may negatively affect company culture -- and even if you ignore these things and land one, you cannot guarantee that they will be hyper productive in your specific work environment. How, then, does Moz identify and cultivate great developers? Fishkin shared his tried and true methods with us (beyond the "developer-flipping" method illustrated with Keyword Explorer).
Stop asking for large projects – start small
First, during the hiring process, Fishkin advises testing engineers with small tasks. And the same is true for after they are hired: "Many people define a project as this big monolithic thing," while he suggests that they should rather assign and assess the "very small micro definitions of the work...with easily proven demos...at regular intervals."
Think about it: if someone is completely new to a team, even if they are an all-star in their field, there will always be a learning curve. It’s extremely unrealistic to think that any employee will be able to perform a huge task to your personal standards straight away.
All employees need a period to adjust to a new culture, familiarize themselves with the product, and understand expectations -- it’s unfair to treat a developer differently. By dividing work up into smaller pieces at the beginning and providing feedback, you are better able to support a developer through this learning curve and make corrections early to unlock their real potential.
And this weaves into his second piece of advice, which is to involve your developers in the decision making process.
Involve your developers in product decisions
Fishkin points out that too often product managers will direct their technical teams with the tone of "'Hey, here’s the thing I want you to build. Go build it.' [Rand doesn’t] think anyone wants that." You can’t expect the best work from a developer working on a project they don’t agree with -- but you can expect the best work from a developer working on a project that they feel passionate about, and if you involve them in decisions and let them apply their creativity and input, they will naturally feel more passionate about the project.
It means turning the process into more of a conversation, in which the developer can also give their input on the best way forward.
For example, Fishkin attributes the majority of the Keyword Explorer team’s success to the fact that they were involved with making decisions "from the top down." It sounds simple, and yet so many managers get it wrong: employees that feel empowered and motivated about their work will perform at their best potential.
Speaking to Rand, it was clear that this mentality has fostered a culture at Moz that encourages employees to reach their own potential and find a space in which they can shine. All without having to fit some Silicon Valley "truism" of finding a unicorn developer (and potentially risking a massive hit to your burn rate in the process). Obviously, there is a small strata of companies for which this is appropriate -- namely, for the Facebook's and Google’s of the world -- where cash is less of an issue and scaling is the primary challenge for a wide variety of products. However, for the vast majority of startups and smaller businesses, we’d be confident placing our bets on Rand Fishkin’s methods for creating a truly great product, team, and overall company culture.
Looking for your own developer? Chat with our team on finding a good fit for your project and budget (learn more and find a developer here).
