[dwb]

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is, as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

[simonw]

I dislike the term "IC" too but it does at least have a stable meaning in most companies: it means you don't have direct reports in a managerial capacity.

[mattgreenrocks]

I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities.

I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT.

I have seen extremely talented engineers not get their promo to this role because they were "too into coding." And I have advocated for one of them (w/o their knowledge), arguing the project wouldn't exist in it's current form without their technical contributions, and then witness the org retcon their judgment into a staff-level promotion without any significant change in duties.

Makes it hard to take too seriously, honestly. If the purpose of a system is what it does, then it's meant to be a miserly, inertial source of institutional status. One that can get you a lot more money, of course, so play the game as best you can without losing yourself in the process.

[the_af]

> then witness the org retcon their judgment into a staff-level promotion without any significant change in duties.

Isn't this good for the engineer, though? Presumably they are good at what they do because they like it. So they get a nice promotion and a raise without a change of duties, so everybody wins.

Why promote them out of their skill set, and possibly into a role they will hate and get them fired or willing to quit?

[ffsm8]

The value an individual provides to the company is - at best - correlated with their position in said company.

It it usually correlates even more with their ability to portrait themselves as capable.

Thankfully, there is significant overlap between these groups, but sadly not a full circle if visualized as a Venn diagram.

[mattgreenrocks]

Agree. I wouldn't say it's broken; the somewhat-overlapping Venn Diagram metaphor is apt. But like many other domains of power, there's a persistent belief that those who are recognized (promoted) are indeed the best candidates and that false negatives eventually correct themselves.

Believing otherwise is psychologically dangerous: if the system is somewhat arbitrary, then that opens up the possibility that their promotion was also somewhat arbitrary and not under their control.

[LPisGood]

My favorite bit is all the contradictions

> 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it.

And

> 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while

Say you need to keep doing what you’re doing, but also change everything.

[swaits]

This is 100% how it works at Amazon. It is said you have to do the job (of Principal Engineer) to get promoted. But most Principal Engineers are doing a different job than the job you have to do to become one yourself. Signed, PE@Amazon for 9 years.

[conception]

I think it’s how it works everywhere. People see who’s good at their job and promote them to manager; an entirely different job though people often think it needs the same skill set.

[the_af]

But doesn't this contradict the bit where they argue "to be promoted to X, you must have already been acting like X in practice"?

[yathaid]

A part of the job is only enabled when you get the Principal label. Unlike almost all other transitions, you only prove that you can do the role when given the opportunities. The hardest part about this transition is that you are doing two almost orthogonal roles - Sr. SDE / Tech Lead and the principal parts. It is very easy to not show impact in the former while chasing the latter.

[the_af]

A part of the job that is completely different to what you've been doing, only you were promoted to it because of what you've been doing?

Isn't this like a recipe for the Peter Principle?

    "The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another"

[hosh]

25 and 26 has been my experience with this as well (not at Amazon; at much smaller organizations) Those paradoxes happen there.

Just my opinion: one of the key mindset shift that happens before someone steps into staff and principal engineering is understanding that the technical choices you make are tradeoffs. You give up conceits (or one should) that a technical opinion is separated from context, while also getting to deeper technical principles that appear across architectural levels or disciplines (such as queues). You also see how technical systems are inseparable from the people using it, and being a part of it.

When you start seeing that, you start seeing that everywhere. You start to act in a way that is informed from that understanding. You need to be on the critical path in order to do what matters, but you also need to connect those dots that are overlooked.

But that is also one flavor of principal engineering. I tended to do the horizontal influence than deep technical and domain expertise. At early stage startups, people have to wear multiple hats, often exceeding the scope of what they were initially hired for.

[maccard]

This is a bit reductive and I’m surprised to see this sort of take on here.

Technically that’s true of any step change - a junior developer is expected (loosely) to fix the bugs and do the tasks, to the spec. They should ask for help early and often, and should have enough slack in their estimates from their leads that they have time to mess up to learn. If they continue to do that they will stay junior forever.

They need to learn when to ask, how to estimate and how to avoid certain pitfalls. When they stop asking the basic questions and learn to research, they’ll be promoted to mid level (which they’re already doing). To be an effective mid level though you need to start making mistakes, but in a different way. You can’t be stuck on not being able to install a tool for 3 days, for example.

[johannes1234321]

You've got to change to do the next job. So you are always paid one level below the Job you are actually doing ;)