Review: Working Backwards

 Working Backwards is written by two Amazon executives who'd each been at Amazon for more than 10 years. When reading business books like this, you expect the usual business guy's self-aggrandizing focus on his great decisions, his ability to work heroically, and how great his CEO was. But Working Backwards surprised me with first, how easy it was to read, and how clear and honest the authors were.

In some ways, Amazon is by far the most surprising of the FAANG companies. They weren't known for being able attract great engineers and amazing designers. They were famous for being frugal, but frugality has never been a sexy virtue in American culture. Yet over and over they beat Google at cloud computing, and search. (Yes search --- raise your hand if you've been trained to visit Amazon for product search instead of Google) But what comes through in this book is that their true secret is this: a process for making good decisions beats out even those other attributes of computing businesses.

One of my favorite examples in the book was Amazon's reaction to Apple's announcement of iTunes for Windows. If you recall, this was the announcement that music has gone digital for all computer users, not just those who had opted into Apple's walled garden. Rather than being baited into reacting immediately, Jeff Bezos pondered and thought for several months before assigning an executive to create an organization around digital goods. Fundamentally, having a single clear owner (Amazon's executives borrowed the computer science term "single threaded" and applied it to leaders) allowed the organization to work on the problem and come up with a long term solution which led to the Kindle. Note that the Kindle was a slow burn, but one that exceeded internal expectations when it sold out right away. It's also very clear that there was no way a company like Google would have had the attention span to devote to something like this, and reading was way too clearly unsexy (and unpopular) an activity to attract Apple's attention.

Another clear sign of the honesty in the book was when one of the author's excerpted from his own self-assessment for a performance review one year.  He gave himself a D for making an error in launching Amazon Unbox. Again, the explanation of the process was clear --- the advantages Amazon had in retail was in delivery and distribution, but with a digital market place, those advantages were levelled, and Amazon had to either move upstream to content creation (which it eventually did), or downstream to owning and controlling the device (which it did earlier, in parallel with creating the FireTV, Fire tablets, and eventually Amazon Echo). The analysis of that decision is well explained and again, you could see that Amazon's competitors were late.

Many of the anecdotes were relevant and clearly explained, such as the creation of the Fire Phone, and an explanation of how one of the authors built in automatic refunds for stuttering video on Amazon Prime rentals, something that I did not expect to see at the top level, but in retrospect, there was no way it could have been a 20% project done by an engineer. One cannot imagine a business leader at Apple or Google deliberately building in a feature into a product spec that would cost the company money. Just that story alone makes the book worth the time spent reading it.

The successes are also explained, such as the evolution of AWS and Amazon Prime. I think this is one of those cases where Amazon's weakness (it never could get as many good engineers as Google) was actually a strength. Amazon's monorepo broke relatively early, while Google's ability to hire good engineers ensured that even today, Google lives with a monorepo and doesn't want to move beyond it. The breakage of that monorepo forced Amazon to learn how to support REST APIs and that in turn meant that when they launched AWS they already had experience in supporting one, something that Google struggled to do.

What comes through in this book is how clear the reasoning behind those decisions are, and I attribute a lot of this to the principle at Amazon where PowerPoints are banned and 6 page narrative arguments are used instead. The book provides examples of those documents, and the process of how to use them and stories about the debates are explained. A key point is that the assumptions behind a PRD has to be written down so they can be debated, not just what the actual product is.

The ultimate secret behind this book is that this type of process is actually very difficult to adopt. Definitely something you'd want to do early on in a company's life cycle, rather than after it's gotten past the startup stage. Well worth reading. I picked up the book one Saturday afternoon and read it overnight. Highly recommended.