Things I Liked About Amazon

I worked at Amazon for about 2.5 years in Product Management & Design. I left the company recently and have been reflecting on my time there now that I’m on the outside. While some negative pieces have been written about the company in the recent past, I had a really positive experience. Below is my view on what Amazon does well, focusing on the things that set it apart from its peers.

My previous experiences with company values were that they were written in some dark executive boardroom, published on the HR brochures and then never heard from again. Indeed its hard for me to remember the values of any of the companies I’ve worked for before this one. At Amazon, the Leadership Principles are company values that are deeply embedded into the culture and the lens through which candidates, employees and teams are evaluated and rewarded. Meet an Amazonian and I guarantee they can name all 12 LPs from memory and give an example of demonstrating them in their time there. Most of them are obvious things you want in any employee: e.g. Deliver Results, Think Big, High Standards, Hire/Develop the Best. Being Customer Obsessed (understanding customer needs and solving them, even sacrificing short term financial impact) becomes second nature for Amazonians but isn’t all that common in industry. Others like Right a Lot give a peek into the hardcore performance culture (it’s not enough to do analysis — your conclusions need to be right!). Beyond influencing behavior I like the LPs because they give everyone a common vocabulary for communicating about performance, which is hard to do at the best of times. I’ll be taking the LPs with me when I leave, for sure.

Nearly every meeting at Amazon starts with a document written by the organizer which attendees sit in silence and read for 20 mins. On the surface this sounds awkward AF. In practice it is brilliant. Writing a document forces clear thinking, complete analysis and concrete proposals. Reading the document ensures everyone is on the same page so that attendees can have a concrete and informed discussion afterwards. You rarely leave a meeting without actions and people who don’t attend can always catch up on what happened by reading the doc and notes. Like with LPs, Bezos has given all employees a standard SOP for ensuring the basics get done well.

This practice has started to seep out of Amazon — we did it at oDesk when I was there, probably because the brilliant Jaleh Bishrat brought it over from Amazon where she was an early VP.

The death knoll of “big” companies is usually when they slow down and stop shipping lots of new stuff quickly. Probably to counter balance this, at Amazon, shipping quickly is valued over almost everything else including product quality, work life balance and team alignment. I’ve seen this same attitude at all levels of management. This sounds bad but it’s certainly one of the reasons Amazon has been able to keep up with the kids of software, more or less. There are of course negative trade offs of this: sacrificing product quality was my biggest concern given that the bar is now high for consumer products.

At Amazon, operational excellence is taken very seriously and it shows in everything from the engineering culture to the way the businesses are managed. From an engineering perspective when there are bugs on Amazon.co that affect customers, “on call” engineers get paged on evenings or weekends and are expected to respond immediately and provide regular updates to managers and the team. Teams have weekly reviews on operational issues where they’re expected to explain the root causes of their service downtime as well as each significant bug that was hit by customers. They’re expected to actively drive down operational issues, focusing on prevention. When a serious bug hits real customers, managers are expected to do a post-mortem following a specific format asking the “5 Whys”. The list goes on and on. For this reason alone, if you’re looking to build a serious software company, an ex-Amazonian Developer or Dev Manager would be a great start.

From a business perspective this is demonstrated through the Weekly Business Review (WBR) which is a weekly walk though of key metrics with every leader on the team. Metrics owners are expected to come prepared with concrete reasons why they missed their metrics and what they are doing about it. While this is as fun as a root canal, it results in a team that knows their numbers will. For example, when I was responsible for consumer metrics for my team, I could tell you in excruciating detail where we were growing well and where we weren’t, factors affecting growth and impact of initiatives we were taking. Nothing crystallizes your priorities better than having to stand in front of your peers and leadership and provide concrete answers to every question. While there are things about WBR I don’t like (and situations where it makes less sense), its hard to argue with the growth Amazon has demonstrated across many categories and WBR is a key contributor to it.

Especially in Tech roles, there are very clear and inflexible things you must do to be promoted. As a result employees generally know what they need to do to be successful and you can be pretty sure that when an Amazon software developer gets to Level 6, they know their shit. The downside to such a rigid system is that sometimes talented developers will not get promotions they clearly deserve because they haven’t “checked all the checkboxes” and thus will end up leaving. In addition, dev managers will sometimes prioritize career development over business (eg. Postponing an important project because it isn’t the right complexity for their Level 5 SDE).

At Amazon every team works pretty independently. Teams can choose whatever tools, technologies and strategies that suit their needs or business context. Even the tech is built to enable decoupled work and thus scaling of effort. For example, to ship a new category on the mobile shopping app, we didn’t need the core mobile app team to write a single line of code — it is built in a way that enables any team to plug-in without depending on work from a central team which would be a bottleneck. The downside is that teams don’t work together unless there is an executive mandate to do so or some obvious opportunity which benefits both teams.

At Amazon, projects generally need a business rationale and decision making is usually grounded in delivering business results. I know that sounds a bit obvious, but it’s not always the case in the software industry that companies are interesting in building businesses :) or iterating on existing products until they deliver business results. The upside is that fewer projects are lead by the tech team that are just cool but not useful. The downside is there are fewer moonshot or experiments with no immediate benefits (although there are a few of those too). I suppose whether you consider this a strength depends on your perspective and role :)

An annual planning process sounds like something that would happen in a communist government run program from the 1960s. Nevertheless, every year at Amazon, teams are forced to create and review a document with the executive team which outlines in excruciating detail their performance in the previous year and their plans for the upcoming year including resource asks. Operating Plan 1 (OP1) is typically a 6 page narrative (with mountains of appendices) looking at every angle of your business and can be the difference between your team getting a bunch of new resources or getting cut into oblivion (Bezos and crew aren’t shy about killing teams that aren’t performing well). While I used to gripe about the amount of our time this process would suck up, the reality is that this kind of rigorous evaluation is probably one of the reasons why Amazon is able to be so focused in their investments and grow in businesses with relatively thin margins. By the way, while OP1 is happening, teams are still expected to be executing on their current plans, so, if you’re involved in this process, you’ve got 1.5 jobs to do :)

At Amazon, people make decisions using data. While this seems obvious and commonplace in the tech industry, at Amazon it is taken to the extreme where even small decisions or things that are seemingly not quantifiable are measured and evaluated. Everything is subject to this, from hiring decisions (Is the candidate better than 50% of employees at the same role?) to design (What proportion of customers in a usability test stumbled in the treatment?). The positive side of this is that data can be used as a tool for reversing any decision, no matter the seniority of the decision maker. For example, in my first few months at Amazon, a major decision was made by one of the Directors in our team, and I disagreed with it. I conducted a user research study to test my hypothesis, presented the results to our leadership and the decision was promptly reversed. In my opinion, there are downsides to being so data driven: people can use it as a crutch to avoid making bold bets using intuition about the customer (as my friend Lawrence Ripsher used to say, resulting in “Local Maxima instead of Global Maxima”).

Amazon is an amazing place full of sharp people. Jeff Bezos has been able to create a culture that has truly scaled as it has grown ensuring everyone at the company is pulling generally in the same direction and with the same level of rigor and intensity. I think many of the elements above play a part in that culture and I’m excited to see what my former colleagues achieve over the next 5 to 10 years. I believe Amazon will be around long after its peers have fallen to irrelevance.

Product Manager. Previously worked at Convoy, Facebook, Amazon and Upwork.