3 ms·

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 offi

by lhorie 5y ago

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.

ZephyrBlu 5y ago
> 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"
- lhorie 5y ago
  > 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.

by lhorie 5y ago

ZephyrBlu 5y ago

> 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"

lhorie 5y ago
> 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.