Mit Amazons Day-1-Sicht auf Entwicklungsteams blicken


prozesse teams organisation
Start Blog Mit Amazons Day-1-Sicht auf Entwicklungsteams blicken

Die Day-1-Kultur von Amazon taucht immer mal wieder auf meinem Radar auf. Und ich frage mich, warum Amazon oft nur mit dem Zwei-Pizza-Team zitiert wird.

Dieses Zitat bringt die Einstellung des Unternehmens auf den Punkt:

Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.

Mir gibt das zu denken und ermuntert mich, den eigenen Standpunkt zu ändern und neue Blickwinkel einzunehmen. Und so habe ich das als eine einfache Übung zur Selbstreflexion mit Sicht auf Entwicklungsteams gemacht.

Zunächst ein schneller Überblick, für was "Day 1" steht.

Eine kurze Übersicht der Day-1-Mentalität

Hier zur besseren Einordnung die Kernaspekte, um die es geht.

Denkweise und Handlungen für Day 1:

  • Schwerpunkt auf Kunden
  • Hochwertige und schnelle Entscheidungen
  • Experimente zur Inkubation neuer Fähigkeiten
  • Fehler erwarten und akzeptieren
  • Schlanke Organisationsstrukturen
  • Kleine Teams, denen das gehört, was sie schaffen
  • Priorisierung von langfristigem, nachhaltigem Wert

Denkweise und Handlungen für Day 2:

  • Schwerpunkt auf interne Herausforderungen
  • Bürokratische, konsensbasierte Entscheidungen
  • Investition in fest verankerte Fähigkeiten
  • Angst vor Fehlern
  • Tief geschichtete Organisationsstrukturen
  • Große Teams mit vielen Abhängigkeiten
  • Priorisierung von unmittelbarem, kurzfristigem Wert

Wenn Du mehr lesen und tiefer einsteigen möchtest, gibt es hier eine von vielen Quellen dazu.

Und nun Punkt für Punkt der beispielhafte Versuch, diese Sichtweisen auf Teams und ihre Umgebung anzuwenden.

Für wen machen wir das eigentlich?

Liegt der Fokus Deiner Arbeit auf dem konkreten Nutzen für eine Kundin?

Oder liegt der Fokus darin, eigene bzw. interne Probleme zu lösen?

Ein einfaches Beispiel: Ist es Dein Ziel als Agile Coach, Teamcoach, Scrum Master oder einer vergleichbaren Rolle, die beste Lösung zu finden, um möglichst schnell Wert für eine Kundin zu schaffen? Oder legst Du den Wert auf die Implementierung einer Blaupause?

Oder das berühmt-berüchtigte Beispiel Reisebuchung und Reisekostenabrechnung. Wo liegt der Fokus des Prozesses dabei in Deiner Organisation? Dass Du möglichst schnell zu Deiner Reise kommst und diese hinterher super einfach verbuchen kannst? Oder dass die Arbeit der Menschen erleichtert wird, die für Dich die Reise buchen und die hinterher die Unterlagen verwalten?

Wie kommen wir zu Entscheidungen?

Werden in Deiner Umgebung hochwertige/ brauchbare und schnelle Entscheidungen getroffen?

Oder reden wir eher von langwierigen Entscheidungsprozessen mit durchwachsenen Ergebnissen?

Generell ein so einfacher, wie oft übersehener Tipp: nicht jede Entscheidung muss per Konsens getroffen werden. Wirf z. B. einen Blick auf den guten alten Decision Poker, um noch sechs weitere Möglichkeiten der Entscheidungsfindung zu entdecken.

Und kannst Du oder Dein Team überhaupt alleine Entscheidungen treffen? Sprich: wie steht es um die Abhängigkeiten und die Autonomie? Wie viele Parteien müssen oder wollen mitreden?

Schließlich noch ein letzter Hinweis: Nicht jede Entscheidung ist unumkehrbar und manchmal sind die vorhandenen Informationen auch einfach "gut genug".

Wozu streben wir Veränderung an?

Führst Du in Deinem Team bzw. Deinem Umfeld Experimente zur Erprobung oder Entwicklung neuer Fähigkeiten durch?

Oder investierst Du in Altbewährtes?

Wozu?

Und im Grunde ist des Pudels Kern: die Frage nach dem Ziel.

Auf der einen Seite gibt es viele Gründe, Veränderungstheater zu spielen. Fragt man hier nach dem "wozu", kämen wahrscheinlich ich-bezogene Antworten rund um Macht und Karriere. Im besten Fall noch Themen wie Recruiting oder Retention. Vielleicht auch einfach Unwissenheit.

Auf der anderen Seite geht es tatsächlich um das Streben nach Veränderung. Und v.a. auch hier lohnt sich das tiefe Bohren nach dem eigentlichen Ziel.

