Amazon Pip Horror Story(linkedin.com) |
Amazon Pip Horror Story(linkedin.com) |
I have friends with horror stories about Sr. SDMs going behind their back to put down names they fought to save. Imagine that SDM now having to tell that report they're at risk of being fired at a performance review.
L6 SDM is the most difficult job at Amazon.
---
SDM - Software development manager.
L6 - Entry level for the role (L5 SDMs exist, but are more rare).
"Here is a dev good enough to get through your screens and panels, they will be keeping their actual job, but will make enough appearances to pull the secondary salary for whatever period time you need before your team is required to lose someone to attrition"
I really doubt that companies raise the average with stacked ranking.
The real reason tech companies use agrressive hiring (and firing that funds hiring) is to steal the most possible fresh IP from competitors (in a legal way).
This is all anecdotal of course, but my experience in working closely with the Smart Home side of Amazon makes me not want to work at Amazon.
If you're a workaholic, you'll do well. If you aren't, you'll hate it.
Again, just one guys POV.
Especially with new grads, they've lowered the bar and stopped doing interviews since it's so hard to hire, that there's a lot of people not cut out for the job so they rely on pip to calibrate quality.
Good luck hiring into a toxic workplace culture, Amazon recruiters!
If this happened in the US and the warning came from managers at Amazon, wouldn't this be an infringement against protected concerted activity and thus illegal?
Perfect example of betriebsblind
This may have happened, but doesn't align with my experiences at Amazon. Maybe things are different based on what org you're in.
My team's senior engineer he told me that I was nowhere near under performing during the last org-wide performance review. I received great Forte feedback that year. All of the teammates that I had talked to, and my former manager who was now at another AWS org, told me the situation seemed suspicious especially due to the timing.
I got out as fast as I could after my manager said that I was under performing. I applied to a handful jobs, interviewed, received an offer, and gave my two weeks notice all within 3 weeks of the start of events. Now I'm at RStudio [1] which pays about the same as AWS but has a significantly better culture while still being able to work on interesting projects.
That experience was pretty terrible. My team and former managers had all given me consistently positive feedback. There was always something I could improve, but overall I was a good engineer. My interactions with this manager still make me question if I am competent which isn't the best feeling.
I had a fairly positive experience at AWS up until this chain of events.
[0] https://www.theverge.com/2021/7/9/22570579/amazon-performanc...
Or Polynesian infrastructure project.
It's all a matter of perspective in planning.
(although to be fair pip and the python package ecosystem has come a long way in the last few years)
So - curious; where does that break down?
We claim to, but at the end of the day want someone else to do the standing behind them while we go back to our lives. And we don’t want whistleblowers around as we fear that we will be their next target. Whistleblowers, in their effort to restore trust, become automatically untrusted by large swaths of society.
Naming makes you persona non grata to a lot of people.
Heck I'll stand behind my words. If you ever apply to a company called Anduril. Watch out for a childish manager named Calvin Hareng. This MF: https://www.zoominfo.com/p/Calvin-Hareng/-1964480350
Anduril is hiring and if you're coming on board watch out if he's going to be your manager. He indeed PIPs you if you try to switch teams, just like this amazonian ass hole.
Unless we can know for sure, or at least from a less biased source, we probably shouldn't doxx the manager?
Maybe the service leaves the manager anonymous until the review amount crosses a certain threshold... 3 to 4 guys calling him out?
Submit this to ycombinator!
We are talking about people in the top 8% of the income bracket in US. Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood. If you have Amazon on your resume, no matter what, you will have no issues finding another job, because the acceptance rate by itself to Amazon is <10% of all candidates, which acts as a very good filter and indicator for other companies that your more competent than a large percentage of work force there, so you automatically get a shot at an interview and likely a job offer if you are actually competent.
The biggest drawback of something like this is maybe having to wait an extra few months before buying that sweet BMW M3 that you wanted.
If anything, this kind of stuff should be viewed as games, because that's all this is. Supply/demand of labor mixed in with a few political and psychological things. The manager is not even close to being an asshole, he is just playing the game like all the employees are. Lets not pretend that the majority of people wanting to work at Amazon care enough about changing the world, they just want that MAANG salary.
>> Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood.
Can you provide source for this claim?
Firing people and putting them on PIP is just a game because amazon is such a great company to have on your resume? It's just a game because his livelihood is not effected?
What universe do you live in?
Let me tell you about how the world works. If you fire people for trying to transfer teams. If you lie and make up stories about performance because someone tried to transfer teams. You're an ass hole through and through. No one is being hated here. Just being called out, and people are expressing their extreme dislike for such behavior.
I can't believe you called it a game. This must be how ass hole managers justify their actions to themselves. It's like a bully in school calling it all a game because the person being bullied still has parents that feed him. Let's be real. It's not a game. Not. at. all.
A lot of these cases end up with the manager not necessarily having a lot of blame since they might not have full information on what's happening. They might also be in a similar performance crisis of their own.
If the entire company is having cultural problems and PIP horror stories are common, then the fault is from the people on the top and not from the M1 that laid out the PIP.
I feel ass holes should definitely be singled out so that they can't be managers again for the future.
Fuck you bezos!
It would have been more pragmatic to fire up leetcode, take a few interviews, and leave the job professionally. This probably would have come with a small pay bump, even with this persons limited professional experience.
Maybe I'm just lucky and I've never had a bad experience like this, but I couldn't see myself posting something like this professionally.
“Perhaps they should just be quiet”?
When are the abused allowed to speak?
Edit: nevermind. Comment history suggests I’ll never get a response.
My point was simply this wasn't a very pragmatic approach to handling the situation. Some employers may not like to see this type of content on their professional profile and it may hurt their career.
That way people can do what jiawei did but without the risk of professional self harm.
Someone in a position of relative power (being able to quit and publicly call out their employer) calling it out also makes the situation better for those that may not be able to afford that risk.
The rest of us are just (well paid) cowards.
I "won't hire" him for selfish reasons, but this guy is a patriot and speaks out against bully's. I hate to admit it, but people like us perpetuate the behavior.
But seriously, I'd rather have a coworker that speaks up when they feel things are wrong. Nothing unprofessional about that.
As such, if some Amazon manager wants to fire, PIP, overload with work, or do whatever he thinks is necessary to its not imorral or makes him an asshole. An employee can just quit and find a different job quite easily and retain his kushy life.
And to be clear this works both ways - if SDEs want to avoid Amazon or share their experiences, thats all fine as well.
But to start going after personal qualities of managers because someone cant keep their 200k/year position makes you the enitlted asshole, not me.
David vs Goliath story
Blind is pretty great but probably overly cynical. It’s not been “discovered” just yet.
The point of the review in my idea is not just to inform potential candidates, but to push individual managers to become better. When your actions have real consequences towards your reputation then you will be mindful of your actions.
(2) There are way too many PIP horror stories from Amazon. It is evident that managers even hire people just to PIP them later. In that kind of environment, such bad behavior is encouraged and normalized. Then this particular manager might not be significantly worse than any other person put in a similar position. If the culture is to blame, then scapegoating one manager will just deflect the blame.
I do agree that it is unfair. You have 100 axe murderers. You put one in jail, the rest get away with it. That is unfair.
Wouldn’t managers just make a service where they review and score engineers too?
Each engineer has one manager, thus they have one review. The profile doesn't open up until after the engineer worked for several managers and 3 or 4 of them leave bad reviews.
It's fair. But managers are more at risk. Still this process keeps everyone in line. Don't be a jackass is the key metric here.
But seriously: there isn't a way. This is why sites like Glassdoor are garbage and teacher rating sites have ruined careers over minor issues.
That means one person can't run a smear campaign. At least 2 or 3 other people have to agree with you, and if they do then it's legit. The system masks the persons negative reviews until that manager has accumulated greater than 3 or 4.
Three or four negative reviews from people in the company is NOT a minor issue.
Companies are just collections of people who are delivering goods and services to customers and returning money to shareholders. The PIP story isn't even surprising based on reporting from Big Technology and even the New York Times story from a few years ago.
I suspect Amazon is going to be in decline the next 20+ years and the start of that decline will be the company breaking up and selling off it's "non-core" businesses.
> The guy made 24 CRs in his entire career at amazon, all in just one CDK package.
> 50% of his CRs are merged without approval.
> So, yeah, there you go !
Amazon is well known for training employees to defend the company on-line. Aren't you being too generous with an anonymous comment that you provide no link to? Is not possible that is just Amazon propaganda?
90% of the point of blind is to shit on your own company anonymously (at least, that's what I use it for). I find it hard to believe that it's false, given that probably hundreds of amazon employees have seen that post and no one's refuted it.
If Amazon is astroturfing blind, they're doing a spectacularly bad job at it, the general consensus (from Amazon employees even) is that it's a hellhole compared to its peers.
I left amazon 5 and a half years ago, but never heard anything while I was there about defending the company online.
Could you elaborate on this?
My number one rule is not to sh*t on former companies with my main account.
Maybe someone who's knowledgeable with the development of CDKs can shed some light on how reasonable those numbers are.
I've only seen it written in typescript so node-module and package-locks are a thing.
For example: * Yes, he "submitted" >50k lines of code. Most of it is auto-generated from infrastructure generation templates.
* His teammates are submitting less lines of code because they're working on business logic
* Amazon doesn't let you put people on performance improvement plans because they are trying to switch teams. What is happening in these situations is that someone is ALREADY on a performance improvement plan because of a problem (and it could be technical, or it could be personal or professional), is receiving feedback for improving, decides they are not interested in working on fixing these issues, and tries to switch teams. This is when they find out that Amazon (like most companies) doesn't want you to just run away from problems by moving internally, and that you are not allowed to transfer. Then they go run to Blind or Linkedin to talk about how their manager is trying to sabotage them or hit PIP quotas.
Just saying. There's always more to stories like this.
that is well beyond real.
The manager got what he/she needed, which is meeting the attrition target and thus will get a TT or HV and carry on, doing the same thing again next go-around. Amazon still carries its brand value and millions of CS grads will still be clamoring to join the company, or experienced SWEs looking to switch company and start the recruiting process.
Jiawei Wang is leaving a big tech company, which happens at thousands a day, and unfortunately he is looking to join another company as a 9-5er, fading into the oblivion of corporate history, like a single blade of grass in a million square mile field.
Unless of course Jiawei join/starts a unicorn and gets a couple Bs, then he will get a nice bio entry in wikipedia and do something like what Tepper did to Corzine to get his ultimate comeuppance.
At least it's not every other week like it was for my team for a while. Now we're up to every 6 weeks.
wait wat? how is this possible? I'm not sure I would be able to even mindlessly type 51k lines of code in one month
* It promotes lazy managers who easily put engineers on PIP. I have heard so many stories where managers put engineers on PIP as soon as they apply for internal transfers and execute very shady stuff like suddenly sending MoM for 1:1 meeting 3 days later with stuff that was never discussed, etc.
* It creates an environment of distrust amongst engineers for the system. I've talked to engineers who have lost trust in all internal mechanisms like Connections, Forte, etc. Blind is full of stories & have seen personally where none of these mechanisms are able to surface structural & cultural problems. Examples like: Managers putting unnecessary pressure on a smaller team due to inability to hire good talent and literally abusing them when they decide to leave. Managers not talking about growth and not doing anything & more importantly not knowing enough to be able to grow their engineers.
* When faced with a bad manager or bad culture, a skilled engineer faces 2 choices, either fight the good fight, try escalating, try reaching out to HR or leave the team or leave Amazon. Even if there were no bad stories, its so hard for an employee to choose the former, but with so many stories floating around, the first choice becomes impossible. That leaves Amazon with a huge blind spot around bad managers, bad teams, and bad orgs.
* In terms of impact, a bad manager has 10x more negative impact to Amazon as compared to a bad engineer, yet the PIP process is carried about when IMO Amazon should be investing in re-establishing trust with engineers, creating processes to discover bad managers, bad teams and then establishing a process to weed them out.
Disclaimer: Amazonian here (soon to be ex).
EDIT: See https://news.ycombinator.com/item?id=28495204 for more info and https://community.cloudflare.com/t/archive-today-does-not-re... from a few years ago. They may of "made up" since, but I've not been using CF for DNS for a while now.
Weird. I have now switched to my provider's DNS to overcome the issue :)
Not saying this guy is wrong, his manager is right, or vice versa. I'm saying you don't know by this post, and by many of the pitchfork comments I'm reading, a lot of folks feel an unwarranted sense of surety in their outrage.
My intuitive expectation would be that the second my boss even expressed concern (in a non-constructive way) about my performance it'd be time to get out. Like what's the point?
https://www.geekwire.com/2016/report-amazon-employee-jumps-o...
https://www.reddit.com/r/technology/comments/5fj9mh/amazon_e...
Unless this is generated boilerplate, it just isn't possible to create that much code, that quickly, and have it be correct.
Managers even bought Java textbooks to put on their desk as some kind of totem as if their days weren't 100% filled with political skirmishes.
Don't think it ever came to pass but this nonsense reaches the highest levels of the wealthiest orgs.
Thankfully he realized the idea was terrible/other events made it irrelevant, but it was discussed and code written to support doing it.
Some people work a short period to get a taste of the tech stack and pace of a FAANG while other people post to HN about upcoming interviews at Meta and how they may hate the company's morality but want that big fat comp package. Everyone has their own reasons for taking a particular job and sometimes that calculation needs include the cost of associating your work history with the brand of the company you are working for, but if you think that what you are doing and the impact it has on the rest of the world is important then that warm and fuzzy feeling is a part of the compensation you are maximizing. In the long run no one will care, so anyone who is not maximizing compensation is probably a fool.
Big companies are actually like a conglomeration of small companies under an umbrella company. The culture is 20% upper management, 80% local management, and so your experience will differ greatly from department to department.
Bad managers exist in most companies. They can and do target people for personal reasons, and usually the targeted person doesn't have the protection or political clout to defend themselves, so they're killed off and life goes on.
I had a similar experience at Canonical of all places, which was a real drag because they were one of the few fully remote companies at the time, and I like the company.
Not everyone has the opportunities you have had. Some people actually have to struggle to climb for X reasons, and make tradeoffs to enable them to survive / grow.
Some people actually need money and can't just ignore wads of cash being thrown at them for the first time in their lives.
You're fighting ignorance with more ignorance.
I internally transferred at Amazon and had many internal offers to choose from - so I went with a team that had great tech survey results and where the manager seemed like an honest guy that I could trust. In < 2 years I had 6 different managers at Amazon, so I felt like I could read managers pretty well and knew what I was looking for. I joined the team and was ecstatic, up until the manager announced he was leaving 2 weeks later. I had to report to his manager who I had interviewed with and could tell I didn't work with. He had newly been hired by Amazon just a few months earlier, and he was exactly the type of micromanaging bureaucrat that Amazon gives too much power. He also clearly didn't want to manage ICs and they weren't clear to him during the interview process that he was going to manage ICs rather than managers.
Things went about as poorly as you can expect. The new manager had no technical knowledge, poor leadership, and blatantly favored the people he was managing before he inherited my team. But I'm not sure if I can convey how bad he was. He would have engineers manually updating excel spreadsheets for his monthly business reviews as part of their oncall work (which was literally his job). He would gaslight engineers into telling them they'd be promoted, and then hand them a PIP. He would lie at status meetings and has numerous documented performance issues and complaints in his connections and directly to his manager and director. His performance was so dismal that our Senior Manager made his team meet together and write down ideas (anonymously) for the manager to stop being so bad. He would blatantly not pay attention in meetings and ask us to repeat whatever we went over in the previous day's meetings (which he attended himself) in standup. He would never back up his engineers on any push back, even when we would get paged to do things outside of our SLA windows and completely let our stakeholders run us over with requests and expectations.
No list about all of his horrible practices could be complete, but I want to emphasize that he was so disliked that he caused 9 people to leave his team in 10 months. I don't want to say I was the best engineer, but I got positive feedback from all of the senior and principal engineers I worked with and I thought I was on a steady path to being promoted. But it turns out this manager realized he could weaponize performance ratings, and gave me and the other L4s that he inherited the lowest performance rating possible while giving his original reports promos and the highest rating possible. This wasn't an absolute shock to me and I already intended to leave Amazon because I couldn't stand him any longer, but this set my team's senior engineer off. He was absolutely livid and escalated the issue to the senior manager that this was a disaster and completely ridiculous. The senior manager met with me personally, told me it was a problem and that he'd make it right. He and the director decided to have my team report to a new (remote) manager, but for me it was too late and I decided to leave amazon.
But what happened to the manager? Well, I wish I could say HR stepped in and fired him for weaponizing ratings, or his bosses PIPed him for being awful, but actually none of those things happened! He caused ~60-70% attrition, had documented performance issues, and abused tools in a documented way and still manages at Amazon! A few months ago he internally transfered and as far as I know his new team doesn't have him on a PIP yet.
What is the takeaway for anyone reading? Just remember that just because you interview with a manager doesn't mean they'll be your manager forever, or even really at all. And it's okay if you underperform at Amazon, as long as your title is SDM. The last thing I wanna say is that I really liked the Senior Manager as a person, but he was too nice to the shitty manager. PIPing is inherently a bad system, but if it can't even catch someone who is so blatantly underperforming for a year straight then it doesn't even do what it says on the box.
Also no matter what don't join Amazon Go Boston. Just as a heads up.
iirc, its not CF blocking the domain, its archive.today returning "bad" info when queries come from CF because disagree with the data CF give them.
For me, (I just checked) I get a valid ip for archive.today when I dig via CF however the server it returns is hosted in Hong Kong but a query via my ISP's DNS servers returns a server in the Netherlands.
It's not just:
git contrib --linecount jdoe
That is a felony in many places in the world. Companies do this kind of harassing, thou. That is one of the reasons that companies need to be taxed way more and use that money to assure that people that lose their jobs can still live a decent life.
There only way citizens well have freedom of speech is if they are not at the mercy of corporations.
We need something like that. Rate my manager/head of engineering @ some large org. Also get a legal team ready for all the lawsuits that will come your way for whoever wants to pursue this idea. I'm all for supporting it though.
2) I remember during the #metoo era there was a Google doc spreadsheet of bad men going around where people could add names anonymously. It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
Reviewers would have to register by company email of course to make sure they're legit.
>It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
I think there needs to be a voting process to make sure it's not a smear campaign generated by a small minority. If the votes cross a certain threshold all the negative reviews are revealed.
It failed on the second purpose, but at least it helped me avoid or anticipate a hard or incompetent professor.
This isn't random people from the internet voting against the manager. It's people in the company who know him, and dislike him.
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 managers like you who try to go against the well-known wisdom and try to use LOC as a metric are what leads to the problem of shitty developers trying to game that count and posting ridiculous metrics like "I checked in 51k LOC in January". Developers who treat their work as a craft will avoid shitty teams like that even if they otherwise do well on the LOC metric.
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, in the general case?
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? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering.
PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because 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).
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.
If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. A hospital manager that measures staff performance by incisions per day is clearly misguided.
One of my own major wins last year was a big update to a project to strip out legacy cruft and tech debt, and scrapped maybe 5,000 LOC. The end result was smaller, faster, easier to test, and more robust. I count that as a win, by pure LOC, it was a massive failure. (Unless you don’t count code removals against an IC’s score, in which you’re optimizing for churn.)
My point is rather this, and I suppose I'm not being clear: If a developer only ever submits tiny amounts of code --and they have no other responsibilities like design docs, mentoring team members, etc-- that's an indicator of a performance problem that should be looked into and discussed with the engineer in case there's an issue.
I'm in no way suggesting that, e.g., the developer who submitted 12K LOC last year is doing a "better" job than their teammate who only submitted 11K LOC. I'm talking about that person on the team who only writes 500 lines of new code in an entire year, and they trickle out tiny simple commits ever couple of weeks. Every team that I've taken over as a manager, I find one person like this, who pushes barely any code, and the code they do push is trivial, and they aren't doing anything else either.
People here are somehow suggesting that LOC is so meaningless, that somehow apparently a person can implement a new map routing algorithm in 10 lines, or implement a new 3D rendering engine in 10 lines, or create a new data-ingestion and validation pipeline in 10 lines -- because apparently LOC is a "meaningless" number.
> slide 20 of https://www.slideshare.net/ddskier/calculating-the-cost-of-m... ("A world-class developer (e.g. Facebook or Google senior engineer) will write 50 LOC per day")
I also found some two scholarly estimates, one at 81 LOC/day and the other at 16 SLOC.
On this topic, don't forget that negative LOC can be good, as in the -2000 LOC story at https://www.folklore.org/StoryView.py?story=Negative_2000_Li... .
Sorry, I wasn't clear. I'm talking about 50 LOC every 2 weeks or so. Like, seriously low LOC of seriously low-complexity (sometimes trivial) code.
I don't actually have a numerical target people should hit. Not at all. It's more like this: on several occasions now (all too common), I've taken over management of a team, and in our initial team meetings and 1:1s, some developer talks about what they're working on and say it's really challenging but they're making progress and making progress and making progress. Then a couple of weeks in, I look at their commit history, and they've committed 6 times in the last 3 months. I give them benefit of the doubt, those must have been 6 meaningful commits. Then the first thing that stands out, the first red flag: each commit is like 25-50 lines. At this point, I have very strong reason to think we have a problem. But of course, to confirm, you look at the code itself, and one commit is just adding a command-line argument/option to a python script. Another commit tweaks some CSS. Or does a bit of dict/list operations that any developer should be able to knock out in 30 minutes.
My first hint that I need to dig in was the low LOC. Obviously, no one goes to a performance plan because they're not "hitting numbers." And obviously, someone whose job is architecture, system design, etc, isn't coding all day, so I'm not at all concerned with how much code they're cranking out. But for those whose job is, primarily, to code, well if you're writing low-complexity code (which is OK in a lot of cases) but you're writing very little low-complexity code... that's a problem.
PS: For a couple of years on my last multi-hundred-developer project, I ran a twice-yearly Code Reduction Week, and I emcee'd the All-Hands where we celebrated the developers who deleted the most code.
Teams of people build things. LOC don't add up to a hill of beans.
LOL. Oh, you!
> 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.
Reductio ad absurdum. A new feature is expressed quite literally as code in a repository. All other things equal (i.e., if one person isn't busy with design docs, or mentoring teammates, etc) if one developer cranks out 5K lines of solid (not bloated, well-tested, etc) code in a quarter, while the other person eked out 150 lines in 3 months, that's an indicator of a potential productivity issue. How can one argue it's not even a hint of a possible problem?
> Is this person engaging at all with their teammates?
No
> Have they been active on design docs or architecture?
No
> Have they been responding to queries from sales engineers?
No
> Have they been maybe going through a big life change?
Sometimes yes. And when I find out that's why they stopped submitting code, I tell them to take the time they need to take care of themselves and their family. And we offload their work to someone else for a few weeks or however long until they're back.
> 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".
I wonder if maybe you had a terrible manager who was like this. Because you're interpreting my statements in the most cartoonish way possible, like I'm here saying "more code good developer, less code bad developer."
This thread started with someone saying LOC tells you nothing. I claim it tells you something, and then it's the job of the eng manager to figure out what. I totally agree that a shitty manager who literally connects LOC to productivity, is doing it wrong. But again: a good manager should be looking at the code from their team, and making sure the amount and complexity matches their expectation of what that person is supposed to be delivering.
Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric.
A metric is just data point, no more, and not a complete picture.
> If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course.
I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate.
To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.
I think maybe you haven't seen how unproductive some people can be. And one hint of their productivity, is that they don't have much code to show for. If someone can explain to me how they're writing significant amount of new software with less code than this comment I'm typing right now, I'd be interested to learn how they did it.
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 and how to minimize bias. Verbally, it's all about numbers and probability. The organization wants X number of people to leave this year, to do that they want Y number of people in performance improvement plans.
There is an intense pressure to force a certain amount of attrition each year. While Amazon may claim stack ranking doesn't exist, Amazon uses rating and calibration mechanisms to learn who you think as a manager are your lowest performers. 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.
As an SDM, I wanted to maintain the illusion of great Amazon culture for my team. Behind the scenes, I spent a lot of time advocating for my team and trying to poke holes in the performance ratings of other teams. It was exhausting. There are certainly a lot of shortcuts I could have taken like putting potential internal transfers on performance management, but did not. I feel bad for the LinkedIn poster here, I think he had a lazy manager.
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.
Sometimes a poorly performing team member was just a bad hiring choice. You politely let them go and work to improve your hiring process. Sometimes the person is struggling for reasons outside work, so you try to find the right supports necessary. But most often, in my experience poor performance is about the worker's environment (culture, process, behaviors, projects), and those are all things managers are supposed to be monitoring and improving.
"Sun Tzu then set the women a simple drill and made sure they understood what to do. However, when he started ordering them to perform the drill, the women burst out in laughter. He tried again with the same result. Sun Tzu claimed that this failure of the troops to obey was the fault of the commanders. So, despite the warlord’s pleas, he ordered the two concubines beheaded as an example for the rest of the company. Thereafter, the women did not utter a single sound and performed the drill exactly as commanded."
This is a depiction of Amazon. However, a "simple drill" is not high speed software engineering.
End result being snakes, backstabbers, and sociopaths rise to the top of the chains. Engineering is a collaborative effort so it speaks to the culture of AMZN how they incentivize this nonsense.
I agree. I’d hate to work at any org that does this as a rule.
To play devils advocate however, I’m sure many of us have been in a situation where a co-worker was coasting, or doing the minimal amount of work, while spending energy to look busy.
I’m thinking this cynical outlook could have contributed to this practice being implemented in large organizations.
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.
Managers don't like to put people into Focus or Pivot (unless the employee is absolutely terrible, which is rare). But we all have URA quotas to fill, mandated by HR.
This is absolutely terrible for team cohesion and morale; while also being the largest source of friction and inefficiency.
Of course teams of employees with emotions and institutional knowledge are a bit more complex than a hand of cards, but that has never stopped bad management strategies.
Statistically, some of your employees probably aren’t good enough to be worth employing. But managers are human, hard conversations are hard, there are lots of incentives to not manage those people out.
By having an attrition target and forcing people to cut the bottom 10%, you basically skip over the soft fuzzy human factors keeping people around, and instead fall back to the statistical truth that the worst 10% probably are negative value employees.
Not saying I agree with this, but I think that’s the strongest case you can make for it.
His answer: "because, of the remaining, a new bottom 20% will be formed"
The other bit is it's a form of resiliency. High churn improves the bus factor. I respect Amazon for building a system that's resilient like this. That's not saying it's a good system to work in, but I admire that they built a system that can operate like this.
This is just one (very depersonalized) approach to not keeping 'dead weight' around, or optimizing staff to always be on an upwards trend. It's like an evolutionary algorithm; trim off the worst performers and the remainder will evolve to higher levels. In theory.
In practice however, attrition goals are terrible. It destroys team cohesion, encourages people to sabotage eachother and incentivizes sociopathic tendencies. If you know the lowest performers will get kicked out, then you have every incentive not to help those around you.
Typically the people who get pushed out are not the lowest performers, but rather those who have pushovers as managers. A vicious manager can fight and defend his reports. The weak ones end up sending someone to the "least effective" bucket, about half of which get fired in the next few months.
Stack ranking, plus rank and yank, absolutely destroys collaboration and teamwork. You can cram people into an open plan to "force" people to collaborate, but if you stack rank it will have no effect. You'll still end up with some pretty savage competition, up to and including being unwilling to help coworkers, unwilling to do anything for another team that is in the same stack rank pool, and some serious bragging and brown-nosing to have "visible" accomplishments (even if you have to steal them from your teammates.)
The whole "rank and yank" thing needs to die in a fire, IMO. It's seriously abusive, and counterproductive in the long term, especially if you consider tribal knowledge and business improvements.
Stack ranking is one thing, but you're against performance reviews? How do you know if you're doing well or poorly in your job? Or does it not matter because firing is so difficult?
I could never work for Amazon. I always write a followup email to my manager after any important interaction. I summarize what we talked about and what my next actions are supposed to be and what the expectations are. On occasion this saves me from having to redo stuff because of misunderstandings.
It did help at Microsoft, though. They tried to PIP me, and I gave them a paper trail a mile long proving that I was working exactly to specification.. We ended up settling on a few months' salary for me to leave.
In retrospect, though, I wish I'd just gotten out of Amazon as soon as the more senior people started scurrying out of my org. I wish I'd quit Microsoft a couple of weeks in when I realized what a Faustian bureaucracy it was, haha. Life's too short to work at terrible jobs, and trying to keep a paper trail like that is too stressful.
Semi-related, I live beneath my means and had many months' worth of liquid savings, which was an enormous help to my peace of mind. I was able to take a year off and relax after I ended up quitting Microsoft, and then find a new job I actually enjoyed with no rush.
Common experience, someone is told shortly before review time that they are doing an acceptable job, then two weeks later they are signing the PIP.
The assumption is their boss had to fire someone, and the PIP victim just happened to be the one who came up short. For whatever reason: short tenure, doing OK but not spectacular, their tasks of lower priority, said something that pissed off a Director, I'm sure we can think of many more possibilities.
I have been in teams where I was doing the best work of my career, yet I was surrounded by the best engineers and hence wasnt able to get into Top Tier for my level. I changed teams and found that I was working on much simpler problems yet I was so easily Top Tier. So much so, my promotion was being discussed as I was challenging technical tradeoffs, decision making of technical ICs from above my level & proving myself right in the new org.
This made me think of the stack ranking structure. It incentivizes engineers to either move to an org where they're consistently smartest in the room and not being challenged but get top of the market compensation or stay in an org where they learn a lot but be fine with not getting the compensation they deserve.
This is recently forcing a lot of talented engineers to move to other companies where they can get both.
Explanation: Jack Welch wrote a book called 'Winning' in which he describes a system for rewarding the top 20% and firing the bottom 10% on a regular basis to foster a performance culture. From Wikipedia [1]:
> Welch popularized so-called "rank and yank" policies used now by other corporate entities. Each year, Welch would fire the bottom 10% of his managers, regardless of absolute performance.
I've never seen a manager face any sort of criticism. They just lead with impunity. Often they are promoted for miserably failed projects because they took a risk, and in large tech companies with big cash cushions, risks are worth it.
In my experience most of the time managers just maintain status quo. Run standup, do 1:1s, hire, and pass on orders from above. They keep their jobs forever.
Failing to meet URA targets is one sure way to get antagonize superiors.
Meta also uses calibrations where I'm told managers present their direct reports performance reviews and essentially "duke" it out with other managers.
Disclaimer: I work at Meta but I'm not a people manager
> I feel bad for the LinkedIn poster here, I think he had a lazy manager.
Is n't OP's manager actually did that?
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.
No, this sociopath manager pushed the big red button in order to goose their own ghoulish metrics and perhaps get an extra on call shift or two out of the engineer.
That's funny, because from the other things you said:
There is an intense pressure to force a certain amount of attrition each year.
As an SDM, I wanted to maintain the illusion of great Amazon culture for my team.
It sure looks like this wasn't the case of a "lazy manager" at all -- rather, that manager was doing exactly what they were told: to force attrition for attrition's sake, regardless of objective performance criteria. In fact, at Amazon that manager would only be seen as "lazy" for not meeting their attrition quota.
I ended up switching teams and had a decent time at the company, but the nightmare situations are very real. You are replaceable and there’s no mercy
It's worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways. So, as expected, the HR dev teams had people move around quite a bit. Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool. Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them. However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it. I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by. I moved to another project within the HR space. Most of the team developing the tool has also moved on to greener pastures. Apart from that one guy, who has been there since its inception. He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it. Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving. Haven't seen someone decide and actually leave a company as quickly as he did. So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
So they go on the offensive and try to manage the dev out before senior management realises that yet another dev doesn’t want to work with them.
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.
The other pathological result is hiring dummies just to put them on pip, again protecting the core team from it.
Principles are things like Integrity, Honesty, Respect -- not Amazon's fuckwit bulletpoints like "Be right a lot" or "Frugality."
Technologically, AWS is built like a fucking house of cards with spit, tape, and glue. There is no real cohesion or organization, just a bunch of teams doing their own practices and gluing their rando codebase into the Yellow Console. Sorry, but just making the frontend look unified doesn't undo what the backend spaghetti is... That's why the outages of late will continue. It's all bubbling up from the absolute toxicity in lack of basic humanism at the core.
Still making more money than GCP and Azure (both of which are worse to use, IMHO) so...who cares?
I interviewed for an Engineering Manager job at MSFT and they looked like they had about 35 hours of meetings a week. On top of that they are expected respond to urgent issues from their direct reports and respond from urgent issues from upper management. Then there is the corporate politics of other middle managers.
The kicker was that most of the interview they were wanting me to do leet code. Really, I'm going to take this job and spend 50 hours a week of dealing with management tasks AND you think that I'm going to be keeping up my coding skills?
But I agree, I've been considering the shift to management (I like people) but the schedule seems punishing. As an IC only 20% of my time is scheduled, which is hard to give up.
Uh. Seems like folks being potentially unfairly pushed out are the ones with the worst jobs?
Everything about the toxic culture, the (unpaid) on call every 4 weeks, management doesn't care about estimations they just set you impossible deadlines, lots of turnover in the team, custom, unstable not documented tools, the "customer first" narrative to make you work overtime and feel guilty. I hear about this everyday. Even me not working at Amazon I have sev2 PTSD.
Never replied to those recruiters, and honestly at this point I try to stay away from FAANG's in general, they have the cash and prestige but I'm sure it's like any other F500 once you're working there. I don't need the stress of being a cog in someones megamachine.
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 scrambled to figure out how to fix the issue, I smelled something burning from another room and heard a fire alarm go off. “Will! There’s a fire! Help!” I heard my girlfriend shout. Now I was stuck in a conundrum — restore a critical Amazon service, or put out the fire in my apartment?
It was at that time I remembered Amazon’s famous leadership principle “Customer Obsession”. There are customers who depend on my team’s application — I can’t let them down! So I ignored the fire and my girlfriend’s pleas, and started debugging the production issue.
But all of a sudden, the smoke in my apartment cleared and the fire alarm fell silent. My girlfriend walked into the room, and to my astonishment, peeled off a wig and revealed herself to be Jeff Bezos himself! “I’m proud of you for being obsessed with our customers,” he said, and gave me a $5 Amazon gift card. He then leaped out of my window and hopped into a waiting Amazon Prime delivery van that quickly peeled away.
Even though I no longer work at Amazon, I’m so grateful for these experiences that taught me lessons I’ll never forget. Agree?
How it is going - https://archive.fo/pdYHy#selection-525.105-525.423
Maybe his manager is a piece of shit, but I can't believe there's no one to report to above him that can see this for what it is and make it right?
I’ve been an EM for a while. I have a lot I can discuss on a lot of different topics.
Nope. All they wanted to hear about was PIPs. I said I’d never had to do that, the goal after all, is to help people improve before it comes to that.
The guy explained that PIPs are a very large part of what their EMs do and are heavily emphasized in the interview process.
I politely declined round two.
What do they offer over their competitors? Same work and pay at other big tech, but you don't have to worry about potentially crazy hours or getting fired for no reason. Or any of the other great companies outside of big tech. Good pay, good impact, no PIP culture.
Recruiters from AMZN are trying to lure me away from Google (as recruiters do), but why on earth would I leave my good job and risk being a sacrificial fire?
There are some great directors and executives at Amazon. I enjoyed my time there. There are also some toxic, toxic people with too much power and ambition.
I worked there for 4 years on the AIV / Prime Video platform across a few teams (2012-2016). Obviously we had performance reviews every year, and I did ok. I transferred 3 or 4 times (within AIV), never a problem. I never heard of mandatory quotas to fit in the under-performing category, I didn't hear my colleagues talk about it either, "under-performing" laid off employees were rare (and unsurprising). Was I ignorant of what was going on around me?
From my perspective, the 'bar raising' in Amazon worked through the hiring process, of which I did many interviews. You only hired someone if you thought they were better than average either technically or on leadership principals.
Did this PIP quota thing always go on? Does this go on now to the same effect as people are talking about, or is this an echo chamber magnification of something that happened within a subset of one org?
However, I was part of the Retail org between 2018-2020. I strongly back the PIP horror stories here. I don't want to share more details, because I'm still not brave enough to publicly bash an employer on the net. But I want to emphasize what I think others have also mentioned here, which is that, due to Amazon's size, there was definitely no one "Amazon culture" to speak of. The variance between orgs (and sometimes, between teams in the same org) was bafflingly huge.
Development plan is a regular plan which you do with your manager, where you are focusing on your career progress. You focus on your strengths and weaknesses. Based on this plan you will get tasks which will utilize skills you are good at and also help you to improve skills you want to have improved.
PIP is a plan which is assigned to employees with unsatisfactory results. It's a few months long plan where you got assigned some tasks you should complete. If you are not able to complete them in time, you are fired.
I would not take his given statement at face value.
Even though Amazon has a history of such events, we should care about the bigger picture, yet be skeptical about the individual claims anyway!
> I only have one humble request, if I submited 51k lines of code in January and my whole team submitted 68k, do not call me a "Least Effective"
Let's give him the benefit of the doubt and assume he works 10 hours 6 days a week. Of course he takes no bio breaks, doesn't eat or drink and is not required to attend any standups or status meetings or design reviews.
This nets you 15600 minutes to code. So even under these absurd conditions he has managed over 3 lines of code per minute. What a god.
Either he's incredibly, incredibly bad at what he does, or he just had the misfortune to step into the bear trap that is the Amazon PIP machine.
Knowing Amazon, he probably just got unlucky.
$ npm updateThough it may also be common to request a transfer when you sense your boss doesn't value you.
As an aside, I don't see much horror in this story - this happens in many industries and is especially prevalent in companies that try to cull their lowest performers. The only sad part (and maybe illegal) is that it appears to be retaliation for requesting a transfer.
To the engineer who posted this on LinkedIn, producing three-fourths of your teams code shouldn't be a metric you use to measure yourself. Communication with the computer is perhaps 20% of your job - communication with your coworkers/customers is the more important 80%.
First, the mandatory minimums. If an org is full of superstars, the org still has to ensure it has at least X% turnover per year, so a superstar has to go. Usually well-performing devs whose manager wasn't skilled enough to convince the larger group that all of their people are superstars.
It's cruel, unfair, and harms the company far more than it has ever helped them.
The second problem is that sociopaths can and do abuse it. There isn't supposed to be a way for a manager to fire someone on a PIP when they ask for a transfer. There's also at least one manager in the Toronto office who openly brags that he does it. He's been there a long time, and the devs warn each other not to go work for that guy if you value your job.
Being a sociopath is not a requirement to become a senior leader at Amazon, but the qualities of a sociopath strongly overlap with the qualities it takes to get those promotions. So naturally, the systems in place are designed to favour sociopath behaviours. There is no system to try to identify and remove such people who abuse the PIP system, because the people in charge would never want such a system.
Kind of glad I left. When I chose which offer to take, I decided to turn down a much higher paying offer because "That company feels too much like Amazon".
I think the lesson of this story is to apply for another role after the performance review season.
Or to not express intention to transfer to current manager?
I can sit there as a project is falling over the edge of a cliff with total inner peace.
My interest stops at the pay cheque and by the clock.
Quit working for them and now I'm a freelance dev.
They asked me to get back on the project and I said fine, that'll be €700/day. After some grumbling they realized they had no other option so they agreed.
The project is still failing due to bad management but I no longer care. I believe to now feel the same sense of calm around chaos and failure like you do.
A lot of developers have real mental scars from bad projects like this, because they get duped into thinking it's a matter of personal pride to see it trough.
It's not. Your primary concern should always be personal health.
It was me and the two founders that I already knew from working together in the past. I expected that my opinion matters, I tried to improve the product, the service, the engineering, but anytime I recommended something it was ignored. After some months, I learned to just shut up and code. This experience taught me that no matter how close you are to the decision makers, influencing them is still hard. Since then, I just don't care. Sure, I'll do my best, but I do it for me and to get another offer in two years.
Now, I work at a big company, I'm like 5-8 levels removed from the decision makers, and I just don't care. I still try to do my best, if I have any concerns, I might mention it once, but if decision makers are not interested in my feedback, I don't mind. I work my hours, do my best, I don't take anything personally, but I also don't care if there is an outage at Friday (that could have been prevented if only we addressed the issues I brought up a couple of times) or if the feature we are developing never gets to production or if the feature fails (predictably, but a CxO has the amazing idea to pursue some obviously bad product decision).
It's difficult to not show the rest of the team how much I don't care. It's very different to show everyone openly you don't gaf (that's not accepted) and just simply not giving a f while pretending you care (that's okay), so I learned to "mask" my true emotions.
My BS filter is highly developed now.
"We will have the project done by the end of the month. Failure is not an option. We dont fail. We are xxxxxx. Come hell of highwater we will get it done. Lets do it". High fives.
"If you get this done you will get ...... " ($$, vacation, yacht)"
"Give it 110% people"
"If we dont get this done ....... "
This means: "This project is screwed. Nothing the team can do will save it.
I do the right thing; I talk to the PM or whoever is in charge and politely but honestly share my professional assessment of the project.
This is most often totally ignored. Which is fine. It is no longer my problem and nobody can come with "I thought you told me you would get this done ,.... " or some such variant.
I will do a good job and try within my own parameters of sanity and health and time.
After a rather unpleasant and unwelcome time I found myself in the army, having people yell at me all day (and night at times) Even when you have not slept for 48 hours, still screaming.
I can't say anything positive about the army but it did give me thick skin.
I am entirely unfazed and bored by some office drone talking to me loudly. Even if said drone starts turning purple.
> ""With all due respect, sir, you're beginning to bore the hell out of me."" (Clint Eastwood as Gunnery Sergent Thomas Highway in Heartbreak Ridge (1986))
This is what I'm (slowly) learning as well, even though I'm not entirely sure I want to. Working on projects where you care but almost nobody else does does that to you, but I'm afraid I won't be able to make it back to a position where I can care for projects.
Getting on 15 years into my career and not sure I'll ever get there. On the other hand, I actually work on a project I care about and for a company that treats me like a human being and not a "resource". Think I'm OK with that.
I try to be professional, hard working and I even do some unpaid overtime when deadlines are strict.
But the moment you pressure and stress me to do more it's the moment I say no and all my commitment goes away.
I'm not here to clean up poor management, project planning and low budget.
Also see, when everything is a priority/emergency, nothing is....
The squeaky wheel has to be actively on fire to get attention at this point.
That's why a PIP puts said pay checque on the line though.
I mean I don't want to do any project with a deadline, ever again, if possible, and I haven't even been exposed to the level of stress and pressure that people get at certain companies.
I thought deadlines had gotten rid of a decade ago in software engineering with the rise of agile software development and the realization that software is difficult to neatly scope, and development time is almost impossible to predict.
In the past, I thought of putting myself in positions like these to increase my understanding in short time, at the short term expense of personal life. I wonder if that's just a stupid thought that leads to nothing but burnout, or actually a viable short-term strategy to get up to speed with some of the tech stack you know but haven't really used in prod at the scale of Amazon.
Nowadays, I have health issues (go figure) so it's off the table and all I can do is wonder :).
People like to talk about how great a teacher failure is, and how it teaches you valuable lessons... and it's true! Failure does teach you lots of valuable things, including things that you don't learn by succeeding. However, succeeding at something challenging generally teaches you more.
Or to cast it in ML terms... you need examples of both success and failure in your data set, but the "success" data points are more valuable.
And like any great, secure, lasting and stable engineering giving you the knowledge and time is key here.
When a company overloads the safety officer with tasks, so they and up not being able to do their work propperly and an incident happens, the company is at fault because it failed to provide the officer with the resources needed for the job.
If they don't give a dev the resources to do their job it is not different in my eyes. The fact that there might be some magical dev who would be able to get something working out of the same circumstances doesn't matter — maybe it has a company crippling flaw in it because of all the haste.
The last 1.5 of those I worked with what I consider two amazingly brilliant a####les.
I ended up leaving the most amazing place I had ever worked at until then (worldwide traveling, learning new stuff, actual high performance systems).
It has taken years to recover and I still cover myself more than I should.
My boss (who I liked) tried to get me back twice after he realized I had not been the problem and the two others had left but by then my salary had increased so much I was out of reach for him (edit:,) and telling my family I'd go down a double digit percentage in salary to work for someone who had not stood up for me back the was out of the question.
I don’t understand this though? Eventually someone’s head needs to roll. If you fail your project and get fired, how is your manager immune from consequence? They failed too (probably more).
Sounds generally like most jobs.
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 worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways.
So, as expected, the HR dev teams had people move around quite a bit.
Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool.
Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them.
However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it.
I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by.
I moved to another project within the HR space.
Most of the team developing the tool has also moved on to greener pastures.
Apart from that one guy, who has been there since its inception.
He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it.
Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving.
Haven't seen someone decide and actually leave a company as quickly as he did.
So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
erm, this makes it sound like he was a not a very good engineer. Your code should always be written so that if you get hit by a bus one day, the rest of your team could pick right up where you left off
Usually you need to gather evidence that you've contributed significantly to a project. And the easiest way to do that is to work on new projects. Maintaining an existing codebase is usually a thankless job, which is also hard to get you promoted.
And once the new project is released it eventually gets abandoned and people move to the next one, which would help them get promoted. Think of all the Google projects that have been discontinued, which were also a product of similar processes.
The manager might not be incompetent, but they sure are an asshole
Well, for starters, this LinkedIn post.
I've found bad managers are able to exist, even thrive, due to a culture of loyalty. Having worked in several countries this is a very Corporate America thing (IME). Loyalty is the only trait that matters. Fealty might be a more accurate description.
So that bad manager's manager looks at a situation where people are leaving. Those people are disloyal and thus bad. The bad manager is completely loyal and thus good.
Seriously.
There are very few Senior Managers who take the time to look beyond what’s immediately presented to them.
The same manager never fired anyone he hired. He fired a few that he had inherited (even calling them 'deadwood') around other employees. Employees who had worked with the 'deadwood' for decades. But his hires? They could be the worst performers, and even though they were contract to hire, he always hired them. To not hire them would be to admit his hiring practices were crappy. And considering he had little technical knowledge, he was susceptible to hiring people who kissed the ring (and stroked the ego).
Some managers are just bad. Peter Principal and all that. Some are great at telling everyone what they want to hear, both up the chain and down.
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 people.
Contrary to some other comments, the folks I’ve seen PIP’d did have performance issues. And I doubt they were hired to be fired. Teams are consistently understaffed and fighting for head count is a blood sport.
During review, PIP candidates come from all managers under a section of an org. There could be 3 from one team and 0 from another. The incentive is then to hire people who are actually good and defend your team’s performance.
Engineers lack visibility into cross team performance and this leads to thinking this system works differently.
Eh, in my company, I've seen managers that will use tools to prevent people from leaving. Fortunately, they have tools other than PIP. But if they didn't, I'm sure they would wave the PIP wand.
One guy was senior and core to the team. When he wanted to move, his manager bluntly told him he needed him for another year so he would not let him leave.
One of the orgs in my company famously classifies all employees as "essential" (nothing to do with the pandemic). Because of that, any time someone wants to leave for another org, it has to be approved by the top staff of the org (this org has thousands of employees, BTW). Although they don't prevent everyone from leaving, they do often prevent people - to the point that during internal interviews some of them were dropped by the interviewing team as soon as they discovered the org they were currently with: "We've been burnt too many times going through the interview loop only to have your org block the transfer - we just won't hire from your org any more."
So yeah, I totally can believe someone would use PIP to keep a good performer in a team, if that's the only way they have.
OTOH, I think I'd be insanely stressed about being judged unfairly for things outside my control (or even being made into a sacrificial lamb) in an environment like that. Even if they kept telling me everything was fine, I'd feel like I had the sword of Damocles hanging over my head all the time.
Source?
As a thought experiment, suppose all of AWS was down for a full week? What would happen after that?
More realistically, how many times can us-east-chaos-monkey bring down various global services before a lot of its users start making moves to mitigate or eliminate their exposure to AWS?
For a more concrete example, I'm working on a project that has an easy but critical use of cloud services. The more I read about Amazon following Microsoft into Ballmer era stack ranking madness, and the most AWS fails objectively fails, the lower the priority it gets for which cloud platform to support first and best.
Don't date women that are easily confused with Bezos in drag?
"He was then PIP'd for accepting the gift card and not being frugal"
That is also:
- Success and Scale Bring Broad Responsibility (We must begin each day with a determination to make better, do better, and be better for our customers)
- Deliver Results (Despite setbacks, they rise to the occasion and never settle)
- Bias for Action (We value calculated risk taking)
- Think Big (They think differently and look around corners for ways to serve customers)
- Are Right, A Lot (They have strong judgment and good instincts)
- Ownership (They never say "that's not my job")
- Dive Deep (No task is beneath them)
Clearly, Will Ye Will Ye is operating at an Amazon final-stage boss level, if only they knew [0]!
This makes it.
Recruiter/spammer
> One night, when I was a dev manager at Amazon, another dev manager in Seattle sent me a 20-page design document at 11:30 pm and told me that he wanted me to get him feedback by 5:30 am the next day.
How fucking rude is that? It’s indicative of an absolutely staggering level of toxicity.
Honestly, what a waste. Imagine how much better Amazon could be if they didn’t treat their staff like cattle.
And another one, "A lack of planning on your part does not necessitate an emergency on mine".
But here's what I think is going on: Amazon's higher-ups (the level(s) above these people) are intentionally making these managers put pressure on each other to keep them overworked and sedate. I feel like this is the case for a LOT of US work culture across a lot of areas. It applies to low wage jobs with a high chance of being fired as well. Keep people stressed about the short term and they won't have the headspace to worry about things outside of their sphere of influence. This allows the rich to get richer and the politicians to become more powerful (and incompetent).
Seriously. You publicly stick the knife in for this shit.
If it was me asking for feedback, I wouldn't have sent it if I wasn't in a pickle that I probably had no control over. Okay, so you didn't read the mail and you only get to it the next day at 8 when your working hours started, cool leave it at that.
Dunno if I would automatically side with his story from that.
At best you're arguing that Amazon is dysfunctional in a slightly different way than the rest of this thread thinks.
[1] https://news.ycombinator.com/item?id=19828317
Edit: I think it's https://www.linkedin.com/posts/hire-jiawei-wang_hi-linkedin-...
Hmm, I think I've known this type of fuckabout whose massive submissions totally screw any hope of team cohesiveness and trust. Ok, slugger you can write shitloads of lines of code. Is it any good? Why would I want that much code when a factor of 10 less is more manageable?
Ugh this hits too close to home.
Additionally, because of the internal transfer policy and teams frequently switching out members, a lot of work is designed to be picked up by a new person, especially at the SD1/SD2 levels, so people are generally replaceable. Couple that with the fact that the interview process only tests for academic knowledge, without really proving that you can set up infra and services in production. And even more on top on top of that, Amazon gets a never ending candidate pool. So you get a combination of both poor performance that actually need to get PIPed out mixed in with poor teams that are ran like crap because managers themselves are not really technical and end up not delivering and then having to PIP people out.
That being said, because of this sort of structure, if you know how to make moves and "read the room" so to speak, Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked. If you are a talented software engineer, not just a developer and generally know how to navigate around managers, you can hit senior engineer or manager levels quite easily, and then cruise control your way at $300k a year, and with an added benefit of lots of remote positions right now (since wfh is a big selling point in order to not get rejected by good candidates). From talking to people at Google/Facebook, those kind of moves are a lot harder to do.
How do you “navigate” your way around an 11:30 PM email that contains a 5:30 AM deadline, as mentioned elsewhere in this thread?
Not really; esp when the processes and priorities are alike across the company (with exception of few organizations that are experimenting newer processes at any given point in time).
> Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked.
I don't think a single tenured co-worker who, during the pandemic, moved to Airbnb, Uber, Google, Stripe, and heck, even Coinbase, look back fondly upon the management structure they were subject to at Amazon, now that they've seen how other companies in the space are setup.
> If you are a talented software engineer ... cruise control your way at $300k a year.
Well, there's this: https://nitter.net/quinnypig/status/1386803846970675200
Edit: I'm trying to imagine scenarios where that could happen, I have two so far. You ordered pizza for a meeting that got canceled, and the office refrigerator was huge. Or you ordered from a fancy pizza place that had waygu or something as a topping. I'm sorry, I don't know why this is bothering me so much.
PIP is a tool in manager's hands and above L6 no one gives a squat. They even encourage using it.
Which is a good idea in itself, but seems like it's best to just skip on that experience. Kind of like a type 2 kind of fun.
I've also heard of good experiences at Amazon, so maybe it's just particular organizations inside it that suffer a lot from this problem?
I think I would be deathly bored at Google from everything I hear.
Don't believe everything you hear (although I suppose that works both directions).
Amazon is largely free of this kind of conflict: Customers and users are the same group of people.
I can't speak for other companies but I work at Google and I've met several people over the years who've confided with me that they've been on PIP (either in the past or at the moment when talking to me). While (thankfully) I haven't been on PIP myself (yet!) so I can't speak from personal direct experience, I can confidently say that all the people I know personally that were on PIP have successfully re-focused their career, haven't gotten fired, and are still working at the company years later.
Obviously it might be survivorship bias and I might simply not be meeting those that do not succeed, but at least I can confidently say that being put on PIP itself is not necessarily just an excuse to get you fired.
My manager either wanted me to start doing my job again, or leave and create a space on the team for someone who would. He seemed slightly biased in favor of keeping me on the team. It didn't seem like a fun situation for him to deal with at all.
I ended up leaving, but it's because I was disengaged and didn't see a way out of it. (And I had great offers elsewhere.) Not because my manager was being abusive.
There are teams at Amazon full of some of the best technical and professional managers on the planet. There are teams at Amazon that are so brutally driven that they will sacrifice anything, even accepting an incomplete pentest audit and a forgoing week's worth of sleep, to hit a launch date.
I personally had a close friend on my team get PIPed and it was obviously a play from management to get rid of him. I have another friend who had to take months off after leaving because of the abuse she experienced. I have other close friends who have stayed for years.
It's such a big organization and the leadership chains are so decentralized that you get a wide variety of emergent patterns, and the decentralization makes it hard for people across the organization to know about the experiences of other teams.
Edit: in general I wouldn't say the horror stories are the norm at all from what I've seen.
Big companies are often far less consistent across teams than you'd expect/they'd like it to be, for better or worse
Once I came in to work in the evening, I had forgotten to bring my phone with me. There I find one of my coworkers crying his heart out because the women treat him like shit. I had not noticed a thing until then. They thought he was sent there to optimize them away and was making his life hell. He had sold his appartment and moved to our little town to work but couldn't take it and moved back again.
The company is the same for everyone (ie un-humanistic in its management), and if and when your personal circumstances change, you'd then perhaps see what others currently in it are moaning about.
Can anyone explain the motivation for this?
I've never understood why a company would want to routinely fire X% of otherwise well preforming employees in a team, when they're going to need to hire that many again anyway.
Nevermind the concept of growing your people. We'll just hope they grow on their own and replace them if they can't.
Every team is already understaffed anyways.
Let me hazard a guess: Microsoft, Coinbase, Uber, or Airbnb?
I’d love to see the data correlating PIPs of reports to manager tenure. I bet there is an inverse correlation. So to prospective hires, ask your hiring manager how long THEY have been a manager AT AMAZON before you waste time going through the whole interview process.
I had a manager who was one of those org-psychopaths you speak of and it was entertaining to watch him tear apart managers of other teams. Absolutely shred their OP1 docs and argue that their team was working on utter bullshit.
Don’t get me wrong there was a lot of good stuff about Amazon, their operations culture is second to none, but a lot of the ways I saw people being treated and bad behavior from managers being tolerated rubbed me the wrong way. I absolutely saw PIP being used reactively to block a transfer to my team, for instance.
High churn is a high bus factor, like by definition of a bus factor. Bus factor => people had kids, retried, got a better offer, got fired, or were incapacitated (the proverbial bus) on a moments notice, and thus are abruptly unavailable to maintain your systems.
Churn is not a mechanism in itself to reduce the bus factor. It doesn't encourage people to mitigate the bus factor, because if you're going to be pushed out anyway, why bother building something sustainable?
I could see the argument for a probabilistic approach in that the company continues to function with critical systems being black boxes that teams have so far successfully scrambled to replace (with varying degrees of success), kind of like a more permanent Chaos Monkey for an entire system instead of cells within an system.
However, that does seem like it would waste a bunch of time, money, and opportunity on churn to deliver what you already have instead of using experience to improve/replace the existing systems.
It might very well be a "both" situation rather than an either/or. But focusing on/scapegoating this manager's behavior, to me, is the wrong takeaway.
Then by definition, it is the directives of senior management that are at fault.
The fact that he didn't is a huge red flag.
I don't need that stress. I just hopped over to another company, cut my commute, and made about 20% more salary.
It's a crazy approach that probably falls apart if you're unsuccessful. But they're very successful so they can just keep burning money to attract new hires. Also, I imagine it's a huge career builder if you work in FMCG or development to have "Amazon retail" or "Amazon Web Services" on your resume. Since everyone uses those platforms.
I imagine what is left at the end is a residue of "born again" workaholics, who're probably pretty great at their jobs. Who then ascend to and form middle management.
And the global express trundles on, powered by these workaholics.
You can call it lazy, that doesn’t make it any less of the goal or KPI Amazon created.
Most people don't care at all about doing a good job. They just want more money. To get along with them, you must help them get more money. If you oppose them on anything, they will make you suffer. And if they have the skills, they will manipulate and gaslight you. You can't make anyone do their work well. People work well when the organization is set up for it. If you can't tolerate your teammates' behavior, just move to a different team or company.
Sounds like if you work at Amazon you might choose to walk in front of a bus one day...
I suppose people working in critical positions were cut some slack. I can't imagine doing interviews is one of those positions.
the fact people actually fall for it is depressing
There are supposed to be emoji's in there
— What do executives do, anyway?, https://apenwarr.ca/log/20190926
IT Crowd reference: https://www.youtube.com/watch?v=ab8GtuPdrUQ
> "TODAY I interviewed a SINGLE mom that had her BABY on her lap and apologized when it started crying. I gave her the JOB on the spot because motherhood is HARD. Let's all give single mom a break and be more human in the process! :clap: :clap:"
I've unfollowed so many people at this point because I use it as an address book for coworkers and recruiters and these virtue signalling posts are not even trying to look human.
If you really don't want to work like this (and I don't), have a 1:1 with the manager, discuss boundaries, and if you can't come to an agreement, change teams or jobs.
And better yet, ask these during the interview! One question I often asked:
"In my current job, I typically leave my laptop at work when I leave at 5-6pm (unless there's a genuine ongoing emergency). Would that work in this role?"
Have I described correctly the situation?
Legend:
M2 - senior management, has other managers reporting to them
M1 - first layer of management, has workers / engineers as direct reports
In my experience at the VP level you have many highly skilled reports who are gunning for your job. Once you get the VP job then there may be many more enticing opportunities at other companies with just tough competition in the current position.
Why they had to invent "to be the best employer of the world" as a leadership principle?
The more people should stand up and make the stupid policies known, that's the only way this can stop. Otherwise this policies will be the norm for many companies since "it can work"
The only thing that management cares about is how much they're paid, and how much power they have. Look at how Elon Musk behaves. He gets mad/irritated when told by regulators that he can't exercise the power he feels is his right. I actually don't think he gives a hoot about how much money he has, except as a tool for accomplishing what he wants.
Others are more into the wallet than the ego. Do you think Zuckerberg gives a crap about what privacy advocates think? Most people have a fair idea of how far FB spies on them, and Zuck knows they don't care as long as they can share cat pictures with their friends, or post Let's Go Brandon stuff. But you can bet that he's supremely pissed about losing so much money due to Apple's privacy changes.
If someone needs to be fired, you don't need to put them through a humiliating process. Explain what happened and why, give them a decent severance and a good reference, and say goodbye.
PIPs are a way for executives to externalize costs of firing unto the team (which has to deal with wrecked morale, an overtaxed manager, etc.) while claiming they "saved money on severance" by firing or force-quitting people for free.
In the case of average performers, reviews are harmful because they prevent a person from being able to reinvent themselves.
In the case of high performers, they are not really needed because they should know in other ways than being told, "You're a 4.3 and will stay a 4.3 as long as you don't annoy me", every year.
And for managers, they consume an inordinate amount of time and make people unhappy. No one wins but the highest of the higher-ups who profit by pitting working people against each other.
I don't think performance reviews should have a part in firings, and the metrics they use to rank/rate people are generally worthless, but it's actually nice to get feedback from time to time on how you're doing. I've had managers who I never heard from at all and that's not ideal.
If a company is thinking they have to fire someone for performance reasons it's way easier for them to have documentation showing what has been going on and that they'd given the employee time to improve. It's better for the employee too to understand what the expectations are they're not meeting and to have a chance to explain what the causes are. I think most people would prefer that over being told out of the blue that they've been sucking at their job and escorted out the building.
It really depends. I have never felt this way about a performance review. I like being informed about whether my manager and I both agree on what my job is. As an added bonus, the day after a good review is when you are least worried about losing your job and your livelihood. Honestly it seems like your beef is with the lack of social safety nets and not with performance reviews themselves.
It may be useful to further refine what we mean when we are talking about "performance reviews". Are we talking about regular discussions between Managers (or skip-level, or product stakeholders) and their reports, or are we talking about an HR-driven process that happens every x months? Personally (for whatever that's worth) I find the former helpful and the latter to be mostly a waste of time.
> How do you know if you're doing well or poorly in your job?
Just my 2¢, but I think most folks would acknowledge that it is easy to have a myopic view, and outside feedback is valuable. But, at the same time, I would expect most (non-junior) engineers (who have been at a company long enough to understand the business) to have some sense of how their efforts and contributions are going? Put more plainly, I know if I'm slacking, and I don't usually need my manager to tell me that I'm writing decent code or getting my work done. That said, this all surely depends a lot on the specifics of the work and the organization/teams involved. And also assumes some healthy and regular conversations between peers and between the Business and the development team.
Know the rules of the game you're playing deeply or you'll keep losing.
I’m a software engineer who likes to have fun on LinkedIn, not a recruiter/spammer. And yes, I was actually an SDE at Amazon!
Thanks for clearing it up, btw. :)
Amazon claims to be data driven, so it assumes that a manager can stack rank their employees and select the lowest performer. But let's all be totally honest here, it's impossible to quantitatively rank employee performances. Any real attempt to do this results in Goodhart's law.
So either managers follow some quantitatve measurement (most CRs, least revisions, most stories done, etc) and ignore things that matter and can't be measured. Or they attempt some sort of qualitative measurement that almost always turns into who YOU (the manager) is most comfortable working with.
Stack ranking and cutting is a broken system that is inhuman. But it fits right in with Bezos' transactional mindset.
I worked somewhere that did weird personality tests as part of the recruiting process.
I talked to my manager later and he basically explained it as - yeah, it predicts nothing. No one ever gets denied because of it.. but its something for HR to wave at you if a hire doesn't work out and say "see it was right here in the personality test".
Just a thought.
This is what I don’t get! If you’re convinced a certain percentage of your people should be pushed out, then you don’t trust your recruiting team!
Maybe Amazons approach is to save money by hiring crappy recruiters, then fire the mishires.
My own experience is that Amazon recruiters are more salespeople than conventional recruiters.
But I can’t imagine organization repudiating a chunk of their workforce, and not asking “why do we keep getting so many crappy programmers.”
Guess who got called in on the weekend for log4j?
Guess who only heard about the problems on Monday at 9am?
You guessed it, the call was made to not pay the (documented) day rate for contractor call outs on weekends. Full-timers got "days in lieu."
Customers always seemed to want to pay me fixed amounts for jobs and be absolutely no good at estimating them. I got paid 28 days contract fees for a job that took 3 hours once. They paid up and asked me to not come in for the last 3 weeks so their other employees didn’t catch on to what had happened…
Basically the higher-ups have to decide what is most important; if the deadline is fixed, then the scope HAS TO BE flexible.
tl;dr; everything in a large corporation is a game of telephone where everyone is incentivized to muddle the message. So any deadline/commitment handed through multiple levels of management is really difficult to negotiate. And the more unrealistic it is, the harder it is the negotiate. Nobody wants to tell their boss that the thing they want done in 3 months will actually take 2 years.
In the beginning, there was a plan,
And then came the assumptions,
And the assumptions were without form,
And the plan without substance,
And the darkness was upon the face of the workers,
And they spoke among themselves saying,
"It is a crock of shit and it stinks."
And the workers went unto their Supervisors and said,
"It is a pile of dung, and we cannot live with the smell."
And the Supervisors went unto their Managers saying,
"It is a container of excrement, and it is very strong,
Such that none may abide by it."
And the Managers went unto their Directors saying,
"It is a vessel of fertilizer, and none may abide by its strength."
And the Directors spoke among themselves saying to one another,
"It contains that which aids plants growth, and it is very strong."
And the Directors went to the Vice Presidents saying unto them,
"It promotes growth, and it is very powerful."
And the Vice Presidents went to the President, saying unto him,
"This new plan will actively promote the growth and vigor
Of the company With very powerful effects."
And the President looked upon the Plan
And saw that it was good,
And the Plan became Policy.
And this, my friend, is how shit happens.Then again, I keep interviewing people with 5-10 years of experience, who will go something like this:
> How would you manage a server? (leaving out a ton of context about what it means to "manage a server")
> Very easy, SSH connection is very fast, reliable, ...
> Awesome, love me some SSH, how about 5 servers?
> Hmm, probably write shell scripts.
> How about 50 servers?
> Shell scripts?
> Even with 500 servers?
> Hire more people..?
And I keep feeling that these people don't have 10 YoE, they have 1-2 YoE times some coefficient.
I feel like if you're in a "successful rut", that's what it will do to you. You feel like you're successful, but in fact, you have fallen horribly behind, without even knowing it.
Your quality of life is probably fine, until you're laid off one day.
I recently came off a project that was technically using "GitOps" but where every deployment involved copying and pasting dozens of files across 3 or 4 repos, and the whole thing was very error prone, and if you didn't change exactly the right things your service would just silently fail to deploy, or be unreachable, with zero feedback.
I've worked at a company with a bespoke CI/CD system hacked together with PHP scripts and Jenkins servers, but where every single process was ruthlessly automated, reversible, with multiple layers of fallback, failure recovery, garrulous feedback, and built-in approvals that you could automate, or if you didn't remember, you'd get a helpful reminder in email and a link to a page to fill in the required information. People could, and did, know how to do a deployment on it their first or second day.
Guess which one was more pleasant to deploy with?
It's the automation mindset that's important. You can find people with the right mindset who haven't had a chance yet to play with ansible or terraform, and you can find people who manage to create nightmarish complexities of manual processes out of ansible and terraform. Unfortunately, I haven't yet found this to correlate much with years of experience.
Not sure what answer you expect here? Just because you have 10 years of experience doesn’t mean you’ve ever worked with more than 25 servers at a time (at least I haven’t).
I consider it a source of pride, I think. You absolutely don’t need mega scale for most things (or maybe mega scale, but still not many servers)
Some people get complacent once they get a job and stop learning. The trick is to keep on learning. I have worked for a company like Amazon with aggressive schedules where we used to work for 12 hrs/day. One time I didnt go home for 3 days. I can say I learnt a lot, but there are better companies with mature planning where you would still learn the same amount.
How different ppl react to toxic environments is also different. Some people may thrive, while some may wither.
I say it is a random walk searching for the best place (for you) to work. You keep iterating until you find what you want.
They ask for a VM or a DB to the DevOps / SRE team, wait a bit days and get a URL. If a team uses CI/CD and K8s, they will write a yaml file from a template, wait a few minutes and app will be deployed.
I wish to thank you for proving my case.
It looks totally fine on a monitor, but because of the narrow width on cell phone displays, a paragraph can extend beyond the display's height, and it psychologically has an impact on people.
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.
The original point was tenure is short, and no manager can guarantee that their “core” team will remain together, for any number of reasons. So letting go a “too good” engineer to keep this team together makes little sense not that PIP isn’t happening.
When doing contract work, you might be paying $500 / month out of pocket for medical insurance but your hourly rate is likely higher than your hourly rate as a W-2 employee even after factoring in company holidays, PTO and 401k matching. You also have the option of not buying insurance if you really wanted to.
Most insurance in the US is horrendous too. The whole system is optimized to provide you the least amount of coverage while making the process as inefficient as possible for you. I spent literally 12 hours on the phone over a few calls trying to get basic information from a few different dental insurance providers, in the end I got nothing concrete out of it and the only way I could have gotten concrete numbers is if I submit a form that takes 30 days to get processed except in the US you only have 30 days a year where you're allowed to enroll into insurance. Basically it was impossible for me to pick insurance based on coverage because it's impossible to know the coverage without first signing up and then you're stuck in it for a year in which case everything resets the next year and the process has to start again from scratch.
This is the normal approach. You are experienced and wise now.
I kinda agree with the OP, I would have a lot of trust issues with management if they pulled this shit on me.
Hunter gatherer survivalist genes just kick in.
YMMV, but I consider it a healthy thing for, at least for some part of your career, to work "Amazon hard." Aka, all the reasons that people list when they say you should really try working for a startup.
When you push yourself to your limits at your profession, a lot of stuff clicks into place and you learn so much.
You can't procrastinate, you can't do it wrong, there just isn't the time.
You should have trust issues with "management" in any corporation because these people have the interest of the shareholders at heart, not of the workers. It's just sad some of us have to go through a traumatic burnout to learn this lesson.
Of course, what i said doesn't apply in a self-organized workers cooperatives where management is the workers.
And yes, I've been a manager in a company where the phrase "managed out of the business" was used. I no longer work there.
I’ve never felt pressured to work overtime, haven’t had to race to meet an unreasonable deadline, and I’ve been rated exceeds on both of the performance evals I’ve been though.
The Amazon I’ve experienced is much different than the one I read about before joining.
After I joined Amazon in 2007, I referred a friend from Uni who joined a few years later.
I had a fairly laid back experience - after a good start, I became depressed and burned out, but somehow none of my managers seemed to care all that much since I was at least getting some stuff done, until I finally got put on a PIP several years in - which I think was probably deserved, although the handling around it was crap. And even then, when that manager moved to a new team, my new manager told me I was doing fine and not to worry about it.
My friend, on the other hand, who was the most diligent and hard working of my entire friends group in Uni, was assigned to a different team a few desks over. She fell afoul of stack ranking (the idea that you should rank everybody in a team and fire the worst) and was pressured until she quit.
I also heard a bunch of horror stories from devs across the company - unreasonable deadlines, regular Sev-2s and firefighting when on-call, a manager evading blame for a disastrous project launch and dropping it all on one engineer.
I think the main problem that I saw was that there wasn't much training for managers on how to be a good manager, and bad managers never seemed to face consequences.
I finally quit after eight years (funnily enough, after ending up working for the manager who made my friend quit) and I'm a hell of a lot happier nowadays. Amusingly, I'm still facing tight deadlines and sometimes random overtime, but I have a great boss who is willing to fight against these things for me, and that makes a big difference.
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.
Like the going rate for a senior here is 900, and a good senior is 1200+. So your starting offer would be at least 1800, probably 2000s to round it up.
Which is the high end of your zone of possible agreement (900-1200) plus 50% for danger money, plus a few hundred to round it up to 2k.
Then you see what happens when you throw out the big number.
It's gonna be a different situation for someone taking their first programming job out of college, and someone who's been doing it for long enough that they don't care (and would probably fire a company like Amazon before being fired themselves).
I have a cronjob that signs out of {slack, email, zoom, ...} at a particular time of day, my work accounts aren't attached to my personal devices, and i respond promptly to communication during working hours. I genuinely don't see work-related comms when i'm not working, and my work availability is in my slack profile, my internal email signature, and in my outlook calendar.
The objectionable part is the magnitude, not the subject matter.
It's just named differently and adds more paperwork (more performance warnings, "talks" with your manager, etc.) before you get terminated.
That time is now gone, and goals are tied to your percentage. A team failing to meet its yearly goal can be expected to be asked to let go 15% vs. the standard 10% say.
It’s real and as messy as people are sharing. Some teams are better off than others.
The only time stack ranking was a force for good was when the French applied it to their ruling elite in the 1790s.
See also how people had to get a "certificate of civism" lest them be considered suspect by default: https://en.wikipedia.org/wiki/Certificate_of_civism
Consider that most parts of the world have lower cost of living than the Bay Area.
I have no idea what typical salaries are in the EU, but that’s on the low end of mid-career for much of the US.
Probably higher now.
The least you could do for "danger money" is 1200 EUR a day (and limit yourself to 4 days a week, but that's another story).
It would be way more efficient for employers not to offer dental insurance and instead give employees a tax-free $1,000 yearly stipend which allows employees to use this for personal and family dental care as an expense report which in turn ends up being a business write off for the employer. Now there's no limitations on what work can get done and no wasting your life trying to chase down dental / FSA details. A higher end dental insurance plan through a company is over $1,000 a year too, so this stipend approach would save employers money and it saves employees a lot of money too because you could easily end up paying $600-700 post-tax money out of pocket for standard cleanings a few times a year when insurance won't cover them (even if that insurance costs $1,000 a year). It's a win / win scenario for both the employer and employee.
Pick the air carrier with the cheapest flight to Mexico.
Found the Timestream guy
I think we generally do not hear about the cases where a PIP was used and the employee was genuinely not meeting expectations, or when a PIP was used and the employee course corrected and went on to have a successful career.
Another thing to note is my father who had completely invested his entire life into this way of thinking and is currently spending his retirement with bad mental and physical health. That’s the end game these working practices tend to lead into.
It’s true that you should work to live, not live to work.
At the end of the day, YOU are the professional. If an amateur decides that you are going too slow, that doesn't mean anything--they can feel free to hire more engineers or whatever needs to be done, but the onus is on _them_ to ante up. No matter how much you love your job, you're probably going to have multiple throughout your career so you need to focus on yourself first and foremost.
The shareholders try to build a social control structure that aligns these, but it never fully succeeds.
def caresAbout(self, other):
if type(self) == type(other): return random.choice([True, False])
return FalseMaybe a cynical take, but if you’re pushing limits then you’re probably just learning the right corners to cut, shortcuts to take, and how to exploit/manipulate people to get what you want fast. If you didn’t learn any of that, then—well, someone else just learned all that at your expense and you’re setting yourself up to just be exploited again and again.
> there just isn't the time
Yeah, that’s the root cause. Why is there no time? Is someone’s life on the line for this deadline or is it just that the manager is eyeing a sweet bonus for delivering early. 99.9% of the time it’s the latter. So why learn how to get manipulated? Learning to work at a consistent pace is far more sustainable. Tortoise and the hare.
Working at such a rhythm helped me learn much. It also durably damaged my body (both because it chipped away at my health and because it made me forego health check-up), my mental health, and made me lose personal connections. To this day, I'm still picking up the pieces.
Human beings are also "designed" to survive long period of hunger if need be, but no one would argue that going without for a week is a fine and healthy way to lose weight.
I guess I should say the healthy thing to do is to work at 100% of your capacity, whilst going to bed at 9pm and doing 25 minutes of exercise every morning?
The only thing worth working 120% for is raising your newborn child. Or maybe making a civilization-altering breakthrough in the natural sciences, like Fusion energy.
Everything is simply 'meh' in comparison and not worth sacrificing your health for. And I say this as a person who doesn't even particularly like or want kids.
source: recently left Amazon as SDM
What it is good for in my view is making managers look and feel tough and establishing a culture of fear that is so necessary for hierarchical power structures. Power/status hierarchies are a common trait for most primates. So my shorthand for this sort of it-doesn't-make-sense situation is, "Primates gonna prime."
Not defending, just explaining.
This is where your cards analogy falls through, in a deck of cards, you know that there are better cards you don't have in your hand, you know exactly what your Jack is worth in absolute terms.
At Amazon, you can have a Royal Flush, and because of stack ranking decide to discard your 10, and if you know your poker, that makes you go from the best hand to one of the worse.
The issue is you wouldn't know your 10 at Amazon was a great engineer and a key asset to your team, and that all replacement candidates are going to be worse, except now you've lost precious time, ramp up, and moral, as well as a great employee.
For a smaller company, it might make sense as you're building a core team and might need to go through a few people before you find a set of good ones, but where Amazon is now, at its size, over time, it has lost engineers that in industry wide averages were above it, and it has created a reputation that hurts it from attracting them back or other engineer's above the industry's average.
Due to this, Amazon is becoming a second pick. Good engineers will pick Netflix, Google, Microsoft, and even sometimes Facebook (due to their higher comp) over Amazon. And since all these companies hiring process are the same, it's common that someone who can pass the Amazon interview can pass one of those other ones as well. In fact, almost 70% of everyone I've seen be released from a PIP went to work at one of the other big tech companies.
The other big problem is that the stack ranking works like American reality TV competitions. It doesn't matter if you've excelled year over year, if you have one bad year, where for whatever reason you get identified as a low performer, you'll get PIPed. In my experience that's often contextual, a new manager or you look like a bad performer because the business and leadership couldn't figure out good projects for you to work on and own that year, or they themselves couldn't get their act together and you're a scape goat. Other people on your team might have performed better simply out of luck of having been assigned better projects.
Amazon used to get away with simply finding the best talent, but in my experience there, that's now backfiring, and instead of growing the best talent, their quest to find it is turning into a system that recruits more and more mediocre talent as time goes on.
But this makes sense _in a game with a fixed hand size_. But a company's staff should grow over time. So shouldn't one have an ROI-based criteria where you want each team member to help grow generate meaningfully more revenue than they cost to employ. If my "lowest" performing team members still make meaningfully more money than they cost to employ, they still increase my ability to hire more.
This acknowledges that the "optimizing a hand of cards" analogy leaves out factors -- which is true.
My point is, even if there were no emotions or institutional knowledge, even if I had a "staff" of AI agents or robots whose "knowledge" could be fluidly copy-pasted, the "optimizing a hand of cards" analogy is poor, because a robot that makes money is worth keeping even if there are better robots out there. An army of low-but-positive ROI robots can help me buy a high ROI robot.
Maybe you hired a 7 of clubs, but given time they can gain institutional knowledge and improve their skillset to become a Jack of Spades.
I'm happy there are companies that set attrition metrics as a KPI, it makes it easier for me to hire and build out a technical team for my company.
I had gotten them for myself and a friend. They are small pies so a single person can easily eat two of them.
The value of pizza is inversely correlated to the time it's been out of the oven. Once it's in the refrigerator it's worth max 1%
So to me it makes perfect sense that it's $100
If you're a manager in a situation where an employee has a problem and aren't meeting the job requirements, you'd probably much rather that they fix the problem and contribute to the team than fire them.
That doesn't mean that all of these plans are done in good faith, or that some managers aren't terrible. And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
But I don't think one can say that it's nothing more than a legal way to fire someone (especially since you can fire someone in most states in the US without cause, and spurious allegations of racial or other discrimination would need documentation that would be hard to produce if it didn't actually happen).
I don't think being put on a pip means firing is certain and imminent. I do think being put on a pip means firing is on the table and a serious threat. In that sense the analogy of 'putting a bullet in the chamber' is accurate if maybe a bit strong.
> And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
Considering both of these statements, a PIP is never the right answer if your objective is legitimate performance improvement.
Even if you're an unexperienced (or outright stupid) manager that doesn't understand this and wants to use a PIP as a legitimate performance improvement tool, the target employee is never going to be on good terms with you or your company and it's very unlikely you'll actually get the desired results. If you do, it's only because the employee has literally no choice but that loyalty will be out the window as soon as he is in a better position to make a move.
Honestly, I should have still quit, because it was burn-out over the role rather than compensation-related. But I stayed, and slacked a lot. Tracked my hours towards the end and I might get 12 actual hours of work done some weeks, including meetings. Still got most of my work done, but often with delays. It wasn't a perfect job, but the team was great and I liked the company culture.
My manager was very clear with me when I was PIPed that he really wanted us to work together to get me back on track. HR wouldn't consider letting me work part-time despite multiple conversations (it went against the company policy, and other people would start asking for it), but he tried to convince me to take paid time off instead. I decided to quit anyway, because I figured I was done spending most of my day configuring automated test pipelines and wanted to spend more time writing code that wasn't bash.
When I put in my notice, the manager tried to convince me to stay again, said they really wanted me just on track, and reiterated again that up to 4 months of paid leave was an option. Seemed really forlorn about the situation during the exit interview.
I honestly believe I could have worked my way out of the PIP, and the management would have preferred that outcome. Employing me at my current level of performance wasn't delivering the value they were paying for though, and quitting was ultimately the best situation for everyone involved.
Companies may additionally prefer to have more standardized procedures. Hiring is expensive, training is expensive, and cohesion can only be gained over a long time. By needing multiple steps to fire someone you reduce the chance you throw the baby out with the bathwater. And even if you’re sure someone is a negative factor and want to fire them with little prior notice, the people who you think are good are not mind readers and might even have a different opinion of their colleague and will question their own employment security.
Amazon doesn't pay top dollar for engineers, and the delta between Amazon and other companies is growing every year. (The compensation ends up being competitive when you take into account stock growth, but the new hire offers are not attractive.) And it's a very results-driven, stressful work environment. The effect of that is that people who get better offers go elsewhere, both new hires and existing employees. Those who are left either don't feel like interviewing or interviewed but didn't like their other options.
Yes comp could help to attract better talent, that's what Facebook is doing. But of the about 150 interviews I've conducted for Amazon, 90% of almost all candidates always ask me: "So is it really as bad as they say working here? With how they treat you?"
I think that's a pretty good indicator that the reputation is just tarnished, and I wouldn't be surprised that that's having a sizable effect on the decrease of talent.
The other thing is, yes maybe some real bad apples leave from a PIP, but the whole culture around it, the stress, the feeling everyone has that they constantly have to fight for trust and respect, that is also a cause for a lot of the really good engineers and high performer to leave as well, of their own, no PIP involved, but it's the same root cause for why they leave.
I see so many good ones, ranking high every year, and after 3 to 5 years say: Well I had enough of this BS, too much hassle always playing the game. If anything, that's the biggest issue.
There are elements of the culture I miss. The focus on writing was great. Shipping things quickly that impact a lot of people is nice. It made up for a lot of the deficiencies, and it isn't universal (cough Google). Amazon tends to make the right tradeoffs with tech choices to enable this, not always, but most of the time.
I enjoyed working with principal and senior engineers at Amazon. I didn't meet a single PE that I didn't thoroughly respect and enjoy talking with. I miss the internal PE talks, and I wish they'd make them public.
Compensation is deeply personal, but once I broke 400k, I really didn't care too much one way or another, and Amazon's total compensation was never significantly less than competitors. It was about the work, impact, and people.
Implying that other developers in my area are available for less than I ask.
I mean, if a person is able to extract 700€ per day, kudos to them but that's still above the 90th percentile of senior developers in Europe.
They can attempt to prove it.
If you don't care about what you're doing, you're spending most of your influence on the world on something you don't care about.
If my choice is between working at a boring job where I can support my colleagues, and an exciting job with cool tech where people are having mental breakdowns and nobody has the mental space to support them, I'll take the boring job where people don't care about stupid directives and dealines from above.
Every time an AMZ recruiter tries to poach me from my current job, I consider replying back with links to the NYT article, the URA article, and various anecdotes from friends that worked there. Ending with a question of 'Why in god's name would I work for your company?!'
Also he has a background in bio, and managed to land a full stack and ML engineer positions, implying he is self taught, and therefore should be already fairly intelligent...but he decided to go get his MS in CS, without even doing any research project and just opting for the GTA instead of GRA route.
None of us can really know for sure, Im just saying it smells a little fishy. If his resume came across my desk, Id have some specific questions about his experience. If you are that smart to have a background in bio, and land the jobs that he did, your career would look very different.
This is pettiness taken to the max.
Most research people do in grad school will not have applicable use to employers. And for an MS, people will simply learn more by going the coursework route. Going the research route is good only for PhD admissions.
And finally, many universities in the US do not even offer a research route for the CS MS. They tell you to apply straight for a PhD.
If you're going to ask tough questions, at least know your domain!
Is that really so impressive? Bio people do a lot of coding, and good dev practices can be learned on the job. ML is probably also something he played with during his studies. Full stack + some ML experience is probably enough for a junior ML engineer.
A CS degree opens doors. And you don't know what he planned when he started his degree.
Asking about someone's experience when interviewing them is reasonable. Calling short jobs during university fishy isn't.
Could you elaborate more on this? I'm assuming this is a detail of the US education system of which I don't know anything :)
Studies don't give you any idea of what a job is actually like. They also don't give you a reliable indication that you'll like a field. Choosing bio out of high school, then moving to CS for any reason, then trying a few jobs using these skills is a normal and healthy way of searching for a job he really likes.
In particular quotas flow down into teams with zero percent of people who should be fired. The effect on the remaining 100-X% employees morale is negative.
Further, in any big organization the weak performers are not evenly distributed. However the PIP / attrition % rates are uniformly forced. So the over performing team has to start cutting into good performers within a year or two, whereas the low performance team can cut and still have many lower performers..
Why is this a statistical truth? In a large, Gaussian distributed population MAYBE this is true (but hiring isn’t random, is it?). But the thresholds are not applied to large populations anywhere I’ve worked. It’s pressure applied to management at all levels.
That means people will devote SUBSTANTIAL amounts of their day-to-day labor in jockeying and positioning.
People will be hired (wasted money and time) explicitly to be fired/PIP'd.
The jockeying will result in disruption of team development.
People will sabotage their coworkers.
Trust disappears.
Paranoia grows.
Blame deflected.
Difficult problems won't be tackled because why risk it.
Bandaids rather than solutions will result.
YOUR BEST PEOPLE WILL LEAVE. Let me emphasize this. You are selecting for people that aren't good, because good people will have OPTIONS and THEY WILL LEAVE.
What are you left with? A management hierarchy of sociopaths. A subpar set of employees that furthermore will not cooperate in good faith (in the best case) or actively engage in institutional sociopathic behavior. You will have a cesspool, and cesspools repulse good people.
And the signal is right in front of people that apply: the hiring process is abusive hazing with the "raise the bar" bullshit.
Staff turnover means abandoned systems. Abandoned systems will be avoided as bad career risk, or reimplemented before the org has gotten good ROI from them.
THAT IS NOT GOOD MANAGEMENT.
Remember: AWS had a CRAP Christmas. Crap. This is starting to boil up.
How does one qualify the new candidate being better than 50% of current team. Better than 50% at what?
Every role has many dimensions, and most members of the team have a mixed set of strengths. You form a cohesive package if you hire complementary people and get 2+2=5 type of output.
The idea that everyone can be treated as an interchangeable cog and objectively, quantitatively ranked is pure silliness.
Where do we get one of those?
The central limit theorem doesn't give us one of those. Not even the Lindeberg-Feller central limit theorem. Neither does the strong law of large numbers. Nor the weak law of large numbers. Nor the martingale convergence theorem.
There is some old material, from about 100 years ago, in schools of education that given a performance measure and a large population the measure will be Gaussian distributed on that population, and the larger the population the closer to a Gaussian distribution. An example is supposed to be the size of the largest eigenvalue in a principle components decomposition. Uh, that largest eigenvalue was long called IQ (intelligence quotient). Nothing intelligent about it. Nonsense. 100% total crackpot nonsense. Brain-dead, cult nonsense.
"Low performers" in need of a "performance improvement program" (PIP)? Start with the managers who believe in a Gaussian distribution. Then move to the managers who believe that the "bottom 20%" are always low performers.
A lot is known about how to be a good manager, and the Gaussian probability density distribution is not part of that.
I've seen a lot of bad managers. A pattern is that they are tyrants, have lots of rules and measures, are big on formality over reality, dot i's and cross t's with great reliability, and have everyone with their nose to the grindstone, ear to the ground, shoulder to the wheel and trying to work in that position. But the organization is stagnant, is not changing or keeping up with the market or technology. So, after a few years like that, it becomes obvious to everyone, customers, BoD, stockholders, employees, even nearly all of the managers that the organization is about ready to die, and often that's what happens, e.g., by firing 50% of the people and going downhill from there.
Once I saw a failing organization where nearly all the managers except at the lowest level were part of a tight clique, cult enforcing failure. Finally the BoD installed a new CEO and fairly soon 80+% of the clique, cult were given "PIPs" and demoted out of management or retired.
But there is also good evidence that even such a sick organization does not have to die and, instead, just needs some good management, starting at the CEO level. In particular, with a good CEO, suddenly, wonder of wonders, 90+% of the employees can be seen as great performers.
So, net, as bad as the situation can be, it is fair to say that Darwin is on the case with improvement on the way!
At one time Amazon was a small mail-order book and record shop run by Bezos from a small office. At least looking from 10,000 feet up, Bezos was a good manager, and, thus, I doubt that he was playing with the Gaussian distribution, firing his bottom 20%, stack ranking, etc. Instead he knew all the employees and the work of each. Sooooo, it sounds like now Bezos should leave outer space, return to Amazon, and fix the destructive nonsense that is ruining the company.
HAHAHA well said.
1. It doesn't work, obviously because they are not in a closed system. Their policies affect their reputation, which will affect their ability to hire ICs who have to contend with an increasingly higher bar to clear.
I wish I could have said that's better than the alternative, but it's not. I suspect the ground is always shifting beneath you at Amazon. Even if your performance is fine, a colleague or your manager could get PIP'd
For a company that's vaunted for it's long-view philosophy, it's a terribly short-sighted policy.
(Somehow stack ranking logic never gets applied that way.)
https://www.washingtonpost.com/archive/politics/1994/07/17/h...
I also want to point out that a lot ppl who suffered or even lost their lives during such period were actually sabotaged or framed by their peers (neighbors, coworkers), rather than the authority.
All the counterpoints about whether 10% is accurate, whether you get the right 10%, whether they’re evenly distributed, whether there are other costs, why not apply the same logic to managers and execs, etc etc etc, yes, I agree!
All this being said, in the context of an organization that actually deserves to exist (a rarity, given that we live under capitalism), it is impossible to say what percentage of people will be ill-fit to their roles, let alone what percentage will be so ill-fit to any role that separation is the only option.
Amazon management practices will breed sociopathy at the root worker level.
I agree that is kind of the average-stage evolution of an enterprisey company. Amazon is worse.
The kind of mean-spirited pettiness that drives actual post-2000 capitalism, and it gets worse the higher you go, is so depressing and repugnant that it can't be put on TV.
Also, characters with no redeeming qualities are considered bad writing. But most coprorate executives are people with no redeeming qualities. You can't put them in fiction; unlike a well-written villain, they'll suck everything into a hole. Even Bill Lumbergh on Office Space had his charms.
If you take the run of the mill Java dev salary here, the net value is somewhere between 900 - 3000 Euros or so, across all levels of seniority [1]. Really makes one consider the benefits of working for companies in other countries, assuming that there are no cultural or time zone issues that cannot be dealt with.
Or, you know, to acquire skills that are high in demand but relatively low in supply.
[1] - https://www.algas.lv/en/salaryinfo/information-technology/ja...
Take Ireland for example. You're not going to be making US level money but I'd say you could easily double what you're making now and there's the potential to go much higher than that.
If you earn 30% more than a salaried employee you are barely breaking even most of the time.
And that's without the expenses, extra healthcare coverage, insurance etc.
So pretty average when you considering that junior developer salaries are within this reach in EU capitals.
Junior developers make 75.000€ after taxes? They make about 50 - 60.000€ BEFORE taxes.
I used 4 weeks, and by my experience that's generous (not talking about paid leave - all the freelancers I know are workaholics and don't take much leave, but maybe that's a US thing).
5*48 = 240 days, which works out to around 84000 EUR. Or 120,000 EUR - 30%.
Regardless, 700 EUR/day seems in the ball-park for a generic all-around developer.
£500/day is the absolute minimum for developer/DevOps outside London, £600/day much more common and including the cheap end for London. Senior is more often £800/day. You don't see values above that advertised, but people do obviously negotiate higher for specialist work; I have seen a mainframe developer charging £1500/day (on the low end of his range). Anything higher than that has always been a large consultancy rather than a freelancer. In my specialist niche I'd be asking for £1500/day top-end, expecting £800-1200 with negotiation depending on flexibility.
Height cannot be Gaussian if only because height is never negative but every Gaussian density is positive for all real numbers, including negative real numbers.
"interactions of many genes that are measureable"
The interactions of many is commonly used to justify a Gaussian assumption, but there is no such theorem. The main theorem to get a Gaussian density is the central limit theorem which usually assumes an infinite sequence of independent identically distributed random variables (plus some), i.e., i.i.d. The i.i.d. is asking a LOT!!! Asking so much that in practice it is essentially unrealistic.
What people often mean by Gaussian is just a central peak, some symmetry, and long tails, but an actual Gaussian distribution has a lot more, e.g., sufficient statistics (as in a classic paper by Halmos and Savage, with a derivation in M. Loeve's two volumes, from Springer, Probability) which, as I recall, E. Dynkin showed are quite sensitive to deviations from actual Gaussian.
Gaussian is important in a lot of derivations -- a LOT is known. But in practice Gaussian has some utility but only as an approximation where don't need to be very careful about accuracy.
Sounds fine.
If you treat heights as some i.i.d.s, then can use the central limit theorem to argue that in the limit for large samples (we get convergence in distribution) the probability density distribution of the sum of heights expressed as a z-score (mean 0, standard deviation 1) has Gaussian probability density distribution.
But that does not mean that the probability density distribution of heights is Gaussian. Indeed, if include both males and females, then for the density likely get two peaks instead of just one. If also include children, then get a left tail longer than the right one.
So, net, we cannot expect that heights are Gaussian. And we will have a tough time finding a large population that is Gaussian. z-scores in the limit for large samples Gaussian -- sure, can get that. A large population Gaussian, not much chance.
Well, at least as long as the culture fit is there etc., admittedly remote isn't for everyone, but on the flip side, geography/commute being less of an issue for the remainder of people is great!