The notion of the “10x engineer” has become a fixture of Silicon Valley lore. It stems from the common observation that there can be tremendous variation in how long it takes different people to complete a task, and that some people seem to get things done quickly on a consistent basis.
Is there really a special gift or talent that a few people have that others don’t? Can 10x engineering be taught? Is there something special about software that makes 10x achievement possible in this field, say as opposed to in other fields such as aeronautical engineering.
Skills and performance
10x performance isn’t a myth, and it’s not that difficult to understand. However, doing so requires a shift in mindset from focus on individual to focus on the task. See Figure 1 below.
Figure 1. For tasks well below someone’s skill level the time to complete the task (normalized to scope) is independent of skill required. As the required skill approaches the individual skill level, time to complete takes asymptotically longer.
The key takeaways is that when the difficulty of a task bumps up against our level of skill, things take longer and longer. If someone takes on a task that’s beyond their level of skill, they probably won’t be able to do it at all.
I’ve oversimplified Figure 1 in various ways. Skills can’t actually be measured along one dimension, and individual limits vary by type of skill. Most glaringly, I ignore learning. Figure 2 addresses this last shortcoming.
Figure 2. People can learn to do tasks requiring skills beyond their initial level, but learning takes time, and proficiency is low initially.
Once you bump up against your skill limit, you’re almost certainly going to accomplish more if you sit down and learn, than if you try to muddle through.
I’ve had the painful experience of tackling a task beyond my level of skill countless times. For example, when I first tried to do data science in Python, I figured, “I know how to program, I’ll just dive into my project and look things up in the reference documentation as I go.” Three days later I gave up in frustration and went back to a familiar technology. On my second attempt I first worked through tutorials, making sure I really understood how to think about basic data structures and how to manipulate them. With the benefit of this foundation, I started to make quick work of various tasks.
When skill helps and when it doesn’t
One corollary of the skills-based model of performance is that having more skills doesn’t make you any better at mundane tasks. For example, a senior engineer with PhD in machine learning is probably going to need about the same amount of time to complete a data cleaning tasks as an entry-level analyst. Having more skills doesn’t help when the task doesn’t require them.
Google’s Jeff Dean is the most famous engineer I can think of. Who else has reached internet meme status? To many, he is viewed as a 100x engineer. Jeff’s is best known for his public work, which includes the MapReduce paradigm that launched the Big Data movement, and the Tensorflow technology that helped make AI mainstream. What’s readily apparent about someone like Jeff is that he has that he has been able to solve problems that the vast majority of engineers, even Google engineers, could never solve. His skills give him a tremendous advantage for at figuring out how software should be written in a new application domain like AI, yet they would give him only a modest advantage at designing an ordinary enterprise business application.
Implications and advice
In my view, too many engineers today are operating up along the asymptote of Figure 1. Most of them are unaware of this, as are their managers. My advice to improve this situation follows.
Tips of for engineers:
- Assess honestly how your skills compare to those needed for the task.
- Commit to learning any missing skills up-front. You don’t have to learn everything up-front, but identify what you will learn, make the commitment to doing so, and set aside the necessary time.
- It’s good to push yourself to learn, but also push back on assignments when the skill gap is too great.
Tips for managers:
- Learn to recognize when someone is struggling because a task is above their level of skill. There’s no use in driving someone to deliver when they should either be reassigned or asked to take a step back and spend time learning.
- Seek to hire quick learners. Fast learning is a wildcard skill that helps every time a task requires missing skills. How do you spot a quick learner? It’s easy, they’ve learned lots of stuff.
- Pay people to learn relevant skills. Doing so will pay off.
You can find various other advice on how to become a 10x engineer or how to hire one. A common theme is the emphasis on focus, prioritization, and time management. These are all contributing factors, and could be good for 2-3x. In my view, however, skills the longest lever and often overlooked.
Looking ahead
I look forward to the day when 10x engineers are mostly a thing of the past. We won’t talk about elusive 10x engineers anymore because most engineers will be tackling tasks that are well within their ability. We will take for granted that the average engineer is 10x as productive they were back in 2020.
How will this happen? The tips listed above can help by making everyone more aware of skill gaps, and by encouraging investment in filling them. Better engineers and better managers are important, yet so is better technology.
Imagine if we tried to write all of the software being written in 2020 using the tools available in 1990, a time when popular and high-productivity programming languages such as Python and Java had yet to be invented, and when many applications stored data in files rather than modern databases. Productivity likely would be less than 10% of what it is today.
One example of a technology that promises to vastly simplify certain engineering problems is serverless computing, which hides the complex operating model of today’s cloud behind simplified programming abstractions. Even experts appreciate the benefits of simplified programming because it frees up time and energy to focus on the most important aspects of a problem, usually delivering unique business value, rather than on undifferentiated technical details. Simplified programming is also an equalizer and a lubricant, allowing more people to build software without first learning highly specialized skills, as well as to jump readily from one domain to another.
There will still be star engineers in the future, however I expect that most companies won’t need them. The combination of better understanding of skill gaps, up-skilling to fill those gaps, and simplified programming models will mean that most programmers will be able to handle most tasks without reaching beyond the limits of their skills.