4 ms·

I wrote up a post about some inherent, fundamental contradictions in leveling / salary band approaches to structured career development. I think it’s under-app

by mlthoughts2018 6y ago

I wrote up a post about some inherent, fundamental contradictions in leveling / salary band approaches to structured career development. I think it’s under-appreciated that these systems are so inherently flawed, especially regarding meritocracy. https://managingml.substack.com/p/a-cap-theorem-for-career-development https://managingml.substack.com/p/a-cap-theorem-for-career-d...

AmericanChopper 6y ago
I've been working as a contractor for more than the past 10 years, and I'd say salary banding is one of the primary reasons I've been able to remain employed 100% of the time. A big company will be able to get some portion of the labor it requires within the bands they set out. But the more in demand the skills they're seeking are, the less likely they'll be able to convince people to work for the band rates they've set. When they encounter those situations, their only options are to hire contractors at even more expensive rates, or to not get the work done. There's plenty of reasons why contingent labor might appeal to a company, but hilariously inefficient salary banding practices seems like one of the more common ones to me.
- sokoloff 6y ago
  Or you just pay certain distinguished people well outside the typical band (or, equivalently, create a “track of one”, both of which are a version of CP). Bands are not the problem. Mindless, extremely rigid adherence to bands is the problem.
  - AmericanChopper 6y ago
    That would be one approach, but I think most big organisations would presume that it would simply spiral out of control, and the bands will end up achieving nothing. From a management perspective, if you’re trying to resource a team or a project, hiring a contractor at a high contracting rate typically works out to be the path of least resistance.
vsskanth 6y ago
Good article. But what you say might make sense in CA, but employers outside CA use non-compete agreements to avoid this type of disruption. Eventually, salary bands and performance reviews just becomes an excuse to underpay employees since they don't have to compete for your talent anymore.
aahortwwy 6y ago
Great post, thanks for sharing it.
joshuamorton 6y ago
I don't really buy your conclusions here. Speaking about Google specifically, the bands exist, but are wide enough that you can have, call it ~40% variance within a level (and actually I think this increases as you go up the ladder, so by staff it's maybe even more), and that's before things like spot bonuses (which granted aren't usually huge but can be nontrivial in aggregate). I guess in some sense you can argue that that is simply a relaxation of A, and that those companies don't have aligned compensation, but I don't think that's true. There's also the problem that, especially as you move further away from direct P&L, calculating value is really difficult. I work in infrastructure and engineering productivity. When I'm lucky, I can get an engineer-hours-saved metric, but most of the time I can't get that directly, and my work reduces system complexity, which pays off eventually in time saved or outages avoided. Systems that try to sort of directly reward performance fail for a lot of cases where that's fuzzy. It also, speaking personally, hasn't been a huge issue, and I don't see the slow-growth that the original article talks about. My compensation has been increasing on a linearish trajectory fairly quickly, and that doesn't appear to be slowing down yet. My growth (both career and compensation) is faster than many, though not all, of my peers. I know people who took 2x as long as me to get promoted, and I know people who did it 2x faster (and that's true both from 3->4 and 4->5, we'll see for 6). That doesn't sound particularly tenure based.
- jameshush 6y ago
  I'd recommend prioritizing getting those numbers. Making the time to setup the measuring/monitoring is a bit of a pain but it's worth it. I worked in the same vertical (infra/"DevOps"/engineering productivity) before I shifted to becoming a people manager. Here's some of the things we're setting up now to measure this: - Using something like https://github.com/ImpactInsights/valuestream https://github.com/ImpactInsights/valuestream to measure number of deploys per week, build times across pull requests, length of time it takes a pull request merged across the entire team, etc. - If you want to get fancier, setting up simple tracking to measure how much time running "npm install" takes across all engineers on their local machines. This could get logged in something like Datadog/Grafana/whatever graphing solution you want. - Zoom out even further. Are releases being slowed down by other teams by accident? E.g. we had a feature delayed a week by accident because the marketing team didn't know a feature was finished, in production, but behind a flag waiting for them to write marketing copy. We're currently setting up a way to track "features in production but behind a flag" in Jira better and feed that "lag time" data into our overall deployment picture. The idea being, for every task you're executing to "improve developer productivity" you should have a hypothesis with about how much time it'll save the team. If you can't get that right away, I'd move on to a task that has a better measure to it and knock that out first. If you completely run out of tasks and measurements, that's when you can take bigger bets on tasks that have more fuzzy measurements next to them. In my experience the work here never dries up though.

