pizza team

back to index

18 results

The Everything Store: Jeff Bezos and the Age of Amazon

by Brad Stone  · 14 Oct 2013  · 380pp  · 118,675 words

to the S Team in the basement of his Medina, Washington, home. The entire company, he said, would restructure itself around what he called “two-pizza teams.” Employees would be organized into autonomous groups of fewer than ten people—small enough that, when working late, the team members could be fed with

, Bezos hoped, these loosely coupled teams could move faster and get features to customers quicker. There were some head-scratching aspects to Bezos’s two-pizza-team concept. Each group was required to propose its own “fitness function”—a linear equation that it could use to measure its own impact without ambiguity

. For example, a two-pizza team in charge of sending advertising e-mails to customers might choose for its fitness function the rate at which these messages were opened multiplied by

parts in the hopes that surprising results might emerge. That, at least, was the high-minded goal; the end result was somewhat disappointing. The two-pizza-team concept took root first in engineering, where it was backed by Rick Dalzell, and over the course of several years, it was somewhat inconsistently applied

to be executed. Teams ended up spending too much time worrying over their formulas and making them ever more complex and abstract. “Being a two-pizza team was not exactly liberating,” says Kim Rachmeler. “It was actually kind of a pain in the ass. It did not help you get your job

brought Nick Swinmurn, Michael Moritz, and Alfred Lin, who had just joined Zappos as chairman and chief operating officer. Playing off Amazon’s famous two-pizza-team culture, the Zappos executives served two pizzas, one with pepperoni and one with jalapeño peppers, from a local restaurant. The meeting was brief and awkward

small groups of engineers are more effective than larger ones at handling complex software projects. The book lays out the theory behind Amazon’s two-pizza teams. Built to Last: Successful Habits of Visionary Companies, by Jim Collins and Jerry I. Porras (1994). The famous management book about why certain companies succeed

Bezonomics: How Amazon Is Changing Our Lives and What the World's Best Companies Are Learning From It

by Brian Dumaine  · 11 May 2020  · 411pp  · 98,128 words

strategy. Bezos concluded the opposite: that bringing everyone up-to-date on a project lengthens its gestation. In 2002, he instituted his now legendary two-pizza teams for software development. Project teams would include no more than ten people, a group small enough that they could be fed by two pizzas. This

control over the success or failure of what they’re working on.” From the outside, this structure seems like a recipe for disaster. Hundreds of pizza teams operating in separate buildings scattered throughout downtown Seattle. But it works. And for one reason only. Bezos had inculcated his business with the tenets of

Making Work Visible: Exposing Time Theft to Optimize Workflow

by Dominica Degrandis and Tonianne Demaria  · 14 May 2017  · 153pp  · 45,721 words

/outline/plan unexpectedly changes something else. When the local pizza company delivers more than two pizzas to the same meeting room, pay attention. A two-pizza team is a team that can be fed with just two pizzas—about five to seven people depending on the size of the appetite. If three

two-pizza teams need to have a joint meeting to discuss their dependencies on each other, then you have high coordination costs. Fifteen to twenty-one people bantering

