Live data from Hacker News

Amazon Pip Horror Story

linkedin.com

361–370 of 771 posts

Re: Amazon Pip Horror Story

#361
post #311

Earlier quoted context omitted.

> So if someone is too good for your team, you put them on pip. They are going to leave anyway, so putting them on pip does the least damage to your team. This sounds like a lie people tell themselves after being PIP’d. Engineers have an average tenure of 1.8 years. You can’t guarantee you’ll hold together anything. No manager PIPs someone for just being TOO good. It’s already difficult enough to find competent peopl…

^ found the boss of the guy in the post

Never been a manager in my life. I think the biggest problem most engineers have is not understanding how the systems around them interact re: company and management.

Know the rules of the game you're playing deeply or you'll keep losing.

Re: Amazon Pip Horror Story

#362

Some people meet this with a healthy level of scepticism, which is great. However I used to work at Amazon, working on the performance evaluation and HR tools used within the company. It was a couple of years back, but I am fairly certain that the same tools are still used, given that all of them were developed from scratch. At the time it was in line with the company's PR of removing its toxic work culture. It's wor…

Some people meet this with a healthy level of scepticism, which is great. However I used to work at Amazon, working on the performance evaluation and HR tools used within the company. It was a couple of years back, but I am fairly certain that the same tools are still used, given that all of them were developed from scratch. At the time it was in line with the company's PR of removing its toxic work culture. It's wor…

I wish I had realized your comment was better spaced before slogging through the previous text brick.

Re: Amazon Pip Horror Story

#363
post #259
post #223

Earlier quoted context omitted.

700 a day??? Why did you undercharge by so much. I know the EU dev market isn't great but those are rookie numbers for "danger money." Three of the "retired, then handed enough money to unretire" COBAL guys at my old place were doing 2500 a day.

Where do you live that 700€ a DAY is low pay? It’s, that’s MORE than 700$ a day, not less. Consider that most parts of the world have lower cost of living than the Bay Area.

Standard day rate for any software contractor in London at the low end four years ago.

Probably higher now.

Re: Amazon Pip Horror Story

#364

I've been an Amazon SDE and an Amazon SDM. I enjoyed my time as an SDE, luckily free from these horror stories. After having been an SDM, I understand how these horror stories can form. Generally, Amazon has two minds about performance management. In written documentation, it's all about whether your reports meet the role guidelines. The written documentation is solid. They share how to evaluate people objectively an…

> As a manager, you get verbal (never written) lashings from your manager and skip manager to put the lowest performers on performance plans that ensure that any attrition counts. As soon as you capitulate, your lowest performer is now considered a low performer.

Clearly, I'm preaching to the choir here, but... I am constantly amazed at companies that do this. Effectively, they're incentivizing their workers to sabotage their coworkers. It is in every worker's best interest to make sure their coworkers perform as poorly as possible; ie, you don't need to be faster than the bear...

Long term, that seems like a fairly straightforward way to make sure you get poor performance out of your workers.

Re: Amazon Pip Horror Story

#365
I think the PIP quota is not necessarily evil. Amazon is a huge company. Like every big company, you'll have many coasters. With everyone working remotely it can get even worse. The problem however that the PIP quota is not a secret anymore, most employees know it exist (thanks to Blind). So it puts unnecessary stress on good employees who will never get PIPd . I think Amazon need to modify the plan in such a way that it's still effectove in removing coasters and bad performers, without stressing out everyone else.

Re: Amazon Pip Horror Story

#366

Earlier quoted context omitted.

> But some people pretend that’s how all their work is, when in reality they take a week to fix a css misalignment, or take a week to refactor some simple python script and add one new command-line argument, and they average 50 LOC or whatever. You already know what the problem with these people is (e.g. they can take a week to add a new command-line argument). Tying that to the LOC count is counterproductive. Shitty…

> Shitty managers like you That's rude and against HN guidelines. Don't make this personal. I'm not attacking you. You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection,…

> Don't make this personal. I'm not attacking you.

