[SavantIdiot]

It is supposed to be a super-smart engineer who is extremely vertical in multiple disciplines, can solve complex problems, and can navigate politics.

I worked at Intel. A principal engineer in the process or architecture was vastly different than a principal engineer elsewhere. For the most part, you become a principal engineer by sticking around, doing lots of extra work, and making at least several major contributions in your career that impact multiple products' bottom line or viability. As a bonus there is a weird deferred-income strategy they use that helps you avoid taxes, your regular bonus multipliers skyrocket, and you are expected to work 24/7.

However, I witnessed several abuses where:

- You can become one if you are friends with an upper manager who scoots you ahead in the line. Several times I saw this type of PE later pushed out by new management, because it was painfully obvious they were in over their heads to everyone else.

- You can become one if you are in a small group that wants to justify its existence. Every group needs a principal engineer, and without one, it is a risk the group will be dissolved. Some managers of tiny groups like their ego trip and want to continue being big fish in small ponds.

- And you can become one if your work a site that hands them out to puff up its image. In the latter case, there was one non-US site that was almost 40% principal engineers, and used that as their claim to fame. "We have the most principal engineers at our site" said the VP. Duh! You are also the VP that approved all of them so you could say that!

So while Intel's definition makes sense and is generally true, it is abused about ... ~35% of the time?

Disclaimer: Intel is an up or out company. You move up, or you move out. It is hard to hover in certain high-pressure divisions. I was passed over twice for PE and shuffled between divisions, and eventually exhausted to the point where i was "out". So i'm a tad bit bitter.

[disgrunt]

I consider principal engineers / architects "astronauts". They've spent so much time floating around they've forgotten what solid ground feels like. They're both disoriented and atrophied when it comes to engineering. It's a trap. You'll eventually have to come back down to earth, and the longer you spend in this role the harder it will be.

[BigJono]

I don't know that I even really buy into the idea of a "principal engineer". Even in a really large company where you have a shit ton of people working on one bit of software, principal engineer doesn't seem like a well defined role that you need, because once you scale past the point where one person (a "lead engineer" or whatever) can manage the technical side for everything, the next "level" up in whatever structure you're working with by definition has to defer to their subordinates for technical expertise. That makes it a management role, not an engineering role.

I think once you're in "principal engineer" territory, it's your job to divvy up the work and hire people to make their own decisions and take responsibility.

If I was hiring specifically for that role I'd probably go with engineering manager or technical product manager or something.

Having said that I think you could make the case that principal engineer works if you're doing that stuff as well as taking responsibility for a subset of the app and continuing to do engineering work. Because I think there's a fairly large range of team sizes where you probably don't have 40 hours of managing to do per week (probably a range like 10-30? Maybe higher? Probably depends a lot on the app too). It's a nice hack to deal with the fact that you can't give someone two job titles.

Btw I think that strategy is underutilised. I've worked with far too many people that are doing 15 hours of really useful stuff and 25 hours of making everyone else's life more difficult because they're a bit constrained by their narrow job description. I really think more devs and designers should have side gigs as little mini PMs, POs and BAs instead of the usual strat of scaling up as quick as possible and running face first into the consequences of Parkinson's law.

[sys_64738]

Maybe that's your experience but the decisions and discussions you're not privy to is where their value is added. An IC4 isn't there to write implementation code as junior engineers can do that.