Five years later that company is now two CIOs removed from the original attrition warrior who left presumably to help the attrition rate even. The company still has a ton of long-timers that they seemingly can't get rid of. Why are companies so bad at coming up with a system that keeps more competent people and eases out less competent people but that also doesn't hurt morale by being a dystopian nightmare?
There will always be high performers and low performers on a team, both in a relative and absolute sense. Good managers don't make it their responsibility to close that gap; they just make it clear what the goals are, fill the team with self-motivated people, and provide the tools and environment to get the work done. And yes, you fire people if they don't meet a clear minimum level of performance, but don't make that an expectation out of the gate. Even if you cut all the "low performers" and double the "high performers'" pay, those people can burn out or get sick and suddenly turn into low performers. "First, Break All the Rules" is a great book on this topic.
There will always be high performers and low performers on a team, both in a relative and absolute sense.
Many years ago I was on a small (2-3 people) team with a truly genius-level coder. He was close to what you'd call a savant. He was (despite being a sweet guy at heart) incredibly difficult to work with - he was unfiltered and abrasive, and would write reams of code to solve pet problems that didn't really need solving in the context of whatever the hell it was that we were trying to do at the moment, because they were "fun" coding challenges that captured his imagination.
The end result was that while he could do the work of several engineers, you also... needed an engineer or two to work with him nearly full-time just to keep him on the rails and actually working towards the project goals, and to act as a buffer between him and people outside the team.
So who was the high performer on our team, and who was the low performer? Well, I didn't suck, but he was certainly the better engineer! But was I really a "low performer" when I did some of the equally crucial work of keeping him on the rails? Was he really the "high performer" when he required lots of people-hours from others just to keep him on task?
Those terms really lose all meaning when you're all engineers but are contributing different things to a team... the high/low performer stuff really only works when people are working in true isolation under identical circumstances. Like maybe for ditch-digging or weightlifting competitions or whatever.
It’s very difficult to evaluate articles like this without knowing the process. I could see it working if you had a simple process that relied on strong training and judgement with some governance to limit the impact of errors.
But if people get ranked based on some stupid ML algorithm and just sliced out of the company, that’s unpleasant for the fired staff, and for remaining staff. Fortunately, I think companies that do a dumb version of bottom 5% will fail or get corrected by their board and directors.
I read The Jordan Rules last year about the Bulls' first championship season and before the season begins, Phil Jackson says something like, "If Michael Jordan wins the scoring title again this year, we won't win a championship." This was after they had reached Game 7 of the Eastern Conference finals the year before.
If I remember correctly, Jordan did win the scoring title that year as well as his first championship ring. But even in a sport like basketball where there are stats and increasingly sophisticated metrics and data analysis, I find it most interesting reading about the less visible contributors and the crucial roles they often play. (Breaks of the Game, the book that inspired The Jordan Rules, I think does even a better job of getting into this aspect of the team dynamic.)
This is also related to the big idea popularized by Moneyball. But where Moneyball struck me as more relevant to hiring, reading about the NBA has led me to think about how teams perform together more carefully where the metrics as you say are often trickier.
In the 1990s, in cricket, we would see something like this from Sachin Tendulkar. He would reach 90s, then eat 8 - 9 overs to just get his century. Net result was, he would continue to set new records for maximum centuries scored- but the team would lose.
>>This is also related to the big idea popularized by Moneyball.
It's fairly obvious to arrive to this conclusion. Having a team full of super stars doesn't win you things. Though this is counter intuitive to understand- Quality exists at various other levels apart from heroism.
Basketball analytics have already begun to phase out guys in the mold of Kobe Bryant, Allen Iverson, or Carmelo Anthony who were great players who scored a ton but did so with (at times) low efficiency.
You have to use SOME kind of objective metric, to check your own personal biases if nothing else. But you're absolutely right in that performance metrics will never do your employees' various talents justice.
Things worked with this guy because at his core, he was actually a very sweet person! (And we were very patient and interested in making it work, if I may say so. Not that we did everything right, not by a longshot)
He was just kind of socially clueless, as opposed to actually malignant...
You can't fire people and keep the morale up unless the sacked have anti-social behavoiur.
Further more, if you can't trust management to hire people you can't trust them to fire people.
All metrics-driven systems that try to collapse complex effects to a single metric without intelligent human supervision tend to produce dystopian or at least spectacularly unintended effects.
In this case, the problem is trying to have a single axis of competence. Quite apart from the range of technologies and circumstances people might find themselves in, there are also the interpersonal skills and meta-competences that matter.
Then there's the company context: were they supported or let down? By their managers or colleagues? Were they working on something that failed for unrelated reasons? Or on something that succeeded despite their involvement?
In many ways it's the same as the hiring problem, it's just less concentrated on a single day.
Competence is a transitive property: people are competent at things, not as a global property of their personality.
So 3 times in two years there was a big push for the marketing, customer success, developer relations, and support etc teams to get ready for a launch that never happened.
How exactly is a customer success person supposed to be judged as a high performer if there are no customers? Support people sitting by a phone that never rings?
This is an obvious example, but I find the same thing really often in engineering groups: "I was asked to do X. I killed myself to make X happen. Turns out X wasn't relevant to the business and now it's all being shut down and I'm a lower performer."
Engineering (especially software engineering) seems like a particularly bad field in which to have "forced attrition" or stack ranking since so much of a team's success depends on the engineers' ability to work together directly on an interpersonal level, and for their code to be easily maintained/extended/tested by others.
I suppose there are partial ways around this, such as factoring rankings from one's peers into the forced attrition.
But overall it's very difficult to imagine any engineering environment that would benefit from incentivizing engineers to compete with one another rather than cooperate.
(Lot of engineers are already good at playing the game in which they look like team players, but are really autocrats of their own little silos and knowingly make themselves hard to replace & keep others down)
It's called the "dead sea effect" and it can be a tough problem to solve. I think every company has a certain percentage of low-productivity, low-competence employees that are hard to get rid of. Doubly so if the employees are unionized.
We have dead-sea effect to some extent in our company and honestly it seems our solution is to just wait until the underachievers retire and then be more rigorous and diligent when hiring their replacement.
And at a certain point, it's guaranteed to be you. Not today maybe, but it will be your head on the chopping block.
Probably because they can't tell the good from the bad.
Human resources are rented, and thus an expense not an asset; I mean, since the abolition of chattel slavery.
And then companies are surprised people job-hop :).
The problem is that it's a self-fulfilling prophecy. For the most part, people are less competent because they don't put in the effort to get more competent. Trying to force people to give more effort is not a fruitful endeavor unfortunately.
That is such an obvious outcome. When it seems layoff/low-morale seems to be coming, people who will leave for new jobs on their own are usually ones with the initiative, right skillset, youth, good with people, etc, which is why they can get a new job with ease. And these are the very people a company wants to hold on to. So the other option to achieve attrition rate is to have lay offs. But of course that is not good for reputation of the company.
> Five years later that company is now two CIOs removed from the original attrition warrior who left presumably to help the attrition rate even.
I have a suspicion the CIO was specifically brought in by higher ups to force higher attrition rate.
Dan Pink wrote a book and gave a took about this: http://www.ted.com/talks/dan_pink_on_motivation?language=en
I think the issue systemic and might need an overhaul.
Amazon is just taking advantage of all the devs that want to work for a big name, its a fair deal for both sides. They work you to death for 18 months, you get "Amazon" on your resume.
I for one, would not look too fondly on Amazon precisely because of the way they treat their workforce and because their product is not very good because of it.
Their revenues would suggest otherwise :)
Maybe they have children to care for at home and doing remote work would help? Maybe they don't like some of their colleagues and a team change is in order. Maybe after months of year of being proactive but being shutdown by management they decided to stop caring? Maybe it's more serious and they should be encouraged to see a therapist.
The janitor, working there some 40 years, retired with $28 million in his pocket.
All it took was management and labor deciding on what it cost to run the business, and savings over that, they put some into an expansion\risk fund, and the rest they split. That technology came out of the 1930's where people were starving, there was no capital and debt to work with, riots were commonplace, and people were looking at the management as food.
Funny thing, when everyone is watching out for one another and helping eachother, really awesome results tend to happen. Sure there's a personell mix issue, but personalities can grow and change. Realistically, all corporations should be run this way. We give the executive management immunity and then we allow them to abuse the staff. That's a recipe for disaster. The majority of company stock ought to be owned by the employee's doing the work.
There's this fatalistic romanticism that goes on with being the top dog, alpha male, name your price, et-cetera. This comes from rich people who never came out of their terrible 2's. They grew up leading isolated lives and never spent time with normal human beings, so they develop this superiority complex and go on tantrums. The reason you see so much advertising that makes no sense for executives is, there are so many of these "VITO's" out there and they all sell emotionally because they are literally box-of-rocks stupid.
The funny part of the joke is people, to their own peril, give respect to these people. We've managed to dress it up with modern marketing\psychological warfare, and we've managed to let the pack of grifters get so large they're now fighting over the scraps. A City of thieves produces no bread. Fertility rates are 1.72 in the US, USSR during its collapse was 1.2. We're halfway there. We need a term to define cannibalistic management; the kind of management there that figures out ways to literally eat people by entangling them in this web of socioeconomic corporatism. We already have "trap" music so we aren't far off, culturally, from defining it conceptually.
Accountants understand risk and cost, MBA's understand Risk, Cost, and Process. It takes someone with specialized experience and skills to figure out how to build an efficient process, or to do R&D because you need to understand bottlenecks and how to cheat at gambling; effectively it takes that kind of person to understand oppertunity, of which the other 2 don't.
So you get into these ridiculous situations where an accountant or MBA is put in charge, with no real understanding of the actual systems at play and its revealed to the staff executive management is really just a bunch of permanent vacationers or grifters. The really great engineers make up excuses based on prior, painful experience as to why they should leave and do so; the existing staff figure no matter where they go, they'll have to deal with the same BS.
Accountants and MBA's always strangle companies, so if you see a new executive manager who's resume doesn't have "line" experience, it's always time to leave for greener pastures.
There are more good ways to deal with people problems as such than there are good ways to deal with people problems as data problems.
The first one or two times a manager is asked to do this, there may be adequate dead-weight around that has accumulated "naturally".
After that, a significant number of managers will game the system -- they'll attract and retain people for this very purpose. Meanwhile, general employees will realize what's going on and you're going to have political games.
I don't see how this works for a company as a policy. It's too rigid. Meanwhile, a great way to get your attrition rate up is create a generally miserable environment. I can see executives patting themselves on the back for achieving their attrition goals even as their better employees are leaving for greener pastures.
This makes so little sense I would doubt it could really be true. Except I've see it myself, and worse (not at Amazon).
Could Amazon really be falling into the same trap so soon?
There are a tremendous number of low achievers in every industry and if you keep them around they are toxic, every bit if not more toxic than Amazon's culture in 2019.
That said, I would have liked to have seen most of the time dedicated to this task allocated to developing the careers of my direct reports because I think that is of much higher value to any organization.
Not hiring idiots in the first place is IMO the proper solution to this problem, but that now seems intractable. It seems there's a real temptation to scrape the bottom of the barrel to fill positions these days.
Of course, it's pretty questionable whether it achieves that aim - one would think it encourages managers to keep incompetent employees around as buffer.
I very firmly believe this, but I have created zero successful companies, and Jeff Bezos has created the most successful company that the world has ever seen, so there's that.
It does seem like Microsoft became far more successful after they did away with their famously bad similar policy, so maybe Amazon would be even more successful than they already are if they valued their employees a bit ;)
If you hire all rockstars and you have to let go of 10%, then how does this help?
So I'd say 500. You'd have to be very good at hiring to get a lower number, and judging from my anecdata, companies that hire software pros use hiring processes that are terrible predictors of future performance, if not entirely useless.
It keeps salaries lower than where they would be and pushes the remaining 90% to work very hard.
Do you not think such a culture is actively detrimental? How can you ask anyone to give 110% if they might be getting sacked next year?
If you have a tremendous number of low achievers, maybe its because the only people you can retain are people who can't find jobs elsewhere fast enough. I know I wouldn't be waiting around for my turn.
As much as I dislike the forced attrition mechanism, people putting in 110% are not going to be forced out. It's the people putting in 30% that are going to be the attrition targets.
My 30% could be somebody else's 110%, though that's not the likely scenario we're talking about.
What if instead, some people put in 110% by putting in 14 hour days and others are judged more harshly who have family or other obligations. This is how we get an industry of 20-somethings with no lives other than work. In a forced attrition scenario, if I were on a team with people significantly younger than myself, I would be shitting bricks.
I was noticeably older than most of the people in my team in Amazon, and I was never shitting bricks. The ones not reaching performance targets were always crystal clear to _everyone_. If you can't spot the underachievers, maybe that's the time to worry.
Despite how detailed the Amazon interview process is, people slip through the gaps and you end up with someone who somehow can barely write functional code, let alone maintainable code. Or you find the person is capable of writing code, just maybe not today, or tomorrow. Is the day after good with you? There are much more interesting things to be doing on-line instead of writing code.
 I was reminiscing with a co-worker in the kitchen one lunchtime about the respective things we'd had to do to deal with the Y2K bug at the places we'd been working at. Another talented and very capable developer co-worker overheard us and commented "I'd never even touched a computer before, back then."
