Innovation und Geschwindigkeit mit den Zwei-Pizza-Teams von Amazon vorantreiben

Wie viele andere Unternehmen, die in der Dotcom-Ära gegründet wurden, war auch Amazon auf schnelle Agilität und die Bereitstellung eines konstanten Werts für die Kunden ausgerichtet. In seinem allerersten Brief an die Aktionäre im Jahr 1997 schrieb Jeff Bezos darüber, wie wichtig es ist, von den Kunden besessen zu sein und für sie einen kontinuierlichen, langfristigen Wert zu schaffen – selbst auf Kosten des kurzfristigen Unternehmensgewinns. Diese unerbittliche Besessenheit von den Kunden war nur möglich, indem eine dazu passende Organisationsstruktur aufgebaut und entwickelt wurde. Und zwar eine Organisationsstruktur von hochmotivierten Entwicklern, die jeden Tag mit Begeisterung aufwachen, um die schwierigsten Probleme der Kunden zu lösen und in ihrem Namen zu erfinden.

„Die Messlatte bei der Einstellung von Mitarbeitern hoch anzusetzen“, schrieb Jeff, „war und wird auch weiterhin das wichtigste Element des Erfolgs von Amazon.com sein“.

Dies war in den frühen Tagen leichter zu erreichen, als sich das Unternehmen auf den elektronischen Handel konzentrierte und die Teams – und die technische Architektur, auf die sie sich für schnelle Innovationen verließen – stärker zentralisiert und eng miteinander verbunden waren. Aber im Laufe der Zeit, als Amazon die Anzahl der Geschäftsbereiche und neuen Innovationen ausbaute, um die Bedürfnisse unserer Kunden zu erfüllen, fingen wir an unter Druck zu geraten, was die Geschwindigkeit und Agilität, mit der wir arbeiten konnten, betrifft. Der Wunsch, eine „Erfindungsmaschine“ zu bleiben, wie Jeff es in seinem Brief an die Aktionäre von 2015 formulierte – ein Unternehmen, das „die außergewöhnlichen Fähigkeiten zur Kundenbetreuung, die durch die Größe ermöglicht werden, mit der Schnelligkeit, Wendigkeit und Risikobereitschaft, die normalerweise mit unternehmerischen Startups verbunden sind, kombinieren kann“ – bekam einen Dämpfer. Unsere eng gekoppelte Architektur und Organisation halfen uns einfach nicht, so schnell zu sein, wie wir es wollten oder brauchten.

Um der zunehmenden Trägheit und Ineffizienz entgegenzuwirken, änderten wir unsere technische Architektur grundlegend und wandelten sie in eine so genannte Microservices-Architektur um. Wir entkoppelten unsere monolithische Architektur in ein riesiges Netzwerk von einzelnen, eigenständigen Services. Auf diese Weise waren wir besser in der Lage, neue Innovationen und Angebote schnell auf den Markt zu bringen, vorhandene Services auf der Grundlage der sich ständig ändernden Kundenbedürfnisse rasch zu iterieren und ständig mit neuen Ideen zu experimentieren, um sie für unsere Kunden zu entwickeln.

Es reichte jedoch nicht aus, einfach die Technologie zu überarbeiten, mit der unsere Entwickler Innovationen vorantreiben. Wir mussten auch die Art und Weise umstrukturieren, wie die Teams organisiert waren, um ihre Fähigkeit zu maximieren, nah an den Kunden und ihren Bedürfnissen zu bleiben, innovative Produkte und Services in ihrem Namen schnell auf den Markt zu bringen und die Vorteile der Agilität und Geschwindigkeit, die eine Microservices-Architektur bieten kann, optimal zu nutzen. Diese Organisationsstruktur wurde als Amazons „Zwei-Pizza-Teams“ bekannt.

Das Konzept der Zwei-Pizza-Teams von Amazon ist einfach: Kein Team sollte so groß sein, dass es mehr als zwei Pizzen braucht, um es zu ernähren. Abgesehen von der Anzahl oder der Art der Beläge (wir haben hier nicht die Zeit und den Platz, um die „Gehört Ananas auf Pizza?“-Debatte zu führen), besteht ein solches Team idealerweise aus weniger als 10 Personen: Kleinere Teams minimieren die Kommunikationswege und verringern den bürokratischen Aufwand und die Entscheidungsfindung. Auf diese Weise können sich die Zwei-Pizza-Teams mehr auf ihre Kunden konzentrieren und in deren Namen ständig experimentieren und innovieren – die größte Priorität der leistungsstarken Teams bei Amazon.

Kleinere Teams erhöhen auch die Eigenverantwortung und die Eigenständigkeit. Dies kann den Ringelmann-Effekt abschwächen: die Tendenz, dass die Produktivität des Einzelnen in größeren Gruppen abnimmt. Wenn die Teamressourcen zunehmen, liegt der Schwerpunkt weniger auf den individuellen Bemühungen, da sich die Mitarbeiter mehr auf andere stützen, um die Last zu schultern. Der Beitrag des Einzelnen nimmt mit zunehmender Teamgröße ab. Umgekehrt nimmt die individuelle Leistung zu, wenn die Teamgröße abnimmt.

Kleinere Teams erhöhen auch die Mitarbeiterzufriedenheit – ein zentrales Anliegen der Unternehmen, die heute versuchen, die besten Talente anzuziehen und zu halten. Eine bemerkenswerte Studie von Hackman und Vidmar zeigt, dass die individuelle Zufriedenheit mit zunehmender Teamgröße abnimmt. In großen Teams ist der Beitrag des Einzelnen oft weniger erkennbar, und die Verantwortung des Einzelnen für bestimmte Bereiche wird diffuser.

Dies wurde in einschlägigen Studien bestätigt. Die Gallup-Studie „The State of the American Workplace“ zeigte, dass Unternehmen mit weniger als 10 Mitarbeitern ein Engagement von 42 % oder mehr erreichten, während das durchschnittliche Engagement in größeren Unternehmen unter 30 % lag.

Aber bei den Zwei-Pizza-Teams von Amazon geht es nicht nur um die Größe. Ein Schlüsselfaktor für konstante Innovation und Geschwindigkeit in einer Zwei-Pizza-Teams-Struktur ist, dass sie sich auf eine einzige Sache konzentrieren können.

► Podcast anhören: C-Suite Strategies for Leading Significant Change

Bei einem Zwei-Pizza-Team nicht nur um die Größe, sondern auch darum, die Eigenverantwortung und Unabhängigkeit auf Teamebene zu fördern und voranzutreiben.

Bei Amazon und AWS sind Zwei-Pizza-Teams nur für ein bestimmtes Produkt oder einen bestimmten Service zuständig. Anstatt komplexe Systeme zu warten oder Probleme zu lösen, die mehrere Services, Geschäftsbereiche oder Kundensegmente umfassen, konzentrieren sich Zwei-Pizza-Teams auf einen einzigen Service oder ein einziges Angebot und nur auf die Kunden, die es nutzen. Diese Konzentration auf eine einzige Aufgabe fördert Effizienz und Skalierbarkeit. Die Roadmap von Zwei-Pizza-Teams – einschließlich der Kompromisse und Prioritäten, die sie eingehen müssen – ist ausschließlich auf die Innovation für ihren Service und das Kundensegment ausgerichtet, das diesen Service nutzt.

Die Zwei-Pizza-Struktur fördert auch die Verantwortlichkeit des Teams. Zwei-Pizza-Teams übergeben etwas, das sie auf den Weg gebracht haben, nicht an ein anderes Team, um es zu betreiben. Die Verantwortlichkeit erstreckt sich auf das gesamte Kundenerlebnis und den gesamten Lebenszyklus des Produkts oder Service eines Zwei-Pizza-Teams.

Daher müssen Zwei-Pizza-Teams jeden Teil ihres Services im Griff haben, mit einer klaren Charta und einem genau definierten Auftrag. Sie müssen nah an ihren Kunden bleiben und die richtigen Nachverfolgungsmechanismen, Kennzahlen und KPIs schaffen, um sicherzustellen, dass ihr Service den Kunden ständig einen Mehrwert bietet.

Dies setzt auch voraus, dass ein Zwei-Pizza-Team über die richtigen Ressourcen verfügt – Technik, Tests, Produkt- und Programmmanagement, Betrieb usw. –, um ihnen zu helfen, ihren Service von Anfang bis Ende selbst in die Hand zu nehmen und zu betreiben.

Wenn die Nachfrage nach einem Produkt oder Service steigt, suchen wir nach Möglichkeiten, die Teams in separate Zwei-Pizza-Teams aufzuteilen, die an einem Teilbereich des Service arbeiten. Diese Mitose sorgt für eine flachere Organisationsstruktur, die Flexibilität, Autonomie und Eigenverantwortung der einzelnen Teams bewahrt.

