10x Developers

A Team Approach

By Santi on July 30, 2019


Managers and recruiters are desperate to find them, developers want to be like them, the world rests on their shoulders, as they are the magnificent individuals who can create wonderful products in the blink of an eye. Even if this sounds like a description of a mythical creature, 10x developers are real. As it happens with other knowledge workers, the differences in productivity for programmers are huge, but the industry approach to taking advantage of this talent is fundamentally flawed.

First, a definition: a 10x developer is a professional who is 10 times as productive as an average developer. As productivity is calculated as output over input, this means they produce more in the same time, or they achieve the same output faster, or a bit a of both. In isolated linear systems, like an automated assembly line, it is simple enough to know if 10 times the outcome is attained: has the throughput been multiplied by 10? In more complex systems, the calculation becomes harder: in software there is no physical product to weight and count, and alternatives, such as lines of code per programmer or features per week, are poor estimators of the amount of work that has been produced.

The biggest problem with 10x recruiting, however, is not the near impossibility of identifying these developers quantitatively, but the idea that labor productivity for developers is a characteristic of the individual and not of the team.

Systems Over People

WhatsApp, the messaging app with most users in the world, only needed 50 engineers to handle 900 million users. In average, they were all 10x engineers. Or it could be the case that there where many 100x engineers, which are as good as 10 10x. It should be obvious by now, this way of looking at talent in organizations is misguided: recruiting might focus on individuals, but productivity depends on teams. These are some of the factors that affect team productivity:

1. Culture

  • Openness to innovation
  • Tolerance and respect
  • Customer and business focus
  • Flexibility: tools, working conditions
  • Response to mistakes: active and systemic (avoiding witch-hunting)
  • Personal Accountability
  • Proper environment: space, noise levels

2. Management

  • Accurate requirements (the most common cause of software failure)
  • Management style
  • Team organization: adjusted to project and people
  • Task assignment: reducing idle time and avoiding silos
  • Motivation
  • Internal friction
  • Review processes: code reviews, test coverage
  • Best practice and code conventions definition
  • Technical architecture design
  • Communication channels and processes
  • Business domain knowledge sharing

3. Individual Talent

  • Computer science fundamentals and technology stack specifics
  • Abstract thinking
  • Communication
  • Self-directed learning
  • Interest in improving efficiency
  • Tolerance to frustration

Competent Programming: a Better Approach to Recruiting

Competent programmers are a requirement for productive software teams. After great efforts in recruiting, companies keep hiring people who literally cannot code, but the solution is not to increase the difficulty or length of technical interviews, but rather to provide programming aptitude tests, ask for code samples, and assess the cultural fit to the organization. One big problem with the 10 X approach is that X is skewed downward by the programmers who cannot code, as David Parnas said:

one bad programmer can easily create two new jobs a year.

While software recruiting is interested in finding great programmers and hiring them, it should instead be focused on identifying weak programmers and avoiding them. Imran Ghory created a popular test on basic coding competency called FizzBuzz, which is meant to address this issue:

After a fair bit of trial and error I've discovered that people who struggle to code don't just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems. […]
This sort of question won’t identify great programmers, but it will identify the weak ones. And that’s definitely a step in the right direction.

On the best seller “Outliers”, Malcolm Gladwell argues:

The relationship between [career] success and IQ works only up to a point. Once someone has reached an IQ of somewhere around 120, having additional IQ points doesn’t seem to translate into any measurable real-world advantage.

This is known as the threshold effect. This phenomenon also applies to the height of NBA players: it matters a lot that a player is tall enough, but then the marginal utility (the usefulness of every extra inch) decreases abruptly. This is not to say it does not matter, but once the threshold is reached, other factors are much more important.

There is still no good measurement for coding skill, but the threshold effect applies to its utility inside an organization. Unless very specific abilities and expert knowledge are required (for example: in advanced research and development), having the best and brightest programmers is not worth the effort that it takes to attract, interview, hire, and retain them. Better to build a 10x team of competent programmers by creating the right environment.


WhatsApp | Wired
Why Can’t Programmers Program | Coding Horror

‹ Previous: Selling Internal IT Next: Technical Debt For Managers ›