This is the part 2 of the summary. If you haven’t finished part 1, I encourage you do so here.
Organizing: Separable, Single-Threaded Leadership
In its early days, Amazon instituted the famous two-pizza-team rule, meaning every internal team should be small enough that it can be fed with two pizzas. They agreed at the outset that a smaller team would work better than a larger one, until they came to realize the biggest predictor of a team’s success was not whether it was small but whether it had a leader with the appropriate skills, authority, and experience to manage a team whose sole focus was to get the job done.
Now free of its initial size limits, the two-pizza team clearly needed a new name. Nothing catchy came to mind, so Amazon leaned into its geekdom and chose the computer science term “single-threaded” meaning you only work on one thing at a time. Thus, “single-threaded leaders” and “separable, single-threaded teams” were born.
STL model is a separable, single-threaded team being run by a single-threaded leader. Separable means almost as separable organizationally as APIs are for software. Single-threaded means they don’t work on anything else.
A single-threaded leader can head up a small team, but they can also lead the development of something as large as Amazon Echo or Digital Music. For example, with Amazon Echo and Alexa, were it not for the fact that Amazon VP Greg Hart was assigned to be the single-threaded leader, there might have been one person in charge of hardware and another in charge of software for all of Amazon’s devices—but no one whose job it was to create and launch Amazon Echo and Alexa as a whole. On the contrary, a single-threaded leader of Amazon Echo and Alexa had the freedom and autonomy to assess the novel product problems that needed to be solved, decide what and how many teams they needed, how the responsibilities should be divided up among the teams, and how big each team should be.
Working Backwards: Start with the Desired Customer Experience
Start with the customer and work backwards—harder than it sounds, but a clear path to innovating and delighting customers. A useful Working Backwards tool is writing the press release and FAQ before you build the product.
Kindle was a breakthrough in multiple dimensions. It used an E Ink display. The customer could shop for, buy, and download books directly from the device—no need to connect to a PC or to Wi-Fi. Kindle offered more e-books than any other device or service available at the time and the price was lower. Today, that set of features sounds absolutely standard. In 2007, it was pioneering.
When Amazon wrote a Kindle press release and started working backwards, everything changed. They focused instead on what would be great for customers. An excellent screen for a great reading experience. An ordering process that would make buying and downloading books easy. A huge selection of titles. Low prices. They would never have had the breakthroughs necessary to achieve that customer experience were it not for the press release process, which forced the team to invent multiple solutions to customer problems.
As they got more adept at using the Working Backwards process, they refined the press release document and added a second element: the FAQ, frequently asked questions, with, of course, answers. The FAQ section, as it developed, included both external and internal questions.
- External FAQs are the ones you would expect to hear from the press or customers. “Where can I purchase a new Amazon Echo?” or “How does Alexa work?”
- Internal FAQs are the questions that your team and the executive leadership will ask. “How can we make a 44-inch TV with an HD display that can retail for $1,999 at a 25 percent gross margin?” or “How will we make a Kindle reader that connects to carrier networks to download books without customers having to sign a contract with a carrier?” or “How many new software engineers and data scientists do we need to hire for this new initiative?”
In other words, the FAQ section is where the writer shares the details of the plan from a consumer point of view and addresses the various risks and challenges from internal operations, technical, product, marketing, legal, business development, and financial points of view. The Working Backwards document became known as the PR/FAQ.
Most PR/FAQs never made it to a stage where they were launched as actual products. What this means is that a product manager will put in a lot of time exploring product ideas that never get to market. This may be because of the intense competition for resources and capital among the hundreds of PR/FAQs that are authored and presented each year within the company. Only the very best will rise to the top of the stack and get prioritized and resourced.
Keep in mind that the PR/FAQ is a living document. Once it is approved by the leadership team, it will almost certainly still be edited and changed. There is no guarantee that an idea expressed in an excellent PR/FAQ will move forward and become a product. As mentioned earlier, only a small percentage will get the green light. But this is not a drawback. It is, in fact, a huge benefit of the process—a considered, thorough, data-driven method for deciding when and how to invest development resources. Generating and evaluating great ideas is the real benefit of the Working Backwards process.
Metrics: Manage Your Inputs, Not Your Outputs
When the retail, operations, and finance teams began to construct the initial Amazon Weekly Business Review (WBR), they turned to a well-known Six Sigma process improvement method called DMAIC, an acronym for Define-Measure-Analyze-Improve-Control. Should you decide to implement a WBR for your business, Colin recommends following the DMAIC steps as well. The order of the steps matters. Progressing through this metrics life cycle in this order can prevent a lot of frustration and rework, allowing you to achieve your goals faster.
#1 Define
First, you need to select and define the metrics you want to measure. The right choice of metrics will deliver clear, actionable guidance. A poor choice will result in a statement of the obvious, a nonspecific presentation of everything your company is doing.
#2 Measure
Building tools to collect the metrics data you need may sound rather simple, but—like choosing the metrics themselves, Amazon has found that it takes time and concerted effort to get the collection tools right.
The next step after determining which tools to use is to collect the data and present it in a usable format. Often the data you want will be scattered across different systems and may take some serious software resources to compile, aggregate, and display correctly.
#3 Analyze
This stage has been given many different labels by different teams—reducing variance, making the process predictable, getting the process under control, to name a few. But the Analyze stage is all about developing a comprehensive understanding of what drives your metrics. Until you know all the external factors that impact the process, it will be difficult to implement positive changes.
#4 Improve
Once you have developed a solid understanding of how your process works along with a robust set of metrics, you can devote energy to improving the process. For instance, if you reach the point where you can reliably achieve a weekly 95 percent in-stock rate, you can then ask, “What changes do we need to make to get to 98 percent?”
#5 Control
This final stage is all about ensuring that your processes are operating normally and performance is not degrading over time. As your fundamental understanding of what drives the business improves, it’s common for the WBR to become an exception-based meeting rather than a regular one for discussing each and every metric.
The WBR is an important embodiment of how metrics are put into action at Amazon, but it isn’t the only one. Metrics dashboards and reports are established by every engineering, operations, and business unit at the company. In many cases metrics are monitored in real time, and each critical technical and operational service receives an “alarm” to ensure that failures and outages are identified instantly. In other cases, teams rely on dashboards that are updated hourly or daily for their metrics.
Pitfalls of WBR
As effective as the WBR process can be, it can also go astray in several ways, including poor meeting management, focusing on normal variations rather than signals, and looking at the right data but in the wrong way.
#1 Disaster Meetings
One issue was that the attendee list got more and more bloated, and Amazon had to keep finding bigger conference rooms to fit everyone. Likewise, the number of metrics they were trying to track kept ballooning—sometimes for the better, but more often for the worse.
The meetings were also just really unpleasant. There was a lack of ground rules and decorum, with quite a bit of interruption and sniping.
#2 Noise Obscuring the Signal
Variation in data is normal. And unavoidable. It’s therefore critical to differentiate normal variation (noise) from some fundamental change or defect in a process (signal). Trying to attach meaning to variations within normal bounds is at best a waste of effort and at worst dangerously misleading. It’s bad enough when someone proudly explains how their herculean efforts moved their key metric up by 0.1 percent this week, taking precious time away from more important things. Worse, if that same metric went down by 0.1 percent, you could easily waste time chasing down the root cause and “fixing” an issue that’s really nothing more than normal variation.