3 ms·
> [Leveling] conflates career development and salary negotiation. It encourages a mindset of saying, “what must I do to make L10” when you want to say, “I want
by n4r9 2y ago
> [Leveling] conflates career development and salary negotiation. It encourages a mindset of saying, “what must I do to make L10” when you want to say, “I want a $10K raise.”
It's not obvious to me why this is a bad thing. I agree that incentivising a box-ticking mindset discourages ownership and initiative. But for software engineers I feel like there has to be some methodical (and transparent) way for raises to be assigned, and for it to relate to skills and traits. Otherwise you can easily end up in a situation where people are rewarded for being bolshy and savvy rather than valuable to the company.
Am I missing something here?
- WJW 2y agoI think that what you are missing is that "what must I do to make L10" and "what is valuable to the company" are typically somewhat orthogonal. A prototypical example is that almost every career ladder out there mentions things like "impact" and architect/systems design work rather than often more valuable maintenance work that keeps current systems running. In addition, measuring the contribution of any individual to a team effort is always difficult, in some cases pretty much impossible until years later. This means that it is always possible to game such career frameworks by focusing only on the things the framework rewards and skipping everything else. In short, encouraging people to get to the next career level in a well-defined framework is exactly the type of "situation where people are rewarded for being bolshy and savvy rather than being valuable to the company" that you mention as being undesirable.
- hiatus 2y agoIf following the framework does not provide value to the company, the framework is obviously flawed.
- throwaway98797 2y agothe frameworks are always flawed the best leaders know this
- alistairSH 2y agoSure, but does that mean the framework shouldn't exist? Something can be flawed and still provide some value. In the case of leveling, I'd suggest the levels are guidelines and not policy. As soon as they become policy, management cannot work around them adequately, and they begin to detract value. For example, at my employer, we have levels (within job families, I haven't seen a level grid that has engineers and personal assistants). But, I've never had to tick every single box to get an employee promoted. I have to make my case, and I do use the levels as a guideline, but I've never felt it necessary to absolutely follow every item.
- ketzo 2y agoWell, that's sort of the author's point -- every framework is focused on something other than simple salary numbers, which definitionally means it is focused on something other than the dollar value provided to the company. We recognize that they can still be a useful tool, because 1) assigning dollar values to employees is an inexact science that's hard to standardize over an organization and 2) ICs like at least some direction about what they need to do to be eligible for more money aside from just "provide more value"
- madeofpalk 2y agoI think the problem that developers may feel is that they want to earn more money for being a better developer, but not nessicarily accept more responsibility or spend less time developing code. I do agree with you that clear progression frameworks are a necessity for transparency and goals for developers, but some may feel daunted by a jump up meaning they don't get to write as much code if L39 (or whatever) starts including responsibilites that pushes you into meetings and convincing.
- margorczynski 2y ago> I think the problem that developers may feel is that they want to earn more money for being a better developer, but not nessicarily accept more responsibility or spend less time developing code. Well the problem is some people don't get there is a limit of how much impact and additional revenue you can create for the company by writing better/more code. And that would serve as a basis for paying you more. The thing is a guy helping out via mentoring 10 other people or recruiting better talent will create much more impact on how the company functions than if he wrote 2x better code or 2x faster. There is simply in almost all engineering effort a hard limit of how much a single person can contribute.
- betaby 2y ago> The thing is a guy helping out via mentoring 10 other people or recruiting >better talent will create much more impact on how the company functions than if he wrote 2x better code or 2x faster. There is simply in almost all engineering effort a hard limit of how much a single person can contribute. Very debatable. Not at all true where I work ( worked ). Better code clearly larger impact on larger timeframes ( think 5+ year ) that perpetually retraining incoming juniors.
- hawk_ 2y agoThis line of thinking applies to creating widgets on the assembly line but writing code combined with solving the right problems can totally have 10/20 even 50x impact. Automation can be levered up quite well with the right setup.
- Moto7451 2y agoPay and rank have a connection but not a direct connection. What is the value of your work? Is your impact worth millions to the company? Is it worth just your salary? Are you in an overhead function that enables the rest of the business? Do you work on just new business ideas that have no value now but maybe a lot later? Can you do things that others can not or will not? The answers to these questions and your ability to negotiate will dictate your pay. The fact is that being savvy and being able to navigate politics/being well liked, intentionally or otherwise, is hugely important. Most companies don’t make it particularly clear how to progress or how a manager should compensate the team aside from a rough rubric on how to get there. Most years an HR BP says to me “you have a X% budget, we recommend an (X - 2)% COLA and the rest is for your merit raises.” At some places they just ask for a stack rank and come up with the number. In either system, demonstrated effectiveness and willingness to work well with people (aka being savvy, political, likable, full of BS, etc - pick your favorite) affects your ability to get more than that Cost of Living Adjustment. When it’s promotion time, a good manager will make sure your skills fit the role. A bad one just picks someone based on their biases - positive in your favor in the short term, bad for your career if you never catch up to what is needed to do the job. Now this is the time to draw the line at pay vs rank. Most of leveling and rank is about org design and you can be a Director making 70K or a Director making 300K in the same type of software role in the same vertical. Leveling is an HR and management thing. Value is what you provide and should be compensated for. Bands are there to keep things from being completely insane. Levels are a guide for what should be. If you were able to change your title at work to “Professional Enthusiast” and your level to L-1, but did all the same work and were just as effective, would you want your pay to be any different? Again, let’s differentiate value and compensation from the rest of the structural stuff. These management constructs are checks and balances on both good and bad managers alike. Even if you do a great job as a manager and someone is ready to be promoted, your HR BP can have the bad news that there is no money for that promotion and to assign no new responsibilities (“no free consulting” as I have had to tell my reports in this situation). Conversely the money could be there but the space for the role is not. Do you really want to work somewhere that has 1000 people and 100 VPs? Who exactly is in charge? Is it VP Tom who is a peer of VP Jimmy who reports to VP Marry who reports to SVP Sarah? Heck no, just break the bands. Every time I’ve had a long tenured Staff/Principle engineer they’re sitting at 25% over what the band says they should make and no one in HR or the SLT ever complains. They see that and they know exactly who that person is. In turn, all of this exists to solve the problem of org design and hierarchy. Leveling is a tool against title inflation. Need to restrict movement into senior management? Get pickier in your leveling. Need to retain people? Give them a bonus structure or widen bands. Titles are nice and all but they don’t buy private school tuitions, sports cars, and fancy vacations. My L4 employees that could afford a new condo and a vacation to Bali were never all that upset they were never going to see L3 and L2 due to org design constraints. I myself am a slightly funny example. I moved from a multinational based in Europe to a small software company in California. My title went from Director (L3 there, Senior directors and in between to VP got point numbers) to Senior Manager (L4.X on the old scale but an effective L3) and my span of control from 30-60 to 6. My job is basically the same except for the number of people in my span of control (in the former job the same number of Managers and Staff engineers reported to me directly). We don’t have a CTO and there are two VPs where one has a “Head of” title. There are a couple Directors as well (call them effective L2 here). Effectively my title has changed but my level has not. The pay also went up a little bit with the move. There is really no where for me to go in this hierarchy since we’re pretty small. If/when they add a CTO, down the ladder I go, a CTO level is added, and more restrictions are placed to stratify the leveling to match the stratification of the jobs. What will a CTO do over the current Head of Tech? Not sure as my skip level does everything all the other CTOs I’ve worked for has done. I’m sure they’ll come up with something for my current Skip Level to stop doing though. In some companies I’ve worked and famously at Google, you have ICs that are at the VP level, by either title or level, that aside from having to go to a few mandatory Senior Management type meetings are exceptionally well paid Staff/Principle engineers. There’s nothing wrong with this so long as the title is not abused and the value is there. It tends to look crazy though. Why do these situations exist? Someone needed to pay them X to get into the business and X happened to be in the band for VP. Or, they were part of an acquisition and actually stuck around. They needed some significant title and to report to the CEO and it happens that VP is the currency available for that even though they’re not doing that work. At my last job we didn’t do this and at one point a CTO of an acquisition actually reported to me, a Director. It’s the holes in the way things work that best betray that value and title are not directly connected but management come as close as possible just to make it possible to figure out what the heck is going on at a glance. In turn, ask for that 10k if you think you’re worth it. It may be easier to get it than to get the level bump.
- mattbrewsbytes 2y ago> Otherwise you can easily end up in a situation where people are rewarded for being bolshy and savvy rather than valuable to the company. This is how it works though. If you have someone that is quiet and does amazing work but doesn't seek out promotions and doesn't actively market their accomplishments then it could happen that they will lag on salary over time. If there are good managers advocating for their people then this will happen less. Its a really simple conversation for a manager to have with their mgmt and HR about person X's salary is behind market, Y and Z are in same title so I think we need to bump them up a little to keep pace. A good organization will recognize that and help make something happen. Bad organizations will have an attitude of not doing anything until its too late. If you work in a bad organization then the path to get raises there is to do the work yourself, go out to the market, interview and get offer(s) and bring them back and/or just leave. I say good/bad organizations but really its not binary, there are situations companies may be in where raises or market based increases aren't possible, there might be bad executives but good managers, etc. YMMV.
- munificent 2y ago> If you have someone that is quiet and does amazing work but doesn't seek out promotions and doesn't actively market their accomplishments then it could happen that they will lag on salary over time. This is a win from the business's perspective. They are getting greater value for lower cost. In my more cynical moments, I sometimes suspect that tech companies deliberately target the sort of low self-esteem perfectionist types for which this behavior is common specifically because the company sees an arbitrage opportunity between what the employee is worth and what the employee believes they are worth.
- SR2Z 2y agoThey absolutely do, but those companies end up getting labelled "burnout factories" like Applied Intuition or Scale AI and as a result have trouble both recruiting good seniors or retaining their juniors long enough for them to become senior. At the end of the day, companies run by adults treat their employees like adults and don't try to stiff them out of a misguided desire to save $100k over three years.
- re-thc 2y ago> It encourages a mindset of saying, “what must I do to make L10” when you want to say, “I want a $10K raise.” > It's not obvious to me why this is a bad thing. In most cases, level isn't the gaming type level. Level these days is more like different jobs. What used to be analyst, architect, tech lead etc are all disguised as "level". As you rise in levels you might code less and focus on system design, coordinating, mentoring or something else. Is it really "career development"? It's moving sideways. > Am I missing something here? Yes, reward people for ownership, and getting better at their job. That's not what the current level system is.
- zeroonetwothree 2y agoI guess it depends on where you work. I’ve moved up four “levels” since I started and I basically just do the same thing. You could argue I should have been the higher level from the start and it took a while to get recognized.
- alistairSH 2y agoThis varies by employer. At my employer, we have several job families that encompass "software developer"... software engineer, cloud engineer, architect, and technical fellow. With the two engineering roles, there are levels... software engineer I, II, III, Lead, Principal. Architect starts with more seniority... architect (roughly equivalent to to Lead), principal architect. And technical fellow is "director level" - basically a terminal spot for ICs who are really good at building software but have no desire to manage people - they typically report to a VP or director - they do have lots of meetings, but they're also setting the technical direction of the company for the long haul.
- guappa 2y agoTo get promoted you must just pander to your boss and completely ignore what your job is supposed to be and what the company needs.
- surajrmal 2y agoThe higher up you go the more important it becomes to make an impact to teams outside the purview of your boss. So I'm not really sure this holds.
- grumpy_coder 2y agoin this context 'your boss' is usually a level or two above your direct manager on org chart Take it as the most senior person you can get regular face time with, this also needs to be gamed.
- guappa 2y agoI thought it went without saying… That's how you get promoted over your boss and become his boss. I've seen it happen.