Letztendlich geht es bei einem Zwei-Pizza-Team nicht nur um die Größe, sondern auch darum, die Eigenverantwortung und Unabhängigkeit auf Teamebene zu fördern und voranzutreiben – von der Ideenfindung bis zur Ausführung, von der laufenden operativen Verbesserung bis zur ständigen Produktiteration und Innovation. Es ermöglicht Teams, schnell zu arbeiten, früh und häufig zu experimentieren und Erkenntnisse schnell anzuwenden, um ihren Kunden einen kontinuierlichen Mehrwert zu bieten. Schnellere Innovationen und Experimente tragen auch dazu bei, die Kosten des Scheiterns zu senken – man lernt schneller und mit geringerem Einsatz, als es in späteren Entwicklungsphasen der Fall sein könnte.

Die Zwei-Pizza-Teamstruktur hat zwar für Amazon und AWS funktioniert, wir sind uns jedoch bewusst, dass sie möglicherweise nicht für alle Organisationen oder für jede Geschäftseinheit geeignet ist. Zwei-Pizza-Teams sind nicht perfekt und nicht immun gegen Einschränkungen. Ein Beispiel ist, dass bei so vielen autonomen Single-Thread-Teams, die schnell arbeiten, um die Anforderungen ihrer eigenen Kunden zu erfüllen, die Gefahr von Doppelarbeit und isolierter Entwicklung besteht. Sie benötigen die richtige Führungsstruktur, um zu entscheiden, wann und wie Anstrengungen kombiniert werden sollen, die rein replikativ sind, ohne die Fähigkeit der Teams zu beeinträchtigen, Innovationen in ihren Zuständigkeitsbereichen voranzutreiben.

Angesichts des schnellen Experimentierens ist es auch notwendig, teamübergreifend zusammenzuarbeiten, um den Erfolg zu forcieren und Ressourcen zu rationalisieren. Noch wichtiger ist die Fähigkeit, die Lehren aus Fehlschlägen zu erfassen und weiterzugeben, um sie besser auf künftige Experimente anwenden zu können und die Richtung der Iteration und künftiger Investitionsentscheidungen abzustimmen.

Ein Aspekt der Organisation von Amazon und AWS, der zur Förderung von Unternehmensführung und Aufsicht beiträgt und es Teams gleichzeitig ermöglicht, schnell, unabhängig und autonom zu arbeiten, ist das Konzept der Single-Threaded Leader.

Die Rolle von Single-Threaded Leadern ist von entscheidender Bedeutung, wenn es darum geht, das richtige Maß an Aufsicht zu gewährleisten, damit ein Team die Möglichkeit hat, im Namen seiner Kunden unabhängig zu innovieren.

Die Führungskräfte von heute sind sich des enormen Nutzens bewusst, der sich aus der Fähigkeit ergibt, Innovationen und digitale Transformation schnell umzusetzen. Die Fähigkeit, neue Produkte und Services schnell auf den Markt zu bringen, ist nicht nur entscheidend für die Bereitstellung eines konstanten Werts für die Kunden, sondern kann auch zu einem entscheidenden Wettbewerbsvorteil für Ihr Unternehmen werden. Da Umfang und Reichweite des Unternehmens jedoch zunehmen, müssen die Führungskräfte sicherstellen, dass sie die richtige Struktur und Führung schaffen, um zu gewährleisten, dass die Teams in der Lage sind, schnell zu arbeiten.

Die Führung und das Management von Teams müssen „Leitplanken“ in Form von Integritätsschutz bereitstellen – Mechanismen, die es den Teams ermöglichen, schnell zu arbeiten und qualitativ hochwertige, schnelle Entscheidungen zu treffen – und nicht „Schlagbäume“, die die Geschwindigkeit behindern, indem sie Genehmigungs- oder Koordinierungslinien anschwellen lassen, bevor die Teams mit innovativen Experimenten vorankommen können.

Bei Amazon und AWS ist die Rolle der Single-Thread Leader von entscheidender Bedeutung für die Einführung des richtigen Maßes an Aufsicht, um die Befähigung der Teams zu erhalten, unabhängig im Namen ihrer Kunden zu innovieren, und gleichzeitig konsistente Mechanismen zu schaffen, die das richtige Maß an Kontrolle und richtungsweisender Vision ermöglichen. Single-Threaded Leader helfen dabei, eine strategische Vision zu entwickeln – und machen dann den Weg für ihr Team frei. Teamleiter müssen dabei helfen, Hindernisse aus dem Weg zu räumen, anstatt eine Barriere zu sein, durch die alle Entscheidungen hindurchgehen müssen. Kleine, agile, autonome Teams, die sich jeden Tag mit ihren Kunden beschäftigen, sind die wichtigsten Fachexperten in ihrem Service- und Kundensegment.

Single-Threaded Leader müssen die Autonomie ihres Teams wahren, um die besten Entscheidungen für das Unternehmen treffen zu können. Die Beteiligung von Single-Threaded Leadern an der Entscheidungsfindung ihres Teams besteht meist darin, das Team in Situationen zu leiten, in denen selbst mit den richtigen Dateninstrumenten und höchstem Urteilsvermögen der Weg nach vorn nicht klar ist.

Ein Mechanismus, der bei Amazon eingesetzt wird, um die Aufsicht durch einen Single-Thread-Leader an diesen Kontrollpunkten zu erleichtern, sind schriftliche Narrative. Diese helfen dabei, das aufgetauchte kundenorientierte Problem zu umreißen, Informationen aus tiefgreifenden Analysen und Daten, die das Team gesammelt hat, in die nächsten Schritte einfließen zu lassen und die Entscheidung, die das Team empfiehlt, zusammen mit den in Betracht gezogenen alternativen Wegen und den Risiken und Vorteilen jedes dieser Wege darzulegen.

Auch wenn es nicht eingängig erscheinen mag, sich die Zeit zu nehmen, ein solches Narrativ zu verfassen, um Geschwindigkeit und konstante Ausführung aufrechtzuerhalten, hat die Verwendung von Narrativen bei Amazon und AWS außerordentliche Vorteile gebracht. Zum einen werden diese Dokumente vom Team, seinen Stakeholdern und Fachexperten für das Angebot und das Kundensegment des Teams oft heftig diskutiert und weiterentwickelt, noch bevor sie auf dem Schreibtisch einer Führungskraft landen. Dies fördert die Zusammenarbeit und verschiedene Perspektiven, stellt Annahmen in Frage und dient dazu, die Ideen und Empfehlungen im Dokument zu optimieren. Letztlich führt dies oft zu qualitativ hochwertigeren Entscheidungen.

Bei Amazon und AWS gibt es viele verschiedene Narrative. Einige konzentrieren sich auf die Einführung neuer Produkte, wie z. B. unser PR/FAQ-Dokument (das für Pressemitteilung/Häufig gestellte Fragen steht), das aus unserem Ansatz des Rückwärtsarbeitens hervorgegangen ist. Bei anderen handelt es sich um betriebliche Geschäftsüberprüfungen (oft in wöchentlichen, monatlichen und vierteljährlichen Abständen), die eine Kontrolle und Steuerung der wichtigsten Kennzahlen, Trends, Spannungen, Risiken und Chancen ermöglichen, die sich im Geschäft eines Teams ergeben.

Wir haben Narrative, die vor der Einführung eines neuen Service eine strenge Überprüfung der Betriebsbereitschaft vorsehen, um sicherzustellen, dass die Aspekte der Architektur eines Service, die Qualität und die Verfahren für die Freigabe sowie die damit verbundenen Verfahren für das Management von Vorfällen und Ereignissen gut formuliert und dokumentiert sind. Andere Narrative, wie z. B. unser Dokument zur Fehlerkorrektur, werden nach der Einführung eines Service erstellt, negativ auf die Kunden auswirkt. Diese Dokumente werden von dem Team erstellt, das für den Service verantwortlich ist – nicht als Schuldzuweisung, sondern weil es als einziges Team, das für diesen Service verantwortlich ist, diesen Service und seine Kunden am besten kennt.

In diesen Dokumenten zur Fehlerkorrektur geht das Team in die Tiefe, um umfassend zu beschreiben, was passiert ist, und liefert relevante quantitative Analysen und Daten zu den Auswirkungen des Fehlers und den Gründen für das Auftreten des Fehlers. Es wird dargelegt, wie nicht nur die Ursache beseitigt wurde, sondern auch, was weiterhin unternommen wird, um sicherzustellen, dass sich so etwas nicht wiederholt – oft durch Aktualisierung oder Schaffung neuer Mechanismen für Kontrollen und kontinuierliche Verbesserung. Diese Dokumente werden dann in einer durchsuchbaren Datenbank gespeichert, damit wertvolle Erkenntnisse bereichsübergreifend weitergegeben werden können.