I am sorry for the adjective, what I meant was "extremely incompetent". That is still harsh, but hopefully conveys my opinion regarding your grasp of management in a more objective manner. It's not meant to be personal, I would say the same thing about someone attempting to use the OCaml compiler to run a Python program, and telling me that's how they do things at their daily job.

> Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?

I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.

> As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into?

Is this person engaging at all with their teammates? Have they been active on design docs or architecture? Have they been responding to queries from sales engineers? (a lot of time at an old job was literally telling Sales "yes, our product can do that"). Have they been maybe going through a big life change?

Without all of these, it's not possible to get a complete picture of why there is a problem. And a lot of them are more specific and better questions to ask than "how many lines were in the diff?"

That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".

> he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).

Since you have shown precisely this in your post (e.g. you didn't say anything about his lack of design or documentation or engagement with teammates; all of which I would certainly expect at that level), I think you need to reexamine your worldview, or at least the way in which you present it.

Re: Amazon Pip Horror Story

#367

I've been an Amazon SDE and an Amazon SDM. I enjoyed my time as an SDE, luckily free from these horror stories. After having been an SDM, I understand how these horror stories can form. Generally, Amazon has two minds about performance management. In written documentation, it's all about whether your reports meet the role guidelines. The written documentation is solid. They share how to evaluate people objectively an…

These kinds of examples are great illustrations of how damaging stack ranking (and most other performance evaluation systems) really are. Instead of focusing on improving their team's performance by reducing the friction inherent in any corporate bureaucracies, this manager is forced to spend time playing Machiavellian games that only serve to reduce effectiveness and engender an anti-productive spirit.

An illustration of why these performance evaluation systems are always going to produce statistically irrelevant results was the Red Bead experiment[0] designed by the late, great W. Edwards Deming.

[0]: https://maaw.info/DemingsRedbeads.htm

Re: Amazon Pip Horror Story

#368
post #139

This comment killed me : Will Ye Will Ye Engineering @ Cohere (cohere.io) 5mo Back when I worked at Amazon as a software engineer, the CRAZIEST thing happened to me. Here’s the story… I was working from home with my girlfriend (at the time), when suddenly I get an urgent ping from my coworker: “Our service is experiencing a SEV 2! We need all hands on deck!” Uh oh, our team’s application has gone down! However, as I…

Lmao this is great because on my "virtual on-site" final round of interviews at Amazon, the fire alarm of the person who was interviewing me went off. She switched to audio on the call and continued to try to work through the little coding challenge as she was shouting implementation details above the echo-y wails of a fire alarm raging in a crowded stairwell. Baffled, concerned for her safety and bewildered by her p…

My apartments fire alarm went off during my virtual on-site with Amazon too. There was about 10 minutes left and the interviewer said I should go and he had what he needed. Got an offer the next day!

Re: Amazon Pip Horror Story

#369

I've been an Amazon SDE and an Amazon SDM. I enjoyed my time as an SDE, luckily free from these horror stories. After having been an SDM, I understand how these horror stories can form. Generally, Amazon has two minds about performance management. In written documentation, it's all about whether your reports meet the role guidelines. The written documentation is solid. They share how to evaluate people objectively an…

Lazy? It seems like you were not doing the job Amazon wanted you to do but rather some other job that you decided was better to do.

I think you did the right thing. But to me it seems the other managers were doing the job amazon told them to do, not being lazy.

Re: Amazon Pip Horror Story

#370
post #356

Earlier quoted context omitted.

> Engineers have an average tenure of 1.8 years. You can’t guarantee you’ll hold together anything. No manager PIPs someone for just being TOO good. It’s already difficult enough to find competent people. Source?

This is a secondary source: https://buffer.com/resources/employee-tenure/#employeetenure... The original source from Paysa seems to be down (the entire site looks down). Edit: It's all employees, not just engineers, but I don't think engineers would differ too much.

5 years old, not just engineers, and doesn't contradict PIPs happening a lot. A PIP control isn't going to affect the median a ton, but can still be problematic.
Post reply on HN