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.
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.
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.
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?
> 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.
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"However, none of this has much to do with what I said: isn't promoting someone for things they would have to stop doing (as in TFA) a recipe for the Peter principle?
At some point, we have to understand articles and blog posts like the one we're discussing are mostly fluff; an ad for the person writing them. They are self-promotion, there's not much sense in trying to extract valuable lessons from them.
----
I thought of another analogy:
"You're an excellent marksman and a sniper, therefore we promote you to... general of the army!"
But, you could argue, maybe the sniper was already directing strategy, and that's why he got promoted? Nope, TFA is clear about this:
"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"
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.
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.