There was a whole kerfuffle on Twitter this weekend because someone posted about 10X engineers. I didn’t give it much thought. However, over the weekend, the noise just didn’t seem to stop, which got me thinking about the olden days and where this idea of a 10X engineer came from.
I first heard about this idea in Steve McConnell’s 1996 book, Rapid Development. This passage appeared in the chapter about people:
Results of individual experiments on peopleware issues are well known. You might be familiar with the claim that there is at least a 10-to-1 difference in productivity among different developers.
This 10-to-1 idea was widely discussed when I started work in 2000. There was a lot of frustration from non-programmers as to why some developers were so much more productive than others. People would then throw the 10-to-1 argument out, as if to explain the variance as something we all had to live with.
Obviously, effective colleagues could make teams more effective. The important thing to note, however, was that the most important metric was the team’s productivity. And this was best increased with soft skills, such as better communications and decision making. McConnell had said as much in the same passage:
Studies have also found variations in the performance of entire teams on the order of 3, 4, or 5 to 1 (Weinberg and Schulman 1974; Boehm 1981; Mills 1983; Boehm, Gray, and Seewaldt 1984). After 20 years of experimentation on live projects, researchers at NASA's Software Engineering Laboratory have concluded that technology is not the answer; the most effective practices are those that leverage the human potential of their developers [my emphasis] (Basili et al. 1995).
It started to become clear to all of us that modern development would require teams of people. This was because, over time, two trends would become indisputable. The first was that our software became richer and richer, encompassing better user experience on the front end and many more integrations on the back end. The second trend was that software was starting to be used to service thousands and later hundreds of thousands of users simultaneously.
Due to the skills needed because of this new, massive scope, no man or woman could possibly hope to build any large scale, often distributed, system on their own. At one point, playing nice became a non-negotiable skill to effectively deliver and deploy software.
At Container Solutions, we have noticed that those engineers and engineering leads who ‘play nice’ are the ones who perform the best on teams that build large-scale, distributed systems. What we have observed is that the moderately assertive engineer/leader opens the door to better teamwork, increased motivation, collaboration, and trust.
If there is a 10X engineer in our modern, connected, and distributed world, then that person almost certainly achieves their impact through technical skills and an ability to get the best out of those around them.
Some of the original research that McConnell quoted is now over 50 years old. The latest study was from 1995. It’s about time we started to look at research that was conducted this century to guide our arguments. We could at least move the debate forward—and to be fair, many in our industry are moving the debate forward.
There are many people at CS who are really good at something. But more than anything, we focus on how we can all become really good at working together. We feel this is the thing that is most worth discussing. And it’s baked in to our mission: We want to foster the next generation of tech leadership, and that leadership will need to play well with others.
In McConnell’s original passage, he stated that ‘we now know with certainty that peopleware issues have more impact on software productivity and software quality than any other factor' [My emphasis]. What McConnell was saying then is what most sane people say now: if you want to be productive, use proper management and leadership to get the most out of each other.