- 10x is a zone we enter at times, it cannot be sustained
- 10x has historically (in Mythical Man Month etc) meant the difference between worst and best developers
- Being 10x better than average is a rare occurrence with short duration
- 10x zone is only achieved after months or even years perfecting required skills/ preparing conditions for the highly productive period to commence
- Many important tasks take the same/ very similar amount of time regardless of the individual – e.g. attending the daily stand up, liaising with another department, manual testing etc
Common Characteristics of being ‘in the 10x zone’
- Task that does not lend itself to parallelism – i.e. efficiency is gained from reducing communication, discussing unimportant implementation details etc
- Full stack developer avoids need to interface with knowledge silos – this is a very common with hyper-productive developers but often leads to resentment from the team unless great care/preparation is taken to handle political backlash
- Using a library/ technique highly suited to task at hand – a great example is deserializing/ serializing xml by hand vs. employing a tool like xsd.exe or JAXB. Many thousands of lines vs. a trivial library call can lead to man-months of saved effort
- Already familiar with business/ technical problem – second time around is always faster. By the third time most problems are solved many times faster
- Bust through politics – managed to obtain access to all necessary sub-systems, and are shielded from political backlash of stepping on toes so can sustain the access
10x Projects are a far Bigger Deal
Over the years I have seen around fifty projects. Excluding the really crazy ones 5->10x is a rough measure for the difference in productivity we see at the project level. Probably more if one considers operational issues; too many systems are moved to production before being fully stable. Many projects fail, so technically there is an infinite difference in productivity. 5-10x is a rough approximation between ones that make it to production.
Common Characteristics of very inefficient Projects
- Too many people – and/or too many of the wrong people
- Cumbersome, un-enjoyable process
- Developers treated as commodities – no praise for quality work
- Better developers left the project early
- Rude, non-technical leadership
Anyone with a few software development projects under their belt knows the main issues that lead to poor projects. Unfortunately after all my years in software development I am now of the opinion that many are inefficient intentionally by design. Yes, the leadership team actually desires this! A sizable proportion of senior management prefer to have very large teams. The root cause appears to be Empire Building; a larger team brings the manager/director more power. Many resist promoting others that could potentially challenge them, and several times I have witnessed life being made difficult for quality individuals with the sole intention of forcing them off the project. As time progresses leadership weakens and it can decimate large companies, especially during tough economic times. This is why many very large companies look outside the firm when time comes for a new CEO.
Obviously there is a massive productivity difference between the best and worst developers. That does not mean someone highly productive on Project A will immediately be highly productive on Project B.
A badly run project can cripple even the best individual’s ability to do great work. This is of far greater importance than bickering about if one developer is actually 10x or not. One great developer is just one great developer with a limited skill-set. The team wins the war, great developers are often decisive in key battles but they cannot win wars alone.
Developers have specialties. Personally I still struggle until up to speed with a new technology – it takes time and hard work to be ‘10x’ again with new technologies. Beware anyone who tells you otherwise, especially the ones who claim to be ‘10x in everything’, everyday on every project’.. That is not reality. Every project failure I have witnessed had at least one guy who would publicly state he was expert in a very long list of technologies.