Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my humble opinion it is not Amazon who is at fault here, but our flawed human nature. Management set goals in good faith and with honorable intentions but then people started to optimize for the numbers more than for the spirit of the goal. I’ve read someone referencing the cobra effect here and it’s a very good example of loopholes causing more harm than if no policy had been implemented. Whenever a company plays with compensation and bonuses, it’s always a tricky game.

PS my SO works at AWS and has never heard of this "practice". I wonder how common it really is. Maybe this is all click-bait. From what I’ve seen AWS hiring processes are stellar.



From what I understand, AWS does this at the org level, i.e., an org is expected to have a certain URA rate. This is not an unusual policy in the tech world.

Personally, I hate systems like this. I can’t think of a quicker way to kill any loyalty or good will I might have to an employer.

Apart from this I think it encourages bad hiring, since hey - we can always just fire em. But on the other hand, a ‘firing people is impossible’ culture has its own problems.


> In my humble opinion it is not Amazon who is at fault here, but our flawed human nature.

Good management should be taking human nature into account.


> Management set goals in good faith and with honorable intentions

If so, then they are incompetent at setting goals. The goal should be for teams to be at or below a specified attrition rate, not exactly at it.


It's management's responsibility to have enough of a clue to look at their employees and determine that they're gaming the system. If they can't do that, then they shouldn't be management.


AWS tends to have different policies from the rest of amazon (such as different promo requirements). Not sure if that's true in this case.


I recently got turned down from a team lead role at AWS and the only feedback i got was that I seemed technically strong and understood performance management in theory but had not performance managed enough members of my team. The problem i have with this is that IMHO if I'm performance managing someone it's more than likely mine or the organisations failing; we've hired or promoted someone into the wrong role, or we've created an environment for failure or something had drastically changed in the individuals life. Fortunately for me these have not really happened to any great extent but that was unfortunate for my AWS interview.

I've a suspicion that I rubbed the group lead the wrong as I asked him a couple of times, non confrontationally and from a place of genuine interest, what he did to set the direction of the group and he didn't really have any answer, still not sure what he actually does.


The promo requirements are not different? The levels are calibrated to be the same across the whole company


Former AWS dev here -- the bar is the same but the workloads can be so insane that you meet the requirements faster than anywhere else in the company (there was one engineer that made principal like 5-6 years out of undergrad, which means they would've had to have been promoted every 1-2 years assuming they were hired as an L4). I think parent comment might be referring to more lenient stack ranking policies, I never experienced any of it during my time there but then again I saw teams with 20-30% annual turnover rates so no need to force people out when they're already showing themselves the door I guess :)


>made principal like 5-6 years out of undergrad

looking at our (we're naturally not FAANG, not even close) dept recent big promotions around - a principal 6 year out of undergrad. No need for insane workloads, just great soft skills around high management people, and the lack of experience and knowledge just helps to always be in enthusiastic agreement with instead of questioning that high management's not smart, to say the least, decisions .


At Amazon, principal means you can direct organization wide technical strategy, implement the foundations and mentor others. It’s an insane bar internally.


in our case that specific person now owns all the aspects of a huge platform (~400 people), right next after the VP of our org (and being an engineer on a pet project of that VP is what resulted in such a career jump). The platform of course is just nowhere to be of any success - it is an unmanageable pile of modern sounding technologies (based on k8s of course; and you name any buzzword - we have it) done in our very "enterprisey" way - yet "we're making progress".

I actually was a principal at one mid-size a decade ago. I went there as an IC and was very clear about that, and they gave me the high level just to bring me in. Nevertheless the principal related crap - powerpointing/etc. - was creeping in, and after the first yearly vest i left, despite all the raises in the counter to keep me, for a normal senior engineer position at another place. 2 years later they tried to bring me back as a chief architect to build a new platform, and i almost went there as the project sounded great, just in the last moment right before accepting the offer i really remembered why i left - the technical work will be overwhelmed by the "organizational" work.


I have multiple friends at AWS and they work 35 hour weeks, around the same as me. With that said I’ve noticed very fast promo cycles in nearly all Tier 1 service supporting teams, both AWS and CDO.


Man I should've done my research before joining, my team was regularly pulling 70+ hour weeks including weekends for the first four/five months I was there (granted we were understaffed and behind schedule for launch at re:Invent at the time). Grateful for the experience because everything else feels like a breeze afterwards, but also definitely never putting up with that again lol




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: