I think the advice is good but maybe the title could be improved.
> But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words.
To me, this is the main problem. Engineer A is unable to describe the impact of their work, how the work affected the business. Your manager isn't responsible for promoting your own work, you are.
> Engineer B’s work practically writes itself into a promotion packet: “Designed and implemented a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and built a configuration framework enabling future extensibility.” That practically screams Staff+.
Maybe it's just the narrow of the article, but if promotion only looks at complexity and not quality of delivery and impact on the business then this isn't a good engineering team to be in.
There are many cases where simplicity is celebrated and recognized. It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.
> It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.
… the impact of my work is more often than not opaque to me, the person doing the work. More often than not I'm not the one setting the priorities, and way more often than not the real world impacts like "we brought in $X M with that feature you wrote" is quite simply not visible to me because "that's not what engineers do".
I would love to know these things, I'd love to have that level of visibility, but finance at tech companies is nearly always a black box. Best I get as an engineer is that I know how much cloud compute costs, so I can figure out the expense side of stuff.
If anything, I usually have to go for far more intangibles: "this internal manager was happy", "this adjacent team had all their wishes and desires fulfilled", etc.
Otherwise, stuff feels like it plays out like the bits you quoted from TFA.