I suspect that 10x programmers are productive because they control the abstractions and tools that makes them productive (for example, programming language they use), and write their own that help to solve the problem faster.
If you control for this autonomy, by assigning them small "routine" tasks, then of course the effect is lost.
The paper somewhat advocates an approach to SW development that can easily result in this. If you give people lot of small tasks to be done, they will never be able to articulate that they are actually all very similar and can be factored out into an abstraction.
I agree: once the development process is organized to the level that for every few lines of code three meetings on higher level managers and "designers" have to happen and be signed and the developer just has to write three lines and make ten times more paperwork (in triplicate), and constantly wait for other parts of the organization, no developer can be better than any other, to the joy of the managers, and all developers became provably replaceable. Not because the developer can't do better, but because the whole organization mostly doesn't prioritize effective development.
I however suspect that such an organization, happy to meter the development, would not meter the efficiency of the whole, and especially would not allow comparing that whole to some other organizing model -- it could prove that the managers are the weak point after all.
Yep, I think you've hit the nail on the head here. I've worked with a lot of colleagues that could implement features faster than me, polish off more story points, or wreck me on whatever the metric of the day is, but if we were both CTOs of startups in the same market I wouldn't even break a sweat worrying about them (from a tech perspective).
Most businesses don't have access to top talent and they know it. Most businesses are specifically trying to create an environment where devs are interchangeable, and optimising their processes for the 50th percentile dev (if that).
If you do your measurements within that context then of course 10xers don't exist. But when it's John Carmack vs Scrum Legend #34598295 1v1 on Final Destintation with No Items, I know who I'm betting the house on.
> Most businesses don't have access to top talent and they know it.
I don't believe it's a matter of finding talent, but a matter of learning it, and you learn it by doing.
The problem is people will only learn skills they need - so if they don't need the skill to be 10x developer, because the management doesn't expect it or doesn't give them the autonomy, then they will not learn it.
And of course, learning something as well goes against short-term expectations of productivity.
If you control for this autonomy, by assigning them small "routine" tasks, then of course the effect is lost.
The paper somewhat advocates an approach to SW development that can easily result in this. If you give people lot of small tasks to be done, they will never be able to articulate that they are actually all very similar and can be factored out into an abstraction.