One area that could be worked on is dealing with “difficult” people. At the moment most managers are not really incentivised to hire for performance, but they are certainly incentivised at a personal level to hire people who do as they are told and don’t make waves. Most managers would prefer a 0.1x person who was pleasant to manage than a 10x person who made their life difficult.
You could blame the 10X dev. But it's fair to say that there isn't much talk about how to quantify those kinds of concerns.
It's not that hard to see that your codebase is a mess.
Even if you have no ability to judge the codebase and systems yourself, extreme case, spin that super-productive person up on an independent side project for a few weeks or months and see how the rest of the team grapples with things.
There are a lot of parts of management that aren't hard, but are annoying and potentially unpleasant - if you realize this dev is much less valuable to the long term health of your systems than you thought, that could lead to difficult decisions and a tricky mentoring situation - so they get ignored because managers are either too lazy, "too nice," or just too oblivious.
> Measuring performance is not hard.
Measuring performance of humans is an intrinsically subjective process when you're dealing with knowledge work or anything more sophisticated than a brutal piece-work assembly line.
There is nothing wrong with subjective measures provided what is being measured is performance and not something else. Assuming a manager is not totally clueless they are able to subjectively measure performance just as well as the rest of the team. Everyone on a team knows who is pulling their weight and who is being being pulled along.
There are course edge cases where some people go unrecognised or other get the credit, but in the main most people know who is contributing and who is not. The real problem is that actual performance is rarely even subjectively measured.
It's a misguided preconception that managers are more skilled than their subordinates. I am still have to see happening this in real life.
OTOH what I usually see happening is that managers assign more challenging tasks to specific people based on their prejudice and assumptions then they evaluate those very same people as top performers, while other team members don't even have the chance to perform well (because of the lack of tasks). :D
As a Manager, I am not measuring your performance based on your skill, but on the tangible output of solutions that provide value to the business that you produce.
Your skills and knowledge are your own tools that you can use to produce such output in less time or with better quality.
If I'm accountable to (recognized) business value, something is deeply wrong. The whole reason we have you is to shoulder that responsibility, and to insulate developers so that we're only accountable for/thinking about architecture and implementation. If I have to do the job of both engineering manager and engineer, I'll find somewhere to pay me both compensation packages (i.e. consulting), or (more likely) somewhere I can do just one.
As an aside, even if all your projects are successful, comparing ICs on business value created only tells you who you gave the most impactful projects to. Sometimes your best engineers are stuck doing unsexy, low-impact but necessary maintenance. They create no business value, but prevent existing business value from being destroyed by bit-rot. Sometimes your weakest engineers get a low-hanging-fruit project that's impossible to screw up and immensely valuable to the business. That does not make them ready to take a larger role in more difficult problems, which is typically what a high performance rating entails.
> ...managers exist to set me in a direction and then free me from the political wrangling necessary to deliver (recognized) business value...
Nevertheless, it demonstrates that measuring performance is a complex activity.
Are you wanting to only ever work for people who have a superset of your knowledge? Who know everything you do (for evaluation purposes) but probably also even more? That sounds miserable.
I consider it part of my job to produce results that demonstrate my skill to my manager. I don't want to be micromanaged, and the most effective way I've found to get independence of method is by demonstrating quality of results.
Measuring performance is incredibly hard in a team environment. People are not machines or cogs, and many skills that make a great functioning team are soft in nature.
> Most managers would prefer a 0.1x person who was pleasant to manage than a 10x person who made their life difficult.
If the 10x person can't get along with their team or manager, then they are probably not a 10x person. Every day I'm surprised that people still thinking writing code is the hard part of software development. For most software development, writing code is the easy part.