Hacker News Reader

Comment by MAGZine | Hacker News Reader

A lot of what's in here reminds me of what we do at PlanGrid, and as someone who has been around to see our system evolve (and add my own feedback to it), I generally agree with the principles that it lays out.

There is one thing that bothers me here though.

> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.

To some extent I agree with this. The part where I don't agree with this principle is that it's essentially saying "do the job of position XYZ, and after you prove to us that you can do it, we will recognize and pay you for it."

If people are taking on additional responsibility and having a bigger impact, pay them for it. Maybe Square does, but normally comp+promotion go together and so I'd be interested to hear evidence to the contrary. If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)

View on HN

That’s unfortunate. As a small business owner, I can understand the business side of things — it can be hard to maintain profitability when someone gets promoted if they aren’t yet able to do all the skills of the job but get paid for it. I wonder if that was part of the strategy — not all the responsibility was added at once to transition?

We handle this a different way - when someone is promoted, they are given a chart of new responsibilities, expectation timeline and a small raise. Once they completely train into the role, which can be anywhere from 3 weeks to 3 months, we give a larger raise. Again this is because we cannot actually afford to pay for work not being done. It seems people like the acknowledgement, clear expectations and reward when they’ve made the cut.

I like your method here - it is a good "carrot based" solution.

What's great about this is you're hedging your bets (prudent) while acknowledging the worker's needs as well. The problem without some kind of middle ground like this is that it reeeeeally feels like getting screwed when you're working above your pay grade for an extended period of time without explicit acknowledgement. I've had a lot of unhappy friends in roles like that where they were doing team lead / manager stuff and getting jerked around by HR and their boss for months or years. Now they're hypersensitive to anything that smells remotely like that experience. I like how you're making a public commitment but making sure to manage your risk. It's a great compromise.

I hope your friends have had better outcomes since. A good thing to protect yourself as a worker is to get a timeline or plan of action or growth as soon as new responsibilities creep in — if the company had the intention to promote, they will appreciate a clear path, of not, they will push back.

I honestly think this mindset creates what I call "The Reverse Peter Principle". I've seen this happen when very inexperienced leadership implements this system based on hype from other companies. You end up having a lot of engineers doing random stuff that's not part of their job description just to try and get noticed/promoted, and nobody is punished for shirking current duties as long as they aren't just completely slacking off or something. You stop getting rewarded for doing the drudge work and crushing your current role, because you start focusing on the future over the present.

I think it all mostly boils down to skilled versus unskilled managers and internal career planning. If a manager is promoting people who aren't able to execute on the new role more often than not, then they are bad at recognizing when people are ready for more responsibility, and they should work to improve that skill while also working to plan things better with their reports and set expectations. To me this doesn't say that there's a fundamental problem with the system that needs to be alleviated through process change.

And on the flip side a skilled manager would be better able to keep everyone on task in their current role even while they are planning/demonstrating for the next role, if you're doing the "no peters" thing.

I worked at a startup that did this, but with one major difference. If you were interested in a promotion, you were given a set of new responsibilities explicitly that you could take on on a trial basis. If, after an evaluation period (typically 3 months) it turned out that you had executed on those responsibilities, you would receive a promotion retroactive for those 3 months, including the pay for those. If you weren't able to execute on those new responsibilities, you were left in your current position.

It has some interesting tradeoffs vs promote on a trial basis and then demote. Whether it's a good idea probably depends on how well the responsibilities and evaluation process are laid out (in that company's case, not so well).

My anecdotal evidence of the contrary: I was hired to replace a junior developer at my employer about 2 years ago. When my teammate left (team of two), I was basically handed over the entire mobile app. I even built and deployed an entirely new tv app by myself.

Our dev lead, hired months after me, has been promoted to CTO and even our sole graphic designer, hired many months after me, went from "Graphic Designer" to "Lead Graphic Designer."

So the takeaway here is classic: As an employee you are seen as a cost, and your boss will gladly let you take on the responsibilities of "Lead XYZ" and pay you as "Junior XYZ" if you let them. I unfortunately let them, so I'll cut my losses and chalk it up to things I learned in my early 20s. Could be worse.

> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.

I think a big part of the problem is the difficult position managers are in when they consider promoting somebody. I've never seen anybody get demoted, even after failing to meet the expectations of a new role. They're either left in their role indefinitely, moved to a less important project, or fired. As a manager there's a lot riding on promoting somebody if my only corrective option is to give them up, especially since they're likely good in their current capacity if I'm considering promoting them. If I want to be absolutely sure, my least risky option is to have them do the work for a fraction of the pay to prove that they can do it. This also helps prove to their peers how capable they are so I'll face less backlash from people who would otherwise argue that they deserved the promotion.

If demotion was common practice it would guarantee indefinite accountability and increase managers' risk tolerance when considering whether or not they want to promote somebody. Realistically I think employees would leave in droves if a company started implementing this over night, but it does seem odd that such a potentially useful course of action isn't even on the table.

> The part where I don't agree with this principle is that it's essentially saying "do the job of position XYZ, and after you prove to us that you can do it, we will recognize and pay you for it."

Google's system worked like that. What they don't mention is that there is a pay range for the various promotion levels, and if you're on your way towards a promotion, you're also on your way to the top of the pay for your current level.

So you are not really sacrificing a ton of pay to be "almost" ready to be promoted. (But the top range of the next level is always pretty incomprehensible to someone at their current level.)

Agreed. This is especially problematic when pressure is put on managers to limit promotions. One friend works at a company where there's some sort of promotion quota. He put one deserving person up and was told other people deserved promotion more, so hopefully the promotion would happen in 6 months.

Not only does this serve to underpay people ready for promotion, but it makes it harder for them to move elsewhere. If they're working at level X but have the title/pay of level X-1, then they'll have a much easier time finding a job at X-1, which effectively resets the promotion clock.

This is pretty much every company. If everyone starts performing at the next level, you can't promote everyone, right? And plenty of things can squish your chances at promotion, like being somewhat unlikable in your group.

I think a better bet for spending your extra energy is often a side-hustle, like contracting.

Why can't you promote everybody who's performing at the next level? If they're delivering more value, they should be paid for that.

This is all based on the toxic and feudal idea that there should be a strict hierarchy of authority and pay that is narrow at the top and wide at the bottom. Each layer of employees should have a smaller layer of higher-paid overseers, going all the way up to the king (CEO).

The side effect of a promotion quota that managers who have the knack for hiring more talented people then other managers may hit the same limit as managers who hire a terrible team.

We have a very similar system here at http://www.synacor.com, and it works really well. The "Promotions don't unlock new responsibilities" thing actually has a big upside: you don't come in the day after your promotion and have the chance to fail at your new job, you were succeeding at it already.

The downside is that it really relies on EMs to work hard to make sure that ICs have clear, measurable plans to advance. At Synacor, there's a standard format for how these plans work, and all plans get review from senior managers, so it works fairly well, but a vague plan or one filled with details that are easily overcome by market changes will usually fail and the individual will not be promoted. It can also be challenging because, at higher levels, the plans often include improvement in multiple areas -- say, improving development skills, but also taking on more mentoring. If the developer learns and applies new skills well, but is having a hard time with mentoring, that will delay the promotion, which can leave a frustrated dev whose promotion is delayed.

It does essentially eliminate the Peter Principle, however -- people who are about to get promoted beyond their abilities will discover that before their promotion, and they'll stay in a happy spot.

I agree with you 100%.

But:

> If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)

The answer is: because they can.

> If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)

Bonus and refreshed RSU's does the same, isn't it?

Absolutely!

I agree with this concern - one of the most common complaints I hear from my friends and coworkers is that they keep getting extra responsibility handed to them, but never actually see the promotion. There is an incredibly delicate balance between motivating people to take on new challenges and discouraging people by not giving them enough in return for it.

The best way to handle this situation (for the employee) is to just sidestep the problem and offer the increased salary and promotion upfront with the new responsibility. There is the additional benefit of internal visibility - if somebody is taking on extra responsibility, it is able to be communicated to the whole team, dodging the common issue that engineers face of not knowing who in their organization they should go to for help/mentorship.

The thing is, I'm often happy to get extra responsibility on its own; it makes the work feel more meaningful.

In this context, I view responsibility as more of a level of operating rather than just "more work". For instance, I'd be very happy to mentor a more junior employee it's not something I'd expect a promotion for.

That's obviously very different than if my on call hours were doubled. Doing twice as much work at my current level is different than doing my work at a higher level (which I almost always want to do).

I'd much rather get called junior while doing senior level work than get called senior while doing junior level work.

Because it’s hard or often even impossible to demote someone. Compensation/title change has only one way (up) so it makes sense to give more responsibilities first to try it out and if it doesn’t work out (on either side) then the employee can go back to their previous position without any loss of face. Although I do think that 6 months is too long, a trial period of 30 days seems more fair to me.

One way to look at it is that you found a management need and filled it. Then you get the job. You created a new job! The trick here is being recognized for it eventually.

If you are backfilling a role though then it can be annoying to not be paid up front even in a probationary period. The crappy part is having to do two jobs but the trick is to start delegating your IC work. So the old saying is that a good QA engineer automated their work away. A good manager manages their work away. Debating works only so far though without authority so you have to develop authenticity and street cred.. or enlist a few interns.

you are (we all are?) confusing promotion as tournament with promotion as payment for services and promotion for span of control

An engineer who stays an engineer will want to increase in skills and experience and be recognised as such through increased pay

An engineer who wants to get the top jobs in management will want promotion because there are scarcer fewer positions as you go up the ladder - they are deferring their pay for a hope of massive tournament winning payouts.They would be well advised to avoid having direct responsibility for greater control (ie approving the change is ok, changing the feature flag yourself bad)

An engineer who wants to stop being an engineer and mentor others (and fight the idiosyncrasies of the organisation) will want promotion with the added responsibility

If your pay and promotion strategy is not aligned with these then problems will result

Reply on news.ycombinator.com