Sustaining a Day 1 Culture: Beth Galetti, Amazon SVP HR

Thanks, Beth. Hi, my name is Stephen Grosevich. I'm a principal evangelist with AWS HR. I've been with Amazon for a little over 21 years. I started out in technology, but I've spent the last eight years really focused on culture, thinking about what it takes for us to remain a Day One company, innovative and driving to solve long-term customer problems.

Day Two is stasis, followed by irrelevance, followed by excruciating, painful decline, followed by death. Now, Jeff's statement isn't idly provocative. A company in today's world must be hyper vigilant, remain customer focused, and stave off practices that hamper its ability to rapidly innovate. A Day Two culture and mentality doesn't simply happen overnight. As a company grows over time, there is often a need to adjust its approach to effectively manage an organization at scale. As you make these adjustments, elements of a Day Two culture may creep in slowly and manifest in different ways. One of those symptoms of Day Two culture is an increase in short-term thinking. Many companies start out with a bold long-term vision. They see an opportunity to disrupt the status quo, to build something bigger and better than what currently exists, or they identify a problem that no one else is solving and seek to solve it in a new and better way. The mission is clear, and there's a lot of energy and activity that can be connected directly to that mission. Now, as the organization matures, it's natural to introduce structure to try to measure what we're doing, to get an assurance that we're working on the right things. That's good; we should do that. But what often happens is that we start to organize our efforts around things that are more directly measurable, which aren't necessarily the same set as those that will help us deliver on the long-term mission. When a company goes public, all too often the activity shifts focus from those harder to measure things like long-term customer delight to short-term targets that keep shareholders happy. There's still a lot of activity; everybody's really busy. But more and more of that activity is centered around shorter-term objectives, and it becomes harder to connect individual activity to long-term objectives. We're no longer focused on the very thing we set out to accomplish. Day One companies have to find a way to maintain long-term perspective while continuing to respond to the short-term needs of the customer. Short-term thinking also has a direct impact on the ability to invent. Environments that are focused on short-term results tend to be risk averse. Other symptoms of Day Two thinking tend to appear as the company grows. Growth itself does not necessarily lead to a Day Two culture, but the actions we take to cope with growth can make the problem worse. One side effect of growth is increased organizational complexity. We add more and more layers and specialization to manage with the expanded scope of the business. We create layers of abstractions so we can manage effectively across the growing portfolio. A growing customer base requires this kind of growth, but there are two kinds of pressure that this growth puts on our organization. First, we tend to slow down in our decision making. The business is more complex, and the decisions we make have more impact. That tendency comes from a good place. Perhaps we experienced a problem and we don't want to repeat that mistake, so we put a policy in place to prevent that mistake from happening twice. That's good; we should do that. But the problem is that we then tend to take that policy or process and spread it across the entire control surface of the organization. And now the quickest we can make any decision is the sum of all of those policies we've put in place. And when we slow down too much, we miss the customer opportunity. To stay a Day One company, we have to find a way to de-risk the business while empowering people at every level of the organization to make as many decisions on their own as possible. Adding layers to the organization can have another negative effect: it can distance leadership from the customer. That direction isn't grounded in the reality of day-to-day customer experience. To stay a Day One company, we have to find a way to hear directly from customers and incorporate that information into our strategic plans. Unless our plans are informed by this direct customer information, we run the risk of making decisions that seem right for the business but don't actually benefit the customer in any way. As the company grows and becomes more complex, we often introduce processes that help us manage the business and drive repeatable outcomes. We find ways to measure inefficiencies and work to drive them out of the system. Again, that's good; we should do that. But the problems come when we're spending more time focused on the process than on the customer. Day Two companies become obsessed with process. Day One companies create process, but the key metrics they use to test whether or not the process is working are grounded in the direct impact to the customer. Now, as I mentioned earlier, no one sets out to intentionally become a Day Two company. But from our experience, good intentions aren't enough to prevent that from happening. Instead, we have to deploy mechanisms to fight against the pull of Day Two practices that are the natural consequences of growth and maturity as a business. We define mechanisms as a complete process that reliably converts inputs into outputs and improves itself over time. A mechanism has four parts. The first part is a tool. But absent the other parts of the mechanism, that's all it is. The existence of the tool isn't sufficient to solve the ongoing problem. The second part of the mechanism is adoption. In order for the mechanism to work, somebody has to do something. You need users to buy into the need for the tool, to know how to use it, and to be able to provide feedback to improve the tool over time. But even if you've created the tool and people are actively using it, you won't know whether it's working properly or not unless you're measuring the performance of the tool, its level of adoption, and whether you're actually achieving the results you want on an ongoing basis. That's where inspection comes in. Most mechanisms generate a set of metrics that allow the mechanism owner and stakeholders to see if the mechanism is working. The fourth part of the mechanism is iteration. If we've actually solved the problem, automated the root cause, and no longer need to use the mechanism, that's where the concept of iteration comes into play. We apply this mechanism framework to recurring problems all over Amazon. Some of our mechanisms drive operational efficiency, they increase safety, they reduce defects. And some of our mechanisms help us be intentional in combating Day Two thinking. They help us focus on the long term, help us stay connected to customers, and set us up for rapid experimentation and iteration. One mechanism that we use that helps us focus on solving long-term customer problems is a process we call working backwards. Now, I have to say it's not the only way you can build products. A lot of companies start by looking at their capabilities. We start by writing a press release. If the product has already launched, we're envisioning a world one to two years in the future where the customers are actually now using the product. What would they say? How would they react and respond? How good of a job is it actually doing? Is it making their life better? Is it really solving that particular customer problem? I get one page to tell a convincing story. If we can't clearly articulate the customer benefit in one page, we haven't thought clearly enough to start working. As we write this press release, we start to build out a set of frequently asked questions. What questions would a customer naturally ask about the big idea? And what questions would a business owner ask after reading the press release? And by the way, if there's that really uncomfortable question you hope nobody asks you about your press release, that's the most important one to answer. The third part of the working backwards process is a visual mockup. It is a rough visualization of the customer experience. The visuals exist to communicate the end-to-end customer experience, helping add detail where words cannot. We do all of this before we start any development work, before we've actually invested any budget, because we find it's easier to walk away from a bad idea that's still on paper. It's a low-cost way to identify bad ideas and allows us to refine our thinking and focus on that long-term customer problem we want to make sure that's where we're spending our energy, and not on a problem that's going to temporarily affect our financial numbers. We use this working backwards process extensively, not just for externally facing products, but even for internal product development. We write press releases before we take on any new initiative. Another mechanism we use is to listen to the customer to get a clear picture of their needs. Sometimes customers' needs are clear; they'll tell you directly when there's a problem. But even when we don't hear directly from customers, we have to do what we can to anticipate their needs. One example of this is our focus on the amount of time it takes for one of our web pages to load. Customers may never call and complain, but we know that slow pages make for a frustrating user experience. So we get ahead of that problem by measuring and optimizing page load speed. We use that approach across all of our businesses, using metrics to help us detect problems our customers might never call us about before they ever get a chance to create a negative customer experience. Another customer-focused mechanism is a program called Customer Connection. These senior leaders can then dive deep into use cases to help solve the root cause of recurring issues and think big about winning solutions that will drive a better customer experience. As much as we use data to drive decisions, the anecdotes we gather from these front-line experiences often show us problems that don't show up in the aggregated data. Issues that might be treated as mathematical outliers in other organizations help us continually refine our metrics and drive us to even higher standards. The more we learn about the customer, the more inspired we are to build. In AWS, we can trace 90% of what we build back to specific customers that had an idea or a problem that one of our product managers heard about. Another mechanism we use to stay close to the customer is hackathons. The most common format is a day-long competition where people team up to invent and quickly prototype solutions to enduring problems or find novel ways to use existing systems and data. Hackathons not only generate new ideas, but they provide a sense of customer-centric community for participants. Now, after we've identified an enduring customer problem or opportunity, we then have the challenge of building a solution that will meet those needs over the long term. And this is where large organizational structures often get in the way. The approach we've taken helps us counteract organizational inertia by empowering small, highly autonomous teams to own the problem end to end. It's a concept we call the two-pizza team. A two-pizza team is a small team that can be fed with two pizzas. It has a threaded focus in one area. These decentralized autonomous teams are empowered to develop and launch based on what they learn from interactions with customers. A two-pizza team also has the right resources embedded in the team itself, from product design to engineering, all with a very tight charter and well-defined mission so they can run as fast as possible in one area. The team creates its own metrics and KPIs to help them be reactive and proactive to their customers' needs. Now, a two-pizza team isn't really about size as much as it is about pushing ownership and autonomy down to the team level. Rather than expanding team size as demands for the product or service grows, we split teams into separate two-pizza teams. This is the practical application of that ideal. While these mechanisms keep us closer to the customer and allow us to respond quickly to changing customer needs, they don't guarantee success. If you're truly seeking to invent, failure is going to be a natural part of the equation. It's important to try to prevent failure, but we think it's more important to figure out how to embrace failure as a necessary part of experimentation and innovation. One great example from Amazon's history is the failure of our auctions business. We knew from early on that we would never be able to buy all of the products that customers might want to buy from us, and we recognized the only way to truly offer massive selection was to incorporate third-party sellers into our platform. We remained stubborn on the vision but flexible on the details. We believed the long-term value that this marketplace idea would have to both customers and sellers, but remained flexible on the implementation and iterated based on what we learned. What finally unlocked this business for us was when we decided to allow third-party sellers to compete directly against us on our own website. Today, Amazon Marketplace is a significant part of our global retail business. Last year, over half of paid units sold were sold by third-party marketplace sellers. Several years ago, we tried launching our own smartphone, the Amazon Fire Phone. It did not do well with customers. In the end, we had to write off $170 million worth of unsold hardware. If you're not failing, you're not innovating enough. If you're not growing, you're not going to be inventing at a size that can actually move the needle. Amazon will be experimenting at the right scale for a company of our size. If we occasionally have multi-billion dollar failures, this kind of large-scale risk-taking is part of the service that we as a large company can provide to our customers and to society. A single big winning bet can more than cover the cost of many losers. What gets missed in the story of the Fire Phone is we weren't just trying to launch a new cell phone; we were trying to change the way humans interact with machines. You know, when touchscreen phones launched, it radically changed what we expect from computers. Everything switched from keyboard and mouse to touch, and we were just asking ourselves, how do we make things even better? We didn't have mass layoffs; we just reinvested. We learned a lot from the Fire Phone failure. Many of the things we learned about building hardware, working with suppliers, material procurement, and so forth, are still helping us today in our devices business. And many of the people who worked on the Fire Phone brought what they had learned to help us launch Echo and Alexa, which I would argue have fundamentally shifted the way humans get information from machines. To remain a Day One culture, you need to find ways to take bigger and bolder bets, to risk bigger and more prominent failure, and you have to create an environment where failure drives improvement, not punishment. Every failure is an opportunity to create something better for customers.