10X developers. Does your company really need one?

ecs-admin 28th September 2018

10 average detectives versus one Sherlock Holmes – who will solve the crime faster?

The 10x developer is adeptly called so because, in theory, they bear the capabilities of 10 developers.

That’s right. Legend has it that a handful of these ‘Rockstar’ developers live and breathe in the tech space, operating at such speed that they outpace their counterparts on every level. Jessica Kerr is said to be one such developer – although her take on 10x developers is that a person will always appear to be 10x more effective than average if he/she is working on familiar code using familiar tools in a familiar environment.

While some remain sceptic, Marc Andreessen, cofounder of Netscape, agrees that “five great programmers can completely outperform 1,000 mediocre programmers.” He also believes that “the gap between what a highly productive person can do and what an average person can do is getting bigger and bigger.”

Mark Zuckerberg is another believer in the Rockstar employee. When asked why he was willing to pay $47 million to acquire FriendFeed – a price that translated to about $4 million per employee – Zuckerberg replied “someone who is exceptional in their role is not just a little better than someone who is pretty good.” And in Zuckerberg’s eyes, FriendFeed were “100 times better” than their counterparts.

Whilst we don’t doubt the plausibility of a Rockstar developer, we feel there are some faults to the logic.

We are also not convinced that businesses should be spending time and money (millions in some cases) trying to hunt these Rockstars down. Not only does it feed into the allure of the lone wolves, rogue elephants and the socially aloof, we believe businesses will have greater success if they focus on attracting the best talent possible to create a well-assembled team that overwhelms with collective capabilities.

Here’s why:

Complete creative freedom is a rare treat

Programming is not a manual labour, but a creative profession. How fast you write code should therefore not be a measure of productivity. What separates an average developer with an experienced one is the knowledge, recognition of redundant parts, and coding abilities that allow them to write the correct code first time, every time.

Programming is also a choices game.

One great programmer will make “great” decisions at every stage whereas an average programmer, you guessed it, will make “average” quality choices. The costs or benefits of these decisions will multiply through the business, for better or worst. And this is just one reason why businesses would look to investment in the ‘rare but great’.

Combine the ability to architecturally design a program with the sub-design of implementing the strategy and this is where a Rockstar developer can really come into their own. The more ‘goal-oriented’ the task, the greater opportunity a 10x developer has to flex their abilities to creatively create a solution with a lot less effort.

However, when the task becomes more rigid in nature – including dictations about what tools to use and an expected process – this opportunity is weakened. Whilst developers can exploit ‘local’ design possibilities, they do not have the freedom to fundamentally change the course of action or actively tweak the specification of the project to allow the same goal to be reached with a fraction of the effort.

What this tells us is that certain projects have the potential for more skilled developers to shine. But when the majority of your work is dictated by guidelines set by clients, you’re unlikely to get a good return on a ‘Rockstar’ investment.

For every one Rockstar, there are ten developers clearing up the mess

The morecommon way for 10x programmers to exist is by generating enough technical debt to keep ten other developers busy in the trail blaze. One developer ends up looking more productive because work is being produced (at a questionable standard but impressive rate), whilst the rest of the team becomes less productive as a result.

The irony is, management will often direct more resources to this superstar based on their ability to ‘get things done’, including jobs where writing new code is required. And yet, as I’m sure any developer will tell you, writing five lines of code in an existing code base is fundamentally more taxing than producing hundreds of lines of new code.

We spoke earlier about coding speed not being an appropriate measure for productivity. But we’d like to go further and support Dave Nicolette’s view that productivity itself can’t be a measure either, since it does not take into consideration the value or quality of the output. He instead looks to effectivenessas a fairer judge:

“effectiveness implies more than just delivering the customer-defined business value of the work items in our backlog”.

If your Rockstar develops quickly but leaves behind enough technical tech to keep your other developers from producing value-add work, it might be time to put them on the bench.

Don’t let perfect be the enemy of good

Avichal Garg notes that start-ups lean more towards individual Rockstars, while larger companies tend to recruit for individuals who possess specific technical skills. There are a couple of reasons for this difference in approach:

For start-ups:
  • There simply isn’t a need, or the budget to fill a room full of engineers
  • Because managing engineering teams is incredibly hard, it’s easier to think about hiring a few “10x” engineers than it is to think about designing processes that create 10x teams
  • When initiating a start-up, people often wear a variety of hats until resources allow these to live across different teams/roles in the business – as seen in larger organisations
For larger companies:
  • Rockstar engineers may actually be counter to business goals
  • A business’s unit of productivity is a team – you need to maximise the output across a broad set of people

If you’ve ever watched Moneyball (2011 film featuring Brad Pitt), you’d probably agree with how larger companies address their recruitment. There is also a strong consensus within the Agile community that the formation of cross-functional teams is of greater benefit than separate work groups.

There is also concern that team context isn’t considered when identifying individual 10x developers. If an individual appears to function at 10x while a member of a high-performing team, they may not function the same in a different environment, and their performance will certainly suffer if they work with no team support at all – especially when considering the section above.

It is about creating a 10x team, rather than fielding one 10x engineer.

And to create a 10x team, it is no longer enough for an engineer to be good at their job. You need individuals that consistently compliment each other, are good communicators and can comfortably work with others. They need to be able to up-skill their team, up-skill their client’s teams and scale quickly when a business grows – which will be a hard task if you’re waiting for a unicorn to knock on your door.


At this point we would like to reiterate that like star musicians, athletes, scientists, and political leaders, star developers are exceedingly rare. If you create a hiring strategy focused solely on hiring ‘Rockstars’, your business, and Dev team, will end up looking lonely. And whilst a one-man-band may be good for space saving, culture and agile working could be hampered.

Whilst we don’t deny that there are some incredibly talented developers out there, don’t let perfect be the enemy of good. Hire the best engineers you can get and give them ample opportunity to develop into a 10x team that is going to best support your business goals. And remember:

  • A bargain is only a bargain if you can afford it.
  • A genius whose abilities cannot be leveraged in your organisational context is no longer a genius.
  • As engineers we know never to engineer a single points of failure into a service. A developer as a core element of delivering and supporting a service is no different.


Found this interesting? Why not share it: