Coderific

rating for Amazon.com

1.0 culling 10% of employees a year posted on July 26, 2010

I've recently heard that Kalpanik S. has published a book called Inside the Giant Machine: An Amazon.com Story.

In his book he talks of the cruelty curve in which Amazon fires 10% of its employees a year. A selected employee is put on a performance plan and fired soon afterwards.

In my group in the space of 6 months, 5 software developers were either fired or strongly encouraged to resign and two managers lost or resigned their managerial positions.

So this is fire rate of well over 30%. It is difficult to give an exact percentage because our two sister groups were merged and disbanded at the same time.

If you go through multiple rounds of firing people, how does this 10% figure work? How can you be in the bottom 10%, when a few months ago over 10% of your group were already fired. Not that I really care where I'm placed by a disfunctionality system led by _flexible_ managers. And nor should you.

I got fired as part of this curve and got no pay-off from Amazon. But curiously people fired before me from my group got two months' salary. Why? Why were some people treated better than others? Surely you would fire the weakest workers first? So why were the weakest workers paid more than the stronger workers? Hmm. The whole thing is silly and bad anyway. Who cares how a dysfunctional, political system treats and evaluates its victims?

I was also told if I did pager duty originally assigned to a new hired SDE I would be less likely to be fired. How does doing someone else's work fit in with this scheme? It seems like the scheme was perverted. Ironically I was attacked over the fact that one person said he had to do some work that I was supposed to do (actually this guy failed to get the latest source code out and so failed to notice the bug was already fixed!!!!). Yet I was bullied into doing pager duty assigned to other people. How sick is that? At the time I was doing lots of pager duty and so thought doing yet another lot would be a bad idea.

At one point during the procedure to fire me, I was told that as far as my manager was concerned I could stay in the company another year. Was I being strung along? I was certainly fired a few weeks later despite the comment.

If you are firing 10 - 30% of people a year, what will happen is that people that have been in the company 3 - 5 years will end up really valuable and all that will happen is that you end up firing people that have been in the company 1 - 2 years (as they have less knowledge of the codebase). People that have been in the company less than 3 months at the time of the firings won't get fired as that would just look silly and be very mean. So this 10 - 30% rule means that you get target people in between their 1st and 2nd years.

Was any of this thought of?

Would groups just hire new people so that they would have fodder to fire?

During my last 6 months at Amazon.com I had to work numerous weekends and evenings to fix bugs caused by other groups at Amazon.com. Plus I had multiple small projects to do. Constantly being interrupted from project work to fix bugs in projects I was not familiar with was very stressful as most of the work I was doing had to be done within days as it affected core functionality. At the same time I was constantly being harassed and put down by my manager as part of this curve business.

The things I was attacked over were imaginary. Chance little things I said in the corridor about a project were purposely misinterpreted and written up as an attack on me. You are targeted first and then a case made against you. To weaken me I had lots of work assigned and a barrage of silly criticism launched against me.

At some point people really need to rebel against this crass stupidity of bullying people to force them to leave the company. It is inhuman.

Hey you just have to non-cooperate when you are being asked to be inhuman. Why don't people learn this? Well I suppose if they manned-up and did the right thing, then they would be in the firing line as well!

At a group wide meeting, one manager said that SDEs should aim at fixing 10 bugs per month. My manager told me I would be fired if I did not fix at least 20 bugs per month. Taking out the weekends from a month, this is almost 1 bug per day. So why was my bug workload doubled? Was this fair? Now the thing is that some Remedy bug tickets required a small amount of coding, some were duplicates, some required no coding and some required two weeks worth of new code written because they were not really bugs but whole areas of functionality that were never implemented. So this figure was absurd. If I got a Remedy ticket which wasn't really a bug fix, but a mini-project then I would get fired for sure. This actually happened. One bug to do with prices wasn't really a bug. Whole areas of code were never implemented for it. Plus most bug fixes require code reviews and QA, which take more than 1 day to complete. So the whole thing was set up to fire me for sure and I never had a chance. Is this dishonest? Why not just fire me instead of making me dance to harassment over a couple of months? Was luring me by saying I would be less likely to be fired if I did more pager duty unfair?