"Wir möchten unseren Prozess anpassen." Wozu?

"Wir führen Modell/ Methode/ Framework XYZ ein." Wozu?

"Wir wollen agil/ anpassungsfähig werden." Wozu?

Selbst bei den darauffolgenden Antworten kannst Du noch tiefer bohren. Das lohnt sich, um einen echten Nutzen zu identifizieren.

Und möglicherweise gibt es dann zur eigentlichen Lösung bessere Wege als ursprünglich gedacht oder geplant.

Wie gehen wir mit Fehlern um?

Ach ja, der Klassiker. Fehler. Oder war es doch eher ein Irrtum?

Werden in Deiner Umgebung Misserfolge in Kauf genommen?

Oder gibt es eine Angst vor Fehlschlägen? Vielleicht wird auch härteres Vokabular wie "Versagen" genutzt?

Strebst Du eine kontinuierliche Verbesserung an, sind Rückschläge unvermeidlich. Dabei sind Fehler und Irrtümer in Ordnung, solange aus ihnen gelernt wird. (Nachlässigkeit und Schludrigkeit fallen in eine andere Kategorie.)

Fehler zu machen sollte dabei nicht das eigentliche Ziel sein - denn seien wir mal ehrlich: Sie machen keinen Spaß.

Und trotzdem kommt ein Team ohne sie nicht aus, wenn es lernen und sich weiterentwickeln will.

Wie sieht unser Umfeld aus?

Ist Dein Entwicklungsteam eingebettet in einer tief geschichteten Organisationsstruktur?

Oder reden wir von Strukturen, die eine gewisse Flexibilität aufweisen? Die unterstützen und nicht behindern?

Natürlich kann nicht jedes Unternehmen im Wachstum weiter als ein Start-up agieren. Und gegen Hierarchie und Struktur per se ist nichts einzuwenden.

Die Frage ist, ob das Umfeld weiter schnelle Entscheidungen zulässt. Oder ob mit wachsender Komplexität nur mehr Kommunikationsebenen einziehen, lange Genehmigungsketten abgeklappert werden müssen und die Notwendigkeit von Konsensentscheidungen oder Kompromissen entsteht.

Wer besser sein will als die Konkurrenz, muss schneller lernen und sich schneller anpassen. Und das im gesamten Unternehmen.

Wie groß ist unser Team?

Reden wir von einem großen Team mit vielen Abhängigkeiten und langen Entscheidungswegen?

Oder von einem kleinen, anpassungsfähigen Team, das Verantwortung für sein Projekt oder Produkt übernimmt?

Die Grenze zwischen (zu) groß und klein genug kann bei der bekannten Faustformel von 10 Menschen oder weniger liegen. Mit Betonung auf Faustformel. Denn auch bei Überschreitung dieser Größe kann immer noch ein produktives Team vorliegen.

Der ausschlaggebende Punkt ist wie so oft die Leitfrage, wie eigenständig das Team agieren und Entscheidungen treffen kann.

Hat es ein klares Ziel? Hat es alle nötigen Fähigkeiten und Fertigkeiten, um das Ziel zu erreichen? Kann, will und darf es eigenständig Entscheidungen treffen?

Das alles sind gute Voraussetzungen, damit die Menschen in diesem Team Verantwortung für ihr Produkt und ihren Kunden übernehmen.

In welchen Zeithorizonten denken wir?

Priorisiert Dein Team bzw. Dein Unternehmen sofortigen, kurzfristigen Wert?

Oder hat ein langfristiger, nachhaltiger Wert Vorrang?

Das wirft natürlich die Frage auf, was "Wert" eigentlich ist. Und ob das Entwicklungsteam ein Verständnis dafür hat, welchen Wert es eigentlich schafft. Oder versteht, was das Geschäftsmodell des Produkts bzw. des Unternehmens ist.

Auch ist die Frage insofern gemein, als je nach Situation das Pendel mal in die eine und mal in die andere Richtung ausschlagen kann.

Doch wo liegt in Deiner Umgebung der Schwerpunkt? Eben eher auf der Seite von "möglichst schnell und davon viel", egal wie hoch die Zinsen in der Zukunft sein werden? Oder eher bei langfristigen Investitionen in die Menschen, die Kundenbeziehungen und das Produkt?

Fazit

Ja, das sind viele Fragen und nur wenige Antworten. Zudem kratzen diese Impulse nur an der Oberfläche.

Doch genau darum geht es ja: einen Denkanstoß geben, um den Status quo zu hinterfragen.

Und ich lade Dich ein, Deine vergangenen, aktuellen und zukünftigen Umgebungen kritisch mit Day-1- und Day-2-Augen zu betrachten.

Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.

Vorheriger Beitrag Nächster Beitrag