You say this, but the role of staff+ engineers often is being a project manager. Not all the time, but at least sometimes.
The difference in responsibilities between levels is somewhat to blame for this. If you are at a particular level doing this kind of project management work is what looks good on a promo packet, because it's cross-functional and you're leading a bunch of people, etc. But if you're not at that level people think you're bad at your role.
E.g. imagine a mid level engineer doing this work vs a staff engineer.
"People in group #2 weren't supposed to exist. They were doing some hard jobs - translating business problems into designs - with great expertise, but these accomplishments weren't interesting to the junior-level promotion committees, who had been trained to look for "exactly one level up" attributes like deep technical knowledge in one or two specific areas, a history of rapid and numerous bug fixes, small independent launches, and so on. Meanwhile, their peers who couldn't (yet) architect their way out of a paper bag rose more quickly through the early ranks, because they wrote reams of code fast.
Tanya Reilly has an excellent talk (and transcribed slides) called Being Glue that perfectly captures this effect. In her words: "Glue work is expected when you're senior... and risky when you're not."
...
People who are naturally excellent at glue work often stall out early in the prescribed engineering pipeline, even when they'd be great in later stages (staff engineers, directors, and executives) that traditional engineers struggle at. In fact, it's well documented that an executive in a tech company requires almost a totally different skill set than a programmer, and rising through the ranks doesn't prepare you for that job at all. Many big tech companies hire executives from outside the company, and sometimes even from outside their own industry, for that reason."
Sure, some amount of project management type work is expected when you're an engineer at a higher level (senior, staff, principal, etc). However, that's not the entire role. Before you reach those levels you should have a deep technical knowledge of how to write code and design systems.
If you don't have those fundamental skills, then you're not going to make a good engineer at higher levels.
If you do have those fundamental skills, but have never demonstrated them because you're too busy doing project management work, then why would anyone believe that you have those skills? Demonstrate them somehow.
If you want a role where project management type tasks are the whole role, then become a PM.
> If you do have those fundamental skills, but have never demonstrated them because you're too busy doing project management work, then why would anyone believe that you have those skills? Demonstrate them somehow
This is the whole problem. You can have the technical chops to back up your project management work but if you have not "demonstrated" them then it's as though they don't exist.
It's relatively difficult to "demonstrate" your skills the way people want them to be demonstrated in a corporate environment unless you have a very supportive manager who helps you write your promo packet and goes in to bat for you.
The difference in responsibilities between levels is somewhat to blame for this. If you are at a particular level doing this kind of project management work is what looks good on a promo packet, because it's cross-functional and you're leading a bunch of people, etc. But if you're not at that level people think you're bad at your role.
E.g. imagine a mid level engineer doing this work vs a staff engineer.
Great article that explores this more and even references the posted article: https://apenwarr.ca/log/20201227.
"People in group #2 weren't supposed to exist. They were doing some hard jobs - translating business problems into designs - with great expertise, but these accomplishments weren't interesting to the junior-level promotion committees, who had been trained to look for "exactly one level up" attributes like deep technical knowledge in one or two specific areas, a history of rapid and numerous bug fixes, small independent launches, and so on. Meanwhile, their peers who couldn't (yet) architect their way out of a paper bag rose more quickly through the early ranks, because they wrote reams of code fast.
Tanya Reilly has an excellent talk (and transcribed slides) called Being Glue that perfectly captures this effect. In her words: "Glue work is expected when you're senior... and risky when you're not."
...
People who are naturally excellent at glue work often stall out early in the prescribed engineering pipeline, even when they'd be great in later stages (staff engineers, directors, and executives) that traditional engineers struggle at. In fact, it's well documented that an executive in a tech company requires almost a totally different skill set than a programmer, and rising through the ranks doesn't prepare you for that job at all. Many big tech companies hire executives from outside the company, and sometimes even from outside their own industry, for that reason."