Turns out, people are often intimidated in talent when they have no desire to replicate it - this is especially true for management. Even if I was able to influence others, there’s nobody left to influence me.
Not to mention, it’s makes your workload significantly more when you’re the only one researching things, asking question, improving things, etc.
So, in short, yes you can be talented and elect to quit rather than influence.
But the weed-common presence of conservative management is what makes disruption possible.
Swings and roundabouts.
We spend so much time screening engineers, going through code tests, assessments, live code interviews, whiteboard interviews, system design interviews etc.
Yet, we don't have the same vetting standards for managers, at least from what I've seen. There is no "Cracking The Engineering Manager Interview" book, for example. The gauntlet isn't there the same way. There also seems to be far more hesitation to look at management as an issue for negative outcomes vs how its ascribed to engineers[0] much more quickly, yet a manager can make or break an entire team - even turning good engineers into bad ones.
While I suspect that management looks out for management on this, you'd think a broader trend among the community would raise awareness around this, but many well meaning engineers continue to look only at their peers, unless management is particularly ineffective or egregious, rather than evaluating possible management and team practices
[0]: which is the reason given for why engineers have these arduous interviewing requirements, to weed out any possible "under-performers"
I'd think that high performers would develop that skill fairly quickly. If they're job hoping they'll learn to sniff out the signals.
For example: if they say they encourage change for the better, but continually overload those who may be able to influence the changes with day to day work, then those managers / that culture will be resistant / allergic to influence.
If Sprint X is dedicated to learning and improvement but always seems to be full of last minute bug fixes, testing, overflow work, then even if influence is on their menu, they ain't got the ingredients to cook it up.
So - high performance aside, this is the route I took in my last company. I felt the engineering team was good - great, even - but the engineering manager left and I moved into that post because I felt that an external hire might risk the team's currently effectiveness. It was a big change though; IC to 25-person engineering team across multiple products, and in a regulated environment. It's not done lightly, and given people can (or could) get paid loads for doing IC work, moving is also a good choice.