Amazon Web Services truly requires no introduction. Over the last 13 years, few tech companies have had more impact on how enterprises operate, innovate, and grow than AWS.
We recently had the great pleasure of hosting Bill Platt, general manager at AWS, for our most recent CIO Insights call. Bill has launched 16 different Amazon services over the past five years and serves on the AWS customer advisor board. The Sun Microsystems veteran talked about how Amazon built a culture of innovation, and how tech leaders are leveraging this innovation at scale. He also answered several insightful questions from our panel of enterprise CIOs.
Key Takeaways:
- Failing fast and continual iteration are keys to innovation
- Loosely coupled systems run by small autonomous teams helps services scale quickly
- Technology investments must be constantly measured and re-evaluated
- Creating a culture around key leadership principles is essential
- Every day offers an opportunity to build something new
BILL PLATT
From the very beginning, the mantra at Amazon has been “think big, start small, scale fast.” That’s how Jeff Bezos began the business back in 1995, and it’s how Amazon is run today. It wasn’t about selling books, it was making a long bet on ecommerce. He knew it would take years to realize a return, but when when it finally arrived it would be outsized.
Like the other disruptors — AirBnb, Spotify, Dropbox, Instagram, and Uber — Amazon’s business model is built around innovation. But innovation is not a goal, it’s an ongoing process. It’s a function of the organization and architecture you put in place, plus the culture and mechanisms. As Peter Drucker famously said, ‘Culture eats strategy for breakfast.’
Your organization and architecture will change over time, but culture and mechanisms are the parts you really have to get right. Amazon’s culture is built around leadership principles that have been curated over time and continue to evolve. These principles are embedded in everything we do, starting from the first job interview through every performance evaluation, decision, and business process. Every company thinks they do this, but it’s rare to see these principles embedded in so many people. It takes a lot of effort to create this kind of culture.
But good intentions aren’t enough — you actually have to do the things you say you’re going to do. So we use a few different techniques to operationalize these principles. For example, we will write up a press release of something we haven’t done yet to make sure we actually do it, or we’ll implement DevOps to ensure we get continuous deployments. Organizationally we lean very heavily on the “two-pizza team” mechanism, where every internal team is no bigger than two pizzas can feed. We then associate ownership over specific customer results and deliverables for each team.
Each page on Amazon.com is an aggregation of 300 to 500 microservices. We manage that by decoupling the digital architecture into smaller building blocks of loosely coupled systems, each managed by a two-pizza team. The more loosely these systems are coupled, the bigger they scale and the faster our people can innovate.
Amazon Web Services was born out of the belief that the loosely coupled systems that allowed Amazon to move faster and innovate more quickly could be applied to other businesses as well. So we decided to sell it as a utility, on a per unit basis, not as off-the-shelf software.
That was our first pivotal decision. Pivotal decision number two was to treat Amazon.com as a customer. So Amazon.com comes to AWS the same way everyone else does. Forcing the business to come through the front door allowed us to learn from a very large scale customer, and it also allowed AWS to scale independently from the ecommerce business.
Key decision number three was to assign every service a general manager. This single-threaded owner would handle everything from detailed technical matters to high-level questions regarding customer experience and business delivery. Together with two-pizza teams, having a single threaded owner allows us to break deliverables into smaller parts, scale more quickly, and innovate more rapidly.
Thirteen years later we have thousands of teams working within a microservices architecture, doing continuous delivery across multiple environments, with in excess of 150 million deployments a year.
But we always say this is still day one. We like to remind everybody that we get the chance every day to make a new choice. We can start over with something and build fresh. That’s what’s exciting to me.
Q&A
How does failure help to drive innovation at Amazon?
Failure is necessary. You need to see failure in order to know whether you’re on the right path. The sooner you can acknowledge something isn’t good, the sooner you can do something about it. With the Kindle, we had many iterations on whether or not to have a keyboard, but we innovated very quickly to the next step to correct our mistakes. Or take the Amazon phone, which was actually a pretty good phone but a colossal failure in the marketplace. At the same time we were doing the phone we were working on Alexa and what became the Echo device. So when we failed in the phone business, we rapidly pivoted people over to Echo and Alexa. We weren’t afraid to say ‘This isn’t working, customers don’t like what we have, we’re not going to grow this business.’
It’s not about being perfect with your vision, it’s about whether you can use data to see that you’re not going in the right direction and quickly recover. The key is that the innovation process is rolling, and you just correct to the next step as soon as possible.
How do you decide when something isn’t working and you need to do something different?
We’re a very goal-driven company. We establish goals on an annual basis, set targets as milestones within those goals, and measure ourselves against those targets every week. When we see drift, we try to intervene with a decision about what to do next, sooner rather than later.
Like a lot of businesses we’re always managing a portfolio of products, but we do it at a very tight line-item level. Amazon Web Services, which is just one part of Amazon’s larger portfolio, has a couple hundred line items we track every week on a business and a customer-experience level.
Early on, the company decided to focus on products that might lose money in the short term but would make a large amount over time. So we look for inflection points. Say there’s a new database line of business we expect to be profitable in three years but it actually takes four. That’s fine if we can see the inflection coming. If it’s not going to be profitable by year five, we will intervene in year three and take action. And we’ll do the same thing on a quarterly basis for products that need to grow over a shorter time frame.
How do you identify big breakout opportunities?
Let me use an example from own portfolio, an IT product called Service Catalog. It’s a good product, but its growth wasn’t the highest and its profitability wasn’t the greatest. In the middle of the year, we looked at these signals and decided to fund a new, related product out of the Service Catalog budget.
The reason we believed the new product was the right thing to do was that we’d done some testing with customers, and the feedback was overwhelmingly positive. The response was so strong that we knew this product needed investment now. The number of customers asking to use this product was 3,000 times higher than those who were ready to use Service Catalog.
When a relative sizing shows up so much stronger than the existing investment, that’s the time to change course. Of course, you need to be willing to take the chance you’re wrong. You have to be willing to fail and to correct your errors. This was a relatively easy bet because the signals were so strong, but not all of them are. The question is, are you willing to move investment that was someplace else into the new thing? We do that a lot, and we do it right in the middle of the year, even if it keeps us from hitting our goals for the first product.
How do you collect all these signals?
We always try to collect hard data, but sometimes we have to rely on anecdotal data. For example, some customers have told us there are a couple of capabilities in AWS they’d really like us to get better at. The same anecdotes came to me, they came to our CEO Andy Jassy, and they came to 25 sales people. That range of anecdotes is almost hard data, especially when you hear the same thing over and over. They’re sufficient for us to know we’re not there yet and we need to make the next decision. We actively search for both hard data and anecdotes so they can feed each other in our decision-making process.
How important is it that Amazon is customer zero for AWS?
We treat ourselves as customer zero around 90 percent of the time. But because we operate at a much larger scale than most companies, we have needs and problems many customers don’t have. Probably 60 percent of the new services you see announced at AWS re:Invent were things we built to solve internal problems, then later decided to externalize.
When big customers have needs that are different from ours, such as high-end financial services, we recruit a customer zero from that field who wants us to help them solve their problems. When we do that, we treat them like they’re part of Amazon. It’s usually mutually beneficial.
How do you decide when it’s time to retire a product?
In the Amazon.com world, it’s all about the numbers — whether customers are buying enough of a particular product to warrant the economics of it. In the AWS world it works a little differently. We don’t take away a service very quickly. We try to make the demand go away by offering another service that will fulfill the same need.
For example, there was a service called Simple DB we shipped years ago. It took 7 or 8 years before the demand finally went away and we could replace it with another service. If a customer builds on top of a service, they aren’t necessarily going to change it right away. That’s part of the price we pay for being an infrastructure provider. It’s a slightly bigger burden, but we feel like it’s the right thing to do to maintain customer trust.
But we do have a very high bar before we make what we call the second wave investment. The first wave is, give it to a customer, see it’s working. The second wave is putting it all over the world, which creates a big fixed cost. Once we make that big investment, we need to find some return for it over a number of years, even if it’s going to be in the negative for a while.
Every year we create an operating plan where we decide how much to invest in innovation and how much to spend on operational excellence. With a brand new product, we’ll spend 90 percent of that budget innovating. As it matures, we’ll typically spend 40 to 50 percent on operations. If we’re spending more than that to keep the product from being broken or messing up the customer experience, we start to worry.
How do you handle customer concerns about being locked into AWS?
We have no intention of lock in with any of the things we do. What we hope to do is create useful and durable advantages for our customers. It’s not about locking anyone into anything, it’s about allowing our customers to be successful at what they’re trying to do.
We’re also working across more platforms and doing more things in the hybrid world. The ability to make workloads portable is certainly important to our customers. We may not have done all the things we want to do yet on that point, but we’re working on them all the time.