I've always been surprised at how readily people accept that "leadership" or "team" are concepts that can be successfully abstracted from a specific project, mission or circumstance. I had a friend who was obsessed with reading about leadership - but when I asked him what he actually wanted to accomplish, he had no idea. I felt, and still feel, that he (and people like him) were putting the cart before the horse. Leadership comes with huge trade-offs, especially if you're a technically capable creative, which makes it something to put off as long as possible. You only assume a leadership role when you have to. You've got to want to accomplish something big, such that you need (many) other people's help, and so you must be willing and able to organize that help. Anything other motive strikes me as empty status chasing.

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.