Working Backwards
For years, I have admired Amazon from afar. No other company has created so many compounding loops as part of their core business (and that doesn't even include the potentially larger business of AWS!).
They've somehow managed to scale a culture that values growth, expansion, and innovation to millions of employees. It's incredibly impressive.
Working Backwards shares the operating principles that helped Amazon grow. It's authored by two 20-year veterans of the company, each of whom had a front-row seat to working with Bezos and the leadership team.
My biggest takeaway from the book is that Amazon (largely driven by Bezos) has applied a tremendous amount of systems thinking and focus on the customer to its internal operations. While I'm sure the book shares an overly rosy view of the company culture, it's tough to argue with the results that Amazon has been able to achieve.
Leadership principles
The book starts with the leadership principles. If you've read anything about Amazon, you probably know that there are a bunch of core values that Amazon screens for as part of the hiring process (more on that later). Their site lists 16 as of today.
There were three principles that stood out to me as part of this book...
Customer obsession
Amazon's mission is to be "the world's most customer-obsessed company". I've always felt that this mission statement was a little vague (customer-obsessed, what does that even mean?).
But the examples in the book changed my mind. The authors share enough cases where Amazon effectively blew up an existing business model (2-day delivery, Amazon Go Stores) or entered an entirely new market that they had no expertise in (Kindle, Alexa Prime Video, AWS), that I was convinced that there's something more to Amazon's process.
The key tenants of customer obsession are...
- work backwards from the things that customers want, don't start with the things you are already good at (too many businesses do this)
- start with a PRFAQ document to highlight the expected behavior and the trade-offs you're making
- it's okay to disrupt an existing business to get closer to the businesses customers actually want, these are the type of businesses that win in the end (a la The Innovator's Dilemma)
- run a lot of experiments, focus more on growth rate than existing revenue
Bezos has a particular knack for identifying the key levers that customers want. His decision to push for two-day delivery happened during a charged holiday season when the company could've simply decided to focus on revenue for the quarter (rather than revenue for the next ten years).
Ownership (aka long-term thinking)
Amazon puts a strong onus on everyone at the company acting like an owner.
I was surprised to learn that Amazon capped its salary at 160k. Instead, employees would get generous equity packages that would align towards long-term shareholder interest. I'm not sure if this is still the case today, but it's a really interesting concept.
Leaders at Amazon tend to think more about the growth rates of different businesses rather than the current revenue. When Andy Jassy had the opportunity to run any business he wanted at Amazon, he decided to grow AWS from nothing rather than command a $1B P&L.
Good intentions don't work, mechanisms do
This isn't a principle, but it's a line echoed again and again throughout the book.
When you hire great people and a team doesn't succeed, you can't just tell them to "try harder next time". They were probably already trying hard the first time!
Instead, Amazon takes the stance that: good intentions don't work, mechanisms do. At scale, you can't rely on everyone doing the right thing. Instead, mechanisms and processes have to ensure it. They use techniques like The 5 Why's from Toyota's Manufacturing Concepts (e.g. any support rep at the company can immediately de-list an item from a seller page that is causing too many returns)
As one meta-point, it's interesting to note that the leadership principles were borne out of the need to scale. In the early days, Bezos would interview every single job applicant. But as the company grew, that became untenable.
So, he and a member of the operations team set forth a 9-month project to capture the principles that made someone "Amazonian".
At many companies, these sorts of values seem aspirational at best. But I get the sense that Amazon really did try and codify the way Bezos would operate.
Hiring: The Bar-Raiser Program
The hiring section had a lot of fairly basic stuff, but an interesting Amazon-esque flavor on it.
If you don't focus on building a scalable hiring program, culture is going to run away from you. "At amazon, we had new people hiring new people hiring new people." Once again, good intentions don't work, mechanisms do here.
Every interview had a 'bar-raiser' component. The bar raisers were a trusted group within Amazon who could block a hire if they failed to show competence in Amazon's leadership principles.
Every interview has to start with a job description. If you don't know what you are hiring for, you are bound to make mistakes. Make this as clear a set of skills as possible. If you're an early stage startup who needs people to code, don't hire someone who previously did a lot of 'coordination'! Apparently Amazon had a specific effort to avoid coodination at some point.
Every interview must have written feedback directly after, which is not shared until the final debrief.
When asking questions, focus on STAR: situation, tasks, actions, and results. It has to be something where the interviewee actually is able to get down to "what they did".
Direct reports may not interview a manager. This was a surprising departure from what we did at Segment, but the reasons for it are decent: direct reports won't be happy if they say 'no hire', and may be more reticent to share feedback.
The book claims that bar-raising helped increase diversity and reduce bias.
Two-pizza teams and single-threaded leadership
Any leader at the company should have the ability to be 'single-threaded', where they are only focused on one key, important task (I think Paypal had a similar concept that I read about somewhere). A team should be able to execute against its goals with minimal dependencies.
This was borne out of the earlier 'tangled' amazon system. Previously, teams would ask one another to make changes on the same codebase or the same database. There was a famous "database cabal" who would meet 2-3x per month to approve any changes to the core database (this happened at Linkedin too!). Progress slowed to a halt.
Eventually Amazon re-framed the problem. Instead of trying to improve and increase cross-team communication and coordination, they instead decided to eliminate it entirely! (See Steve Yegge's Amazon Platform Rant)
Where 2-pizza teams worked
Small teams of 8-10 tend to work really well.
Teams which have full ownership over their mission work really well. They shouldn't be beholden to anyone else and should de-couple interactions via APIs.
Teams which carry their own P&L and own metrics that they are responsible for work really well. This helps the team think like owners and try and find the areas of biggest impact.
The S-team (aka the exec team) is responsible for helping test the metrics and goals, teams are responsible for the "how".
Where 2-pizza teams didn't work
R&D only. When Amazon tried out on sales, legal, HR, there weren't any benefits. These teams don't have dependencies in the same ways, since the processes are relatively well-defined.
Amazon famously had each team create a "fitness function". This would be the single scoring function that would reveal how well a team was doing. Ultimately the fitness function was abandoned. It ended up being too complicated in practice and too many teams agonized over what weights to give vs just monitoring the right metrics.
GM-style managers of 2-pizza teams were really hard to find. Amazon had a few of these, but they eventually folded into a Matrix org instead. I can speak to our own experience scaling Segment that cross-functional athletes who can think about business, tech, and product are very hard to find indeed.
Some teams end up having to serve other teams. This is viewed as a 'tax', and some teams are in a higher tax bracket than others.
Single-threaded leadership
The update on Two Pizza teams: Single-threaded leaders.
A single-threaded leader should be responsible for everything they worked on, and only care about that one area. That said, the team could be bigger than two pizzas, so instead the idea of the single-threaded leader arose.
Six Pagers
Originally inspired by Edward Tufte, Bezos decided to ban powerpoints. This meant that anyone could write a six-pager, and the first 20 minutes of the meeting were spent in silence reading it. It helps separate the ideas from the presenter, and helps anyone (whether they were in the room or not) figure out what happened.
This was done at S-team meetings to inspire better decision making and more clarity of thought. With a presentation, it's easy to get low information density and low clarity of thought. Anyone can throw together a powerpoint, but it's tough to craft a well-drafted six-pager.
There's a gem in here about Bezos' own technique for giving feedback: "I assume each sentence is wrong and try to convince myself why it might be true".
I think there's a lot to this idea, and it's one of the cornerstones of High Bit-rate People.
Working Backwards
Start with mockups, PRFAQ, and customer demands. Never start with the engineering "what's possible" first, because it's likely that you will miss the market demands. A good example: Samsung decides to launch a TV, Marketing finds that people want one for
Bezos was apparently a stickler for high-fidelity mockups. If a team didn't have them, it wasn't worth staffing yet. (my cofounder Ilya Volodarsky does this too!)
There's a good example of the PRFAQ in the book talking about a proposed "Melinda" device that acts like a lockbox/refrigeration unit for groceries and deliveries at your front door. It is sure to include TAM calculations, cost of materials, and names explicit customer problems.
An interesting note, PMs are expected to build many of these, and then not ship most of them. It reminds me of Sam Hinkie's motto: "if you aren't happy with the existing options, you should get more of them!"
Input and output metrics
Teams should ignore any metrics that they don't have direct control over (e.g. "output metrics"). These really aren't able to be influenced and won't help the team move forward. Outputs (things like stock price) are distracting.
Instead, teams should focus on inputs. Which metrics they can directly control which lead to the results that they want. (Keith Rabois subscribes to this same idea)
All metrics are examined as part of a "Weekly Business Review". There, the teams will try and understand "what's actually happening" with their part of the business.
There's a great story talking about how these metrics evolve. Initially for Amazon it was "number of product pages". But they soon realized that number of product pages didn't matter if customers didn't see them! So the metric moved to "number of product pages customers saw". But a product page wasn't any good if the item wasn't in-stock, so the metric shifted again: "number of product pages customers saw with items in-stock"
Every week a metric should be reported on, and owned by the person who has watched it daily. This tracks with my experience running digital with Ilya.
Case Studies
The book ends with a bunch of different stories of different products, and how they did (or did not!) use the working backwards process.
Kindle
Amazon's first foray into hardware was really interesting. They did a bunch of work focused on the 'whispernet', a service that ensured you could download an e-book at any time of day. In retrospect, this was pretty revolutionary. They also acquired technologies for the e-ink and the Kindle software.
I'm not sure what to make of the Kindle from a commercial perspective, but building Amazon's hardware muscle clearly seems valuable.
Amazon Prime
Borne out of an obsession with the customer: the big issue is that the options were either to pay for shipping which is fast, or get free shipping which is slow. Both of those options suck. Obviously a customer wants free shipping, fast!
Bezos realized they needed to create a moat around their customer base. That moat was prime.
What's interesting here is that apparently Amazon's existing infrastructure could not service prime. Instead, they had to build entirely new software and a new fulfilment strategy in order. They don't talk much about the specifics here in the book, but re-tooling Amazon's fulfillment sounds like a fascinating story.
Prime Video
Prime Video was originally launched as Amazon unbox and was a huge failure. The biggest problem was that they approached it in a decidedly un-amazonian manner!
They paid too much attention to competitors and rushed the launch (because apple was going to launch the same day). They didn't think about the raw customer experience, which was focused on being able to download films (vs stream them).
AWS
I hadn't realized this, but part of the impetus for AWS came from trying to give sellers an API for items that was only data. Sellers did wild things with this data, they created a "graph view" of Amazon, games where users had to identify the author based upon book cover art, and a mobile version.
The whole chapter is a great reminder into how 'static' the internet used to be, vs how dynamic it is today. An API used to be sort of a crazy thing, when today it's basically table stakes.
It also made me consider what other APIs out there that need to be created? Some sort of hard real-world process that everyone needs to go through? Good examples: background checks (Checkr), food delivery (Doordash, UberEats), transportation (Uber). I'm sure there are tons in the medical + shipping spaces.
There's a tradition at Amazon of leaders joining currently small, but high growth efforts. Leaders want to care more about the growth rate of businesses, rather than the overall revenue that they command. After all, even Amazon's core retail business started by generating tens of millions per year. Andy Jassy could have taken any job at the company, and he decided to start a new department.