by breaking them down into smaller groups, hidden dangers await if there are unknown dependencies. Cross team communication is hard. When a bunch of two-pizza teams with lots of dependencies between them spend a lot of time coordinating to avoid stepping on each other’s code (due to the merging of

. Pizza is frequently delivered to these teams. (Remember the pizza problem from Section 1.2?) They had heard about the success Google had with two-pizza teams, and so this large organization decided it would work for them too. Many stories impacted other teams. They called these stories “away” stories because you

took a long time to finish stories because the experts capable of solving the issues weren’t available when needed. When a bunch of two-pizza teams have a lot of dependencies between them, how much time is spent coordinating? It’s true, we like small teams because they can move fast

One Click: Jeff Bezos and the Rise of Amazon.com

by Richard L. Brandt  · 27 Oct 2011  · 222pp  · 54,506 words

a decentralized, even disorganized company where people could come up with independent ideas rather than subscribe to groupthink. He ruled the company with the “two-pizza team” concept, that dictated any team should be small enough to feed with two pizzas. Empathy is not something that comes to him naturally. When he

(EC2) Electronics Ellison, Larry Employees Bezos interaction with compensation and cult of Amazon expansion (1998) firing (2000) hiring practices individualistic “Just Do It” award two-pizza teams Wal-Mart executives, hiring of work environment Endurance (Lansing) E-Niche Equinet Erwise Everybook Express Lane Farsight Financial status cost-cutting decline (2000) first investors

Working Backwards: Insights, Stories, and Secrets From Inside Amazon

by Colin Bryar and Bill Carr  · 9 Feb 2021  · 302pp  · 100,493 words

’d been operating under was incorrect. Amazon ultimately invented its way around the problem by cutting off dependencies at the source. First Proposed Solution: Two-Pizza Team Seeing that our best short-term solutions would not be enough, Jeff proposed that instead of finding new and better ways to manage our dependencies

throughout the company and synthesized them, then came back with a clearly defined model that people would talk about for years to come: the two-pizza team, so named because the teams would be no larger than the number of people that could be adequately fed by two large pizzas. With hundreds

of these two-pizza teams eventually in place, Rick believed that we would innovate at a dazzling pace. The experiment would begin in the product development organization and, if it

worked, would spread throughout the rest of the company. He laid out the defining characteristics, workflow, and management as follows. A two-pizza team will: Be small. No more than ten people. Be autonomous. They should have no need to coordinate with other teams to get their work done

in real time. A team’s real-time score on its fitness function would be displayed on a dashboard next to all the other two-pizza teams’ scores. Be the business owner. The team will own and be responsible for all aspects of its area of focus, including design, technology, and business

team’s work will pay for itself. Be approved in advance by the S-Team. The S-Team must approve the formation of every two-pizza team. As with any major innovation at Amazon, this plan was merely the beginning. Some of its tenets endured, some evolved, and some perished over the

. One major effort is worth recounting in some detail, however, because it was both vital and extremely difficult for us to achieve. Just as two-pizza teams replaced a single large organization with something faster and more flexible, a comparable reorganization was overdue for much of the Amazon software architecture to enable

need to be pointed in the right direction and have the tools to quickly course-correct when warranted. That’s why, before any proposed two-pizza team was approved, they had to meet with Jeff and their S-Team manager—often more than once—to discuss the team’s composition, charter, and

classic example of the Dive Deep leadership principle. I participated in every one of the Fitness Function alignment meetings for the first set of two-pizza teams, which owned things like Forecasting, Customer Reviews, and Customer Service Tools. We questioned every metric from every angle, probing how those data would be collected

also built up trust between Jeff and the new team, reinforcing their autonomy—and therefore their velocity. We started with a small number of two-pizza teams so that we could learn what worked and refine the model before widespread adoption. One significant lesson became clear fairly early: each team started out

so, but once they had removed dependencies, built their fitness function, and instrumented their systems, they became a strong example of how fast a two-pizza team could innovate and deliver results. They became advocates of this new way of working. Other teams, however, put off doing the unglamorous work of removing

make some satisfying early progress. Their dependencies remained, however, and the continuing drag soon became apparent as the teams lost momentum. A well-instrumented two-pizza team had another powerful benefit. They were better at course correcting—detecting and fixing mistakes as they arose. In the 2016 shareholder letter, even though he

wasn’t explicitly talking about two-pizza teams, Jeff suggested that “most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90

that other limits to autonomy would also need to remain, with each team still tied to others by varying levels of dependency. While each two-pizza team crafted its own product vision and development roadmap, unavoidable dependencies could arise in the form of cross-functional projects or top-down initiatives that spanned

multiple teams. For example, a two-pizza team working on picking algorithms for the fulfillment centers might also be called upon to add support for robotics being implemented to move products around the

, for example, had to be involved in almost every new initiative, even though it wasn’t in their original charters. Some Challenges Still Remained Two-pizza teams were a much-talked-about topic at Amazon, but as originally defined, they didn’t spread throughout the company as completely as some other new

improve the way Amazon worked, they also exhibited some shortcomings that limited their success and broader applicability. Two-Pizza Teams Worked Best in Product Development We weren’t sure how far to take the two-pizza team concept, and at the beginning it was planned solely as a reorganization of product development. Seeing its

did not suffer from the tangled dependencies that had hampered Amazon product development. Therefore, implementing two-pizza teams in those orgs would not increase speed. Fitness Functions Were Actually Worse Than Their Component Metrics Two-pizza teams had been meant to increase the velocity of product development, with custom-tailored fitness functions serving as

would move in the right direction. Combining them into a single, unifying indicator was a very clever idea that simply didn’t work. Great Two-Pizza Team Leaders Proved to Be Rarities The original idea was to create a large number of small teams, each under a solid, multidisciplined, frontline manager and

such brilliant managers, they turned out to be notoriously difficult to find in sufficient numbers, even at Amazon. This greatly limited the number of two-pizza teams we could effectively deploy, unless we relaxed the constraint of forcing teams to have direct-line reporting to such rare leaders. We found instead that

two-pizza teams could also operate successfully in a matrix organization model, where each team member would have a solid-line reporting relationship to a functional manager who

, director of software development or director of product management—and a dotted-line reporting relationship to their two-pizza manager. This meant that individual two-pizza team managers could lead successfully even without expertise in every single discipline required on their team. This functional matrix ultimately became the most common structure, though

each two-pizza team still devised its own strategies for choosing and prioritizing its projects. Sometimes You Need More Than Two Pizzas We all agreed at the outset that

experience to staff and 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 we leaned into our geekdom and chose the computer science term “single-threaded,” meaning

discipline to stick with it. We learned as we went, adapting and refining the idea of two-pizza teams until, in the end, we had something far more capable. What was originally known as a two-pizza team leader (2PTL) evolved into what is now known as a single-threaded leader (STL). The STL

teams to deliver their key benefits at any scale the project demands. Today, despite their initial success, few people at Amazon still talk about two-pizza teams. We say that the STL is bigger and better, but better than what? Certainly it’s an improvement on the two

-pizza team it evolved from, but is it better than other alternatives too? To answer that question, let’s look at a more common approach to developing

and separable, single-threaded teams, and we went through a number of solutions along the way that ultimately didn’t last—like NPIs and two-pizza teams. But it was worth it, because where we landed was an approach to innovation that is so fundamentally sound and adaptable that it survives at

at any company to work autonomously and yet be in sync with the intentions of their leaders. On the organizational side, we used the two-pizza team structure, which allowed our Digital teams to not be dependent on or a distraction to the engineering and business teams running the retail and marketplace

point of view, this meant he wouldn’t be stymied by arbitrating resource conflicts and dependencies at the ground level. He could hold each two-pizza team leader accountable for staffing their team and achieving their goals. Furthermore, he could easily audit whether an important initiative was staffed to succeed. Because the

, studios, and record companies). Each general manager (GM) category leader had a corresponding peer leader on the engineering side. Each engineering category had a two-pizza team for each major component of the software services (e.g., content ingestion and transformation) and for client application software. This was mostly a pragmatic decision

