Because identifying, hiring, and keeping 10x programmers is difficult and expensive. Companies fail at it and assume the problem is the concept of a 10x programmer, rather than own inability to handle this difficult objective.
There a lot of hiring managers, who think the process has one step: post a job 'looking for 10x engineer' and then judge the results. Rather than consider that their approach might be flawed, they attack the concept of a 10x engineer.
There absolutely are 10x people out there in many fields, and many of them are humble about their methods/approach. Software engineering might even have 100x people.
As someone who has reasonable experience founding a company, hiring, training, motivating and managing developers and teams, I feel I can tell you what I really believe:
Forget 10x developers. Forget berating developers for checking in code that doesn’t compile.
If you are planning to build a real growing company, You need to progressively put more stress on your SYSTEM. That is your job.
Have a kickass onboarding set of tutorials and documentation for everyone. Have a culture that anyone can assign an issue to anyone, instead of interrupting them. They can get feedback via updates on issues.
Use pre-commit and post-commit hooks to catch as many mistakes as possible, and clean up team formatting standards for your code.
Hire developers who are super familiar with whatever technology (language, platform, techniques) that you need them to work on. But NO ONE SHOULD BE A HERO, everyone’s code should be easily understandable, use only the simplest language features to get the job done (but no simpler), and be documented. Accrue no code code debt.
Each developer’s work should be documented and tested, preferably by someone other than themselves.
Each developer should be replaceable. That extra 30% cost spent on fully documenting and testing their code means months saved onboarding someone to take over.
Working remotely is actually GOOD. Working asynchronously 90% of the time is even BETTER. Everything in your system should assume people don’t share time or space.
People live lives. Companies build products. That is our motto. It means exactly this... ask yourself whether you are building a product, and if so, do not give responsibility to PEOPLE, but to the system. If they take a day off to spend with their kids, or work 3 hours a day, it shouldn’t have a major effect on the product.
And our compensation model reflects this, too. Instead of full-time employees, feel free to take anything from this:
This attitude makes perfect sense from a managerial perspective. If workers are easily replaceable, they don't have negotiating leverage and you can pay them less, and you don't have to worry about risk to your company if one of them gets hit by a bus.
Conversely, it is in an employee's interest to be hard to replace if they can be. It gives job security and negotiating leverage. A "good" 10x engineer, the ideal stereotype, would be hard to replace because by definition, you'd have to hire 10 people to replace them, and even then, the 10 might not be able to accomplish certain hard tasks.
The bad stereotype of a 10x engineer is that they wrote a business-critical monstrosity only they can understand.
What they both have in common is that they are hard to replace. That is why, I think, that when big companies hire well-known 10x engineers, they put them on non-business-critical research type roles. And smaller companies would presumably be wise to avoid them altogether.
Agree. Entirely too much misplaced focus on finding better/more technical talent when commonly the bottleneck for a companies growth is not limited by engineering brilliance. It's much more common for the limiting factors to be logistical than technical. Or the 'system' as you describe it.
However the compensation model you describe seems a little wild. I'm not sure it's that easy to tie projects to specific performance numbers.
Because identifying, hiring, and keeping 10x programmers is difficult and expensive. Companies fail at it and assume the problem is the concept of a 10x programmer, rather than own inability to handle this difficult objective.
There a lot of hiring managers, who think the process has one step: post a job 'looking for 10x engineer' and then judge the results. Rather than consider that their approach might be flawed, they attack the concept of a 10x engineer.
There absolutely are 10x people out there in many fields, and many of them are humble about their methods/approach. Software engineering might even have 100x people.