I think this varies a lot with the type of software you’re building and composition of the team. If you are making a very typical CRUD web app in a structured environment (eg a shop that cranks these out one after another, or with strong project/product managers and designers who do a good job speccing things out) you do not need some rockstar 10xer to get it shipped. In fact, that kind of environment might bore or not be rewarding enough for someone like that to stick around even if they do show up.
But you still need people to actually care about their work and get it done even when it’s not “hard”. Someone who could be a solid engineer on one team could be a “10xer” on another team just from caring about the project and consistently putting in the hours on it, if their team is mostly coasting by doing the bare minimum or highly underskilled. In fact I think many so-called 10xers may just be solid engineers who found themselves in workplaces with a culture of “not my problem” or “I can probably stretch this ticket out a few weeks”.
Conversely if you take someone who might be a wizard on one team and drop them into some super complex “engineering catnip” project they might just be seen as a solid engineer there. I think cases like that demonstrate the author’s point pretty well: if you design the project’s processes and tooling around the wizard’s wizards who eg dont use debuggers because they have some insane skill with tracing running binaries you are missing out on the productivity you might gain from the less skilled engineers.
But you still need people to actually care about their work and get it done even when it’s not “hard”. Someone who could be a solid engineer on one team could be a “10xer” on another team just from caring about the project and consistently putting in the hours on it, if their team is mostly coasting by doing the bare minimum or highly underskilled. In fact I think many so-called 10xers may just be solid engineers who found themselves in workplaces with a culture of “not my problem” or “I can probably stretch this ticket out a few weeks”.
Conversely if you take someone who might be a wizard on one team and drop them into some super complex “engineering catnip” project they might just be seen as a solid engineer there. I think cases like that demonstrate the author’s point pretty well: if you design the project’s processes and tooling around the wizard’s wizards who eg dont use debuggers because they have some insane skill with tracing running binaries you are missing out on the productivity you might gain from the less skilled engineers.