[jayceedenton]

It's typical of engineering organisations to come up with this kind of list, the main reason being that as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly. We demand the right to define it but when given the chance we always set the bar unrealistically high.

To recognise someone as a Principal Engineer, they should be definitively and objectively exceptional in every way, right? Their depth of knowledge in all technical areas is unmatched, they deliver innovation, domain knowledge, expert teaching and mentoring, strategic vision. They're growth hackers and also they design and deliver timeless systems and ever-green architectures. They're research scientists, and also inspiring leaders who (with no formal seniority) are able to align large groups of engineers via respect alone. How else can they be deserving? I wonder, does any other discipline in the org require this?

Whenever we come close to settling on a sensible way of recognising the value that experienced engineers (that are well connected to the domain and the business) can bring, it takes only a few years before that route is smashed by a new iconoclastic bunch of thought-leaders.

The parts of the org that are outside engineering now just let us get on with sabotaging ourselves.

[lmm]

> as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly.

Are we wrong to? We've all had the experience of being held back by poor decisions from a senior person who simply didn't have the skill. I watched a 200-person company full of smart people single-handedly destroyed by a "software architect" who just made a lot of, frankly, stupid choices that all of the freshly-graduated engineers could see were stupid.

Frankly I've found the vast majority of "experienced engineers" aren't actually any better at their jobs than fresh grads. There should be very high, objective standards before we allow one person to overrule the rest of the organisation.

[lumost]

Bear in mind, an Amazon Principal Engineer is intended to be a 1 in 100 engineers position. The pay is generally above 600k, with the max pay dependent on the position.

[sokoloff]

In a field where the spread of outcomes is as wide as software, it seems reasonable that the right tail of practitioners would be very impressive.

In practice, no company requires their equivalent of principal engineer to hit 100.00% of the defined marks, but rather a comfortable majority of them with no glaring weaknesses.

Principal engineer roles should be filled on ability and impact not seniority/experience.

[ahupp]

I'm not familiar with Amazon, but the equivalent level at FB (according to levels.fyi) represents just 1% of engineering. So this isn't only "experience, seniority and progression", it represents something really unique.

It's hard to look at a list like this and say "oh I know what to do now", but it is useful as a rubric; is this person meeting most of the criteria? Just a few?

[username90]

Principal at Amazon is the first level above senior software engineer, so closer to staff than principal at Google/Facebook. It isn't a particularly uncommon level to reach at Facebook or Google.

[amzn-throw]

Principals at Amazon are 1.8% of the SDE population, so no, the comparison to "Staff" engineer is unfounded.

[username90]

Amazon is just more stingy with promotions.

[amzn-throw]

Yes, and so their "staff" engineers stay Sr. Engineers. Isn't that the same point I made?