I'm in non-AWS and things aren't any better here. It is very much dependent on the manager and team, and I've been optimistic (~3 years now), but it gets harder as time goes on.
> I'm just not 100% sure about the whole PIP scene. Our service was extremely critical and we were extremely understaffed. So I don't think it applied to anyone in our org but I know of other teams who would have no issues in taking in a fresh college grad, making them do work for 6-12 months and then just randomly putting them on PIP.
Our team is over-worked and has a large ticket queue, constant sev-2 pages, understaffed, etc. - and yet they still PIP'd (and then fired) someone last year who didn't deserve it IMO.
Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them in a few months to keep the rest of the staff scared enough to overwork themselves so they can understaff.
> Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them [...]
So... Amazon has a lot of money therefore they have to resort to money-saving practices? Or is the causality the other way around? How do these two sentences fit together?
Amazon has a lot money. These practices make them additional money. If they didn't have a lot of money they couldn't afford to hire to fire.
How can they do both?
- They waste money when they hire to fire and constantly onboard.
- They make money by not staffing enough resources but by using fear of being fired to force overtime.
Maybe the hire to fire costs are justified because the savings they get by understaffing outweights the cost.
I don’t think they do, but it’s a way to smear and make all Amazon engineers unemployable by proxy. I already have difficulties finding interviews at good companies because the Amazon name implies IBM level talent instead of Google level talent.
Same. My team was down to 4 people and they put the L6 external hire in Focus (the informal coaching plan precursor to PIP) and he left. And we own critical services.
> The thing I've noticed at Amazon is that not only are the pre-existing conditions awful, but nobody has any interest or willpower to fix it. Everyone will happily vent to you and tell you how awful things are, but any suggestions to fix it or make things more efficient (even if the fix is very simple and requires low effort) will be met with hostility. And I'm not just talking tech issues, but also process/workload issues.
In my case, direct management seems interested in these issues and understand there are problems we need to fix, but ultimately the feature/product launches always make it into the sprint and the larger bug fixes never do. It's very much "actions speak louder than words".
In at least a few orgs I've seen the switch was to RDS (usually postgres) instead of dynamodb because they couldn't justify an entire redesign of the schema at the same time as the switch. It was a huge effort with a lot of late nights especially at the very end of the cutover.
At least in large companies it can be pretty hard to actually find the good teams among all of the noise. I've tried to keep my eyes open for them but haven't had any luck yet.
Wow reading all these stories about Apple really is eye-opening, as I've only usually heard these types of things about Amazon before.
I say that because I work for Amazon, and my work environment is pretty bad by my standards (my team cuts a lot of corners, we are given unrealistic deadlines by upper management, our on-call is paged at least 10 times a week, we have a huge backlog of tickets and bugs that we can never prioritize, and it is overall a very stressful environment.) I guess it can always be worse...
I'll add: even if he is speaking for AWS with some authority, he certainly doesn't speak for the rest of Amazon. I've seen some teams with _really_ bad practices (security and otherwise.)
As for your comment about the writer, the entire website feels very "off" to me - no author listed, no "About" page with names/links, nothing to give this credibility. I did see the link to the cofounder's Twitter page, so at least there is someone behind it, but it is pretty well hidden.
To be fair, with the way Amazon's TC/RSUs work you always have some left unvested - I don't know if it is possible to quit "fully" vested (unless you're referring only to the initial grant.)
More specifically they don't support CloudFlare's DNS. The operator of Archive.(today/is/md) has decided to specifically provide bad IPs when the EDNS client subnet extension isn't provided, which CloudFlare's DNS doesn't provide due to privacy concerns.
> I'm just not 100% sure about the whole PIP scene. Our service was extremely critical and we were extremely understaffed. So I don't think it applied to anyone in our org but I know of other teams who would have no issues in taking in a fresh college grad, making them do work for 6-12 months and then just randomly putting them on PIP.
Our team is over-worked and has a large ticket queue, constant sev-2 pages, understaffed, etc. - and yet they still PIP'd (and then fired) someone last year who didn't deserve it IMO.