Working Backwards, Colin Bryar title: Organisationen #6: Working Backwards, Colin Bryar & Bill Carr Bill Carr
(back to books)
- Amazon hat von Anfang an klare, beständige Werte:
- in 1997 und 2018 beschrieb Jeff Bezos 4 Werte: extremer Kundenfokus, langfristiges Denken, Innovations-/Fehlerbereitschaft, operative Exzellenz
- Weekly Business Review (WBR) + meeting (tactical end-to-end review of the business week, owned by Finance)
- Method: DMAIC (Define-Measure-Analyze-Improve-Control)
- deck contains many graphs, tables, anecdotes and exception reporting and does not change significantly over time
- written narrative undercuts efficiency of the read-through with so much data (anecdotes are fine though)
- Caveats: Don't compromise on gathering data across systems; don't continue with imperfect information on a process you don't understand yet
- Alltag von Jeff Bezos:
- "Reguläre" Arbeitszeiten von 10-19 Uhr, 5-7 Meetings pro Tag mit Produkt- und Vorstands-Teams
- wöchentliche Termine: 4-stündiges S-Team-Meeting (ca. 80% Fokus auf 2-4 S-Team-Zielen), WBR, informal Monday-morning S-Team breakfast
- Für maximale Aufmerksamkeit verkündete Jeff Bezos neue Produkte im Press Release der Quarterly Earnings Results
- Organisatorische Innovation: "Single-Threaded Leadership"
- Problem: eingeschränkte Lieferfähigkeit
- Warum #1: “The best way to fail at inventing something is by making it somebody’s part-time job.” - unklare Prioritäten
- Warum #2: viele, feste Abhängigkeiten (Firmen versuchen Kommunikation zu verbessern. Entferne stattdessen Abhängigkeit.)
- Idee: ein Team, das sich nur auf ein/e Projekt/Initiative/Produkt fokussiert. Interaktion mit anderen über APIs.
- einziger Zugang zu Business-Funktionalität ist API; kein direkter Datenbank-Zugriff; kein Daten-Austausch zwischen Services.
- Größter Erfolgsfaktor: Führungskraft mit richtigen Skills, Autorität, Erfahrung.
- Ein Single-Threaded-Team beginnt damit, Abhängigkeiten zu weiteren Teams zu lösen. Das bringt keinen unmittelbaren Mehrwert.
- Manchmal müssen Single-Threaded-Teams andere Initiativen unterstützen. Das ist eine Art Steuer, um autonom arbeiten zu dürfen.
- Operative Innovation: Working Backwards process
- Problem: We are stuck in internal company perspective and lack external customer perspective
- Idea: define customer experience, then iteratively work backwards until you have clarity around what to build.
- Tool 1: Six-Pager (describe, review, propose any type of idea, process, business)
- Format: max. six pages, no formatting tricks (assumed avg. reading speed = 3 mins per page);
meeting starts with reading the six-pager (roughly 1/3 of meeting);
strong six-pagers anticipate counterarguments; half-baked mock-up = half-baked thinking
FAQs and appendices can be attached, but not required reading in meeting.
- Nach Lesen eröffnet Six-Pager-Owner Diskussion (kein Wiederholen des Dokuments)
Feedback wird protokolliert.
- Tool 2: PR/FAQ (announce product and anticipate tough questions)
- 6 PR components: Heading, Subheading, Summary Paragraph, Problem Paragraph, Solution Paragraph(s), Quotes and Getting Started
- FAQ should be max. 5 pages and is often divided into external (customer focused) and internal (focused on your company) Qs.
- Amazons Strategieprozess: transparente, gemeinsame Zielsetzung
- im Sommer: 4-8 Wochen Zielsetzung durch S-Team (bspw.: “Steigere Umsatz von $10 auf $15 Mrd.”)
- ab Herbst: 3-6 Monat für OP1 ("Umsetzungsnarrativ") durch Unternehmensgruppen
- OP1-Komponenten: Bewertung vergangener Leistung, Zielerreichung, Lessons Learned; Schlüsselinitiativen für folgendes Jahr;
detaillierte Budgetanforderungen (inkl. Neubesetzungen, Marketing-Budgets, ...), S-Team markiert Initiativen/Ziele, die sie als wichtig betrachten
("S-Team-Ziele", von Finanz-Team überwacht und quartalsweiser Review)
- Ziele müssen SMART (Specific, Measurable, Attainable, Relevant, Timely) und aggressiv (nur 75%-Zielerreichung erwartet) sein
- im Januar: OP2-Prozess (Anpassung OP1 um Ergebnisse aus Q4, gleicht OP1-Ziele an Unternehmensziele an)
- Später hat Amazon den Prozess für Retail und AWS aufgeteilt, mit unabhängigen S-Team-Zielen
- Recruiting-Innovation: Bar Raisers
- Problem: variierende Qualität der Recruiting-Entscheidungen, weil kein standardisierter Recruiting-Prozess
- Idee: skalierbarer Prozess mit "Bar Raisern" für planbare, erfolgreiche Recruiting-Entscheidungen
- Bedingungen: Raise the bar; reduce confirmation bias; focus on essentials (Fragen ohne klares Ziel vermeiden)
- Bar Raiser helfen Fehler zu vermeiden, coachen Teilnehmer, haben Veto-Recht (darf nicht gleiche Person wie Manager oder Recruiter sein)
- Written Feedback: Feedback mit Beispielen aus Interview; beleuchtet mind. eines der Arbeitsprinzipien von Amazon; beinhaltet finale Bewertung des Interviewers (ja, eher ja, eher nein, nein); weiteres Feedback erst danach einsehbar.
- Offer Through Onboarding: Manager soll Anbgebot machen, nicht Recruiter; nach Angebot ein Team-Mitglied mind. 1x pro Woche beim Kandidaten nachfragen; "Buchbombe" schicken; VP/CEO bitten, Kandidaten anzurufen.
- Gescheiterte Organisationsinnovation: "New Project Initiatives (NPIs)"
- Gescheiterter Ansatz, der von Amazon aufgegeben wurde. Hieraus entstanden "Two-Pizza-Teams" und letztendlich "Single-Threaded Leadership".
- Idee: Entscheiden, welche Initiativen sofort und welche später begonnen werden.
- Notwendig: One-Pager; welche Teams betroffen; wie gelangt Produkt zum Kunden; Business Case; warum strategisch wichtig
- Ablauf: 1) quartalsweise reichen Teams Projektinitiativen ein, die Ressourcen ausserhalb ihrer Teams benötigen; 2) NPI-Core-Team filtert NPI-Einreichungen; 3) Technisches und finanzielles Scoping (in einem Meeting-Raum): Führungskraft gibt Schätzung ab, wie viele Ressourcen von ihrem Team benötigt werden würden; 4) NPI-Core-Team entscheidet, welche Projekte tatsächlich umgesetzt werden.
- Problem mit NPIs:
- "Getting NPI'd": Dein eigenes Projekt wurde nicht freigegeben, aber du musst jetzt zusätzlich zu deiner bestehenden Arbeit Initiativen anderer unterstützen. Du bekamst "nichts für etwas".
- Löste zugrundeliegendes Problem nicht (feste Abhängigkeiten zwischen Teams), sondern erhöhte Kommunikations-Overhead