[HarrisonFisk]

The big tech companies (ie. FANG) all have huge demand for principal+ engineers and know how to scope and support them properly. The size means they have lots of them which reduces the snowflake nature of the role and makes career development, salary support, etc… more standardized. Since they are large, there can be some variance, but overall they are a good option if you are interested. I don’t know where in EU you are, but most of FANG has roles in EU and some even do remote as well.

Smaller companies tend to want principal engineers in theory, but as you are finding they can often struggle with how to utilize them properly. Often you see them playing a Chief Architect role or something similar which is more hybrid with PM than pure tech. So getting PM skills could help set you up for this direction as well.

Finally, you have said you did management for a bit before, so you should know if this is an interesting path or not. This is a very different role, so I would recommend you do this only if you have the passion and desire to do this full time. Most principal engineers I know have done management for a bit and gained a lot of skills related to it, but ultimately wasn’t what they wanted to do.

[notacoward]

The problem at the big (especially FAANG) companies is that to be effective you need to really buy in to the company's tech stack and development ethos. People who were promoted to those roles naturally do; you probably don't. In fact, if you have a lot of experience elsewhere you're likely to have opinions that conflict with the company zeitgeist, and that leads to conflict with its champions. Similarly, effective principal/staff/+ work requires a lot of strong connections to people in many teams, which again tends to favor internal promotions. This is not competition for its own sake. It means that when you're compared to your home-grown peers every review cycle it will be difficult for you to keep up let alone stand out (even for a while after the typical one-year grace period which isn't long enough at this level). This is discouraging, and in some cases can leave you in a permanent bind w.r.t. team trust or possibility of an internal transfer. Many thrive despite all this, but many also end up seeing it as lost time and opportunity. Quite a few end up going back to where they were, while others opt for a smaller company.

P.S. I'd argue that, for all their advantages within the company, those internal promotions are usually over promotions. People's attachment to that tech stack and development ethos, and lack of experience with any other, means there's an even sharper drop in their value going elsewhere than for outsiders coming in.

[martincmartin]

you need to really buy in to the company's tech stack and development ethos.

You need to be of the mindset that you're hired to help the company. The company has a certain tech stack and development ethos, so you're hired to help them with that. Just because you know there are better ways to do it, your job is still to help them do it their way.

It can be possible to get them to change development ethos, but this is a big deal and uses a lot of political capital. If you can really convince most people that it's better, you'll be seen as a senior tech leader for sure. But if you're optimizing for the best performance reviews -- in other words, the incentives the company has set for you -- then it's usually better just to work within the system.

"To be a leader, you need to have followers." So leadership isn't having the best product, e.g. the way Google is a leader in search. It's more like class elections in high school, it's a popularity contest. Your job is to figure out what people are complaining about or advocating for, and do those. Most likely, everybody is used to the development ethos and just thinks it's the only or obvious way to do things. So nobody is really complaining about it.

[notacoward]

> your job is still to help them do it their way

Mostly I agree with everything you say, especially about needing followers before you can lead, but I think this part deserves more discussion. At staff level (if not slightly before), "help the company" and "do it their [historical] way" are often not the same thing. As I said in another sub-thread, at that level you're hired to bring knowledge and skills and perspective that the org doesn't already have (or have enough of). Unlike lower levels, pulling in some direction is part of the job in this case. I think EMs at all levels understand this and often support it quite well. The problem I've seen is other high-level engineers who never knew anything but the current way and believe that it's generally the only way (except of course for the one part they personally understand and want to change). This sometimes leads to hiring people and then thwarting their efforts to do what they were hired for.

> uses a lot of political capital > ... > optimizing for the best performance reviews

That's the problem. These two should be aligned. You should reward what you want to see more of, and I think people using their best professional judgment qualifies. Relying on the continual presence of people who will sacrifice their own career/financial progress to make needed change (as I mentioned in another sub-thread) is not an effective or ethical strategy. I won't even say whether I believe I'm in that category myself, but I certainly saw other people who got tired of lying down across barbed wire so other people could run past them.

[bradleyjg]

To put a more positive spin on what you are saying, very senior ICs carry the company’s technical culture. They have influence in shaping it, but they aren’t hired or promoted to buck it. If you want that kind of influence you need to climb the EM ladder up towards VP Engineering or equivalent. However, in that case you don’t get to spend 30%, or any, time programming. On the third hand you can go to a start up and wear a ton of hats, but you probably won’t get high cash comp.

Life is always about trade offs.

[notacoward]

Agreed. There's a lot of opportunity there if people are willing to adapt to local norms, even if that means setting aside past (often hard-won) lessons. Some can. Some can't. Most don't really know if they can or not until they try. That's all fine, but I do take issue with this.

> you need to climb the EM ladder

No. Many of these companies take pride in being "engineer first" but that's a false claim if engineers are discouraged from challenging the local orthodoxy too much and only high-level execs may do so. It's too easy for territoriality and NIH to set in, or for real progress to be replaced with mere churn. Didn't we learn these lessons with older tech giants like IBM or AT&T or DEC? They had the same pattern of people replacing one internal system with an almost identical one, because reaping credit and promotions that way was easier than fighting for true change. They had the same pattern of people who had learned those habits too well becoming DEs or fellows and using the same "guardians of the culture" excuse to enforce conformity for its own sake. And look where it got them.

Obviously those who wish to challenge the status quo need to balance that with productive work within the existing paradigm, and strong claims require strong evidence (which a VPE is unlikely to have BTW), but that's exactly why there should not be additional barriers. I was not the first or only person at Facebook to observe that the whole thing would come crashing down if not for an ever-changing cast of engineers determined to do the right thing despite the effect they knew it would have on their PSCs. In a true engineer-first culture challenges to the status quo would be encouraged and engaged, but in my experience that wasn't always the case. Corporate ossification wasn't only a problem for prior generations.

[bradleyjg]

EMs are engineers even if you don’t respect them because they don’t write code anymore. This is different than old school tech companies where managers were businessmen and engineers were thought of similarly to assembly line workers.

The Dilbert dream of no hierarchy (vice a hierarchy made up of engineers) has never worked beyond small companies.

A truly flat org is communism of corporate cultures—-great on paper, a disaster in practice. The dysfunction at these places isn’t because they haven’t flat org’ed hard enough or because of evil, devious middle management subverting the purity of the system—-it’s because the idea is bad in the first place.

[notacoward]

Let's not turn this into an exercise in moving goalposts and constructing strawmen, OK? I never expressed any disrespect of EMs, nor did I propose a flat organizational structure. You specifically mentioned going up to Vice President of Engineering level, which is quite different than a line EM, and I responded to that. Your absurd invocation of communism aside, that's way over on the old-fashioned authoritarian/hierarchical end of the organizational spectrum.

[bradleyjg]

That’s where some decisions should be made. For example, creating a new programming language. The answer is almost always “no, that’s a horrible idea” the determination otherwise should be made by the person ultimately responsible for all engineer execution.

[adamcstephens]

If a flat org is communism, what is a top-down org? A dictatorship or authoritarianism?

[goodpoint]

A top-down org where employees don't have the power to vote out management is exactly that - an authoritarian structure. That's why is called privately owned.

[bradleyjg]

I don’t say it is communism rather it’s like communism in that both look good on paper and are disastrous in practice.

[mbot5324]

> start up and wear a ton of hats, but you probably won’t get high cash comp.

I'm not sure start-ups are any freer on the dogma, so you'll still run into this unless you find a start-up that matches your own. Worse still -- start-ups have serious pressures that make debating dogma look like not carrying the load.

[bradleyjg]

If you are in early enough the decisions haven’t been made yet, so by definition they can’t be set in stone. You could have a technical co-founder that wants to decide everything without discussion but in that case you probably don’t want to be there for many reasons.

[balaji1]

> Similarly, effective principal/staff/+ work requires a lot of strong connections to people in many teams, which again tends to favor internal promotions.

This might be a smaller factor for doing effective work itself, the number of new faces at all levels at big big companies might offset this. And generally, ppl working under this principal/staff+ engineer usually follow along.

But promotions would require connections to many ppl in many teams.

[Fiahil]

Other big non-FANG companies also need Staff/Principal Engineers. You can find them in AI consulting companies, banks, insurance, and pretty much everywhere when you know what to look for. This includes most European cities if you have a EU passport.