Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Levels, Promotions and Salaries

daily.co

Post reply on HN
Print view View original

171–180 of 206 posts

Re: Rethinking Levels, Promotions and Salaries

#171

Post by 3pt14159 »

ldoughty wrote: post #132
3pt14159 wrote: post #78

Earlier quoted context omitted.

My boss doesn't know how much I'm paid. I like it that way. He communicates how he feels I'm doing to the people that need to know and it's working out ok.

I find that interesting, and also concerning.. but I suppose it depends on the office culture. I tried to ignore my peers and direct reports salaries when I first moved into management... I lost an employee after 2 years when another place offered him a 80% raise. At that point, I realized I couldn't count on a 3rd party to properly evaluate an employee's worth, and I started to take an active role in ensuring people…

Well, I make a lot. I'm sure my boss is aware of that. I don't know a single person that is paid this much in Toronto and doesn't have to manage others. Not even close. So maybe that's why he doesn't need to know.

Re: Rethinking Levels, Promotions and Salaries

#172

Post by pmmck »

bluGill wrote: post #157
ashtar wrote: post #146

Earlier quoted context omitted.

This is a great way to lose your best people. Or it's pure /s

Not if handled right. Remember those unimportant projects are often self-assigned as try the latest thing to see if it is useful to us, and they often get high visibility to management as cool things we want to do next. Of course if this is only treated as unimportant projects they will leave.

Maybe a better term would be "critical projects" instead of "important projects" in that case?

Re: Rethinking Levels, Promotions and Salaries

#173

Post by joshuamorton »

nerdponx wrote: post #112
humanrebar wrote: post #74

Earlier quoted context omitted.

If you felt you were underpaid, leaving is fair. I don't really understand the requirement that all bosses are paid more than those they supervise, though. I mean, emotionally I can understand feeling that way. But I don't think it's a rule of nature or something. For instance, coaches often make less than their star players. Directors and producers often make less than star actors. Hospital directors seem to make le…

I think this makes a lot of sense. Management is not "better", it is simply "different". And in terms of actual value delivered to the business, I doubt that a low/mid-level manager delivers significantly more than an experienced and productive individual contributor. Organizations need both good managers and good individual contributors. Clearly managers of technical contributors need enough technical experience to…

I agree that inherently management isn't more valuable than IC-ness, but in terms of scope (which is one, though not the only metric for value) it's hard to argue that you have more scope than your manager. They're still responsible for what you're working on. Often more competent ICs are more independent, so this is a bit complicated since a manager of an independent IC can focus more effort elsewhere, but still.

The way I see this usually at places with strong IC tracks and levels is that an L7 IC is payed more than an L6 manager, but its uncommon for the L7 IC to report to the L6 manager. You usually, though not always report to someone more senior than you, and very rarely report to someone less senior.

Also its far easier for a people manager to increase their scope than for an IC to do the same, so in some sense the advancement path is more clear.

Re: Rethinking Levels, Promotions and Salaries

#174

Post by closeparen »

deepsun wrote: post #29
parkingrift wrote: post #18

Strong disagree with basing salary on years of experience. I see almost no correlation between output, skill, and years of experience. I actually consider this an anti-pattern that actively encourages coasting.

I've yet to see anything better than years-of-experience (or years-in-company). I've worked in both FAANG and startups plenty, and personally I've seen worse outcomes from "impact-driven" OKRs, nepotism, team-surfing, than from coasting. Coasting can be fixed by firing or layoffs (which I consider a healthy lifecycle for any company). "Coasters" at least know that what they do today they might have to support for N y…

Recently I have been musing about a SlateStarCodex-ish "compensation systems very different from ours."

One is Oxide [0], which has uniform compensation across the board, explicitly with reference to this problem about how performance processes influence work and culture.

Another might be to take LeetCode-style interviews more seriously. We have already concluded that the most important criteria for whether we want to work with someone is their ability to solve algorithmic programming tests under time pressure. Why stop at initial hire? Maybe they got lucky with familiar material. Maybe they crammed and didn't actually internalize it in a stable way. We should probably be giving coding interviews continuously to existing employees. Further, since we have concluded that shades of interview performance are a good way to determine seniority and responsibilities, we could also use these continuous tests in place of the promotion process. Knock it out of the park? Congrats, you're a staff engineer now. Barely squeak by? Back to intern. It sounds facetious but it also addresses the "promo criteria distort architecture" problem and the "YOE isn't ability problem." The civil service is not too different. Officials get to the next level by passing written and oral exams.

Another might be to have stakeholders bid on talent per project. This would match e.g. the creative industry where teams are constantly created and disbanded, and your next gig is based on the department head or director’s assessment of the quality of your work or the experience of working with you in a previous project.

[0] https://oxide.computer/blog/compensation-as-a-reflection-of-...

Re: Rethinking Levels, Promotions and Salaries

#175

Post by felipellrocha »

baobabKoodaa wrote: post #134
blitzar wrote: post #124

Earlier quoted context omitted.

Telling or managing a player to kick the ball into the back of the net is a lot easier than actually kicking it in the back of the net. Telling or managing a team of 20 people to put products on shelves is a lot harder than putting products on shelves.

