Amazon was better when you cried at your desk

I used to work late nights to make things right for customers, but now I work all night to make things look good for managers.

Before 2016, Amazon had a formal performance review process which involved the following:
1. Developers wrote in-depth self-reviews about their past-year performance and set goals for the new year, and provided feedback for their peers and leaders backed by evidence.
2. The self-review and feedback is then used to rate the performance of the employee, which determined their compensation and whether they should be PIPed.
3. The manager communicated the feedback and rating to the employee in a transparent manner. The manager also provided a formal section-by-section critique of the self-review to the employee.

The process helped since:
- Bottom-up feedback from reports was used to assess management and leadership, which meant leadership was forced to be accountable to those below them through Amazon's own rating system.
- Factual peer-to-peer feedback allowed people to socialize their performance bar. The information communicated clear peer expectations to each other.
- Review of goals and setting new goals helped individual contributors to retrospect on their performance. It allowed us to assess our situation and reflect on what we want to achieve next. The mechanism enabled rapid growth for many developers I worked with.
- Hard-evidence provided in self-review and peer feedback ensures that one's contribution is the most important factor in the review. If someone in the leadership chain does not like you, they had minor affects on your ratings.

On the surface, the process seemed sub-optimal because:
- Transparent ratings felt threatening. When a person gets a bad rating, they may feel compelled to work harder in fear, leading to degradation in work-life balance and mental health.
- Negative feedback backed by concrete evidence was painful to read, impersonal, and hard to dispute. It is much harder to swallow something that is true and indisputable, than something one could dismiss.
- Substantial effort spent on such review felt like a political overhead for many. Developers sometimes spend weeks or even months writing reviews and feedback. For many, this felt like a waste of time. However, not spending time on it felt threatening since their ratings would depend on it.

These problems prompted the NYTimes article, "Inside Amazon: Wrestling Big Ideas in a Bruising Workplace", which described a cut-throat culture where personal problems are not respected, work-life balance is traded off for fear of bad performance, office politics seemed to be the rule, and, as a result, everyone cried at their desk. It also prompted Amazon to change its process.

Amazon made the following changes starting 2016:
1. Developers no longer need to back their self-review and feedback with evidence. The new review and feedback format encouraged short summaries.
2. The self-review and feedback is NOT used to rate the performance of the employee (this may be changing in some orgs in 2021).
3. The performance rating is NOT communicated to the employee. The manager only presents back the self-review, peer feedback, and a summary of their thoughts to the employee.

The new process addressed the problems mentioned in the NYT desk-crying article:
- Developers spent less time writing feedback for one another.
- Feedback summaries not backed hard evidence is open for interpretation, and therefore easier to swallow.
- So-called "cut-throat" ratings and anytime feedback was no longer surfaced to individual contributors, though managers and leadership continued to assign ratings and ask others for feedback behind your back.

It is a worse situation than before:
- Since the feedback in general is now detached from the ratings system, leadership is no longer held accountable to those below them through this system. A manager may get great ratings as long as he can hold his developers hostage while delivering business goals.
- The performance bar is no longer socialized among peers since the new feedback is more open to interpretation. SDE performance bar has been dropping since 2016 across the board.
- We no longer have a systematic way to help developers reflect on what they did and what they want to do next. As a result, many developers saw minimal growth year over year.
- Without having hard-evidence to back the performance of an individual contributor, the performance rating is now largely based on the perception of leadership. Your top-performer may get PIPed because a leader does not like them. Your under-performer may get promoted because a leader likes them. This has led to regretted attrition and low growth rate for developers.

Role: SDE III
YOE: 10 Years at Amazon
TC: 330K