I really don't think coining the term 10x did anything to help developers or the state of development, and likewise here.
I like to think we are all 10x developers. The question of a 1x developer should be how to grow their productivity (assuming they are motivated to do so). Less productive developers should not feel like they have one tenth of the natural talent someone else has. Instead they should look at how they can improve their work flow/knowledge and companies should try and maximise the output of their employees.
Yes some people will always be better/more productive than others, but most people are differentiated by completely controllable factors.
Well, that's why the author had to call tech leads "100x developers". x inflation has led us to this situation where 10x is now a baseline minimum. Anything under 100x is just mediocre.
Who's "we"?
1) Make sure that the people working for them are happy and challenged
and
2) Remove any roadblocks required for developers to solve the problems that they are working on (I would say "write code", but I don't think that the ultimate measure of developer productivity is how much code they write).
I think that good tech leads should help to keep productivity growing mostly (almost?) linearly as the engineering team grows.
I thought it was a well written article though, and the author’s company sounds like the best environment to be in with a tech lead.
That fact notwithstanding, I’ve never met someone more than 4x faster than anyone I would consider adequate. Maybe that says I have demanding standards (likely). Maybe that means I’ve never been in the presence of great developers (less likely).
What I have met is people who value their own productivity over that of the team. They create code that slows all but themselves down. The more clever the person the worse the damage. I have no doubt that such a one could force a situation with a ten to one ratio, especially with developers without the self esteem to push back.
100x 200x gives me an idea for terrible clicker game.
I've only known one. And having that type of engineer isn't necessarily all it's cracked up to be.
The other members of the team would discuss a problem, hash out a couple of potential solutions, and then begin assessing how long it will take and who will do which parts.
Two days later the 10x engineer would drop an amazing implementation of the solution into our laps.
The result is that everyone else on the team got demoralized and stressed about whether they were going to have meaningful work to point to in their performance assessments. The entire team ended up blowing apart.