Ironically the new director at the time said more time should be allocated to do things properly. So why did my manager say I should fix 1 bug per day or be fired? Is this allocating more time to do things properly?

The Fixed Review
===============

The problem with trying to numerically evaluate SDEs, is that each employee is doing different projects with different co-workers. One SDE may do 6 small projects and fix 30 bugs caused by other people in the space of a year. Another SDE may do 1 project only in the space of a year. How do you compare these different workloads? If you do 6 different projects with 6 different managers in a year, and you get 1 bad review out of the 6 then you can get fired. However if you stick with 1 large project, then you are less likely to get a bad review even if you do much less work. Quite frankly doing 6 different projects in 12 months is more difficult than doing 1 project in 12 months, because you have to learn much more about the undocumented codebase.

In my review I named managers that liked the work I did. However my manager did not reference any of what these managers said in my review. My manager just honed in on one bad review, which was a mistake because the code was working fine until two different projects submitted code that altered the same functions at the same time. The problem was known and fixed internally. So this bad review was the result of a misunderstanding. One wide-boy SDE just jumped on this problem to look good at my expense. There never was any problem with the code I wrote, it was just another totally separate project submitted code into the same functions at about the same time.

There was one bug that my manager suggested a hacky fix for. He attacked me in the review for not thinking of this fix. However this was unfair because I was not familiar with this area of the code because I had never worked on it before. As I had recently moved sub-groups this area of code was not even the responsible of the old sub-group I was in. The sick joke was this manager's hacky fix DID NOT EVEN WORK. So I was attacked over not thinking of something that did not even work. I had to remove this manager's hacky fix from the codebase after problems with it were noticed. Yet the attacks on this went on even after I had told the manager about this. Did they even read what I wrote and listened to what I said during the review? Obviously not.

After being at Amazon.com for a few months, my workload increased enormously. I was working evenings and weekends. I was assigned one smallish project to do. The project manager for this project was different to my actual manager. My manager told me project managers can't tell you how to allocate your time, only managers can. While I was doing this small project my manager constantly gave me bug fixes (in projects I wasn't a part of) to do. In fact I was interrupted seven times during this one small project. I told the project manager of each interruption. At one point my manager told me to drop the project and then he ran off. I looked for him in his office but he wasn't there. I was going to tell him I just needed 30 more minutes on this project and then I could put it to one side and another employee was depending on this work. So I couldn't work on this project anymore. As another employee was being held up the project manager piped up. I had previously told my manager that I was being overloaded with work, but he just replied Amazon employees should be able to multitask. At my review I was criticized for the last interruption, although there was nothing I could do about it. The fault of my manager was that he didn't stick up for the SDEs enough. This was a management problem of giving all the bug fixes to people (i.e. me) with small projects and not making the people doing longer projects take up their fair share.

The whole review was a joke. The people responsible for it should be ashamed.

A Colleague Was Fired But Management Didn't Know What He Did Last
=========================================================

A fellow group member of mine was fired. Well actually he was in a different sub-group of the same group. I didn't really know him that well. I had only spoken to him once or twice. A couple of projects he was working on were passed on to me. My manager just told me to push out the projects as fast as possible. I was not familiar with the background of these projects or what had gone on. My new manager just assumed that the project work was mostly or totally completed and only needed some QA. After looking through what code had been written I finally worked out that very little working code had been written for both projects and one project only consisted of cut-and-pasted code from a totally different bit of work. Obviously the code did not work, not because it wasn't buggy code - it was totally the wrong code! Maybe the guy had no real time allocated to do this work. Actually his experience was writing code in another language and so he was at a disadvantage doing this kind of work.

