Levels of Technical Leadership(dr-knz.net)
dr-knz.net
Levels of Technical Leadership
https://dr-knz.net/levels-of-technical-leadership.html
7 comments
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.
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.
> If you're good at higher level competencies but don't have much experience, too bad, you're a dumb junior.
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.
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.
Why are you assuming such extremes? It's not about having 0% competency in execution, 100% competency in planning. More like you might be average at executing and excellent at alignment.
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.
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.
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
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.
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.
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.
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.
What's not unusual to see is that people that have been around longer are more likely to occupy the higher levels despite not really having any specific technical competence advantage over some peer.
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.
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.
Well, if we're going to talk about edge cases, I also see the opposite: people who are allegedly at EM or staff levels coming in for phone screen interviews and only getting a recommendation to move forward at senior level.
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.
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.
I agree that generally speaking it makes sense, but it's inflexible to deviations. I also think that level designations are largely lagging indicators of skill.
This article does a better job of explaining than I will: https://apenwarr.ca/log/20201227.
This article does a better job of explaining than I will: https://apenwarr.ca/log/20201227.
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.
> 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.
> 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"
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"
> 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.
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.
This is a sacrifice that is required for the company to exist.
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.
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.
Yeah, I agree. I would suggest the following scale:
- "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..."
- "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..."
If you're good at finding the problems but not solving them, youre great for the product side of things
There are roles other than engineers that have their own level definitions
There are roles other than engineers that have their own level definitions
What if you are great at finding problems and ok at solving them?
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.
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.
yes i've never seen ladders actually used in practice . They are only there as as ruse for management to deny ppl promotions and raises.
they'll promote the usual bootlickers and brown nosers.
they'll promote the usual bootlickers and brown nosers.
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
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 know what you're doing for the next year
You think you know.
You think you know.
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.
That approach is useful and has been discussed in works like https://en.wikipedia.org/wiki/Requisite_organization
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.
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.
Separating those who manage vs those who don't and calling them an ic misses the company wide impact an ic could and should be making. Those who manage are often labelled as multipliers but the truth is they may be multipliers or dividers within the same group. From a scale of doing harmful to everything possible -1 to 1 multiplier effect per person on average is 0 and .999 for the best.
Yeah, my VP and I have been talking about my promotion to a senior-staff level position and have been discussing with the SVP how the culture of senior-staff/prinicpals being so hands-off from IC work is a serious waste of talent. We are actively shaping my new role to be much more hands-on than other senior staffs are often expected to be.
I mean, I think you kinda need to look at historical context too. Traditionally, "leadership" meant managing people pretty much exclusively. What is colloquially referred to as the "IC route" is a relatively new way of recognizing ancillary responsibilities that employees at senior level start to undertake to "dabble" into leadership, especially if you have the more progressive view that leadership is about facilitating rather than imposing.
I think there's still value in EM roles in the sense that I feel that communication about large scale strategy tends to flow more freely among managerial-oriented roles, whereas ICs have a tendency to "silo" more.
I think there's still value in EM roles in the sense that I feel that communication about large scale strategy tends to flow more freely among managerial-oriented roles, whereas ICs have a tendency to "silo" more.
It isn't clear to me from the article, but has this ladder been implemented somewhere or is it a theoretical framework?
My issue with many such articles is that they propose and idea without having tried it in practice. Unless you have implemented this and seen it working well for a period of time, it's only "armchair leadership".
My issue with many such articles is that they propose and idea without having tried it in practice. Unless you have implemented this and seen it working well for a period of time, it's only "armchair leadership".
It’s not mentioned directly in the article but this is the typical Big Tech IC ladder and levels. Eg ones at Google, Meta, Uber, Databricks, Amazon, Dropbox etc all like up like this, including the level numbers (L6, L7 etc). Though there at small differences on the interpreting and focus points at each level.
I agree the article could have been more clear.
I agree the article could have been more clear.
this is pretty typical stuff these days for a typical well to do SaaS org.
I've seen it work well. It can help facilitate the conversation between a manager and direct report when trying to understand what the gaps are between their current role, and where they want to go next. It also helps keep those discussions aligned across different managers/directs across the organisation.
It also has it's down sides. There's no perfect solution to soft skills.
I've seen it work well. It can help facilitate the conversation between a manager and direct report when trying to understand what the gaps are between their current role, and where they want to go next. It also helps keep those discussions aligned across different managers/directs across the organisation.
It also has it's down sides. There's no perfect solution to soft skills.
What's with the unique font?
e.g. "sp" and "ct"
e.g. "sp" and "ct"
They're called ligatures [1].
Congratulations, you're one of today's lucky 10,000! [2]
1. https://www.thoughtco.com/ligature-in-typography-1078102
2. https://xkcd.com/1053/
Congratulations, you're one of today's lucky 10,000! [2]
1. https://www.thoughtco.com/ligature-in-typography-1078102
2. https://xkcd.com/1053/
Those are some really archaic and distracting ligatures though.
[deleted]
or you know, you could just write code and not give a fuck about titles :-D
Titles never seemed to matter much for many things. I think though that people defer to authority and to do a thing that requires to get other people involved seems to require blessings - from above, from your "authority" etc. Note this is completely anecdotal and that those with a special big sounding title do have sway.
Unfortunately, we live in a society.
Yeah, but that society is shaped by people like you and me.
Society is much, much bigger than two people, and that's why titles happen.
titles happen because people want to feel good about themselves. The best thing is to just let it go
Again, we live in a society. Titles are a way of communicating your role and seniority in an organization, using a roughly shared language. It's a bit naive to think that titles serve no purpose, as if everyone is just being dumb for the hell of it.
sir, this is a wendys
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