become too broad to break up or divide teams into subteams. A simple example: in 2004, video client application development was handled by one two-pizza team. It then became three teams, one for web, one for mobile devices, one for TV devices. Then the mobile team became four teams (iPhone, Android

, Android tablet) and the TV team became five-plus teams (Xbox, PlayStation, TiVo, Sony Bravia, Samsung, etc.), such that by 2011 our original two two-pizza teams were now more than ten. Some of the digital media leaders—including Neil Roseman and Dan Rose—came from inside the company. Others, like Erich

great additions to the Amazon digital media team. Since the Mobipocket team consisted of about ten people, they remained in place as an Amazon two-pizza team with a single-threaded focus on Kindle reader client-application development. With the Mobipocket team and their software on board, Gregg, Neil, Felix, and Ian

Colin joins Amazon 1999 Bill joins Amazon Bar Raiser program launched 2001 Formal Weekly Business Review (WBR) established 2002 Amazon Product API launches First two-pizza teams created 2003 Colin starts as Jeff’s shadow Amazon Web Services (AWS) group is formed 2004 Working Backwards PR/FAQ process formalized Use of PowerPoint

OP1 OP2 S-Team goals Anthony, Felix application program interfaces (APIs) Amazon Product API Amazon Seller API definition of dependencies and Green Corp. example two-pizza teams and Are Right, A Lot leadership principle Baker & Taylor Bar Raiser (Amazon’s hiring process) Behavioral Interviewing Debrief/Hiring Meeting diversity and Hire and Develop

and high standards Press Release/Frequently Asked Questions process and Prime and Prime Video and single-threaded leadership and S-Team and on tenets two-pizza teams and on underpromising and overdelivering Working Backwards and Bezos, MacKenzie. See MacKenzie Scott Bias for Action leadership principle Black Lives Matter movement BlackBerry Blu-ray

New Project Initiatives (NPI) and organizational dependencies Press Release/Frequently Asked Questions process and relational database single-threaded leadership and software code technical dependencies two-pizza teams and Digital Media. See Amazon Digital Media disaster meetings Disney Disney+ Dive Deep leadership principle Door Desk Award Dornfest, Rael E Ink Earn Trust leadership

compensation as foundational mechanism of Leadership Principles four-hour meetings goals Kindle and members PowerPoint and Prime and single-threaded leadership six-pagers and two-pizza teams and S-Team goals Amazon Digital and annual planning process Dive Deep leadership principle and finance team’s tracking of growth and evolution of high

