[caprock]

Unfortunately, what I see the most is:

An increase in seniority comes with (A) a decrease in hands-on time with technical problems and (B) an increase in time spent on project management, team organization, and people problems.

None the less, there are some possibly interesting resources regarding levels at Honeycomb [1], Netflix [2], and Gitlab [3]. There's a whole book if you're going to venture into "staff" [4]. Last but not least, don't forget the Peter Principle [5].

[1] https://www.honeycomb.io/blog/engineering-levels-at-honeycom...

[2] https://blog.pragmaticengineer.com/netflix-levels/

[3] https://about.gitlab.com/job-families/engineering/developmen...

[4] https://staffeng.com/guides/staff-archetypes

[5] https://en.wikipedia.org/wiki/Peter_principle

[dieselgate]

Wasn’t familiar with the Peter principle before but seems it’s a common trope. Doesn’t this assume the individual stops learning though?

[caprock]

I was throwing it in as a bit of humor, but your comment illustrates how it really can provide fuel for an interesting set of conversations around ladders/roles where an engineering team can thrive.

Does the peter principle assume a person stops learning? On the surface, yes. And if learning leads to skills, maybe we could also consider success in different jobs as a combination of both skill and motivation. This would highlight a couple of the common, real-world problems I see when engineers "rise" up the ladder:

1. A first problem is many senior roles require new organization and leadership abilities, thus the core of the Peter Principle. (skill)

2. The second is that absent careful thinking and goals, many engineers will seek arbitrary advancement only to find their ability to succeed disappearing when those new skills aren't as fun/engaging/fulfilling. (motivation)