AmericanChopper 6y ago

I've been working as a contractor for more than the past 10 years, and I'd say salary banding is one of the primary reasons I've been able to remain employed 100% of the time. A big company will be able to get some portion of the labor it requires within the bands they set out. But the more in demand the skills they're seeking are, the less likely they'll be able to convince people to work for the band rates they've set. When they encounter those situations, their only options are to hire contractors at even more expensive rates, or to not get the work done. There's plenty of reasons why contingent labor might appeal to a company, but hilariously inefficient salary banding practices seems like one of the more common ones to me.

sokoloff 6y ago
Or you just pay certain distinguished people well outside the typical band (or, equivalently, create a “track of one”, both of which are a version of CP). Bands are not the problem. Mindless, extremely rigid adherence to bands is the problem.
- AmericanChopper 6y ago
  That would be one approach, but I think most big organisations would presume that it would simply spiral out of control, and the bands will end up achieving nothing. From a management perspective, if you’re trying to resource a team or a project, hiring a contractor at a high contracting rate typically works out to be the path of least resistance.

vsskanth 6y ago

Good article. But what you say might make sense in CA, but employers outside CA use non-compete agreements to avoid this type of disruption. Eventually, salary bands and performance reviews just becomes an excuse to underpay employees since they don't have to compete for your talent anymore.

aahortwwy 6y ago

Great post, thanks for sharing it.

joshuamorton 6y ago

I don't really buy your conclusions here. Speaking about Google specifically, the bands exist, but are wide enough that you can have, call it ~40% variance within a level (and actually I think this increases as you go up the ladder, so by staff it's maybe even more), and that's before things like spot bonuses (which granted aren't usually huge but can be nontrivial in aggregate). I guess in some sense you can argue that that is simply a relaxation of A, and that those companies don't have aligned compensation, but I don't think that's true. There's also the problem that, especially as you move further away from direct P&L, calculating value is really difficult. I work in infrastructure and engineering productivity. When I'm lucky, I can get an engineer-hours-saved metric, but most of the time I can't get that directly, and my work reduces system complexity, which pays off eventually in time saved or outages avoided. Systems that try to sort of directly reward performance fail for a lot of cases where that's fuzzy. It also, speaking personally, hasn't been a huge issue, and I don't see the slow-growth that the original article talks about. My compensation has been increasing on a linearish trajectory fairly quickly, and that doesn't appear to be slowing down yet. My growth (both career and compensation) is faster than many, though not all, of my peers. I know people who took 2x as long as me to get promoted, and I know people who did it 2x faster (and that's true both from 3->4 and 4->5, we'll see for 6). That doesn't sound particularly tenure based.

jameshush 6y ago
I'd recommend prioritizing getting those numbers. Making the time to setup the measuring/monitoring is a bit of a pain but it's worth it. I worked in the same vertical (infra/"DevOps"/engineering productivity) before I shifted to becoming a people manager. Here's some of the things we're setting up now to measure this: - Using something like https://github.com/ImpactInsights/valuestream https://github.com/ImpactInsights/valuestream to measure number of deploys per week, build times across pull requests, length of time it takes a pull request merged across the entire team, etc. - If you want to get fancier, setting up simple tracking to measure how much time running "npm install" takes across all engineers on their local machines. This could get logged in something like Datadog/Grafana/whatever graphing solution you want. - Zoom out even further. Are releases being slowed down by other teams by accident? E.g. we had a feature delayed a week by accident because the marketing team didn't know a feature was finished, in production, but behind a flag waiting for them to write marketing copy. We're currently setting up a way to track "features in production but behind a flag" in Jira better and feed that "lag time" data into our overall deployment picture. The idea being, for every task you're executing to "improve developer productivity" you should have a hypothesis with about how much time it'll save the team. If you can't get that right away, I'd move on to a task that has a better measure to it and knock that out first. If you completely run out of tasks and measurements, that's when you can take bigger bets on tasks that have more fuzzy measurements next to them. In my experience the work here never dries up though.