The industry is not expecting mechanical engineers to actually do advanced work fresh of university but somehow in some places programmers are thought of as a ready worker package for the sewing machines.
I'm also yet to meet these programmers who can't code. There are plenty of engineers that barely can code though, but they don't call themselves programmers. And there are plenty of inexperienced programmers that can't code and if they won't learn they will drop out for other positions.
There's a difference between "can write code" and "will write code" which is what I was more intending to express in my post.
Everyone that gets a Dev job in Amazon has to be able to pass multiple loops where development skills will be tested.
To put it another way. You should be focussed on maintaining and motivating the top 10%, not on getting rid if your bottom 10%.
Exactly, but knowing that, even if you think you're safe, you might not be, so what do you do?
Plus you're saying below average people hire below poor talent.
This just means that really the good manager is sacking good people, whereas the poor manager is sacking just 1 of his limitless supply of poor hires.
So as an average employee what do you want, good manager and be bottom of the bell curve, or poor manager and be top of the bell curve?
This isn't as bad as it sounds as they got medical retirement.
There was no explicit "We need to get rid of x people" but there were performance reviews every year and getting the lowest performance mean being reassigned to another team and 3 consecutive lowest performance means forced attrition.
I don't even know why it's controversial (unless its a botched up execution). Most companies have dead weights that got in somehow and are toxic to the culture and a burden to the team.
We are not talking about 5% or 10% attrition rate here.
The most flagrant example of this in my experience was when I was ready to hand an AWS customer a simple script that would replace their command line application and magically make it run in the cloud, uploading inputs and, and downloading results, it was blocked from release to the customer immediately because it wasn't a full web app with staffing and an on-call pager.
Also this manager would get the feedback from all the teams his reports worked for and make his own decision. Quite often he would even ask the employee why his project manager rated him low.
Overall from what I had seen the process worked not too shabby even though it was unfair.
The decision and final axing was always done by the HR and managers could only intervene if they thought it was unfair.
Anyway, they have PIPs too. My slapstick comedy of 4 months there was nothing compared to the horror shows others endured there. That's how I ended up at Amazon in the first place and my first four years there were actually pretty good. It wasn't until the New York times article that things started going downhill there in my opinion.
Google has great food and great perks, but it was one of my worst employment experiences of my entire professional career. Amazon, warts-and-all, was far better to me and for me.
And I haven't even mentioned the time in 2014 when the manager of Android Store recommendations asked to speak with me and so I showed up on the googleplex, only to have him walk me out of the building to the swamp behind the googleplex to tell me that yes I'm on some sort of blacklist and he would make an exception to bring me in if I were willing to work on these recommendations. Now this is really interesting and nearly industrial espionage because I was secretly working on Amazon product recommendations at the time and he should not have known I had any such experience because we had just won our first web lab. It all ended when I asked him if I could use GPUs for this and he said no.
So my point is just because they don't have forced attrition doesn't make them a great employer across the board because WTF was that about?
I don't know about this personal drama with two particular programmers. I'm not sure it's relevant.
+1 to this. The reaction to that article was, in my personal view, the wrong one.
Oh god, I can't disagree more. I've been an interviewer at Amazon. I've probably done 50+ interviews in house and hired maybe 5 of those. I'd really prefer if we'd lower the hiring bar and focused more on building (and RETAINING) engineers. It would be far less effort, imho.
Seems like forced attrition is .. not ideal. Having some consistent way of assessing performance of engineers across teams, and then looking at the front end (hiring groups involved in creating the low performing teams) and on management (focus on who is accumulating higher numbers of low achievers) would be better.
But having seen excessively stable R&D organizations, I completely agree that not getting rid of low achievers is extremely toxic to a high performing team (product quality and morale).
Presumably leetcode avoids this. what is your opinion about that? Is it effective in your experience?
Leetcode questions measure interview study and how far removed you are from college classes, not how competent you are at your job.
Would you really want to hire such a person who does no work all day, and only prepares to move on from current company?
Several of my interview questions were slight variants on recent topcoder questions. And other than annoying the guy who clearly had some complicated algorithm he wanted me to write that I instead simplified to the quadratic equation, things went well.
As someone who's managed teams for many years, I think it's really odd to do this stack-rank thing.
A team is supposed to be more than the sum of its parts. People on the team do different things that are complementary. If you've ever watched sports, you know what this means. Not everyone is scoring the goals, someone needs to make critical passes, someone needs to get the ball out of defence, and so on.
That's not to say everyone should be paid the same. Clearly some roles are more rare than others and need to be compensated thus. But it is also true that your star needs someone to carry water for him, and that having the star and the water carrier makes the team more effective than two of either.
So when it comes to letting go of people, it rarely makes sense to try to decide who is productive and who isn't. A lot of businesses wouldn't even operate without juniors on the lowest grades. For instance junior investment bankers make powerpoint slides and financial models. Senior investment bankers, who have long forgotten how to use PowerPoint, take these to customers and get business.
The only times I've let people go is when I've thought the team really doesn't need this person. It's not a question of being inherently productive, it's a question of whether the marginal productivity of the team goes up. And as in sports, sometimes you find it's a star player who needs to go. Sometimes a bit-part player.
But in no sense is there a magic score from which the bottom can be removed.
What Amazon fails to consider is the number of high-caliber engineers who would never consider applying to work for companies that have policies like this.
Forced attrition is bad for morale but it's an especially shit situation every review-cycle, when people are on edge because someone has to go, no matter what, and it's either going to be themselves or someone that they work with.
"A-Players hire A-Players; B-Player hire C-Players"
If B:s hires C:s than in analogue A:s would hire B:s since it's a bell curve-ish distribution not digital buckets. Who hires the A:s? A, B and C:s by accident?
"I believe it forces people to improve themselves and their game."
You probably want people to improve their skills in their craft, not players to improve their skills in the a management game.
CFO: What happens if we train them and they leave?
CEO: What happens if we don’t and they stay?
1) Reserve 5%-10% of your staffing for people going to be laid off.
2) Hire people that won't make the cut after 1 year.
3) Fire them
4) Rinse and repeat
In other words the only reason they were being hired was so that the manager could protect the performers of this team.
Basically if the manager's view is the only one that matters, he can pretty much get away with it.
I want to be an SRE:
Scapegoat Redundancy Engineer
Charge by the month and rotate in different companies to be hired and fired yearly!
I'd rather deal with a company that puts all of its cards on the table like Netflix does rather than an implicit forced attrition process that is described here.
Even in team with very skilled and productive engineers managers will still set expectations so high that someone will be put on dev plan.
The forced attrition is no surprise. I’m in Seattle and considering the thousands and thousands of people they were hiring in recent years, it would be impossible to not get the bottom of the barrel devs who can pass algorithm problems but fail to work independently or deliver at all.
I believe because people do not see forced attrition as a surprise, they also believe this post. I agree that we shouldn't take every Reddit post as truth but it makes sense in the culture Amazon portrays. Also there hasn't been anybody that offers a counter perspective into the inner workings (that I have seen). True or not, it would be interesting to see the companies that do practice this and what kind of workplace culture they put forward.
My experience has been that people at Amazon are generally pretty willing to help each other in various different ways, whether helping a teammate on a project or helping someone new to a technology on one of our internal mailing lists.
Many on the reddit thread take it for granted that Amazon is, as one person called it, a "hellhole." That is not at all my experience - I know others in different orgs or different roles may of course have a different experience. Amazon has been significantly less stressful than almost everywhere I've worked (and the one exception was not less stressful in a good way).
At least among people I know, most of the people who leave our team join another team at Amazon. I've known a few people who have left Amazon, but we haven't had 5% of our team leave Amazon every year as this thread would indicate.
For seniors: yes be wary.
Apparently the US HQs of Japanese motor companies follow Japanese corporate model and do not lay off employees. So they end up with quite a bit of low performing employees. Just rumors I heard.
And then there were those who really really did not generate output at work and apparently management hoped(?) they would do the same in their personal life and not bother moving to another state.
You seem to think that this desirable goal is actually achieved by this method.
If there is, does it offset the potential tendency of workers to not want to help new hires getting up to speed in fear of being eaten by the alligator?
What about teams that turn around and beat the alligator to death with sticks. It sounds like the foundation of civilization.
Maybe cooperation is not for co-operations. Who knows.
Or, in other words, the above comment is making broad-brush conclusions out of zero data points. sigh