I mean, generally speaking, the implication is that each level is demonstrably able to do everything that the lower levels can, and that levels broadly indicate organizational impact (note: not to be confused with customer impact).
A ML problem, for example, may be technically very hard and even mission critical, but it would be considered a "senior" level problem if development is well constrained within the boundaries of a team. "Staff" level typically implies that the role deals with people problems across an organization, e.g. there may two or more teams that are individually highly competent to come up with technical solutions to some hard, nebulously defined problem, but who aren't collaborating effectively or at all despite the existence of overlaps between the two.
What's not unusual to see is that people that have been around longer are more likely to occupy the higher levels despite not really having any specific technical competence advantage over some peer.
In your example the ML person that lead some original effort when the company was smaller, and was "senior" in that context, would now be "staff" when a new team is formed, and it's possible that the "senior" in the new team is actually better in every way than the other senior. Naturally when it's time for said "staff" to look for a new job they'd be looking at staff level positions. I've seen this in so many places that I'm willing to bet it's true everywhere. Now one can simply argue that by being around longer and understanding how the org works the more tenured senior is the right person for the staff role but IMO this leads to stagnation and sometimes a complete reversal of the entire levels system where you find people fairly high up in the organization that are not doing a good job. Peter's principle at play. The role/tenure also tends to feedback into whatever performance evaluation system that's in use.
The other big problem in our industry is that the impact of decisions isn't known/felt until a really long time after they're made. Often by the time there's a problem it's somebody else's problem and the appearance of competence != competence. There are lots of other subtle ways where people game the system, e.g. changing schedules. I've seen so many tech projects where the project was delivered on time and on budget, except it wasn't.
Then you have the people that are punching way above their weight but the output isn't always very visible or measurable.
The bottom line of sorts is that this is super tough. Peer reviews help but most systems can have pretty large error bars in gauging either the business or organizational impact of individuals IMO. Sometimes the system gets it right but sometimes it gets it very wrong.
Anyways, I guess it's the game we all play, and partly with experience we learn to play it better.
Well, if we're going to talk about edge cases, I also see the opposite: people who are allegedly at EM or staff levels coming in for phone screen interviews and only getting a recommendation to move forward at senior level.
One thing that became apparent to me is that despite companies having rubrics for levels, the actual levels vary a lot, certainly between companies but even between teams as well.
Perhaps it speaks to the idea of "getting promoted until your ceiling of competence" that standardization of levels across organizations is a concern that typically only gets tackled at around ~L8+ in the tech career ladder. Or, of course, as you alluded, maybe the problem is simply that hard by its very nature.
I agree that generally speaking it makes sense, but it's inflexible to deviations. I also think that level designations are largely lagging indicators of skill.
I don't really understand the argument about inflexibility to deviations. The article you linked to acknowledges the type of workers you talk about:
> the official word was most employees should never expect to get past Senior Engineer. That's why they called it Senior
Career ladders - unlike democratic systems - are gradually more and more selective of specific set of attributes as you go up the ladder, and more and more competitive with less and less roles to be filled at each rung. It's effectively a pyramid. It doesn't follow that merit in any single dimension should equate higher levels, and indeed typically the rubric looks at several dimensions.
It may seem that the term "technical leadership" suggests that more technical ability alone should equate a higher level, and this is a common misconception among senior level people and lower. But I think the way most organizations think of technical leadership means applying technical know-how in the service of more than merely building computerized systems, e.g. use technology to multiply efficiency of multiple workers.
Another way to look at it is to see it from the perspective of someone very high up: suppose a high profile, highly technical product was launched and that shows up in Bob's promo package as his accomplishment. But perhaps due to his "tunnel vision", he doesn't see that the success of "his" product also depended critically on teams working on storage systems, frameworks, CI, auth, deployment and half a dozen other subsystems that also power half a dozen other high profile things. Many of these subsystems are also done by brilliant technical people. But recall the point about pyramids: a company cannot reasonably promote everyone; it would just dilute the value of the title. So pragmatically, it looks at the rubrics that it perceives as being valuable to bring cohesion to all of these subsystems, and the people behind them.
> The article you linked to acknowledges the type of workers you talk about
And then it goes on to say: "She suggests a separate progression for "rock solid" engineers, who want to become world-class experts at things they're great at, and "steep trajectory" engineers, who might have less attention to detail but who want to manage ever-bigger goals and jump around a lot".
Career ladders generally don't support that kind of progression.
> Career ladders - unlike democratic systems - are gradually more and more selective of specific set of attributes as you go up the ladder, and more and more competitive with less and less roles to be filled at each rung
I think you're misunderstanding my point, because I don't think that everyone should get promoted. What I'm saying is that there are impactful roles/work that are not covered well by the roles in career ladders.
An extremely pertinent snippet from the OP in the "Acknowledging employee growth" section:
"These behaviors come at the expense of direct technical impact; there is simply not enough time in a work week to push these behaviors to a fruitful outcome and also focus on direct technical impact. From that perspective only, these behaviors are detrimental to recognition and progression on a regular IC career track.
Meanwhile, obviously such an organization does rely on these behaviors, increasingly over time. They are beneficial to the organization and thus should not be disincentivized either."
And some examples from the article I linked:
"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."
"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"
> Career ladders generally don't support that kind of progression
I can't speak for the generality of edge cases as I don't have that much experience with them, but from my limited experience, that's not what I see. In my company, people putting together promo packages will typically ask people at higher levels to provide feedback or supporting evidence.
For promo packages that I helped with, I'd absolutely look for evidence of packing punches way above their level as it's literally the best evidence that the person could operate at higher levels. As far as I can tell, IC promos do run on the back of relatively narrow expertise (e.g. mine was on the back of expertise about integration between niche systems that a person of my background wouldn't normally think to integrate). But the pursuit for said expertise was also in service of organizational impact with high visibility among higher-ups, i.e. one could argue it could fall under both "rock solid eng" and "steep trajectory" buckets simultaneously. So I don't think it's as clear cut as an "either/or" proposition.
A ML problem, for example, may be technically very hard and even mission critical, but it would be considered a "senior" level problem if development is well constrained within the boundaries of a team. "Staff" level typically implies that the role deals with people problems across an organization, e.g. there may two or more teams that are individually highly competent to come up with technical solutions to some hard, nebulously defined problem, but who aren't collaborating effectively or at all despite the existence of overlaps between the two.