Working Backwards Book Review
Working Backwards is the most important book to read for Series A+ founders this year. I’m surprised that Amazon allowed this book to be published, since it goes into so much detail on processes that Amazon created which have given it a competitive advantage over the last twenty years. Although it describes a period of time after Amazon went public, that was an era when much more immature companies IPO’d. The struggles Amazon was dealing with and their solutions are a must read for high growth founders in Series A+ companies.
This review is not intended to be comprehensive, but to point out the areas most relevant to high-growth founders. The four main topics I found useful are how to organize your team, how to use time well, how to stay creative, and how to build a moat.
Organizing Your Team
1 — One metric per team
The book does a great job of describing what happens without a single metric per team. When a team has a choice between two metrics or more to define success, they inevitably go for the more known metric, or the easiest one to move. Amazon tried fitness functions which combines metrics into a formula, but quickly realized how good people were at gaming these formulas. It should not be earth shattering in 2021 that having a single metric pinned to a team is the way to get things done, but I would say only a quarter of my Series A+ companies can show me an org chart broken down by teams with a single metric each. This works, you should do it.
2 — The smallest unit of organization is a pod with 6–8 people and larger teams are made up of pods.
Importantly, the book goes through the typical thing I see my startups try instead of getting to pods. Amazon tried lots of coordination and project management efforts to prioritize the myriad tasks flowing into the engineers queues before finally throwing up their hands and getting to small teams with single metrics. The most important insight here is that the team must be completely autonomous, with all of the resources in their control to achieve their goals and no requirements to do work for others.
For founders, the most common bump on the road to pods is that the people on the team aren’t senior enough to take on leadership of pods. Many times, product people are stretched across too many projects and engineering talent is too junior to lead an autonomous team. I consider these forcing functions both for focus (do a smaller number of things well through pods with clear metrics) and for hiring (get the right people on board capable of leading an autonomous team).
Probably an equally valuable insight is that larger teams are just collections of fully autonomous pods. This is a massive change in approach from the departmental organization that still dominates many companies. This is an area where larger tech companies like Facebook and Google are ahead of startups. They have had to disaggregate power and responsibility to autonomous teams to compete.
3 — Technically, the product needs to be separated into clean interfaces so teams don’t depend on each other and don’t step on each other’s work.
My favorite description of this is here by a Google engineer who had spent time at Amazon. Ultimately this allowed Amazon to create AWS, but more importantly, it allowed Amazon’s pods to be completely autonomous, working with shared services through well defined interfaces.
Organizing Your Time
1 — Instead of slides, Amazon meetings require a memo of no more than six pages. That memo is read during the first twenty minutes of the meeting, with team members sitting together silently.
The main point to me here is that using a narrative structure for discussion and decision making is superior because people need a lot of context to get their heads into your idea. The second point is that people need time to digest the context before discussing. I give Amazon a lot of credit for blowing up the traditional meeting structure, which I think is a waste of time for 80% of the people in the room.
Some of my startups have gone even further in the covid and post-covid era. Instead of scheduling a meeting, they write a document, allow people to edit it, and hold a meeting if there are meaty disagreements or areas that they want to go deeper in a live session. There are a few reasons this works well. First, most people don’t think well on the fly. They come up with the most obvious answer instead of the one requiring deeper thought. Second, many thoughtful people are not comfortable taking on the powerful in a meeting context, or don’t express their thoughts as clearly, but may be willing to state their case in writing and then give it enough thought to discuss it in a meeting.
Staying Creative
Neither Amazon’s core cultural principles nor the authors lesson learned chapters discuss the area that is most admired about Amazon — the ability to stay creative at scale. Luckily, the second half of the book talks about the development of Kindle, Prime, and AWS and could be called the Experiment Your Way to Success section. It starts with a great quote from Bezos, “I believe we are the best place in the world to fail, and failure and invention are inseparable twins. To invent, you have to experiment.”
It is very important to note that the type of experimentation Amazon does is dependent on single-metric autonomous teams. Repeatedly they would put someone in charge of an experiment like a Kindle or other new product, and remove them of any of the burdens of their previous role. We used to call this type of operation a skunk works or fly a pirate flag like the Mac group did at Apple. Amazon operationalized it using single-metric autonomous teams. The teams have no dependencies and no responsibilities other than to achieve their goal, and that unlocked the creativity necessary to find an answer if one was there.
For example, it’s really shocking in retrospect that Amazon had the gall to become a hardware company. Back in 2007, when they launched Kindle, contract manufacturing was still pretty nascent and being a hardware or software company was pretty defining. So breaking out of that box was a real testament both to the customer orientation of Amazon (people needed a better digital device for reading books if Amazon was going to make ebooks a big business), to single-metric autonomous team structure and to their experimental/iterative method of getting there.
Creating a Moat Intentionally
I really appreciated the section on the development of Prime, because a lot of my companies find product market fit, grow incredibly rapidly, but don’t necessarily have strong moats. If I had written the chapter on Prime, I would have titled it “Creating a Moat Intentionally”, because they leaned into the single most difficult thing in the business — removing friction from shipping — and built something that no one has yet copied successfully, and one which has a scale barrier to entry that may allow it to never be copied. One of the most fascinating parts of the book is the narration of all of the things Amazon tried with high urgency before they got to Prime. It dispels the Hollywood version of startup stories where the founder has a brilliant idea and money rains from heaven.
For founders, my advice is to buy the Audible version, put it on 2x and listen to the following chapters while you work out. The whole thing will take just under 2 hours to read and likely will change the way you think about building your company:
3. Organizing: Separable Single-Threaded Leadership
4. Communicating: Narratives and the Six Pager
7. Kindle
8. Prime
10. AWS
