AWS Initiate - A Cultura de Inovação da Amazon direcionada ao sucesso do Cliente
•Transferir como PPTX, PDF•
2 gostaram•317 visualizações
Apresentação utilizada no AWS Initiate Brasília em 17/09/2019
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a AWS Initiate - A Cultura de Inovação da Amazon direcionada ao sucesso do Cliente
Semelhante a AWS Initiate - A Cultura de Inovação da Amazon direcionada ao sucesso do Cliente (20)
Mais de Amazon Web Services LATAM
Mais de Amazon Web Services LATAM (20)
Último
Último (20)
AWS Initiate - A Cultura de Inovação da Amazon direcionada ao sucesso do Cliente
- 1. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. The Culture of Innovation at Amazon: Driving Customer Success Wesley Rodrigues - WWPS Solutions Architect wesrod@amazon.com
- 3. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How many teams with a unique focus on innovation are there on Amazon around the world? ?
- 4. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. “Any company big enough to have a research lab is too big to listen to it” Alan Kay
- 5. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. (innovation) = (org * arch) ^ (mech * cult)
- 6. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Our mission to be Earth’s most customer-centric company
- 7. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Where innovation begins start with the customer and work backwards
- 8. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. “There are many advantages to a customer-centric approach, but here’s the big one: Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.” - Jeff Bezos, 2016 letter to shareholders
- 9. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Growth Flywheel > Price > Selection > Convenience © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 10. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 1994 m Founded 1995 m Amazon.com 1998 m CDs & DVDs 2006 m AWS 2007 m Kindle 2011 m Video 2012 m Groceries 2014 m Alexa/Echo 2015 m Bookstores 2017 m Go http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-corporatetimeline
- 11. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do we organize for innovation? Culture Customer obsession, hire builders, let them build, support them with a belief system Mechanisms Encoded behaviors that facilitate innovative thinking Architecture Structure that supports rapid growth and change Organization Small, empowered teams that own what they create
- 12. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do we organize for innovation? Culture Customer obsession, hire builders, let them build, support them with a belief system Mechanisms Encoded behaviors that facilitate innovative thinking Architecture Structure that supports rapid growth and change Organization Small, empowered teams that own what they create
- 13. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Every one of us is a leader on our mission bit.ly/aws-lps Invent and Simplify Hire and Develop the Best Frugality Deliver Results Are Right, A Lot Dive Deep Bias for Action Insist on the Highest Standards Earn Trust Ownership Think Big Customer Obsession Have Backbone, Disagree & Commit Learn and Be Curious © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 14. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Invent and Simplify Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.
- 15. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Willingness to be misunderstood for a long time…
- 16. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 73 Price Reductions (since ‘06) 1957 New Services and Features introduced in FY 18 Millions of Monthly Active Customers
- 17. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Bias for action Speed matters in business. Many decisions and actions are reversible and do not need extensive study.We value calculated risk taking.
- 18. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Is it a one-way or a two-way door?
- 19. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do we organize for innovation? Culture Customer obsession, hire builders, let them build, support them with a belief system Mechanisms Encoded behaviors that facilitate innovative thinking Architecture Structure that supports rapid growth and change Organization Small, empowered teams that own what they create
- 20. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ”Most companies write the software, they get it all working, and then they throw it over the wall to the marketing department, saying ‘here is what we built, go write the press release.’That process is the one that’s actually backwards.” Jeff Bezos Founder and Chief Executive Officer Amazon.com, Inc. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 21. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Working Backwards is a mechanism Use it to get clarity, not to document what you’ve already decided to do Customer Press Release FAQ Visuals
- 22. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Press Releases
- 23. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. FAQs • Include both customer FAQs and internal FAQs • Include the hard questions • Share your Press Release early to gather questions Sample Customer FAQs: 1. How is this different from what Amazon offers me today? 2. Can I get a refund if I’m dissatisfied? 3. Are there things I need to manage or keep track of? 4. How much does this cost? Sample Internal FAQs: 1. What decisions and guidance do we need today? 2. What customer feedback have we collected so far? 3. What will customers be most disappointed in? 4. What other options did we consider and reject? 5. What are our MLP features? 6. What are our hotly debated topics? 7. Are we stepping through any “one way doors”? 8. Who is the single threaded leader?
- 24. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Visuals • Show the customer experience • Rough idea – rough drawing • Match fidelity to maturity of your idea • Don’t be afraid to be provocative
- 25. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Artifacts from the Working Backwards process Press Release FAQs Visuals
- 26. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do we organize for innovation? Culture Customer obsession, hire builders, let them build, support them with a belief system Mechanisms Encoded behaviors that facilitate innovative thinking Architecture Structure that supports rapid growth and change Organization Small, empowered teams that own what they create
- 27. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 2929 A shift to microservices • Single-purpose • Connect only through hardened APIs • Largely “black boxes” to each other • Business logic and data only accessible through APIs © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 28. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Self-service platforms without gatekeepers Creating powerful self-service platforms that enable builders to use the right tool for the right job © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 29. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 30. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. How do we organize for innovation? Culture Customer obsession, hire builders, let them build, support them with a belief system Mechanisms Encoded behaviors that facilitate innovative thinking Architecture Structure that supports rapid growth and change Organization Small, empowered teams that own what they create
- 31. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon hires builders and lets them build © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 32. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Two-Pizza teams are fast and agile, fostering ownership and autonomy Small, decentralized teams are nimble Own and run what you build © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 33. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Experiment early & frequently. Build on existing services. Lower the costs of failure. Prototype, iterate a LOT. Embrace failure as learning. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 34. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
- 35. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Auctions, zShops -> Marketplace Learn from failures… fire Phone
- 36. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. (innovation) = (org * arch) ^ (mech * cult) Now, does it make sense?
- 37. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you! Wesley Rodrigues - WWPS Solutions Architect wesrod@amazon.com
Notas do Editor
- Our mission is to be earth’s most customer-centric company. This is broad, meaning it does not restrict the domains or markets we enter – this mission is not defined by an industry, a geography, or by technology. We aim to be a customer centric company, and that can take many shapes. Notice this says nothing about selling books, or ecommerce. While this mission is broad, it is also specific – it helps us make decisions. Often, the tie-breaking question in a decision is: ‘Is this customer obsessed? What is the best thing for our customer?’ …
- Our mission is to be earth’s most customer-centric company. This is broad, meaning it does not restrict the domains or markets we enter – this mission is not defined by an industry, a geography, or by technology. We aim to be a customer centric company, and that can take many shapes. Notice this says nothing about selling books, or ecommerce. While this mission is broad, it is also specific – it helps us make decisions. Often, the tie-breaking question in a decision is: ‘Is this customer obsessed? What is the best thing for our customer?’ …
- Our mission is to be earth’s most customer-centric company. This is broad, meaning it does not restrict the domains or markets we enter – this mission is not defined by an industry, a geography, or by technology. We aim to be a customer centric company, and that can take many shapes. Notice this says nothing about selling books, or ecommerce. While this mission is broad, it is also specific – it helps us make decisions. Often, the tie-breaking question in a decision is: ‘Is this customer obsessed? What is the best thing for our customer?’ …
- We start by diving deep to understand customers – what they need or want. Where they have frustration or pain in their life. And we work backwards from there, by inventing ways to delight customers. It’s not only about being close to customers and asking them what they want, but deeply understanding their situation and context so we can invent on their behalf. There are many viable approaches to how you center a business. You can focus on competitors, invent new technologies, innovate around business models, and there are more. We’ve chosen to center Amazon around obsessive customer focus. (next slide)…
- Why is that? Why have we chosen to center our business on obsessive customer focus? Here is what Jeff Bezos wrote in his 2016 Shareholder letter: “Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.” Innovation is something to do on behalf of customers. We don’t build technology for technology sake. We don’t invent in isolation – we put the customer at the center of everything we do.
- ---optional slide----potentially used in intro section--- This is Amazon’s core approach to take care of Customer and grow the company on the retail side of our business – focus on price, selection, availability. When you find customer needs that are stable in time, you can continue to pump energy into them because everything you put into them will still be paying you dividends 10 yrs. later. A lot of other things you may form strategies around will not be stable over the long term. – technology, competitors – these can change very rapidly. In everyone of our arenas we can find these durable customer needs. In AWS, we know what they are – customers want availability, ease of use, data security – you’ll never find 10 yrs. from now customers say ‘I love AWS but just wish it was a little less secure’ or ‘I love AWS but I just wish it was down more often.’ These are inconceivable things. So once you know those things you can put energy into them. And we have those similar things for Amazon Studios, for Alexa – we know those things customers are going to want 10 yrs. From now. Speaker Notes: 1. Jeff Wilke describing (to learn, don't show video to customers) https://broadcast.amazon.com/videos/1401 2. Check out Q1-19 all hands video, jeff talking about durable customer needs: https://broadcast.amazon.com/videos/126771 - 4:30 min in
- And When you start with customers, it opens you up to explore and innovate in many more areas. We started as an online bookstore, expanded to other categories – first with CDs and DVDs -- and now we offer cloud computing w/ AWS, devices like Kindle and Echo, we are a TV and film production studio, and have physical stores with Amazon Books, Amazon Go and more. These businesses are all run by individual leaders, who work hard to meet the needs of their customers. On the surface these businesses may seem unrelated, and yet inside Amazon the way think about inventing is remarkably consistent, and deeply embedded into our culture. When you understand our approach of focusing on customers, and working backwards to invent on their behalf, it makes sense why we have so many businesses that on the surface may not seem unconnected.
- These are the four pillars around how we organize for innovation. You’ll see as we progress that these are overlapping and interdependent constructs. That they depend on each other, and when we do them all together, we take innovation (which in many companies is something that is managed centrally), and move it to the edge, unlocking the potential of everyone in our company. So the first thing is our Culture…
- You need the people to operate our system of innovation, and what drives consistency in the people we hire is our leadership principles
- At Amazon, we hold ourselves and each other accountable for demonstrating the Leadership Principles through our actions every day. These 14 Leadership Principles describe how Amazon does business, how leaders lead, and how we keep the customer at the center of our decisions. We have a philosophy that everyone is a leader. And so we use really use these everyday to make decisions. From hiring, promotion, development and feedback Here are a few examples of how our LPs help us make decisions…. [If you want to dive deeper:] Following all 14 of these at one time is difficult, if not impossible. Notice these are not meant to be completely harmonious – how can you ‘dive deep’ in details, while also having ’bias for action’ and moving quickly? We expect leaders to have judgement and know when to practice these. And different LPs will be more important in different situations, different times in your career. For example, if it’s your first job out of college hire and develop the best is not an emphasis – more about learn and be curious, dive deep, bias for action. For director and VPs, hire and develop the best very important. [can talk about how we hire here] For speakers Watch Jeff Wilke discuss the history of LPs: https://broadcast.amazon.com/videos/126744
- ---optional --- Another example of an LP. Used to introduce willingness to be misunderstood for long periods of time/Kindle & AWS examples.
- One of our leadership principles is ’Invent and Simplify’ which includes a phrase ‘As we do new things, we accept that we may be misunderstood for long periods of time.’ An example of this is Kindle. Many people questioned the first generation of the kindle. And it was quite big and heavier than most books, and outsiders questioned why build a product that could cannibalize sales of physical books sold on Amazon.com But we believed in the long-term customers would want the simplicity of being able to download and start reading. But we started with a vision of ‘any book in the world, in 60 seconds or less’. We still focus on this vision today, and continue to invent on behalf of readers, lovers of books. Contrast the original Kindle with today’s versions – which are light, affordable, easy to read in bright daylight or in the dark, and some are even waterproof. (next slide)…
- One of our leadership principles is ’Invent and Simplify’ which includes a phrase ‘As we do new things, we accept that we may be misunderstood for long periods of time.’ An example of this is Kindle. Many people questioned the first generation of the kindle. And it was quite big and heavier than most books, and outsiders questioned why build a product that could cannibalize sales of physical books sold on Amazon.com But we believed in the long-term customers would want the simplicity of being able to download and start reading. But we started with a vision of ‘any book in the world, in 60 seconds or less’. We still focus on this vision today, and continue to invent on behalf of readers, lovers of books. Contrast the original Kindle with today’s versions – which are light, affordable, easy to read in bright daylight or in the dark, and some are even waterproof. (next slide)…
- Or the other example of ‘willingness to be misunderstood’ and long-term thinking is AWS. In 2006 we started the business, and Wall Street and others said it was a risky bet. [read cover] We were getting from wall street – ‘what do you know about technology? You’ll need an enterprise salesforce? Is this secure? And btw, please make your retail business profitable.’ But at the time we had learned a lot about building scalable infrastructure and thought other enterprises would benefit. [click to display stats] But jump ahead a decade, and it is the business of AWS that Wall Street loves. Speaker notes: -Source: 73 price reductions since ‘06 [as of April 4, 2019]. https://w.amazon.com/index.php/AWS_Communications_Portal#HPublicAWSStats
- ---optional --- Another example of an LP. Used to introduce one-way/two-way door decision making
- Another leadership principle is ‘bias for action’ which states: “Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.” So how do we decide when it’s appropriate to move quickly? We’ll a clue is in the description – whether it is reversible. One helpful mental model we’ve developed is one-way vs two-way doors. One way doors have significant and irrevocable consequences and needs deep analysis – such as building a new fulfillment center or data center. [We dive deep] Two way doors – which are most decisions – have limited and reversible consequences – such as experimenting with a new feature on our mobile shopping app. When we see a two-way door and we have enough evidence and reason to believe going through it would be a good idea, we just walk through it – either way, we have learned a valuable lesson. We teach leaders they should make a decisions when you have around 70% of information you wish you had. If you wait for 90% you are probably moving too slow.
- At Amazon, mechanisms are complete processes that turn inputs into outputs. In the context of innovation, we refer to mechanisms that are encoded behaviors that facilitate innovative thinking and execution
- ---optional, cut if short on time---- A ‘Mechanism’ has a very specific meaning inside amazon. Jeff has a famous presentation inside Amazon at which he states – Often, when we find a recurring problem, something that happens over and over again, we pull the team together, ask them to try harder, do better – essentially, we ask for good intentions. This rarely works... When you are asking for good intentions, you are not asking for a change... because people already had good intentions. But if good intentions don’t work, what does? Mechanisms work.” A mechanism is a complete process…a “virtuous cycle” that reinforces and improves itself as it operates. We build tools (software, processes), drive adoption of that tool, and inspect results to see whether we are having the impact we intended; we then improve our mechanism. There are many types of mechanisms at Amazon – these allow us to scale, and help leaders operate beyond their direct line of sight. Examples include the Andon cord to allow front-line customer service agents to remove defective product information from the Amazon catalogue, the hiring Bar Raiser program help us hire the very best people by converting the input of a candidate to the output of an Amazonian. And our Weekly Business Review which helps drive operational excellence.
- ---optional --- [can use instead of video if desired] Jeff was asked at an internal all-hands about the working backwards process, and he ended his response with these words: “Most companies write the software, they get it all working, and then they throw it over the wall to the marketing department, saying ‘here is what we built, go write the press release.’ That process is the one that’s actually backwards.” (next slide)…
- In the context of innovation - The hallmark mechanism we have to consistently drive customer-centric innovative thinking and execution is the working backwards process. We take the input of a raw ideas, put it through our mechanism, and get the output of customer-centric products and services. Every customer-facing product or service developed across Amazon uses the Working Backwards process. We use this mechanism to make sure that we are build the right thing for customers and that we are customer obsessed from the very beginning of any idea. The central artifact of the working backwards process is a Working Backwards doc, commonly referred to as a PR-FAQ. This WB doc includes three things – PR, FAQs, and Visuals.
- Along with the Press Release, we include Frequently Asked Questions. While the PR is one-page, the FAQs could be 5 or more pages. This is where we dive into the details of the proposed product or service. We include two types of FAQs – customer and internal. Customer FAQs’ questions that we anticipate a customer may ask, such as ‘how much does it cost, what happens if it breaks’. In AWS that could be “How does this service relate to/work with other AWS services?” In our retail business we may ask “How does this affect me if I’m a Prime member, non-Prime, or new to Amazon?” Authoring answers to these questions forces us to anticipate the tough questions a customer may ask, and ensures teams think from the perspective of end customers from the very beginning of a project. In addition to these customer FAQs, we also include FAQs internal stakeholders may ask — such as how this maps to internal goals, business outcomes, financials, security questions, and more. Examples of Internal FAQs include questions like “Why do we believe the first release of the service will be successful?”, “What differentiates this solution from any other available solution?”, and “What use cases would customers not want to move to the service, and why? What % of the market segment do these use cases comprise?” Teams may write their own FAQs, and some parts of Amazon have developed specific “must-have” FAQs that should always be included. Early drafts may not have answers to all FAQs, but even listing a question (without the answer) can signal to a reader that an author knows where they have gaps. This helps build trust and generates velocity towards a solution.
- Along with the Press Release, we include Frequently Asked Questions. While the PR is one-page, the FAQs could be 5 or more pages. This is where we dive into the details of the proposed product or service. We include two types of FAQs – customer and internal. Customer FAQs’ questions that we anticipate a customer may ask, such as ‘how much does it cost, what happens if it breaks’. In AWS that could be “How does this service relate to/work with other AWS services?” In our retail business we may ask “How does this affect me if I’m a Prime member, non-Prime, or new to Amazon?” Authoring answers to these questions forces us to anticipate the tough questions a customer may ask, and ensures teams think from the perspective of end customers from the very beginning of a project. In addition to these customer FAQs, we also include FAQs internal stakeholders may ask — such as how this maps to internal goals, business outcomes, financials, security questions, and more. Examples of Internal FAQs include questions like “Why do we believe the first release of the service will be successful?”, “What differentiates this solution from any other available solution?”, and “What use cases would customers not want to move to the service, and why? What % of the market segment do these use cases comprise?” Teams may write their own FAQs, and some parts of Amazon have developed specific “must-have” FAQs that should always be included. Early drafts may not have answers to all FAQs, but even listing a question (without the answer) can signal to a reader that an author knows where they have gaps. This helps build trust and generates velocity towards a solution.
- Visuals are the third pillar of a Working Backwards document and exist to communicate the customer experience where words cannot. There are many types of visuals including rough sketches, storyboards, wireframes, technical architecture diagrams, and more. This practice doesn’t require being a great designer, rather, it’s meant to help visually communicate the idea expressed in the press release and FAQs. A helpful axiom is “the fidelity of the visuals should match the maturity of the idea.” This means that early on when an idea is rough, the visuals should also be rough. A photo of a sketch on a whiteboard may be all we need early on. As we clarify thinking and flush out details in the press release and FAQs, the fidelity of the visuals should increase. Visuals should communicate the customer experience so that when combined with the press release and FAQs a reader comes away with a clear understanding of what the proposed product/service is.
- WB docs have these 3 main parts. The Press Release is a one-page narrative describing a new product, service using customer-centric language. With the Press Release, we leap into the future and imagine how a customer feels and what they may say about a new idea before writing a single line of code. Limiting the PR to just one page forces us to be crisp around how we describe the launch of this new product. In the PR we communicate who the customer is, what problem the customer faces today, and describe the solution with a description of the most important benefit. We also include a date we expect the product to launch (is this 3 yrs. out or 6 months out?). And a customer quote – a fictional quote from a fictional customer. This forces us to put ourselves in the mind of customer, and think about how they would describe the benefits and value around the launch of the new product or service. Speaker notes: [cover PR here, then cover FAQ and Visuals later]
- The third thing is Architecture. First is culture, and LPs are how we drive consistency in the people we hire. Second, we have mechanisms, and specifically the working backwards process for product teams who using the same consistent behavior around how they’re imagining new products, and defining what should go be built. You need to give these builders an architecture platform and robust set of tools they can use that frees them up from any kind of inhibition. Imagine you created a good idea to develop amazon go — but what if that engineering team didn’t have access to server capacity, and they had to wait to have a server provisioned? But they were able to get started very quickly because they are using lambda, using Kinesis for video streams, using P3 instances for deep learning computer vision.
- More than a decade ago Amazon took our monolith code base and broke it apart into a service oriented architecture. We refactored our single code base into small, focused, single-purpose services, which we call "primitives.” For example, we had a primitive for displaying the buy button on a product page, and we had one for calculating taxes. Every primitive was packaged as a standalone web service, and got an HTTP interface. The business logic, and (critically) the data, were only exposed to other teams through hardened APIs. These building blocks only communicated to each other through the web service interfaces so other teams could take advantage existing services. This created a highly decoupled architecture where these services could be iterated on independently as long as they adhered to their web service interface - to give you an idea of the scope of these small services, I've included this graphic - this is the constellation of services that deliver the Amazon.com website back in 2009, and today there are tens of thousands of these across Amazon - this term didn't exist back then, but today you'd call this a microservice architecture
- We’ve fundamentally done something with our architecture with is there is no gatekeeper. There’s no line to wait for storage, compute, databases, or start using ML. In the old world, when you asked engineering teams how long it might take them to get a server to try and experiment, you get answers like 10-12 weeks. In the cloud, you can provision thousands of servers within minutes, and then we have 165 services that you can put together and use in whatever combination so want. You get from an idea to implementation in several orders of magnitude faster. This totally changes an organization, impacting the amount of cycles employees spend thinking about innovation because they know, if they have an idea, they have a chance to see if it works. This expands the group of people inside a company that are thinking about new ideas from a select few to everyone.
- Single-purpose microservices hold both business logic and the data. And no team can touch that data except through API – no exceptions, no shortcuts, no backdoors. Our architecture supports and accelerates the pace of innovation (show how innovation story links to AWS platform) First, we are able to prototype very rapidly —With AWS you spin up thousands of servers in minutes and you have access to a very robust, full-featured technology offering that lets you go from idea to launch in record time. Second, we have low costs of failure. When you can prototype rapidly, this totally changes an organization because it expands the group of people inside a company that are thinking about new ideas. And with pay-as-you-go pricing it’s much cheaper to experiment — you simply turn off new ideas if they’re not working. Third, we can move to scale really quickly when something works — AWS enables customers to deploy globally in minutes, and with the elasticity to instantly scale up or down along with the needs of the business. So it’s these three things – rapidly prototype, low cost of failure, and scale really quickly.
- The final point is organization --- How do we organize for speed and agility?
- First you need to find the right people that can operate that system. We hire builders -- we mean people who like to invent, people who like to look at different customer experiences and assess what's wrong with them and reinvent them, and people who get that launch is the starting line, not the finish line. And you need to organize these builders so they can truly build – empower them to invent on behalf of customers.
- We have a distinctly Amazonian way of organizing to optimize execution. We’re structured organizationally to try and enable agility. And one of the ways we’ve done that is what we call our ‘two-pizza teams. --meaning that no team should be big enough that it would take more than two pizzas to feed them. The fundamental concept of the two-pizza team came out of efforts to minimize the need for communications, minimize time in unnecessary meetings, and accelerate the decision making process. While we can debate around the size of the pizza, this concept is fundamentally around creating a little startup of around 5-10 people. Providing the conditions so that each team has ownership and autonomy, and provide deep focus in one area. These decentralized, autonomous teams are empowered to develop and launch based on what they learn from interactions with customers. Why do we do this? We found there is an exponential function in the overhead of communication with the more people you add on a team. And once you get to 11 or 12 is when you hit that exponential rate. You add more people, more people means more communication, that slows things down. So a 2PT has the resources embedded in them to have full ownership. So they own every function from engineering, to testing, to product management – and we try to embed all those resources on that single team and make them single-threaded, with a single owner, and give them a very tight charter and mission to they can run as fast as possible and have focus in one area. [Single threaded leaders] So 2PT push ownership, push autonomy. You build the software, you test the software, you operate, you think about the future of it. Btw, this also has an impact on code quality. If you’re responsible for maintaining, and you’ll get paged on a sat. night if your software breaks, you’ll probably do a better job building it in the first place. As demands grow and the team needs to expand, we split teams into separate 2-pizza teams working on sub—areas, rather than simply make the team bigger. This concept of a 2PT has been around for many years, and culture at the individual team level has changed very little, because it’s self-reinforcing and it’s one of the things we’ve done that’s helped us scale dramatically over time.
- Enable experimentation via primitives Build on existing services Lower the costs of failure Prototype, iterate – a LOT Embrace failure as learning
- So our organizational model of these 2PT allows for invention around the company. But like Jeff says ‘failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.’ So we’ve had our share of failures:
- 1. We had the failure of the auction market - twice!. We launched Amazon Auctions in 1999. But it didn’t pan out. Later we launched zShops -- For a small fee, Amazon would let anybody set up a virtual store on Amazon to sell their products. But that idea didn’t pan out either. But we kept at it. Now Amazon Marketplace –it’s a significant part of our retail business. Last year, 51% of paid units were sold by 3rd party marketplace sellers*. We have our FBA program, the allow sellers to store their product in warehouses, and makes those products eligible for Prime shipping. 2. And of course the Fire Phone was a public failure. We later did a $170 million write down of unsold inventory. Building hardware is hard. And yet many of the things we learned about building hardware, working with suppliers – they help us today in our devices business. Some of the people who worked on Fire Phone went on to work in the early versions of the Echo and Alexa. You need a culture where if you work on something that fails, you aren’t automatically forced out of the company. Jeff said ““If you think that’s a big failure, we’re working on much bigger failures right now — and I am not kidding,” he said. “Some of them are going to make the Fire Phone look like a tiny little blip.” Also: “It is our job, if we want to be innovative and pioneering, to make mistakes and as the company has gotten big — we have $100 billion-plus in annual sales, 250,000-plus people — the size of your mistakes needs to grow along with that,” he said. Ref: https://www.geekwire.com/2016/amazons-jeff-bezos-fire-phone-working-much-bigger-failures-right-now/ * Active seller accounts represent accounts that have received an order during the preceding twelve-month period Speaker Note: There is a myth that the fire phone lead to Alexa and that technology from Fire Phone was reused in Alexa -- as if without the failure of the fire phone Amazon would not have created Alexa. This is not true. Best link is to say what is written above (#2)