But that seems something old companies with a ton of bureaucracy would have, not suitable imo for a "young tech company".
For those, I highly prefer this fits-in-one-tweet definition of L3, L4, L5, L6: https://twitter.com/ZainRzv/status/1502550200396750851
What if someone is awesome at finding the right problems to solve, but isn't amazing at building the solutions? Or they're great at designing a solution but not amazing at building it?
There is no room for those people in these level definitions. If you're good at higher level competencies but don't have much experience, too bad, you're a dumb junior.
It can also go the other way as well. Someone could have extremely strong technical skills with little interest in searching for new problems, so they don't tick the box for Staff even though they can provide an enormous amount of value by tackling known, hard problems.
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.
This article does a better job of explaining than I will: https://apenwarr.ca/log/20201227.
> 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.
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"
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.
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.
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.
they'll promote the usual bootlickers and brown nosers.
Yeah, and hopefully not even a junior (e.g., not hired at all).
I don't mean to be overly glib, but I don't really have much interest in working with a software engineer who is "awesome at finding the right problems to solve" but can't actually do any of the work to solve them. Most of the staff and principal folks I have worked with in the past are great developers, if maybe a bit rusty sometimes depending on the exact role/company. It's an important skillset to have and if all you can do is lay out high-level technical designs, you're at best 25-30% of the way toward one job.
Ex: 10-30-50 like described here for PMs but for engineers instead: https://twitter.com/shreyas/status/1055725977769136128
It's silly to assume that all engineers will have similar levels of competency in all areas, but that is how career ladders are structured.
More on it in this article: https://apenwarr.ca/log/20201227.
There are roles other than engineers that have their own level definitions
Also, product is a completely different skillset than engineering. Being good at finding and identifying engineering problems is not the same as being good at product.
A big company cares more about there being a predictable structure, less chaos and consistent productivity than actually solving the problems, improving the business and rewarding those that produce more.
This level system manages peoples' egos and prevents junior engineers who are way better than the senior ones being promoted too fast and upsetting the others.
You might think this is inefficient or unfair, but it is by design.
- "Software engineer: solves problems at one's best levels of autonomy and quality."
Any pre-defined set of boxes for people to sit in I've seen have only restricted people's opportunity for growth.
I also don't care much for the internal bureaucracy and politics that people waste time on that come with a pre-defined set of boxes.
Yes, you should be compensated at a market-appropriate level for your expertise. But a pre-defined set of boxes also does not help with that.
Yes, if you want a fancy title when you are looking for a job, feel free to call yourself Grand Emperor of the Thundering Herds. If someone calls me for a reference, I will say, "sure, ZephyrBlu was our grand emperor of the Thundering herds, and their responsibilities were..."
L3 => you know what you're doing for the next few days to a week.
L4 => you know what you're doing for a month
L5 => you know what you're doing for a quarter to a half
L6+ => you know what you're doing for the next year
You think you know.
But I agree the tweet is pretty accurate for a small (<20 person) engineering org[0]. I don't think this article really comes into play until 20+ (maybe 50+?) employees.
[0] It's also accurate within, say, a single well-isolated smaller team in a bigger org, but then the scope/risk/responsibility is often smaller unless you start adding the typical "across multiple teams" thing to senior/staff/etc.