Anyone who seldom codes should *NOT* be on the staff or principal level. Your levels are basically sorted as "codes less, is more senior" which is a false dichotomy.
Thanks for the input Abbas! Let me clarify a few points about this specific framework. Keep in mind that these levels and titles are not 100% equivalent across different companies.
The levels in this system are not sorted by seniority vs coding but, rather, by the impact radius and nature each level is responsible for.
In this framework, an L4 engineer would still code a good amount, but they would focus on higher impact individual contribution work (ex: core systems, major refactors, high risk fixes, etc.). This is the level where helping plan and execute cross-team projects or major single team initiatives becomes more important. The time dedicated to some of those activities is not being dedicated to coding.
Tangible example: one of my past L4 identified the opportunity of significantly reducing his group's operational costs by moving several systems from x86 to ARM. He created an experiment, where he deployed the stacks on an ARM cluster, identified which code needed to be updated, and the expected cost reduction. He coordinated the implementation of this change with the EMs of multiple teams, coded key parts himself, and helped other engineers code theirs. End result: ~40% less platform costs! Approx. time breakdown coding vs non-coding: 50-50, I think.
This trend continues into the L5 level. Tangible example: L5 noticed that our customer dashboards were slow and hard to scale. He dove into the data and found the culprit - the underlying data architecture. He redesigned the analytics system into a fully-fledged lambda architecture and coded a reference implementation for key parts of the system. He helped convince PMs of the necessity of the change, plan the change across ~30 engineers and 5 EMs, bi-directionally aligned with engineers and helped them navigate key parts of the project. Key results: 10X faster dashboards and 30X less cost-per-query, to cite a few. Approx. time coding: 10%-20%.
Naturally, exceptions exist: I've seen L4s and even L5s who coded a lot while working on incredibly critical or foundational projects, though rarely alone.
This strategy seems to work well across many successful tech companies, including those I led. As with many things in tech, I expect there to be different ways of solving this problem. How would you do it?
Anyone who seldom codes should *NOT* be on the staff or principal level. Your levels are basically sorted as "codes less, is more senior" which is a false dichotomy.
Thanks for the input Abbas! Let me clarify a few points about this specific framework. Keep in mind that these levels and titles are not 100% equivalent across different companies.
The levels in this system are not sorted by seniority vs coding but, rather, by the impact radius and nature each level is responsible for.
In this framework, an L4 engineer would still code a good amount, but they would focus on higher impact individual contribution work (ex: core systems, major refactors, high risk fixes, etc.). This is the level where helping plan and execute cross-team projects or major single team initiatives becomes more important. The time dedicated to some of those activities is not being dedicated to coding.
Tangible example: one of my past L4 identified the opportunity of significantly reducing his group's operational costs by moving several systems from x86 to ARM. He created an experiment, where he deployed the stacks on an ARM cluster, identified which code needed to be updated, and the expected cost reduction. He coordinated the implementation of this change with the EMs of multiple teams, coded key parts himself, and helped other engineers code theirs. End result: ~40% less platform costs! Approx. time breakdown coding vs non-coding: 50-50, I think.
This trend continues into the L5 level. Tangible example: L5 noticed that our customer dashboards were slow and hard to scale. He dove into the data and found the culprit - the underlying data architecture. He redesigned the analytics system into a fully-fledged lambda architecture and coded a reference implementation for key parts of the system. He helped convince PMs of the necessity of the change, plan the change across ~30 engineers and 5 EMs, bi-directionally aligned with engineers and helped them navigate key parts of the project. Key results: 10X faster dashboards and 30X less cost-per-query, to cite a few. Approx. time coding: 10%-20%.
Naturally, exceptions exist: I've seen L4s and even L5s who coded a lot while working on incredibly critical or foundational projects, though rarely alone.
This strategy seems to work well across many successful tech companies, including those I led. As with many things in tech, I expect there to be different ways of solving this problem. How would you do it?
PS: excellent follow up read on the "trident model", from Pat Kua - https://www.thekua.com/atwork/2019/02/the-trident-model-of-career-development/