As such I never had any time to work on these projects and I was constantly given a stream of bugs to fix caused by other groups and people. I finally managed to finish both projects and my code worked first time around.

But it just shows my colleague was fired and management had no clue what he had been doing in the last months.

What management should have done is waited until this guy had finished and pushed out his project work instead of firing him before the work was finished. The incomplete project work was handed to me and then within days or weeks of being handed this work, I too was told I would be fired!!!!

You're Fired, But We Expect You To Work A Few Weekends Before You Go
============================================================

Thinking back it was just crazy that I should effectively told I was incompetent, was fired, had to work my last two or so months and then was asked by the management of the group to work on some weekends. I also was woken up at midnight to fix some major problems (not caused by me). Why did management not think this state of affairs was crazy? I could have easily have told them I was fired and they should fix their own problems when I was on-call in the early hours of the morning. But I did not.

The Arrogance
=============
Amazon.com may have achieved great things, but when I was there (circa 2001) areas of the code base were mostly undocumented and fragile. A great deal of my work was fixing problems causing by other groups, people or bad process. Yet despite this my manager had the bare-faced arrogance to attack me again and again over unresearched and imaginary problems. How could I be incompetent when a lot of my job was to fix problems caused by other people (well maybe this happens when the code gets very complicated)? Since I have left Amazon my software works first time around and has thousands of happy customers. I make a living that does not involve waking up at odd hours to keep buggy systems alive.

The End
=======

The most disappointing thing about my time at Amazon.com, was not that I lost my job (although the procedure employed by my manager was awful - I should have just been fired instantly instead of the procedure dragged over months), was that what I am competent at was wasted. A lot of my time was fixing bugs, being woken up at 6am and midnight for false alarms and not actually writing real software.

Now that I'm out of Amazon.com I have managed to make a difference. In my small area I've managed to create software that managed to maintain several advantages over the competition for years. People congratulate me for what I've done rather than dragging me down in a quagmire.

Summary
========
Although I was told I was being fired, it took months for the process to complete. During this process I still was woken up at 5/6am in the morning for false alarms, had to work weekends (pager duty, sharing pager duty etc) and had to wake up in the middle of the night to fix problems (not caused by me!). Despite this work my manager threw complete nonsense in my face during this period. It was shameful.

See 24 more ratings for Amazon.com!

0 comments

Write a comment!
    scores in this rating

    development process

    clear requirements unrated
    design and planning unrated
    quality assurance unrated
    automated testing unrated
    peer review unrated
    development environment unrated
    development hardware unrated
    physical workspace unrated
    infrastructure and support unrated
    issue tracking unrated
    source control unrated
    product quality unrated

    culture

    cultivation of creativity unrated
    mitigation of risk unrated
    reasonable workload unrated
    prevention of crunch time unrated
    hitting deadlines unrated
    taking responsibility unrated
    development autonomy unrated
    keeping ego in check unrated

    compensation

    salary unrated
    health coverage unrated
    paid time off unrated
    snacks unrated
    other perks unrated

    organization

    advancement opportunities unrated
    employee retention unrated
    hiring process unrated
    quality of development management unrated
    quality of upper management unrated
    quality of developers unrated
    team-to-team communication unrated
    internal team communication unrated
    management-developer communication unrated

    general

    location unrated
    nearby food unrated
    business model unrated
    cool technology unrated
    vision and strategy unrated
    warm fuzzy feeling unrated
    overall 1.0

    preferences

    casual dress code unrated
    use of Free Software unrated
    development of Free Software unrated
    use of GNU/Linux unrated
    use of Mac OS unrated
    use of Solaris unrated
    use of Windows unrated
    use of BSD unrated
    use of Python unrated
    use of Perl unrated
    use of Ruby unrated
    use of Lisp unrated
    use of Java unrated
    use of C# unrated
    use of Objective-C unrated
    use of C unrated
    use of C++ unrated
    use of PHP unrated
    use of ASP unrated
    use of legacy languages unrated