The principal engineer role usually comes with expected impact on a big organization or even the whole company. Having that kind of impact is impossible as an “IC” in the traditional sense. Unless you are in some very cutting edge area, or get very lucky, your principal role will involve a big dose of the same leadership and management tasks that a manager or director would have.
So what is your vision of IC "in the traditional sense"?
Most senior engineers at organizations require a significant amount of coordination and people-skills. If you're not managing a team, you're definitely managing the relationship with your manager and coworkers/project teammates.
My vision for a "traditional" IC is someone who sits in front of a computer and writes computer programs. This kind of role ends at senior, or if you are lucky, staff. A principal engineer is much more likely to be in a meeting heavy environment, coordinating with many teams and driving alignment towards some vision. While this is not strictly managerial work, at least to me, it seems to fall much closer to "senior manager" than "software engineer".
Thats totally fine for folks who thrive in this kind of role. However, it does take away the ability to grow your career if you want to keep developing software. So for example, if you program for 20 years, and keep improving during this time, you would expect to be rewarded with some career progression for the progress you've made in years 10 - 20.
But as it stands, these days, if you run into someone who has been programming for 20 years, you can assume their career has mostly stagnated, and might even count them off as a low performer because they failed to grow. So it's almost a self fulfilling prophecy - staying a "true" IC has no growth, and therefore there is an incentive to just sit back and stop growing.
> The principal engineer role usually comes with expected impact on a big organization or even the whole company.
Yes, but you're not managing people. It's a lot of collaboration and leadership, certainly, but not doing any of the HR-adjacent bureaucracy that comes with being management.