I like the analogy, but I don't fully agree with it. If the "product on shelf" is a basic CRUD app, then sure, managing a team of 20 people might be harder than doing the individual tasks related to putting the product on shelf, but oftentimes there are challenging technical aspects related to the product. In some cases those technical challenges might be harder than management of the team.

have you ever been a manager?

Re: Rethinking Levels, Promotions and Salaries

#176

Post by closeparen »

darkerside wrote: post #161
robertlagrant wrote: post #144

Earlier quoted context omitted.

See above - it's strange to discount management techniques for promotions and pay rises, but still use it for firing people.

I think I missed the point where parent said not to use management techniques for promotion and comp. Can you highlight what you are seeing?

We're talking about leveling and compensation based mostly or entirely on years of experience; this implies they are based only a little or not at all on performance reviews.

Re: Rethinking Levels, Promotions and Salaries

#177

Post by ipaddr »

rk06 wrote: post #158
ipaddr wrote: post #127

Earlier quoted context omitted.

Those who leave are not always the best. Those who leave many places quickly are more likely to be difficult themselves and demand more. Those who leave after many years usually turn out to be great.

Those who leave may not always be the best, but those are best will certainly leave. It makes no sense to Not switch jobs if you get higher salary and have capability to get it. In tech industry where job hopping gives significantly greater raise than yearly increment, those who switch jobs get more exposure and better worldview. While those who stay get 1 year experience 10 times. PS: Exceptions are always there

Completely understand where you are coming from. I think a combo of both can be important. Some depth at one org is important to see the results of some of your decisions/actions.

Re: Rethinking Levels, Promotions and Salaries

#178

Post by phendrenad2 »

soco wrote: post #79
humanrebar wrote: post #74

Earlier quoted context omitted.

If you felt you were underpaid, leaving is fair. I don't really understand the requirement that all bosses are paid more than those they supervise, though. I mean, emotionally I can understand feeling that way. But I don't think it's a rule of nature or something. For instance, coaches often make less than their star players. Directors and producers often make less than star actors. Hospital directors seem to make le…

Here in Switzerland, most of the non-IT people I'm talking with are genuinely surprised that for instance project managers are paid less that developers. For them just hearing the word "manager" = big buck.

Whenever I hear the term "Project Manager", and imagine all of the confusion collectively experienced by anyone who has had to explain that job, I think of Mr Burns from the Simpsons saying "Am I that out of touch? No, it's the KIDS who are wrong".

Let's call it "Project Coordinator" or "Project Advocate" or something.

Re: Rethinking Levels, Promotions and Salaries

#179

Post by ryandrake »

tcbawo wrote: post #73
deepsun wrote: post #29

Earlier quoted context omitted.

I've yet to see anything better than years-of-experience (or years-in-company). I've worked in both FAANG and startups plenty, and personally I've seen worse outcomes from "impact-driven" OKRs, nepotism, team-surfing, than from coasting. Coasting can be fixed by firing or layoffs (which I consider a healthy lifecycle for any company). "Coasters" at least know that what they do today they might have to support for N y…

A part of me wonders whether certain organizations tolerate "coasters" as a talent reserve of sorts, expected to engage when things get busy or new/interesting challenges emerge. For whatever reason, many businesses fire underperformers, promote overachievers but treat the 80% in the middle very generically. Why work to be a top 20% performer when you are treated the same as the bottom 20% performer? Coasting seems l…

I think "coasting" is a really uncharitable word to use, too. For some people, yea they really are just throwing the gear into neutral and drawing a paycheck while they play Minesweeper. But for a lot of people, they reach the point in their careers where the next step is "up" but there are very few "up" roles available. So they end up in this slugfest, competing with a lot of people for that one rare "Director" slot that opened up. And for every 1 person that rolled snake-eyes and got promoted, there are 10-30 that are thrown back to Thunderdome to compete again the next time an opportunity arises. I don't think it's fair to label these people who keep fighting for those rare promotions "coasters" just because they've been doing the same thing for the last 15 years. I've been in the Thunderdome for even longer, and I'm still "Senior Individual Contributor number 32291." Am I coasting?

Re: Rethinking Levels, Promotions and Salaries

#180

Post by JonChesterfield »

bluGill wrote: post #128
JonChesterfield wrote: post #95

Earlier quoted context omitted.

Compilers are why we can write in C++ instead of assembly. The related fields of interpreters and language runtimes are why we can write in Python. The optimising part makes languages that are faster to develop in run fast enough that they can actually be used to build useful things. Bugs introduced in that stack are horrendous to run down, easy to introduce and broad in fallout. Rather a lot of our modern tech world…

While you are not wrong, it isn't the full picture. For most projects we don't need more language/compiler performance. Most web sights are served with a handful of servers, likely shared servers on AWS or something (so that you can get full data center failure redundancy - which is probably overkill). The total cost to run the servers isn't all that much on the bottom line and so you shouldn't pay more for compiler…

This only works because you already have access to an optimising compiler and high level language implementations, likely both available for free, because other people and organisations have already paid for them to exist.
Post reply on HN