-threaded leadership being Amazonian and flexibility of size Fulfillment by Amazon and history and origins of rewards of separability and two-pizza teams and See also dependencies; New Project Initiatives (NPI); two-pizza teams (2PTL) Six Sigma six-pager advantages for presenters advantages for readers conducting meetings with FAQ feedback and ideas prioritized over

Shipping Szkutak, Tom Taylor, Tom technical program managers (TPMs) Think Big leadership principle timeline TiVo Toyota transactional video on demand (TVOD) Tufte, Edward Twitch two-pizza teams (2PTL) Amazon Digital and autonomous teams challenges of characteristics, workflow, and management of course correction and history and origins of Inventory Planning team Mobipocket team

Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century

by Jeff Lawson  · 12 Jan 2021  · 282pp  · 85,658 words

were stepping all over each other, and the coordination energy to get anything done was massive. Things were slowing down, so Bezos wrote the “two-pizza team” memo proposing that they divide the company into small teams in order to move faster. (The idea was that you could feed the whole team

. Despite the fact that Amazon seemed to me like a huge company, it felt like a startup. The whole company was divided into small, two-pizza teams, each operating like a tiny startup. There was urgency. There was energy. What we were doing mattered. We were inventing the future—that’s the

in the company to learn from others but still have a functioning meeting. The goal is to address one of the shortcomings of the “two-pizza team” approach, which is that when you have a large number of small teams (our product side alone has 150 teams) they all start to run

interface with each other. This would enable them to move independently, with the relationship between teams formalized in technology. With this one-pager, the “two-pizza team” was born. Rick went back to his leaders and within a week turned Jeff’s initial idea into a six-page workable plan that Amazon

Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton and Manuel Pais  · 16 Sep 2019

provides the kind of valuable input provided by people in a productivity or tooling team, facilitating and encouraging good practices across teams. The Amazon two-pizza-team model is an example of stream-aligned teams: the teams are substantially independent, have ownership over their services, and have responsibility for the runtime success

, May 1, 2009. https://hbr.org/2009/05/why-teams-dont-work. Crawford, Jason. “Amazon’s ‘Two-Pizza Teams’: The Ultimate Divisional Organization.” JasonCrawford.org (blog), July 30, 2013. http://blog.jasoncrawford.org/two-pizza-teams. Cunningham, Ward. “Understand the High Cost of Technical Debt by Ward Cunningham— DZone Agile.” Dzone.com, August 24

, 2019. Morris, Kief. Infrastructure as Code: Managing Servers in the Cloud. Sebastopol, CA: O’Reilly Media, 2016. Munns, Chris. “Chris Munns, DevOps @ Amazon: Microservices, 2 Pizza Teams, & 50 Million Deploys per Year.” SlideShare.net, posted by TriNimbus, May 6, 2016. http://www.slideshare.net/TriNimbus/chris-munns-devops-amazon-microservices-2

-pizza-teams-50-million-deploys-a-year. Murphy, Niall. “What is ‘Site Reliability Engineering’?” Landing.Google.com, https://landing.google.com/sre/interview/ben-treynor.html. Murphy,

al., Team of Teams, 94. 3. Rozovsky, “Re:Work—The Five Keys to a Successful Google Team.” 4. Crawford, At opening quotes. “Amazon’s ‘Two-Pizza Teams.’” 5. Dunbar, “Neocortex Size as a Constraint on Group Size in Primates,” 469–493. 6. Snowden, “The Rule of 5, 15 & 150;” Dunbar, How Many

, The Principles of Product Development Flow, 265. 3. Lane, “The Secret to Amazon’s Success—Internal APIs;” Hoff, “Amazon Architecture.” 4. Crawford, “Amazon’s ‘Two-Pizza Teams;’” Munns, “Chris Munns, DevOps @ Amazon.” 5. Kramer, “The Biggest Thing Amazon Got Right.” 6. Sussna, Designing Delivery, 148. 7. Pink, Drive, 49. 8. Eckstein, “Architecture

Amazon Unbound: Jeff Bezos and the Invention of a Global Empire

by Brad Stone  · 10 May 2021  · 569pp  · 156,139 words

, and meticulous consideration by company leaders, most of all from Bezos himself. Meanwhile, working groups inside Amazon were broken into small versatile units, called two-pizza teams (because they were small enough to be fed with two pizzas), and were ordered to move quickly, often in competition with one another. This unusual

. But that wasn’t growing smoothly or fast enough for Bezos’s liking. George instead reorganized Alexa around the Amazonian ideal of fast-moving “two pizza” teams, each devoted to a specific Alexa domain, like music, weather, lighting, thermostats, video devices, and so on. Each team was run by a so-called

Bezos approved all these changes and stayed intimately involved, attending product reviews and reading the Friday night compilation of updates from all the various two-pizza teams, and responding with detailed questions or problems that the groups would then have to fix over the weekend. Alexa execs, like leaders elsewhere in Amazon

for users to phrase commands in the right way to trigger third-party skills and specialized features. The decentralized and chaotic approach of countless two-pizza teams run by single-threaded leaders was manifested in aspects of the product that had become overly complex. Basic tasks, like setting up a device and

atmosphere while the truck sent out text alerts to the smartphones of nearby customers, announcing the item on sale that day. Herrington assembled a two-pizza team to develop the project over the fall of 2014, alongside Prime Now and the private-label push. Though the idea itself was whimsical, the technical

delivery to another. Fraud was prevalent, with drivers finding loopholes to get paid for work they didn’t do. One problem was that dueling two-pizza teams in Seattle and Austin worked concurrently on versions of Rabbit for iOS and Android, magnifying the confusion among delivery firms. “All of the things were

, 291, 301, 303, 335, 351, 354–57, 364 third-party sellers on, see Amazon Marketplace transportation networks of, see Amazon transportation networks and logistics two-pizza teams at, 10, 49, 51, 205, 239 2015 as critical year for, 94 Vine program of, 201 Washington Post and, 117–21, 126, 130, 134, 357

How to Build a Billion Dollar App: Discover the Secrets of the Most Successful Entrepreneurs of Our Time

by George Berkowski  · 3 Sep 2014  · 468pp  · 124,573 words

of simple processes in place to be in a position where your company can weather any kind of hiccups – and continue to scale quickly. Two-Pizza Teams and Internal APIs Amazon’s business model is predicated on the thinnest of margins, and as a result the company has been able to innovate

one of the most entrepreneurial companies in history. Two reasons Amazon is able to keep its momentum even with 97,000 employees are pizza teams and APIs.1 TWO-PIZZA TEAMS. Jeff Bezos structured Amazon as a decentralised company where small groups can innovate independently and are free from the inherent problems of groupthink

. He introduced the principle of the two-pizza team. If two pizzas can’t feed a team, then the team is too large. That limits a task force to five to seven people, depending

419, 421 and getting your app found 147 initial public offering 421 and Instagram 51, 76–7, 79–80 name 110 and virality 281 ‘two-pizza’ teams 374 Uber 6, 36, 87, 89, 333, 350 and attribution for referrals 231 design 131 funding 320, 384, 422 international growth 295, 299–302 name

WTF?: What's the Future and Why It's Up to Us

by Tim O'Reilly  · 9 Oct 2017  · 561pp  · 157,589 words

focus on who their customers are, regardless whether they are externally or internally.” Work is done by small teams. (Amazon famously describes these as “two-pizza teams,” that is, teams small enough to be fed by two pizzas.) These teams work independently, starting with a high-level description of what they are

team building each function. Kim explained to me that “writing the press release first is a mechanism to make customer obsession concrete.” As are two-pizza teams producing services with hardened APIs. “Amazon does a better job of creating these kinds of mechanisms for its corporate values than any other company I

: O’Reilly, 2015), 6. 114 “communication is terrible!”: Janet Choi, “The Science Behind Why Jeff Bezos’s Two-Pizza Team Rule Works,” I Done This Blog, September 24, 2014, http://blog.idonethis.com/two-pizza-team/. 115 “both to technology and to the workplace”: Burgess, Thinking in Promises, 1. 116 animated explainer videos: Henrik

The Geek Way: The Radical Mindset That Drives Extraordinary Results

by Andrew McAfee  · 14 Nov 2023  · 381pp  · 113,173 words

The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece

by Ron Jeffries  · 14 Aug 2015  · 444pp  · 118,393 words

The Startup Way: Making Entrepreneurship a Fundamental Discipline of Every Enterprise

by Eric Ries  · 15 Mar 2017  · 406pp  · 105,602 words

The Connected Company

by Dave Gray and Thomas Vander Wal  · 2 Dec 2014  · 372pp  · 89,876 words

Building Microservices

by Sam Newman  · 25 Dec 2014  · 540pp  · 103,101 words

API Marketplace Engineering: Design, Build, and Run a Platform for External Developers

by Rennay Dorasamy  · 2 Dec 2021  · 328pp  · 77,877 words

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

by Sam Newman  · 14 Nov 2019  · 355pp  · 81,788 words

Shipping Greatness

by Chris Vander Mey  · 23 Aug 2012  · 231pp  · 71,248 words