[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.