Innovation und Geschwindigkeit mit den Zwei-Pizza-Teams von Amazon vorantreiben
Artikel | 10 Min. Lesezeit
von Daniel Slater
Worldwide Head, Culture of Innovation, AWS
Lernen, Innovation zu skalieren - nicht Komplexität
Führungskräfte von heute möchten ihre Organisationen in die Lage versetzen, ständig neue Angebote einzuführen, kontinuierliche betriebliche Verbesserungen vorzunehmen und das Wachstum des gesamten Unternehmens zu beschleunigen.
Im AWS-Erkenntnisbericht von Führungskräften 2022: Cloud-gestütztes Wachstum, einer umfassenden Umfrage unter 1 500 Führungskräften in 15 Märkten und 10 Branchen, wurde festgestellt, dass mehr als die Hälfte der heutigen Führungskräfte angeben, dass das Geschäftswachstum in ihrer Unternehmensstrategie Priorität hat. Dazu gehören schnelle Innovationen in ihrem bestehenden Geschäft sowie die Schaffung neuer Kundenwerte, Umsatzströme und Wachstumschancen.
Die Gewährleistung von Agilität und Geschwindigkeit in den Teams ist entscheidend für erfolgreiches Wachstum und digitale Transformation, aber sie ist oft schwer zu realisieren. Legacy-Organisationsstrukturen eignen sich möglicherweise nicht für ein Tempo, das auf die Beschleunigung von Innovationen abzielt. Auch Unternehmen, die anfangs noch agil sind, können sich mit zunehmendem Umfang ihres Geschäfts überfordern und sich in Prozessen und Entscheidungsfindungen verzetteln, wenn das Geschäft expandiert und komplexer wird.
Unternehmen werden immer globaler. Produkte und Services werden vollständig digital. Durch all das steigen die Kundenerwartungen, da sie jetzt über Informationen verfügen und Entscheidungen fällen können.
Um mit diesem Tempo des Wandels Schritt zu halten und gleichzeitig auf Marktchancen und Störungen zu reagieren, braucht es unternehmerische Flexibilität. IT-Verantwortliche, die einen kundenorientierten Ansatz verfolgen, können die Voraussetzungen dafür schaffen.
„Um wirklich ein leistungsstarkes agiles Unternehmen zu werden, muss man seine Organisationsstruktur anders betrachten und bereit sein, seine Denkweise und sein Verhalten zu ändern.“
Amazon und AWS sind gegen diese Dynamik nicht immun, da unser eigenes Unternehmen skaliert hat. Als die Anzahl der Geschäftseinheiten zunahm und unsere globale Belegschaft schnell wuchs und geografisch verstreuter wurde, mussten wir die Organisation unserer Teams umgestalten, um die rasante Innovation aufrechtzuerhalten und unsere Tag-1-Mentalität beizubehalten.
Innovationstempo
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 Gesetz von Conway (1967 vom berühmten Informatiker Melvin Conway geprägt) besagt, dass die Art und Weise, wie eine Organisation strukturiert ist und wie ihre Teams kommunizieren, sich auf die Art und Weise auswirkt, wie sie Technologien und Systeme entwickelt.
Förderung von Innovationen mit dem Zwei-Pizza-Team
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.
Die Gründe für Zwei-Pizza-Teams
Kleine Teams haben die Bürokratie minimiert und die Zeit maximiert, sich auf Innovationen für die Kunden zu konzentrieren, was wiederum die Mitarbeiterzufriedenheit erhöht.
Sie schwächen den Ringelmann-Effekt ab (die Tendenz, dass die Produktivität des Einzelnen in größeren Gruppen abnimmt).
Team haben die Möglichkeit, schnell zu arbeiten, frühzeitig und häufig zu experimentieren und die gewonnenen Erkenntnisse rasch anzuwenden, um den Wert für ihre Kunden kontinuierlich zu steigern.
Sie tragen 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.
Verantwortung übernehmen
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.
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.
Single-Threaded Leader
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 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ü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.
Die Rolle von Narrativen bei Amazon
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.
Erkenntnisse
Auch wenn die Struktur und die Mechanismen von Zwei-Pizza-Teams nicht für alle Unternehmen geeignet sind, können Führungskräfte in ihren Unternehmen für mehr Agilität, Geschwindigkeit und eine Innovationskultur sorgen. Sie können nach Möglichkeiten suchen, die Autonomie und Eigenverantwortung auf Teamebene zu erhöhen, indem sie den Teams Leitlinien an die Hand geben (die Führungsprinzipien von Amazon sind ein solches Beispiel), die unabhängige, qualitativ hochwertige und schnelle Entscheidungen ermöglichen.
Eine bewusste Entscheidung über die Teamstruktur und darüber, wie diese Struktur die Fähigkeit der Teams optimiert, die technische Architektur zu nutzen (und umgekehrt), kann dazu beitragen, die Flexibilität, Agilität und Marktreife neuer Innovationen zu fördern, die den Bedürfnissen der Kunden entsprechen. Cloud-Microservices, die von Teams genutzt werden, die stärker von Abhängigkeiten und Einschränkungen (sowohl technischer als auch administrativer Art) entkoppelt sind, ermöglichen es ihnen, schneller auf Marktveränderungen zu reagieren und auf der Grundlage der gewonnenen Erkenntnisse zu iterieren.
Die Vereinfachung und Rationalisierung der Probleme, die jedes Team zu lösen hat, kann die Innovation beschleunigen und es den Teams ermöglichen, mehr Zeit damit zu verbringen, ihre Kunden zu verstehen und in deren Namen zu erfinden.
Schließlich können Führungskräfte den Teams gezielte Mechanismen zur Verfügung stellen, die es ihnen ermöglichen, neue Ideen einzubringen. Sie können mutige Experimente fördern, indem sie das Scheitern als notwendigen Teil der Erfindung akzeptieren. Und sie können Teams in die Lage versetzen, Erfahrungen zu sammeln und auszutauschen, um künftige Experimente zu verbessern – und das alles mit dem richtigen Maß an durchgängiger Führung und Steuerung.
Auf diese Weise werden Unternehmen zu einer „Erfindungsmaschine“, die kontinuierliche Möglichkeiten für neues Geschäftswachstum bietet und ein echtes Unterscheidungsmerkmal darstellt, das es ihnen ermöglicht, Kunden zu überraschen und zu begeistern und in deren Namen zu erfinden.
Erste Schritte
Suchen Sie nach Möglichkeiten, kleineren autonomen Teams die Verantwortung für einen rationalisierten Service, ein Angebot oder ein Kundensegment in einer Hand zu geben.
Führen Sie diese Teams mit Single-Threaded Leadern, die sich darum bemühen, Hindernisse für ihre Teams aus dem Weg zu räumen, damit diese ständig experimentieren können, anstatt die Engpässe bei der Entscheidungsfindung zu sein.
Schaffen Sie kohärente, hochgradig verteilbare Mechanismen, die den Entwicklern Anhaltspunkte für autonome, qualitativ hochwertige und rasche Entscheidungen geben.
Lassen Sie die Führungskräfte das richtige Maß an Kontrolle und Steuerung schaffen, um Schnelligkeit, Agilität und Kundenorientierung zu gewährleisten, und ermutigen Sie zu ständigem Experimentieren und zum Austausch der Lehren aus Fehlschlägen.
„… Erfindungen sind die Wurzel aller echten Wertschöpfung. Und Wertschöpfung lässt sich am besten als Kennzahl für Innovation betrachten.“
– Jeff Bezos, Brief an die Aktionäre 2020
Daniel Slater, Worldwide Head, Culture of Innovation, AWS
Dan Slater leitet als Teil des AWS-Teams für digitale Innovation die Innovationskultur. Dan kam 2006 zu Amazon, um die ersten Angebote für digitale Inhalte direkt an Kunden zu lancieren. Er half beim Start des Kindle-Geräts und der globalen Content-Marktplätze von Kindle sowie des Selbstverlagsdienstes von Amazon, Kindle Direct Publishing (KDP). Nachdem Dan das digitale Geschäft der 60 größten Fachverlage überwacht hatte, leitete er die Akquisition von Inhalten, die Nachfragegenerierung und die Lieferantenbeziehungen für KDP. Vor seiner Zeit bei Amazon war Dan Senior Acquisitions Editor bei Simon & Schuster and Penguin und leitete den Vertrieb eines IT-Verlagsunternehmens (Vista, jetzt Ingenta). Dan wurde in Toronto, Kanada, geboren und lebt mit seiner Frau und seinen zwei Kindern in Seattle. Er erwarb seinen MBA an der Fuqua School of Business der Duke University und absolvierte einen dualen Bachelor of Arts an der Cornell University.
Zugehörige Lektüre
Grundsätze kundenorientierter Innovation
Produktmanagement bei Amazon
Den nächsten Schritt machen
In Verbindung bleiben
AWS Executive Insights ist ein digitaler Ort für Geschäfts- und Technologieführungskräfte, an dem wir Informationen, bewährte Methoden und Einladungen zu Events veröffentlichen.
Zuhören und lernen
Hören Sie sich an, wie Führungskräfte und AWS Enterprise Strategists, allesamt ehemalige leitende Führungskräfte, über ihre Erfahrungen mit der digitalen Transformation sprechen.
Neue Erkenntnisse erschließen
Erfahren Sie, wie Sie das Wachstum fördern und Änderungen implementieren, die auf Ihr Unternehmen ausgeweitet werden können.