This is exactly why it seems to odd to me that many companies see management as a logical "next" step in someone's career. It is a completely different path and requires very different skills. At least, the way many companies have set up their company structure.
That's because there's a clear career ceiling for engineering roles in those companies. They're in a mindset of let's say McDonald's management - there's no career track for cashiers, no "principal burger flipper". They see engineering similarly. It follows from there that the only way to go up is to go to the management.
They're also not the same roles. Usually roles (except fake titles) above senior are a completely different beast just as well. Staff / principal replaces things like architect, system designer and other positions we had in the past.
Alternatively, I've seen a "senior principal" dev working effectively as IC in a technically very demanding project (specialized database engine).
Basically champion firefighter in addition to what you describe. Arguably the role we'd have if there were many CTOs and they were still practicing, instead of getting showtime
You end up doing less coding, more mentoring, drawing diagrams or doing requirements analysis with the team output customers.
I never get why companies are so fixated on salaries being tied to titles. People just do different jobs and you shouldn't need technical or people leadership to get paid more.
If someone is really effective at their job they don't need to be called (or do the work of) a principal engineer. Just pay the 10x engineer 10x.
That's on a company's performance reviews... and so how do you measure salary increases, bonuses, anything? There shouldn't be a different standard to it.
The only difference is the engineer shouldn't be forced into a different field to get paid more.
> What’s a 10x engineer
It's just an expression I'd say. Can be 2x, 5x, whatever. Most of the time a good engineer is forced into management of some sort (technical or people) before the 2x mark (salary wise).
More frustratingly, for example quasi-governmental places, the total comp raise any individual can receive is a hard limit written in their rules. Even if you skipped 5 levels you couldn't even get that raise. That's why new employees are hired at a higher rate than existing employees. The only solution is to quit for a time and then come back to the org. Though maybe once every 5 years they'll do a realignment of pay bands.
If only we do the "same" work and provide the "same" value in software. 90% of the time you're always doing something different and hence why estimates fail.
Someone that knows the ins and outs of an ever complex system will be worth the 30-40% bump. If it was so simple there would be a lot less stories about rewrites etc, which often occur because no 1 knows and maintained the existing system.
Knowing how an entire large or complicated product works can be very important, and can take an immense amount of time.
In fact, most engineering jobs that I've worked existed entirely because shoddy and poorly engineered products needed whole new product categories invented to make up for shortcomings.
The reason that the progression is expected to be IC -> EM is because that is a path that leads to software people being managed by other software people. Alternate paths lead to less efficient managers because they tend to have critical knowledge gaps.
So if you want junior engineers to really try to learn and contribute don’t tell them “well, if you really suck as an IC and focus on socializing you can be the boss of everyone here”. It’s pretty self explanatory actually.
Do note that I specifically said many companies, not all companies. I think there certainly is room for software people being managed by other software people. If this is done in ways where the managing people also do keep being involved in the actual work in order to keep their skills and, more importantly maybe, their perspective up to date with what is happening.
I see too many companies where this is not the case and I see ex-software people giving justifications based on skills and insights that have very little relevance with the current situation on the floor.
For an IC the application of those skills will be quite novel. But that is what career progression is. Same skills, new puzzle.
I was lucky enough to work at a company where one logical next step was to move into technical consultancy with companies, so rather than managing a project, you became the technical interface between the customer and the project. At best, this could involve conducting or facilitating some really fascinating collaboration both with the customer and the supporting devs.
It sometimes also involved myself and the PM doing a good-cop-bad-cop routine with the customers, which could be 'interesting'.