6 ms·

Looks like typical SWE ladders / profiles for roles in FAANG. One can go this route, and then create N-1 preso/diff for "L3 to L4" , "L4 to L5", "L5 to L6" etc.

Looks like typical SWE ladders / profiles for roles in FAANG. One can go this route, and then create N-1 preso/diff for "L3 to L4" , "L4 to L5", "L5 to L6" etc. 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 https://twitter.com/ZainRzv/status/1502550200396750851

majormajor 5y ago
Well, the article is talking about there being multiple, separate ladders for IC development, which I wouldn't call typical. I have seen "depth or breadth" as mentioned as both potentially valid approaches at some companies, but not always. Breadth/"cross team" impact is usually prioritized. 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.
xmprt 5y ago
Even shorter (but slightly less accurate) is talking about the time scale that you are working on. 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
- Thaxll 5y ago
  > you know what you're doing for the next year You think you know.
  - chestervonwinch 5y ago
    I think the spirit of it is somewhere between "you know what you are doing" and "you can envision what you are likely doing". The latter isn't quite as catchy though.
- WinterMount223 5y ago
  That approach is useful and has been discussed in works like https://en.wikipedia.org/wiki/Requisite_organization https://en.wikipedia.org/wiki/Requisite_organization
ZephyrBlu 5y ago
I find definitions similar to that tweet extremely dumb. It implies a lack of agency and strict boundaries for competencies. 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.
- lhorie 5y ago
  A cynical take is that armchair architects who talk as if they can build Uber in a weekend are more likely to be junior than distinguished/fellow engineers
  - ZephyrBlu 5y ago
    I'm not talking about armchair experts, but people who have demonstrable competency that doesn't happen to line up with the prescribed ladder. 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.
    - lhorie 5y ago
      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.

majormajor 5y ago

Well, the article is talking about there being multiple, separate ladders for IC development, which I wouldn't call typical. I have seen "depth or breadth" as mentioned as both potentially valid approaches at some companies, but not always. Breadth/"cross team" impact is usually prioritized. 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.

xmprt 5y ago

Even shorter (but slightly less accurate) is talking about the time scale that you are working on. 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

Thaxll 5y ago
> you know what you're doing for the next year You think you know.
- chestervonwinch 5y ago
  I think the spirit of it is somewhere between "you know what you are doing" and "you can envision what you are likely doing". The latter isn't quite as catchy though.
WinterMount223 5y ago
That approach is useful and has been discussed in works like https://en.wikipedia.org/wiki/Requisite_organization https://en.wikipedia.org/wiki/Requisite_organization

ZephyrBlu 5y ago

I find definitions similar to that tweet extremely dumb. It implies a lack of agency and strict boundaries for competencies. 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.

lhorie 5y ago
A cynical take is that armchair architects who talk as if they can build Uber in a weekend are more likely to be junior than distinguished/fellow engineers
- ZephyrBlu 5y ago
  I'm not talking about armchair experts, but people who have demonstrable competency that doesn't happen to line up with the prescribed ladder. 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.
  - lhorie 5y ago
    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.