He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.
I definitely think tools can have a lot of leverage, and an experienced IC could easily develop a tool that would save time for the whole team. And I've seen it happen.
But IME this is the exception rather than the rule. The experienced engineer usually gets the credit for building the system with the tool (for which it was essential), but not building the tool itself. The tool is considered useless until someone has proved it on a important, shipping project.
I'm a manager and I have a member of my team that does exactly this. They have built tools and process that has allowed everyone else to be more efficient. Anyone on my team can, but they gravitate towards it. It's up to a manager to make sure they are paid appropriately and make sure that they are given space to actually do this type of work.
Can not be customer satisfaction (by quality) or employee happiness or retention.
I wonder what those other metrics are.
A big one is that managers are de facto judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.
Edit: Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
> It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
This again... I dread to imagine going through the day around people that think like this. But people that think like this exist, and I imagine they concentrate somewhere. If some place makes them happy (and everybody else unhappy as a consequence), you'll probably find them there. This is really believable.
If you do it right, this also scales well. If you can help a hundred people do their work 10% more productively, that is also more effective than helping four people do their work 50% more productively. Most tech companies that have separate engineering-IC and engineering-management ladders try to keep roughly similar expectations at each level about scope/breadth of impact, it's just that for engineering management, it's "how many people do you transitively manage," and for the IC ladder, it's not as obvious.
I think this article does address that by pointing out that the design management career track generally expects you to manage both increasing numbers of people and increasing amounts of work, and those don't need to be the same thing:
> Overlapping responsibilities between IC and managers is the most prominent issue I’ve observed, but it’s an easy one to resolve by looking at where the line is drawn between people and product on the team.
(This sort of reminds me of a similar problem in academia: there are three separate skillsets, doing research, leading researchers/scaling a research lab, and instructing students, that tend to be conflated into one ladder. They don't need to be.)
However, that linear multiplier doesn't mean jack in a world where technology can create exponential leverage. I'm pretty sure on a given day, the potential for a single or small set of individuals (without any centralized management) to produce products and systems that change the world is higher than any day previous.
That is why you see tiny hedge funds doing well, both for finance, quant, and tech workers.
No better way to spread your skills to the whole team.