Buying kimono and black belt does not make one good at martial arts - reading about leadership will not make someone a leader.
Which makes me think about Dwight Shrute type of people.
I have noticed a combination of examples that confirm and reject this. Speaking for myself and some of the colleagues whom I consider good developers: none of us want to deal with the official responsibility that comes with being a leader so we don't want to step into that role. On the other hand our manager is an excellent developer and super sharp individual and he seems to have boundless energy for leader-type activities - the kind that just thinking about makes us feel weary. My (unsubstantiated) theory is that it comes down to a combination of culture+work ethic+ambition+grit: just putting one's head down and getting stuff done, irrespective of whether it is creative or enjoyable. Of course, our manager gets paid very very well so that, at least partially, makes up for the trouble.
I suppose at the end of the day I'd like to understand how you can read a manual like "How to win Friends and influence people" while still maintaining high standards of quality and integrity. Because it seems like most people read books like that and become spineless manipulative dishonest people. I've come to prefer the honest, harsh judgments of technologists to the constructed speech you often get from leaders. I would be thrilled to work with a leader who can somehow square that circle.
Perhaps the closest thing I've seen to a "lab" that might begin to experiment intelligently with abstract leadership ideas is something like YC, which is in position to iterate on the expensive, difficult, messy game of tech business leadership, because they have a privileged position to see what works, what doesn't, and what the limits of those observations are. And I would bet that even after ~2k companies (or whatever it is) no-one in their right mind at YC would think they've seen it all. They have, at best, a set of good heuristics. Not great, just okay.
From the IC perspective, high perf means the ability to modify the product quickly and surely, while making practical trade-offs using sound judgement about the larger context of the work, by manipulating the code and code meta data (e.g. bugs and features). These systems are highly complex especially analyzed across ~20 dimensions of performance, and success often means guessing which dimensions to care about and which to leave to their own devices. If there is a systematic error mode in an IC its when your prioritization scheme is wrong because it's ossified, or because you're unlucky.