I strongly disagree. “Staff engineer” as a construct should be understood as an alternative to the previous dominant paradigm, which held that manager track is the only progression track beyond some point (usually Senior or a “Senior II” level).
This toxic concept was pretty commonplace through 2010, particularly outside Silicon Valley.
Any system can be done wrong. But this system is, I believe, objectively better than the one preceding it, as having a dedicated IC track gives a way of growing your engineers who aren’t interested or talented in management.
What you are complaining about sounds like an instance of poor management or poor team composition, not anything to do with the concept of Staff Engineer; if people are not doing their job then they are not being performance managed properly. Showing you can act at the level above is great but you still need to nail your core responsibilities too.
Alternatively, I've worked with Staff Engineers who are still fixing bugs, and also building (maybe staff-level?) tooling and project improvements. The most significant issue is the lack of standardization of expectations. "Staff" doesn't mean anything in a vacuum because it doesn't mean the same thing between any two companies.
Personally, I love doing senior stuff. I don't know if I even want to be staff at any point, maybe I'll want a different challenge someday, but I still get a lot of enjoyment out of churning out high-quality code and shaping things at multiple levels. But if I stay where I am, I'll eventually be promoted to staff with minor shifts in the work I do.
While you're not wrong I want to point out that you generally don't get the opportunities to practice staff-like skills until you've proven you can do the 'boring' work too. The system does incentivize performative leadership, but only for a relatively short amount of time in your career, so I don't think this is a huge deal.
Perhaps in some cases, but the ones I worked with pre- and post-promotion didn't really change what they were doing over that period. What I'm saying is that titles are fluid, not fixed, in meaning. They can be inflated or deflated according to an org's mood.
Those can be some of the most fun problems. Fixing deeply rooted reliability or scalability problems in the business's core product without disrupting users? That's absolutely a path to recognition and rewards.
From personal experience: no it is not. This mentality leads to nothing but frustration and burnout as upper management sends you to tackle your "staff"-project.
Titles are all based on organizational politics and the macroeconomics at the moment. Were you hired during the 2021-2022 hiring spree where companies would give anything to keep engineers from getting poached? You probably were hired at Staff. If not, then what were you doing? Lol these folks were the first ones laid off.
Personally, I received my highest raises in 2021 and 2022. Multiple salary (and equity) bumps; a title bump. Life was fucking good.
Nowadays, you can just be glad not to get laid off. Instead of the promotion they promised, you get a slap in the face and some chump change.
I know I sound jaded but the fact that there are MULTIPLE books on "Staff"-level engineering (all un-ironically written by managers and executives rather than ICs) is completely laughable.
People read it and all of them like to act like a staff engineer when in fact there are only available slots for a fraction of the engineers.
Now nobody wants to fix bugs and improve product quality. Why? Because those tasks are not staff-level work.
The reward system and the definition doesn't work.