Mythical 10x Developer

They have been called by different names, rockstar, coding ninjas, distinguished engineers, all of these accolades refer to the developer who is, supposedly, 10x more efficient than an average developer. The average developer here is supposed to be the person who gets ‘meet expectations’ in their review every time. That’s the definition of average. Job descriptions love to include that they are looking for a superstar, teams don’t miss a chance to boast they are a small group of highly motivated developers. A point to note that 10x developers are not working 16-18 hours a day, they achieve the 10x efficiency just by working the regular office hour, same as the ‘average’ developer. Given that this concept is so common, why do people question it and call it a myth ? That is what I’m trying to explore.

Before I begin, let me share my opinion: I do believe that the concept 10x developer is a myth and a term coined to goad naive developers into working more.

To declare someone 10x there has to be an established baseline. The definition I heard is that it is the industry expectation from a developer working a certain role on a certain kind of project. Fair enough, so, a mid-level developer working on a web application development project is supposed to deliver a certain amount of goals based on the industry standard. A bit non-tangible but there are enough signals in the field to get an approximation. With that baseline the performance of a 10x developer will be hard to ignore ! There are companies with less than five developers that consistently release quality features every quarter. With a 10x developer in the team the pace will be insane. There will be a new production feature released every week.

I’m not gonna claim that I know the development process and achievement of every team on earth, based on just a few anecdotes. But there must be some smoke coming out of somewhere where these developers are lighting things on fire with their performance.

10x Managers ?

If 10x developers do exist then they are limited by the lack of 10x managers in industry. Think about it if there is nothing on the sprint how can the 10x developer work. They just work for a few minutes every day and then stay idle. What a waste ! If there are 10x developers in a team we should always ask who is the 10x manager of the team keeping that developer productive. And just for fun, what would a 10x manager look like; managing a team of 100 people with 20 one on ones every day, creating well written PRD and RFEs for the team with solid research, or would it be a person spewing ideas and visions all day long and asking just code it, cause believe me everyone is already a 100x idea guy.

The KPIs of a development team

On a serious note, the developer efficiency does matter when it comes to forecasting deadlines for features and promising a certain mean time to recovery in case of a production bug.

Forecasting

Estimating the time it will take to build and release a new feature is essential for every product. It affects the go to market strategy, sales calls and eventually the revenue forecasting. When everyone is on board and shares correct expectations there are never any late night or over the weekend developmental tasks. The estimation of development efficiency matters here and it becomes very subjective given the complexity and uniqueness of every production requirement and deployment strategy.

MTTR

Recovering from a production failure is even more important than releasing new features. What’s the point of having so many features if they don’t work half the time? This highly depends on the process and the experience of the team to assess the severity and figure out a solution.

Both of these require consistency across the team, not a single person who can just power through and finish all the tasks. Efficiency of a team working together on a project increases over time as they get used to working together and gain a better understanding of the code base they are working on. They produce more accurate estimates for new features and recover production faster in case of a failure. An outlier is not a team. An outlier, even on the right most side of the bell curve, may end up hurting the overall efficiency of the team. A team that grows together and brings in more similar people is likely to achieve higher performance than before.

There are no 10x developers but there sure are 10x development teams.