Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Bevor wir uns mit dem Thema heute beschäftigen, das Thema ist Team Topologies, aber so aus der Praxis, ein paar Hinweise.
Also der eine Hinweis ist, wir haben diese Woche gleich drei Episoden, nachdem ja irgendwie jetzt ein bisschen, wie soll ich sagen, Ruhe erstmal war.
Und zwar haben wir am Donnerstag um 14 Uhr live von der BATKON eine Episode mit dem Jochen Marder zum Thema Supply Chain Security.
Und am Freitag um 10 Uhr eine Episode auch live von der BATKON mit der Friederike Sternberg zum Thema Sprache schafft Wirklichkeit.
Und heute soll es um das Thema Team Topologies gehen und dazu habe ich mir Kim eingeladen.
Schön, dass du da bist, Kim.
Willst du kurz zwei Worte über dich sagen?
Wenn ich vier darf, ja.
Also mein Name ist Kim Duggen.
Ich bin Organisationsarchitektin bei der Firma Embarc.
Genau, und so ein bisschen halt der Aufhänger, warum wir dachten, dass das vielleicht eine ganz nette Idee wäre, mal gemeinsam darüber eine Episode zu machen.
Wir hatten ja auch, ich hatte ja auch schon eine Episode alleine gemacht.
Wir hatten sogar mehrere dazu.
Auch eine mit der, na ich komme noch drauf.
Und wir machen gemeinsam ein Training bei der Firma SoCreatory zu diesem Thema Team Topologies.
Und zwar ist das so ein Team Topologies Deep Dive und ich packe den Link dazu auch nochmal in den Chat.
Da kann man sich halt irgendwie anmelden und das machen wir zusammen mit dem Michael Plöt und dem Alexander von euch.
Und genau, die Idee ist halt eben tatsächlich so aus der Praxis zu berichten.
Und wir haben da mehrere Termine über mehrere Wochen verteilt, wo wir zu verschiedenen Themen diskutieren.
Genau, und die Episode, die wir vorher gemacht haben, war mit der Anja Kammer.
Da ging es halt auch um Team Topologies.
Das ist auch schon etwas länger her.
Ich weiß gar nicht, willst du noch etwas ergänzen zu dem Training?
Ich glaube, wir haben noch einen Kollegen von mir vergessen.
Der Stephan Todt ist auch noch dabei.
Und ich glaube, das eigentlich Coole ist, genau das, was du gesagt hast, dieser Deep Dive.
Also so theoretisch und zum Einstieg kann man, glaube ich, viel machen zu Team Topologies.
Aber das mit Leuten zu diskutieren und zu erarbeiten, die das alles schon mal in der Praxis angewandt haben und mehrere Fallstricke und Herausforderungen gesehen haben, ist, glaube ich, so das, was das ausmacht.
Genau, und das ist ja eigentlich auch ein bisschen die Idee von heute, dass wir das mal ein bisschen praktischer anwenden und diskutieren.
Genau, und deswegen ist es eine ergänzende Episode.
Und genau, guter Punkt.
Also Stephan ist auch noch dabei und wir haben Termine sind der 7.11., der 8.11., der 11.11. und der 18.11.
Und das ist online, sodass wir jeweils vier Stunden haben.
Müsste man also auch mit der, wie soll ich sagen, mit der richtigen Arbeit gut kombinieren können.
Gut, wir wollen, nachdem die Episode so ein bisschen dazu da sein soll, dass sie alleine stehen kann, wollen wir noch mal kurz darüber diskutieren oder kurz darstellen, was Team Topologies eigentlich ist.
Da gibt es eine Episode, wo ich das irgendwie in der Stunde diskutiere.
Es gibt irgendwie auch ein kurzes Erklärvideo, was da irgendwie verlinkt ist.
Aber wir haben uns halt dazu durchgerungen, das nochmal irgendwie zu erzählen.
Wir machen das anhand der Grafiken, die Lisa für diese Episode gemacht hatte.
Und genau, das Erste, worüber wir sprechen wollen, sind, glaube ich, die Teamtypen.
Und du kannst, glaube ich, den ersten Teamtyp sozusagen schon mal aufmachen und was dazu sagen.
Genau, vielleicht einmal so ganz grundsätzlich.
Es ist ja die Aufteilung von Team Topologies, dass es vier Kernteamarten gibt.
Die Erste wären die Stream Align Teams, das sind auch die Zentralen.
Dann gibt es gleich noch ein paar Zusammenarbeitsmuster, Interaktionsmodi und so eine Grundidee davon, dass man nicht einmal eine Struktur baut und sagt, so sieht jetzt für immer unsere Organisation und Zusammenarbeit aus, sondern dass die sich halt evolutionär weiterentwickelt.
Und was ich schon auch sehr zentral finde bei Team Topologies ist, dass wir eigentlich nicht so viele Begriffe neu lernen müssen, sondern vielleicht so im Kern diese vier Teamarten, und mit denen können wir schon dann viel mit einer gemeinsamen Sprache schaffen.
Und diese zentralste Teamart, die es eigentlich sozusagen geben soll, wenn wir dann die Organisation richtig geschnitten haben, sind mehrere wahrscheinlich dieser Stream Align Teams, die eben wertschöpfende Teams sind, die das ausmachen, was die Organisation eben produziert, für das andere irgendwie intern oder extern Geld bezahlen wollen.
Im besten Fall sind die cross-funktional besetzt, also haben alle Kompetenzen, die sie brauchen, um end-to-end verantwortlich zu sein für ein Produkt, ein Teilprodukt oder ein Service, und genau, sollten so die führende Teamart sein.
Alle anderen sollen denen dabei helfen, dass die hier einen guten Job machen können.
Genau, und vielleicht, ich habe das einmal in einem Training irgendwie vergessen zu erwähnen, welches Problem lösen wir überhaupt?
Das Problem, was wir versuchen zu lösen, ist indirekt eigentlich klar, aber ich sage es nochmal explizit, wir haben irgendwie ein großes Projekt, wir haben da mehrere Teams, Teams sind irgendwie kleiner als zehn Personen, also diese berühmten Scrum- beziehungsweise Zwei-Pizza-Teams, und die Frage ist jetzt, wie sorgen wir dafür, dass wir die Arbeit auf diese Teams aufteilen und wie organisieren wir diese Teams?
Was zum Beispiel impliziert, dass wir über ein Problem reden und über ein Thema reden, was erst ab einer bestimmten Größenordnung überhaupt ein Thema ist, nämlich an der Stelle, wo ich sage, ich habe mehrere Verwicklungsteams, die irgendwie koordiniert werden müssen, ist also nichts für, ich habe ein Scrum-Team, sondern ist eben genau die Ebene darüber.
Genau, und die nächste Teamsorte sind die Enabling-Teams, das sind Teams, die eben, der Name sagt es, Stream-Aligned-Teams dazu verhelfen, irgendwie Hindernisse zu überwinden, also Beispiel ist für mich so etwas wie ein Architektur-Team, das sollte halt durch eine Kompetenz, nämlich Architektur-Kompetenz, dafür sorgen, dass eben ein Stream-Aligned-Team irgendwie dazu in der Lage ist, irgendwie Wert zu generieren und das ist da, glaube ich, so im Wesentlichen die Idee.
Genau, was ich bei den Enabling-Teams auch noch zusätzlich wichtig finde, ist, dass die zum einen genau den sozusagen Spezialfähigkeiten oder Spezialunterstützung anbieten, die den Wert schaffen sollen, aber dass man auch ganz gut so etwas wie zentrale Konzepte da reinlegen kann.
Also wie du gesagt hast, es reicht nicht nur die Hands-on-Architektur-Aktivität, die wir im Enabling-Team dann abrufen können, sondern die können eben auch über mehrere Stream-Aligned-Teams sozusagen nicht Regeln vorgeben, aber Strukturen erarbeiten, Konzepte erarbeiten, die die anderen dann lernen zu nutzen.
Das wird auch nochmal ganz hilfreich.
Sehen wir nachher auch nochmal wieder in unseren Praxisszenarien.
Genau, und weil du es halt gerade sagtest mit Regeln und so, ich glaube, ein wichtiges Thema, deswegen finde ich auch dieses Architektur-Beispiel wichtig, ist eben, dass es unterstützend ist.
Du hattest es gerade eben gesagt bei den Stream-Aligned-Teams, aber ich würde es gerne nochmal unterstreichen.
Die Stream-Aligned-Teams sind die Teams, die tatsächlich Probleme lösen.
Die anderen Teams sollen denen halt helfen.
Und das ist gerade eine Abkehr von diesen ihr blöden Teams, die da draußen die richtige Arbeit machen.
Ihr habt ja keine Ahnung, wir müssen euch irgendwie kontrollieren.
Das ist halt eine unterstützende Meinung, ein unterstützender Ansatz an der Stelle.
Genau.
Absolut.
Dafür sind diese Teamarten, die Plattform-Teams, eben auch extrem hilfreich.
Da ist die Idee, dass alles, was es an Services geben könnte, im besten Fall sogar Self-Services geben könnte, die allen anderen Teams, allen Stream-Aligned-Teams, manchmal sogar auch an App-Link-Teams, zur Verfügung gestellt werden können, man in so eine Plattform und in ein Plattform-Team oder mehrere Plattform-Teams auslagert.
Das heißt, da kann ich sehr gut sozusagen alles, was wir vervielfältigt, was keinen Sinn machen würde, wenn jedes Stream-Aligned-Team sich selber darum kümmert, wäre das vielleicht ineffizient, sowas kann ich gut ins Plattform-Team legen.
Die dürfen auch so Sachen haben wie Blueprints, wie Text-Stacks, wie einfach Ideen sozusagen, die sich bewährt haben, die sie allen zur Verfügung stellen wollen, als Konzept und Vorschlag und Idee, aber es sind eben Vorschläge.
Und die Stream-Aligned-Teams könnten auch entscheiden, dass sie das nicht nutzen, was die Plattform im Angebot hat, sich selber behelfen.
Da ist so ein bisschen auch der Austausch, gar nicht ein bisschen, sondern extrem wichtig, zwischen die Stream-Aligned-Teams gegen den Plattform-Teams eben auch regelmäßig Feedback.
Ist das, was ihr uns da anbietet, eigentlich sinnvoll?
Ist auch ein indirektes Feedback, wenn keiner nutzt, was die Plattform anbietet.
Also der Austausch ist wichtig.
Und da ist auch, zumindest zu den Organisationen, die ich sozusagen in den, also bevor ich Team2Politiks Kante gesehen habe, ist auch die Richtung eigentlich ein bisschen umgedreht.
Die Stream-Aligned-Teams entscheiden, ob sie es nutzen wollen und geben sozusagen den Qualitätsanspruch vor.
Und es ist nicht, hier bitte 17 Formulare ausfüllen und froh sein, wenn du was deployen darfst, von der Richtung sozusagen.
Genau, also und die Metapher sind halt die Produkte, so wie es da irgendwie steht.
Und Produkte kann man eben auch nicht nutzen, so wie du es richtig gesagt hast.
Ich glaube, da ist noch ein, also da sollte man vielleicht auch noch mal kurz sagen.
Ich habe letzte Woche in dem Training, war das so eine Diskussion, die da irgendwie aufgekommen ist.
Wir fokussieren da drauf, dass wir halt Teams haben wollen, die Wert generieren.
Das ist das Ziel.
Das bedeutet eine Vereinheitlichung und eine Kostenoptimierung durch eine Vereinheitlichung ist eine sekundäre Priorität.
Und daraus ergibt sich das, was du gerade sagtest, dass wir eben nicht sagen, die Plattform muss aber genutzt werden, weil dann würden wir das Ziel Kostenoptimierung priorisieren über eben Flexibilität und Wert generieren.
Und das ist eben nicht die Idee.
Gut.
Komplikierte Subsystem-Teams, genau.
Das sind Leute, die halt verantwortlich sind für einen Teil des Systems, das halt irgendwie kompliziert ist und Fachwissen erfordert, zum Beispiel auf algorithmischer Ebene.
Das Beispiel ist Versicherungsmathematik.
Und bei Versicherungsmathematik muss man halt verstehen, wie man ausrechnet, ob eine Lebensversicherung ein guter oder ein schlechter Deal ist.
Und das ist irgendwie nicht trivial.
Es geht nicht so sehr um, sprich, das ist so algorithmisches, fachliches Wissen.
Es geht nicht so sehr um Legacy-Systeme, die halt irgendwie aus dem Grund, weil sie halt schwer wartbar sind, kompliziert sind, sondern es geht eben um Dinge, die halt sozusagen intellektuell irgendwie eine hohe Anforderung haben.
Und zwei allgemeine Hinweise würde ich noch kurz gerne loswerden.
Das eine ist halt, man sieht hier diesen Magneten.
Den haben wir bei den anderen Teams auch gesehen.
Das heißt, was Team Topologies eben sagte, ist, das sind Magneten, wo wir uns hin entwickeln wollen, was ja umgekehrt bedeutet, dass man jetzt nicht irgendwie sich hinstellt und sagt, wir machen das jetzt mal kurz und dann ist irgendwie alles klar und alle Teams sind halt genauso, wie es hier steht, sondern das ist irgendwie ein Ziel.
Und es gibt so eine standardisierte grafische Notation.
Also hier ist es halt dieses orange Sechseck.
Und das ist eben tatsächlich standardisiert grafisch.
Das heißt also, komplizierte Subsystem-Teams sind sechseckig-orange aufzumalen.
Genau.
Für nur eine Ergänzung, warum ich die komplizierte Subsystem-Teams eigentlich ganz cool finde, ist, die dürfen auch und sind häufig temporär.
Das heißt, ich finde, die haben eine große Kraft in Organisation, wenn man nämlich mal aufzeigt, dass Menschen nicht den ganzen Tag 100 Prozent ihrer Zeit zum Beispiel in einem Streamline-Team arbeiten und da Wert schaffen, sondern eigentlich auch noch aus dem vorherigen Projekt.
Der eine Typ sind, der immer Ahnung hat von dem und den musst du dann immer fragen und die noch in drei anderen Projekten aushelfen, weil die nämlich dieses spezielle Wissen haben oder weil es eben neben dem, dass wir eigentlich an unseren Wertströmen arbeiten sollten, immer noch diese Zusatzprojekte gibt, die irgendwie mit unserer Organisationsstruktur nicht abbildbar sind.
Und deswegen finde ich diese komplizierte Subsystem-Teams und erst mal ist es nur ein oranges Sechseck.
Aber wenn ich stark unterscheide, was sind eigentlich die Wertströme, die wir konstant haben und was sind die vielleicht auch zum Teil temporären CSTs, in denen Leute auch tätig sind und ganz offen mit dieser Teilung von eigentlich Zeit und Ressource und Denkfähigkeit umgehe, vielleicht mir auch überlege, welches dieser speziellen Fähigkeiten müsste eigentlich in ein Enabling-Team, damit die Organisation auf Dauer einfach schlauer wird.
Und dann in so ein Lila-Team hat das einfach eine große Kraft in diesen vier eigentlich am Ende doch sehr simplen Strukturen bei, im Zielbild zu denken.
Genau, und mir fällt gerade ein, wir haben jetzt nicht diskutiert, dieses Konzept von Cognitive Load, was glaube ich irgendwie auch noch irgendwie so zentral ist.
Also sprich, das Ding ist halt, wenn ich mich hinstelle und sage, du bist Streamline-Team, macht halt einfach, dann kriegen die halt ganz viele Aufgaben.
Also sie müssen eine Infrastruktur betreiben, sie müssen komplizierte Subsystems umschlagen und so weiter und so weiter.
Und das ist eben genau die Idee, weswegen ich eben diese anderen Teams einführe, damit ich das halt ein bisschen aufteilen kann.
Und das ist so der Grund, warum die anderen halt irgendwie existieren.
Und dieses Konzept, glaube ich, von Cognitive Load ist irgendwie auch so zentral, dass man es, glaube ich, bei einer Einführung von Team Technology zumindest mal erwähnen sollte.
So, dann haben wir die Team-Interaktion.
Das sind drei.
Da gibt es halt erst mal Access to Service.
Das heißt, ich biete halt ein Service an im Sinne von über eine Web-Oberfläche oder halt als Schnittstelle eben von einem Modul biete ich halt irgendwas an.
Also prototypisches Beispiel wäre halt ein Plattform-Team.
Plattform-Team bietet eben entweder eine API an, mit der ich einen neuen Kubernetes-Cluster bauen kann oder halt eine Web-Schnittstelle, mit der ich das irgendwie tun kann.
Und der Vorteil davon ist, dass ich wenig menschliche Interaktion benötige.
Das heißt, ich reduziere halt irgendwie den Kommunikationsaufwand auf menschlicher Ebene.
Und das ist, glaube ich, da so ein bisschen die Idee.
Collaboration willst du sagen, nehme ich an?
Richtig, total gerne.
Genau, da ist die Idee, dass es eine wesentlich engere Zusammenarbeit gibt.
Nicht nur du kannst das von mir sozusagen haben oder du kannst es lassen, sondern ich würde tatsächlich mehr miteinander interagieren, wahrscheinlich auch häufiger.
Also man würde allein an der Menge von Meetings oder Abstimmungsrunden sehen, dass da eher eine Kollaboration als ein Service, sozusagen als Zusammenarbeitsform gewählt wurde.
Grundsätzlich vielleicht auch nochmal eine Randnotiz ist die Idee, gerade wegen der Reduktion dieser kognitiven Belastung von Teams, dass wir es im besten Fall hinkriegen, dass die relativ autonom sind.
Also da soll nicht jeder komplett alleine für sich irgendwas tun, aber es soll auf jeden Fall möglichst wenig Abhängigkeiten, möglichst wenig Warten oder unsicher sein, wer jetzt verantwortlich ist in der Organisation geben.
Und deswegen wäre die Idee schon, dass wir möglichst wenig enge, viel Abstimmung zwischen Teams haben, möglichst wenig Kollaborationen, die irgendwie unklar definiert sind und hingehen mehr zu, wir haben klare Verantwortlichkeiten pro Team und im besten Fall würden jetzt die Streamline Teams mit Plattform-Teams eher über Access-as-a-Service arbeiten als über Kollaboration.
Da eignen sich bestimmte Teamarten und Interaktionen irgendwie ganz gut.
Genau, wobei, ich muss gestehen, ich habe da ein bisschen vielleicht eine andere Wahrnehmung.
Ich habe irgendwie das Gefühl, dass da draußen die meisten Leute irgendwie sagen, wir wollen halt irgendwie autonome Teams haben, die möglichst wenig miteinander interagieren.
Was ich bei Team Topologies gut finde, ist, dass sie halt sagen, naja, manchmal geht es halt nicht.
Und dass sie halt irgendwie nicht sagen, nee, wir wollen halt immer autonome Teams und deswegen interagieren Menschen nicht, sondern hier bei Collaboration sagen sie sogar, das ist halt eine enge Kollaboration.
Also es wäre denkbar, dass jemand aus dem Architektur-Team sich in ein Streamline-Team setzt und halt mit denen zusammen irgendwas prototypisch implementiert oder halt irgendwie durchführt oder macht vorübergehend und dann irgendwie wieder rausgeht, weil es soll ja nicht dauerhaft sein.
Und das ist so ein bisschen die Idee.
Es wird dadurch irgendwie nicht gesagt, wir müssen aber, weiß ich nicht, wenig miteinander interagieren, sondern es wird irgendwie gesagt, manchmal kommen wir halt nicht drum herum.
So würde ich das interpretieren.
Ich weiß nicht, ob das…
Ich glaube, es geht eben insgesamt darum, dass Dinge explizit gemacht werden.
Also dass wir zum Beispiel uns genau überlegen, warum ist da jetzt gerade sinnvoll, dass der Architekt ins Team geht und mit dem Team da was ausarbeitet und dass das nicht der Default ist, weil wir nur einen Architekten haben, der voll viel Ahnung hat, ist da dann allen anderen steht er gerade nicht zur Verfügung.
Dann wäre eher die Frage, wie kriegen wir es hin, dass das jetzt nicht auf Dauer ein Flaschenheiz ist und in welchen Situationen macht es Sinn, dass sie eher kollaborieren oder eher facilitierend unterwegs sind, also Leute schlauer macht und sich dann aber auch wieder rauszieht.
Genau, es ist einfach dieses explizite Entscheiden und Tun und nicht, das ist halt so, hat sich so entwickelt.
Damit hast du halt Facilitation eigentlich auch schon erklärt.
Das wäre irgendwie so, dass jetzt jemand sich halt hinstellt und sagt, okay, es wäre vielleicht mal gut, wenn ihr zu einem Team Topologies Training geht oder zu einem DDD Training oder nicht.
Ich zeige euch das mal oder wie auch immer.
Also eben dort unterstützt, auch feststellt, was halt Herausforderungen sind und dann irgendwie auch dafür sorgt, dass die halt beseitigt werden.
Gut, ich glaube, dann haben wir es soweit, nicht?
Ach so, genau, die Fracture Planes.
Genau, vielleicht kannst du die ja mal erklären und dann kann ich die gleich überleiten auf unser erstes Praxiszimmer.
Ja, sehr schön.
Also Fracture Planes sind halt eine Möglichkeit oder sind Möglichkeiten, mit denen Stream Aligned Teams finden, wofür sie halt zuständig sind.
Und der wesentliche Punkt dabei ist, dass in der naiven Wahrnehmung halt gesagt, eigentlich immer gesagt wird, na ja, nicht ein Team, was halt irgendwie Stream Aligned ist, was implementiert und wertgeneriert ist, ein Team, das verantwortlich ist für eine bestimmte Fachlichkeit.
Im Worst-Come-When-Manöver sagt das halt zum Beispiel.
Und das ist auch tatsächlich eine von den Fracture Planes.
Also die erste Fracture Plane, die da steht, ist DDD, Baun und Kontext.
Also ich gebe Baun und Kontext an ein Team.
So, und das Spannende, finde ich, ist eben, dass jetzt aber umgekehrt gesagt wird, na ja, manchmal ist das irgendwie nicht die Fracture Plane, mit der wir halt arbeiten wollen.
Und da gibt es dann solche Sachen wie Regulatorien.
Also zum Beispiel PCI-Geschichten, wo ich halt aufgrund von Kreditkartensachen irgendwas implementieren muss, ein Vier-Augen-Konzept haben muss.
Irgendwelche solche Geschichten, Dinge, die sich halt gemeinsam ändern. Änderungsfrequenz könnte halt ein Thema sein.
Standort.
Ich habe ein Team in Kaiserslautern.
Ich habe ein Team irgendwo anders, in Indien oder so.
Und dann sage ich halt, okay, ich trenne es halt irgendwie durch den Standort.
Sachen, die halt eine vernehmliche Performance haben sollen oder auch sowas wie Personas, wo ich also sage, für Neukunden habe ich halt irgendwie Leute, die dafür arbeiten.
Und dann habe ich halt irgendwie Leute, die eher arbeiten für die Bestandskunden.
Und das, finde ich wiederum, ist halt eine interessante sozusagen Erweiterung, weil es eben nicht nur sagt, na ja, nicht, also du willst denen halt eine Fachlichkeit zuweisen, also ein Bauen im Kontext, sondern da ist dann wie die Diskussion größer aufgemacht.
Und das, finde ich, ist eigentlich auch wieder ein ganz gutes Beispiel für dieses Explizitmachen.
Wenn man auf die meisten ein bisschen klassischeren oder sogar auch agileren Organisationen guckt und fragt oder hinterfragt, warum seid ihr eigentlich so aufgeteilt und verantwortlich, dann ist häufig die Antwort, dass es mal irgendwann einen Fracture Plane gab wahrscheinlich oder ich nenne die Schnittkriterium, also vielleicht wirklich eine Fachlichkeit oder funktionale Rolle.
Und dann hat man irgendwann gemerkt, das reicht nicht mehr und dann hat man so Matrizen gebaut und die sind halt irgendwie, fühlen sich immer nicht so cool an und sind ein bisschen mühsam.
Und was ich jetzt im spannenden ersten Schritt finde, eigentlich, wenn man Team Topologies als Topologie benutzt, um sich ein Zielbild zu organisieren, wie wollen wir eigentlich in Zukunft an diesem Stück Software, Hardware, was auch immer arbeiten, ich finde, das eignet sich auch für Nicht-Entwicklungsorganisationen übrigens, dann finde ich genau diese Frage, wonach wollen wir jetzt die Teams schneiden, die zentralste.
Und im besten Fall finden wir genau ein Kriterium.
Und häufig ist es, wie du zum Beispiel vorhin gesagt hast, ausgerichtet an zum Beispiel sowas wie Kundennutzen.
Dafür müsste ich irgendwie verstehen, warum das für uns sinnvoll ist.
Und ich müsste irgendwie verstehen, was für Probleme wir eigentlich mit der neuen Struktur lösen wollen, aber genau das ist ein zentraler Punkt.
Und vielleicht mal ein Szenario aus der Praxis, wo ich glaube, dass es in der ersten Iteration gut funktioniert hat und in der zweiten dann geht so.
Die haben schon ein paar Jahre mit Team Topologies gearbeitet, aber die Idee war initial, dass wir nur einen Teil der Organisation umbauen durften und haben uns da dann eben nur den Teil der Webshop-Entwicklung angeguckt und die App-Entwicklung war erstmal wie so eine Art CST aufgebaut.
Man hatte die Organisation, der Stream-Align-Teams war geschnitten nach taglichem Bounded-Kontext aus dem Webshop und App war woanders.
Und dann haben sie irgendwann festgestellt, das ist ein bisschen doof, weil die sich jetzt sozusagen von den Featuren und von der Kundenorientierung immer weiter auseinander entwickeln.
Jetzt müssen wir die irgendwie wieder zusammenbringen und dann, finde ich, zeigt sich eine Stärke von Team Topologies, dass man jetzt eben die Organisation nimmt, wie sie ist, und einfach Varianten bauen kann.
Und wir haben dann eben eine Variante gebaut, wie wäre es denn, wenn die Stream-Align-Teams, die es heute schon gibt, die auf dem Webshop gucken, einfach quasi die App-Entwicklung mit dazu kriegen.
Dann würden die ja automatisch alles, was mit Warenkorb zu tun hat, immer in Webshop und App denken.
Das wäre eine Variante.
Eine andere wäre, ich habe ein paar Stream-Align-Teams, die Webshop bauen und ein paar, die App bauen und irgendwie müssen wir jetzt überlegen, wie die miteinander reden.
Das könnte man machen.
Und natürlich wird das nicht geheilt und gut dadurch, dass wir es einfach hinmalen und sagen, es könnte so und so aussehen.
Aber dieses explizite Überlegen, was sind jetzt die Trade-offs, wenn wir es so machen, was sind auch die Veränderungskonsequenzen, wenn wir es so machen, und was ist, wenn wir es anders machen, das finde ich eine Kraft.
Was bei denen jetzt dazu gekommen ist, ist, dass sie nicht rein nach diesen Kriterien entscheiden können, sondern einfach jetzt noch Stellen gibt und Abteilungsseite gibt, die irgendwie verteilt werden müssen.
Und dann muss man sich plötzlich an was anderem orientieren als der Kundenorientierung.
Aber dieses explizit Machen, finde ich, ist auf jeden Fall eine Kraft davon.
Wie ist denn da dein Erlebnis?
In gewisser Weise ist das ein Klassiker.
Ich bin mir nicht sicher, aber ich kann mir vorstellen, dass das sogar schon in meinem Microservices Buch, was für Mitarbeiter auch schon ewig alt ist, ein Thema war, dass man gesagt hat, ich habe Funktionalitäten, ich habe ein Team, das für eine Funktionalität zuständig ist, und dann habe ich, wie du sagst, eine App.
Und jetzt ist genau die Frage, sollen die Teams die App mitentwickeln oder eben auch nicht?
Und was ich gut finde an dem Team-Topologies-Modell ist, dass jetzt klar gesagt wird, du hast beide Möglichkeiten.
Das eine, würde ich behaupten, ist die Fracture-Plane-Technology, dass ich sage, die iOS-Anwendung und die Android-Anwendung, das machen wir in dem einen Team.
Da haben wir Leute, die sich damit auskennen.
Die andere Fracture-Plane wäre im gewonnenen Kontext.
Ich sage, so etwas wie ein Bahngorb ist in einem Team drin, und ich muss überlegen, was ich mache.
Das ist jetzt nicht mehr so ein Unfall, sondern ich kann mir das ernsthaft überlegen.
Es ist nicht mehr so ein Störfaktor.
Das Problem, das ich auch mit diesem Inverse-Combi-Manöver habe und mit dem, was da rumläuft, ist, es ist simplifizierend.
Wenn man das zu stark nur auf die Fachlichkeit bezieht, dann hat man eben genau das Problem, dass man in der Realität möglicherweise Schiffbruch erleidet, weil ich in der Realität bedarflicherweise auch Technologie habe und ich muss mich damit rumschlagen.
Es ist nicht erkennbar, dass ich die Fachlichkeit dominieren lassen sollte.
Das andere, was ich spannend fand bei diesem Praxisbeispiel, ist, dass die Macht des faktisch-politischen dann doch dazu führt, dass etwas entschieden wird.
Das ist ja gesagt, da gibt es Abteilungsleiter und welche Rollen, die geführt werden sollen.
Das beeinflusst die Entscheidung und das, wo es hingeht.
Das ist auch wieder etwas, was aus der Praxis herauskommt.
Was vielleicht auch mein Problem ist mit dem Team Tomologies-Buch, wo ich darüber nachdenke.
Sagt Team Tomologies etwas darüber?
In gewisser Weise schon, aber es steht gleich am Anfang in einem der ersten Kapitel, dass so etwas wie ein Organigramm nur die Hälfte der Wahrheit ist.
Aber ich bin mir nicht sicher, ob das so richtig durchdekliniert wird.
Hier in dem Beispiel ist es ja offensichtlich ein ganz wichtiger Einflussfaktor.
Ich glaube nicht, dass im Team Tomologies-Buch drinsteht, wenn du deine Teams aufteilst, guck nochmal nach, ob du die einzelnen Manager zufriedenstellst mit ihren Karriereplänen.
Aber de facto ist das ein Einflussfaktor.
Absolut.
Was ich aber auch trotzdem hilfreich finde, ist, dass wir zumindest den Teil auch wieder sehr transparent machen können.
In der ersten Iteration ist wirklich die Frage, wollen wir es kombiniert denken, weil es dann für die Kundin in dem Fall auch wirklich wichtig ist, dass, wenn sie in den Webshop oder in die App guckt, das Gleiche passiert, dass die gleichen Kampagnen ausgespielt werden und das gleiche Verhalten der Systeme irgendwie erkennbar ist.
Und dann haben die sofort gesagt, nö, das sind nämlich völlig unterschiedliche Kundengruppen, das ist für uns überhaupt nicht relevant.
Dann konnten wir eher gucken auf, ist es denn kompetenzmäßig sozusagen möglich, gemeinsame Teams zu bilden, wo wir wirklich ausreichend App-Entwickler, Webshop-Entwickler haben, die irgendwie zumindest teilweise zusammen denken können.
Nee, auch nicht.
Die hatten viel weniger App-Entwickler, als die Webshop-Entwickler haben.
Und das sind dann erstmal ja sozusagen die Kundenorientierung, die Kompetenzorientierung nach innen, die ich hilfreich finde, um zu sagen, wie müsste denn optimalerweise die Organisation geschnitten sein.
Und wenn dann jemand sozusagen aus Management-Kreisen was anderes entscheiden will, können wir zumindest sagen, das können wir so machen, aber es hat folgende Konsequenzen.
Dann ist es eben auch was Explizites.
Und dann wäre zum Beispiel sowas abzuleiten, wie es wäre wahrscheinlich smart, auf Dauer Leute im Enabling-Bereich zu haben, die die App-Kompetenzen stärken, da irgendwie ein bisschen fachorientierter und kundenorientierter werden können.
Oder nee, wir glauben, das Kundenbedürfnis ändert sich überhaupt nicht.
Also diese strategischen personellen Fragestellungen einfach bewusst zu modellieren und immer zu gucken, was ist besser.
Macht es das schlimmer oder besser als vorher?
Sind die Trade-offs aushaltbar?
Das, glaube ich, ist schon eine Stärke.
Und den Rest müssen wir dann nehmen, wie wir ihn erleben, sozusagen.
Und vielleicht noch eine Sache, die mir jetzt bei der Diskussion auch nochmal aufgefallen ist.
Aus irgendwelchen Gründen ist dieses Beispiel so ein Beispiel, was mir zumindest öfter mal begegnet ist und dir dann ja offensichtlich auch.
Und eigentlich ist das nicht erklärlich, dass das nur ein ausgerechnetes Beispiel ist, weil diese cross-funktionalen Teams an ganz vielen Stellen Schwierigkeiten haben.
Ich habe sehr klar, wenn ich in der heutigen Technologiewelt und mit den heutigen Themen, ich sage, dieses Team soll von der Analyse bis zur Implementierung alles machen.
Das führt immer zu einem Problem, weil das einfach wahnsinnig viel ist.
Und wir haben hier jetzt ein Set von Konzepten, um das auch allgemein zu lösen.
Also um nicht zu sagen, du solltest eigentlich fachliche Teams haben, aber es gibt diese Ausnahme mit den mobilen Apps.
Sondern man kann jetzt sagen, es gibt Enabling Teams, es gibt Cognitive Load als grundlegende Ansätze.
Und damit können wir jetzt allgemein auf Probleme, die existieren, draufhauen und kriegen dann eben dort hoffentlich Lösungen raus.
Dann haben wir das Beispiel sozusagen durchdiskutiert.
Das nächste Beispiel, glaube ich jedenfalls nicht.
Oder hattest du noch was zu ergänzen?
Das nächste Beispiel ist halt etwas, wo eigentlich es eine Architekturfrage gab.
Und zwar war eigentlich die Architekturfrage, können wir in diesem spezifischen Kontext wiederverwendbare Komponenten bauen?
Und das ist so eins von den Themen, wir haben tatsächlich mal, also ich habe mal eine Episode dazu gemacht, bei Software Tech, genau hier im Stream, zu dieser Frage mit der Wiederverwendung.
Und wir hatten auch diese Episode zu Product Line Engineering, wo es halt irgendwie darum geht, dass ich mehrere Produkte, Gemeinsamkeiten rausfinde.
Und das ist tatsächlich eine total spannende Architekturfrage.
Die kurze Zusammenfassung ist, also nein, man will eher nicht wiederverwendbare Komponenten bauen.
Technisch, gerade bei technischen Komponenten, ist sowas denkbar.
Also Frameworks, die wir nutzen, Spring Boot oder so, sind halt massiv wiederverwendbar.
Wenn ich sowas selber baue, PDF-Generator oder so, macht das halt auch sehr viel Sinn.
Und es ergab sich dann halt, dass die architekturelle Frage eigentlich relativ klar beantwortbar ist, mit einem Ja.
Die Ebene von Dingen, die ihr da irgendwie bauen wollt, die kann man, glaube ich, die kann man halt wiederverwendbar bauen, weil die halt irgendwie eher technisch sind.
Und das war eine relativ eindeutige Sache.
So, und das führt jetzt aber zu der Frage, ja, wie mache ich das denn jetzt eigentlich?
Und das würde halt implizieren, dass ich halt irgendwie ein Plattform-Team habe.
Das spielt jetzt Team Topology eine Rolle.
Und die bauen halt diese Plattform.
Das heißt, die bauen halt irgendwie etwas, was ich halt wiederverwenden kann.
Also tatsächlich eine Software-Komponente.
Das ist auch eine Plattform, also es ist nicht nur Kubernetes.
Und das führt jetzt aber dazu, dass ich halt eine Abhängigkeit habe, wenn ich ein Streamline-Team bin und halt auf die Zulieferung von denen halt irgendwie angewiesen bin.
Und das ist halt inhärent.
Und normalerweise sollte das halt irgendwie auch kein Problem sein.
Aber in diesem spezifischen Fall war es halt so, dass in dem Projekt halt Schwierigkeiten auf Ebene von Fehlerkultur sind, sodass es eben sehr wahrscheinlich so sein würde, dass irgendwie das Plattform-Team nicht sagt, hey, wir haben da übrigens ein Problem.
Und das dauert halt irgendwie, bis wir irgendwas implementiert haben und bis wir dieses Feature hinbekommen haben.
Sondern es wird wahrscheinlich eher so, es wäre eher zu erwarten, dass irgendwie das Plattform-Team mit den Problemen hinter dem Berg hält.
Und zwar eben, weil es halt sonst bestraft wird dafür, dass sie halt sozusagen nicht performt haben.
Und das führt jetzt zu dem anderen Problem.
Das führt nämlich zu dem Problem, dass ich als, also nicht, wenn ich verantwortlich bin für ein Streamline-Team, ich bin ja nicht dumm, ich weiß, dass das halt so ist.
Und ich habe halt gleichzeitig das Problem, dass ich selber in einer ähnlichen Situation bin.
Das heißt also, wenn das Problem tatsächlich von dem Plattform-Team halt kommt, dann habe ich eben das Problem, dass ich bestraft werde, weil ich mein Ziel nicht erreiche mit meinem Team und verantwortlich ist dafür halt irgendwie ein ganz anderes Team, nämlich das Plattform-Team.
Aber das kann ich halt nicht lösen, weil so ist eben dort die Fehlerkultur.
Das führt dazu, dass, also wenn ich halt in dem Kontext selber aktiv gewesen wäre, hätte ich mich halt irgendwie hingestellt und hätte gesagt, alles klar, ich baue das jetzt selber.
Und unabhängig von der Frage, ob das halt irgendwie sozusagen technisch machbar ist, und zwar einfach aus einer Kontrollfrage heraus, also weil, wenn ich die Leute halt bei mir selber im Team habe, dann habe ich halt die hoffentlich berechtigte Hoffnung, dass die halt irgendwie, dass ich halt mit denen über die Probleme reden kann, halt irgendwie herausfinden, was damit das Problem ist und ich habe halt eine stärkere Kontrolle, während ich halt bei dem Plattform-Team das halt irgendwie nicht glaube.
So, jetzt ist halt so ein bisschen die Frage, was hat das eigentlich mit Team Topologies zu tun?
Ich glaube, die eine Sache ist eben, dass man durch Team Topologies dazu kommt, dass man nicht nur die Architekturfrage fragen muss, sondern irgendwie auch die soziale Frage fragen muss.
Also wenn ich halt, also die Architekturfrage war relativ klar entscheidbar.
Ja, das kann man halt bauen.
Die soziale Frage ist das wirkliche Problem.
So, und das ist, glaube ich, der eine Vorteil, dass ich also plötzlich halt auf dieser Ebene halt auch was diskutieren kann.
Der nächste Schritt wäre jetzt die Frage, wie kann ich halt irgendwie dieses Problem lösen?
Und das ist auch einer von, also deswegen finde ich das halt gut, dass wir das nochmal diskutieren, weil ich da tatsächlich interessiert daran bin oder es total spannend finde, was du da halt siehst.
Ich glaube halt, dass am Ende das Problem ist, dass man halt die Fehlerkultur ändern muss.
Und das kann Top-Level-Management tatsächlich lösen, weil ich halt dort, wenn ich ganz oben bin, mich hinstellen kann und sagen kann, okay, ihr habt halt ein Problem, schön, dass ihr es halt genannt habt, lasst es uns gemeinsam lösen.
Also tatsächlich hatte ich letzte Woche genauso eine Diskussion und da hat halt die Person, mit der ich geredet habe, hat irgendwie gesagt, okay, cool, du hast halt ein Problem, wie kann ich halt irgendwie helfen?
Und das ist eine andere Art von Fehlerkultur, zu sagen, okay, du hast halt ein Problem, das ist doof, löst das bitte.
Genau, das ist also etwas, was man machen kann.
Und ich muss halt gestehen, eine Option, die sich in meinem Kopf vielleicht erschreckenderweise herausgebildet hat, ist, ich würde, glaube ich, einige Leute aus dem Team einfach entfernen, also aus dem Projekt-Setup, weil ich mir nicht sicher bin, ob man die sozusagen dazu bekommen kann, eine andere Fehlerkultur zu leben.
Und insgesamt ist, glaube ich, hier der wesentliche Punkt, und deswegen hatten wir ja auch irgendwie gesagt, okay, wir müssen halt irgendwie nochmal so ein Training und halt auch einen Stream machen, der das irgendwie nochmal anders darstellt.
Also sich irgendwie hinzustellen und zu sagen, da gibt es halt ein Plattform-Team, es gibt eine Plattform, das sind wiederverwendbare Komponente, das ist in diesem Fall tatsächlich einfach, dafür zu sorgen, dass es wirklich funktioniert, ist eine andere Frage.
Und das ist hier so ein bisschen halt die Nachricht, also dieses Vertrauen schaffen, diese Weichenfaktoren, die sind da halt irgendwie zentral.
Genau, Kim, du hast da bestimmt jetzt Anmerkungen und Dinge dazu zu sagen.
Ja, also was ich erstmal spannend finde an dem Beispiel, und das hast du ja auch gerade schon gesagt, ist, dass es nicht alles lösbar ist sozusagen, indem wir etwas umbauen, sondern es braucht auch ein anderes Befähigen der Menschen und Strukturen in diesem neuen Setup dann zu arbeiten.
Und ich glaube, was aber etwas ist, was durch Team to Projects vielleicht auch nochmal zentraler ist, ist genau diese Umkehr.
Also ich hatte ja eigentlich das Ziel, ich habe Stream-Aligned Teams, die das total hilfreich finden, dass es ein Plattform-Team gibt, das mir coole Sachen anbietet, damit ich mir das Leben leichter machen kann.
Und da müssen wir ja aber erstmal alle hinkommen.
Also das Plattform-Team und die Menschen, die da drin arbeiten, müssen darin befähigt sein, so eine Art Service-Discovery machen zu können, zu verstehen, was brauchen eigentlich die Stream-Aligned Teams von mir.
Und dann brauchen sie die Fähigkeiten und Ressourcen, diese Services zur Verfügung zu stellen.
Und darüber müssten dann irgendwann mal die Stream-Aligned Teams lernen, dass es so ein bisschen wie diesem Part of least resistance, dass es total sinnvoll ist, das zu nutzen, was das Plattform-Team hat, weil die eben voll smart sind und mir das Leben leichter machen.
Und ich nicht mehr darauf angewiesen bin, das immer alle selber zu bauen.
Jetzt könnte ich quasi versuchen, so Strukturen zu malen und die Teams darin enablen, das irgendwann zu machen.
Was viele Organisationen machen, ist aber, dass sie stattdessen einfach verordnen, dass die Plattform gezwungenermaßen benutzt werden muss, weil dann ist ja die Wiederverwendung irgendwie klar.
Und dann haben wir das geschafft.
Ich glaube, das ist der ungünstigste Schritt, weil das Verordnen von ihr vertraut jetzt darauf, dass das irgendwie verwendbar ist, was die Plattform da herstellt.
Das kann ich ja nicht verordnen.
Die Nutzung kann ich verordnen, aber die ist vielleicht sehr, sehr unzufriedenstellend.
Und dann hätte ich noch eher wahrscheinlich eine Situation geschaffen, wie du gerade beschrieben hast, wo die Plattform sich schön zurückhält, zu sagen, wir haben eigentlich Probleme, weil niemand darf das merken.
Und die Streamline-Teams müssen das jetzt irgendwie verwenden und sind dann unzufrieden und fangen an, Schatten-IT zu bauen.
Also, was das nochmal zeigt, ist, dass es, glaube ich, gerade auf diesem mittleren oder auf der Ebene drüber im Management eben auch noch ein Support-System braucht, nämlich, dass sie zum Beispiel schon mal gar keine gegenläufigen Ziele haben oder nichts widersprüchliches, sondern sie haben eine Produktvision, auf die sie zum Beispiel einzahlen.
Das Plattform-Team genauso wie die Streamline-Teams, weil es wäre ja absurd, wenn sie für unterschiedliche Dinge belohnt werden oder anstreben müssen, dann sind die ja schon so eingestellt.
Und ich glaube, dass es eben auch nicht zu unterschätzen ist, was die Rolle, also ein Streamline-Team-Mitglied hat schon andere Fähigkeiten und auch Soft-Skills, als jemand, der im Enabling agiert oder im Plattformen agiert.
Und diese Transformation wird häufig einfach unterschätzt oder nicht gemacht.
Also man nennt das Team anders und es kriegt vielleicht ein paar andere Verantwortlichkeiten und es kriegt eine Schnittstelle zu anderen Teams.
Aber ich glaube, da sind auf anderen Ebenen eben noch mal sowas wie eine Kundenorientierung, wenn ich im Plattform-Team bin, wäre schon hilfreich.
Oder der Wunsch, jemandem was beizubringen und es nicht selber zu lösen als Enabler, wäre auch hilfreich.
Und das muss ich schon auch mit entwickeln, sozusagen, auf dem Weg in so einer Organisation.
Also ein Gedanke, der mir gerade gekommen ist, also wie soll ich sagen, Agilität hat irgendwie dieses Feature, dass ich halt sage, ich mache eine Iteration, stelle ich halt fest, die Leute benutzen es halt nicht oder ich habe halt irgendwie andere Arten von Schwierigkeiten.
Und dann ist halt die Frage, wie geht die Organisation damit um?
Und das ist meiner Ansicht nach auch eines der Probleme, was halt Agilität hat.
Wenn die Organisation damit nicht vernünftig umgeht, dann habe ich halt ein Problem.
Was manchmal dazu führt, dass man Agilität nicht umsetzen kann, weil man halt irgendwie diese Probleme halt nicht sehen möchte.
Und das ist hier vielleicht etwas Ähnliches.
Also ich kann das Plattform-Team sozusagen aufsetzen, dann stelle ich halt fest, niemand benutzt die Plattform.
Und dann müsste ich halt jetzt irgendwie anfangen und das Problem halt irgendwie lösen, was halt dazu führt, dass sich halt niemand das benutzt.
Was halt positiv bedeutet, ich habe ein objektives Kriterium, nachdem ich entscheiden kann, ob ich erfolgreich bin oder nicht, also ob ich ein Problem habe oder nicht.
Was aber eben auf der anderen Seite bedeutet, ich muss diese Probleme lösen.
Darf ich dennoch eine direkte Frage stellen?
Also würdest du in so einer Situation überlegen, wenn du Verantwortung tragen würdest, einfach einige Leute, wie soll ich sagen, aus dem Projekt zu entfernen?
Glaubst du, dass das hilfreich ist?
Ich finde das schwer auf der grundsätzlichen Ebene zu beantworten.
Also ich glaube erstmal daran, dass es die Aufgabe von Menschen mit Verantwortung ist, die Menschen da rein zu begleiten, auf genau den Ebenen, die ich gerade beschrieben habe, also strukturell und soft- und hard-skill-technisch sozusagen, wenn ich das denn unbedingt will.
Ich glaube auch, dass es in deren Verantwortung liegt, diese gemeinsame Produktservice, was auch immer, Projektvision so runterzubrechen, dass den Leuten irgendwie klar ist, aha, das ist irgendwie das, wo ich hinlaufen soll.
Und wenn es dann Menschen gibt, die dafür ein bisschen länger brauchen, da sozusagen hinzukommen, entweder skill- oder zielorientierungstechnisch, dann glaube ich, dass ich das vorher einplanen muss.
Also jeder dieser Changes wird auf jeden Fall auch eine Zeit brauchen, auf der Ebene anzukommen.
Und für mich ist jetzt jemanden rauszunehmen, immer erstmal ein krasser Bruch, der auch nicht zu unterschätzen ist, was er den anderen Leuten, die nämlich drinnenbleiben, signalisiert.
Das heißt ja dann irgendwie so ein bisschen, wenn du dich jetzt hier nicht anpasst oder was auch immer einfindest, dann kann es auch sein, dass du irgendwie rausgenommen wirst.
Also diese, ich weiß nicht, ob das was ist, was ich da sozusagen pflanzen möchte, weil das hilft wahrscheinlich auch nicht unbedingt der Fehlerkultur.
Genau, also das wäre für mich schon die letzte Bastion.
Ich glaube, es ist spannender.
Wir haben zum Beispiel schon auch in Projekten erlebt, dass es Menschen gibt, die wir, wir bauen diese Struktur in Team Topology, sehr cross-funktional mit mehreren Menschen und dann nehmen wir Feedback von allen Leuten, die betroffen sind dafür, wie die Struktur am Ende aussehen soll und nehmen die auf den Weg dahin schon mit.
Und dann reden wir über Verortung in dieser neuen Struktur.
Und da gibt es schon oft den Fall, dass jemand sagt, da sehe ich mich einfach nicht, sehe mich nicht als ein Abler.
Ich sehe mich als jemand, der einfach hingeht und Sachen heile macht.
Und ich will jetzt auch nicht plötzlich mit 17 Leuten arbeiten.
Oder ich war vorher Teamleiter.
In dem neuen System gibt es keine Leitungsfunktionen im Mittelmanagement.
Dann fühle ich mich da eben nicht mehr wohl.
Also es sind schon immer Menschen, die dann aus diesem Change sozusagen sich herausentwickeln, aber nicht von oben entschieden, sondern sozusagen gemeinsam herausgearbeitet.
Ich glaube, das ist halt ein guter Punkt.
Also was halt so ein bisschen bei mir ankommt, ist, wenn man das halt tatsächlich tut, ist das halt auch eine Niederlage und gewisserweise eigentlich ein Versagen.
Weil eigentlich müsste man halt dafür sorgen, dass die Person halt einen konstruktiven Teil von dem Team hat, irgendwie wird in einer bestimmten Art und Weise.
Der Gromio bei YouTube hat folgende Frage gestellt.
Genau, ich glaube, wir haben das so ein bisschen zu Ende diskutiert, nicht, das Beispiel?
Genau, okay.
Er hat also gefragt, habt ihr praktische Erfahrungen in Sachen intrinsisch motiviertes Teambuilding?
Die HR-Teams finden sich eher selbst, anstatt die Aufteilung top-down festzulegen.
Ja, habe ich in Projekten gesehen.
Ich muss gestehen, dass ich mir immer ein bisschen unsicher bin, ob das sozusagen der in Anführungszeichen richtige Weg ist, weil ich halt behaupten würde, dass zum Beispiel, also wie soll ich sagen, du hast es gerade eben ja schon in Ansätzen gesagt, Menschen wollen halt bestimmte Dinge tun, Menschen können bestimmte Dinge gut tun.
Es ist irgendwie wenig sinnvoll zu sagen, nee, du machst jetzt irgendwie ganz was anderes, sondern man muss ja dort einsetzen, wo sie sinnvollerweise Wert generieren können und dazu muss man es halt sozusagen diskutieren.
Ich finde es ehrlich und ja, also sowas habe ich halt irgendwie gesehen, dass sich Teams sozusagen selbst organisieren.
Ich finde es ehrlich gesagt ein bisschen schwierig, weil ich halt zum Beispiel erwarten würde, dass bestimmte, wie soll ich sagen, wenn ich halt weiß, in diesem Bereich ist jetzt irgendwie ganz viel, was halt gemacht werden soll, da sollen halt wahrscheinlich mehr Leute daran arbeiten und die Teams sagen, nee, machen wir halt irgendwie nicht, dann ist es halt schwierig und dann weiß ich nicht, wie ich sozusagen nachsteuern sollte.
Auf der anderen Seite kann man natürlich argumentieren, dass das halt Versagen von dem Teambuilding und den Teams halt an sich ist.
Mich erinnert das an die Geschichte mit, wie finde ich sozusagen einen sinnvollen Job und ich glaube auch, ein Job ist halt, also für mich selber, was ist die Karriere, die ich halt irgendwie anstreben sollte, für mich ist das halt ein Kompromiss zwischen etwas, was halt Geld bringt, etwas, wo ich halt irgendwie gut drin bin und etwas, was mir irgendwie Spaß macht und das sind so drei Parameter und ich kann halt sozusagen nicht alles haben.
Also es gibt halt Dinge, die mir zwar Spaß machen, wo ich halt irgendwie nicht gut bin und für die es halt kein Geld gibt, das ist dann halt irgendwie kein guter Job und ich glaube, das ist halt bei Teams ähnlich.
Also wenn wir nur sagen, was macht euch irgendwie Spaß und macht dann das, was euch Spaß macht, finde ich es halt schwierig.
Wahrscheinlich muss man da Kompromisse machen.
Wie siehst du das denn?
Genau, ich glaube, es hat einfach noch so ein bisschen unterschiedliche Parameter.
Also ich arbeite jetzt gerade mit einem Kunden zusammen, die machen genau ein Ding.
Also die machen Beratung für ein Themengebiet Digitalisierung von Finanzmärkten und alle Menschen, die da arbeiten, machen das.
Und was die schon ermöglichen und ich glaube, das macht Sinn und wir bauen jetzt gerade eher sozusagen die Support-Ebene.
Wir überlegen gerade, was kommt ins Plattform-Team, was kommt in die Enabling-Schiene.
Alles, was streamlined ist, was wertschöpfend ist, ist sowieso quasi eine fluide Menge von Menschen, die man manchmal in dieser Gruppierung und manchmal in dieser braucht, um Beratungsprojekte bei Kunden zu machen.
Und die haben schon so einen Ansatz.
Die haben Mission-Teams und man darf sich sozusagen auf Beratungsaufträge dann bewerben.
Man darf auch gucken, mit wem würde man dann da beim Kunden landen und die ermöglichen, international und remote, sodass es keine anderen Faktoren eine Rolle spielen als sozusagen Skill-Level und Passung mit diesem Projekt-Team.
In Transformationen von jetzt sozusagen bestehenden Firmen, wo es irgendwie bestehende Produkte gibt und bestehende Verpflichtungen und bestehende Services, die man irgendwie nachkommen muss, glaube ich, ist es schon auch Aufgabe von irgendwem.
Es kann ein cross-funktionales Change-Team sein oder es kann Führung sein, so eine Art Group-Design zu machen und zu sagen, das ist so die Struktur und das ist so die Group-Vision, die wir irgendwie haben und wir nehmen euch jetzt mit auf den Weg der Falljustierung.
Also ich würde niemals sozusagen Team-Topologies verorten, weil die Prinzipien dahinter sind ja schon auch Autonomie, Selbstorganisation und so und das kann ich nicht Leuten bis ins Kleinste vordeklinieren und sagen, so musst du jetzt arbeiten.
Aber ich glaube, so eine Art Vordesign und dann in Feedback-Schleifen zu gehen und zu sagen, haben wir die Stream-Align-Teams sauber geschnitten?
Gibt es noch enabling Dinge, die wir euch zur Verfügung stellen müssen, weil wir die nicht in ausreichender Menge da haben?
Sind die Plattform-Dienstleistungen wirklich sauber geschnitten?
Ist das irgendwie Quatsch, was wir da im kleinen Change-Team uns überlegt haben?
Da die Leute mitzunehmen, finde ich super wichtig und eben auch in der eigenen Verortung, dann in dieser Zielstruktur, müssen wir sie mitnehmen.
Da müssen die selbst motiviert reingehen.
Ja, genau.
Du hattest gesagt, die können sich halt bewerben, was ja impliziert, dass jemand nochmal sagt, nee, du halt irgendwie nicht.
Also potenziell zumindest.
Und ich habe jetzt gerade die Frage auch nochmal gelesen, da steht halt, finden sich eher selbst und das macht glaube ich irgendwie auf jeden Fall Sinn.
Und vielleicht ist noch die letzte Sache, weil du es halt sagtest mit den selbstorganisierten Teams.
Also eigentlich, wenn ich sage Teams sollten sich selbst organisieren, dann müssen sie sich selbst organisieren, dann wäre das halt tatsächlich die Konsequenz, dass sie halt irgendwie sagen, sie finden sich halt irgendwie auch selbst.
Und ich glaube, für mich ist das auch ein Thema von schlicht Vertrauen.
Also sprich, glaube ich, dass die Leute das auf die Reihe bekommen.
Und ich suche da irgendwie immer noch den besseren Begriff.
Das ist auch etwas, was für mich bei Architekturarbeit so eine große Rolle spielt.
Wenn ich den Teams Verantwortung delegiere, impliziert das, dass ich denen vertraue.
Und wie soll ich sagen, einigen kann man nicht vertrauen.
Ich weiß noch nicht, was der bessere Begriff dafür ist, weil sie beispielsweise vielleicht bestimmte Kompetenzen nicht haben.
Und mit dem muss man dann halt irgendwie anders umgehen.
Und das ist hier vielleicht auch der Punkt.
Also einmal bedeutet es halt, dass ich dem vertrauen muss im Sinne von, ich muss mich wagen zu sagen, ihr macht das schon und da wird das Richtige bei rauskommen.
Da gibt es diesen englischen Begriff von Liebe of Faith.
Dass ich halt irgendwie diesen Sprung von Vertrauen, also im Prinzip sage, ihr macht das schon und ich vertraue euch und ihr kriegt das hin.
Das ist eine Komponente.
Und die andere Sache ist diese objektive Qualifikation, die ich haben muss und wo ich auch mit umgehen muss.
Und ich glaube, das sind schon Parameter, die sowas dann halt ermöglichen oder eben auch nicht.
Also sprich, es kann sein, wenn ich irgendwelchen Teams sage, hört mal zu, ihr sucht euch jetzt die Aufgaben selber.
Dass die mich halt irgendwie im Extremfall mit leeren Augen angucken und sagen, was willst du jetzt von mir?
Und dann muss ich halt irgendwie anfangen, muss ich halt irgendwie enablen und halt andere Dinge tun und kann das vielleicht erst mal nicht machen.
Und ich finde das auch gar nicht schlimm, ehrlich gesagt, weil dann muss man eben mit den Leuten anders umgehen.
Das ist ja nicht unbedingt schlimmer oder schlichter.
Ich glaube aber auch, dass es eine Frage ist von, also für mich ist das Haltung, was du vielleicht mit Vertrauen meinst.
Also erst mal habe ich, wenn ich sowas machen will, wenn ich sagen will, lass uns mal nach den Prinzipien von Team Topologies auf unsere Organisation gucken und lass uns mal gucken, wie wir möglichst autonome Teams enablen, autonom arbeiten zu können, dann wäre es schon eine gute Idee.
Ich würde da auch daran glauben, dass das funktionieren kann und dass die Leute nur dahin enabled werden müssen und nicht kontrolliert werden müssen oder bestraft oder so.
Und gleichzeitig ist es dann, finde ich, aber auch Verantwortung derjenigen, die solche Entscheidungen treffen und die so eine Organisation umbauen, zu gucken, wie schaffe ich denn eine Struktur, in der die Leute gut die Autonomie sozusagen ausprobieren und erfahren und immer besser werden können darin.
Und das ist für mich dann etwas, was ich sehr explizit machen kann, mit Team Topologies zu sagen, unsere Stream Align Teams in unserer Organisation haben übrigens diese Verantwortung von Anfang bis Ende.
Das beinhaltet und danach orientieren die sich und danach wird Erfolg gemessen.
Und unsere Enabling Teams sind dafür da, dass die hier irgendwie besser werden.
Und unsere Plattform Teams haben natürlich sozusagen auch einen Verantwortungsbereich, der abgesteckt ist und die Verantwortung, diesen Stream Align Teams zu helfen.
Wenn ich das gut definiere und schärfe und die Rollen auch klar habe, die es dann in diesen Teams braucht und das Enabling klar habe, was es für die ganze Organisation braucht, dann kann, glaube ich, Selbstorganisation sehr gut funktionieren.
Und für mich heißt aber Selbstorganisation auch nicht, alle müssen alles immer überall mitentscheiden, sondern eben kompetenzbasiert.
Wenn ich Ahnung habe von Security, wäre es gut, wenn ich zur Security was sagen darf.
Deswegen muss ich aber nichts zu, weiß ich nicht, hübschen UIs sagen müssen.
Also das wäre für mich auch nicht ein effizientes, gut organisiertes, selbstorganisiertes Team.
Sondern es ist eher die Frage, wie kriegen wir die Leute, die Ahnung haben, in eine Struktur, in der die ihre Ahnung gut nutzen kann.
Ich glaube, du hast gerade eben was total Wichtiges gesagt.
Also wenn ich eine Struktur aufbaue, wie Team Tobotodgies, die auf selbstbestimmte autonome Teams setzt, dann muss ich das auch wollen.
Und ich glaube, das ist in der Praxis einer von den Hemmschuhen.
Ich will zwar die Produktivität dieser Teams und ich will, dass die möglichst schnell etwas bauen, aber in Wirklichkeit vertraue ich denen nicht.
Und dann fange ich doch an zu kontrollieren und das führt dann zu dieser Inkonsequenz, die ich möglicherweise habe.
Man muss irgendwie auch dieses Vertrauen haben und muss dafür sorgen, dass man es immer umsetzen kann.
Und ich glaube, das ist auch noch ein ganz wichtiger Aspekt.
Ich glaube, damit haben wir das Thema durch.
Ich gucke gerade, wir haben noch so ungefähr fünf Minuten.
Können wir eigentlich noch dieses andere Projekt durchdiskutieren, oder?
Ich glaube, das schaffen wir wahrscheinlich.
Das ist eigentlich etwas, was gar nicht so nur ein konkretes Projekt ist, aber es ist etwas, was ich öfter beobachte.
Ich habe halt irgendeine Aufteilung von Teams.
Stream Align Teams, Platform Teams, Complicated Subsystem Teams.
Und tatsächlich ist es aber so, dass es zum Beispiel in dem Beispiel verschiedene Consistencies gab, die sich da eher bekämpft haben und die bestimmte Teile von diesem System entwickelt haben.
Das heißt, ich habe mehrere Dienstleister und diese Dienstleister sind verantwortlich für bestimmte Dinge und die sind sich nicht unbedingt grün bzw. die stehen auch im Wettbewerb, weil sie natürlich Kunden einen guten oder weniger guten Eindruck machen und dadurch mehr oder weniger Umsatz mit dem Kunden machen.
Für mich ist das allgemein eigentlich typisch.
Ich habe meine Folie dazu gemalt mit Deutschland vor 1871 mit diesen vielen kleinen Königreichen.
Das ist ehrlich gesagt das, was ich meistens spüre bei Projekten und bei Organisationen, dass es diese eher menschlichen Beziehungen gibt und diese individuellen Königreiche, wo Leute versuchen, ihre Karriere oder ihren Einfluss oder den Umsatz der Firma, für die sie arbeiten, zu maximieren, indem sie mehr Leute unterbringen.
Das ist eine andere Ebene als diese Ebene mit diesen Stream Align Teams oder das, was Team Topologies sagt.
Das scheint erst mal nichts miteinander zu tun zu haben.
Eigentlich ist das, was wir jetzt beschreiben, dass ich einmal diese formalen Teamtypen, diese formale Team Topology habe und dann diese andere Ebene.
Aber in Wirklichkeit ist es so, dass am Anfang von dem Team Topologies Buch gleich steht, ein wesentlicher Teil der ganzen Geschichte steckt eben nicht in den Organigramm.
Also in diesem Fall zum Beispiel die Consultancies, die da arbeiten, die Dienstleister, die da arbeiten.
Das ist nicht in dem Organigramm wirklich drin.
Die persönlichen Befindlichkeiten spielen eine Rolle, wer mit wem wie kann.
Was man von Team Topologies ablesen kann, ist, es gibt dort einen bestimmten Fokus.
Bestimmte Dinge, die nicht wirklich verhandelbar sind, die als Magnete, als Optimum dargestellt werden.
Also zum Beispiel diese vollständige Verantwortung für einen Strom von Änderungen, den ein Stream Align Team hat.
Die Idee, dass die anderen Teams Dienstleister sind, dass das Stream Align Team in der Führung ist und das nicht Architektur kontrolliert, sondern unterstützt.
Da gibt es in dem Kontext, aber auch in anderen Kontexten Optimierungsbedarf.
Damit sagt es erst mal, worauf es wirklich ankommt und setzt klare Prioritäten.
Das andere ist, dass das für mich auch nochmal ein Indikator dafür ist, dass man mit externen Dienstleistern, ich habe das in einem anderen Kontext erlebt, wo man Teams aufbaut, dass aus verschiedenen Unternehmen von verschiedenen Dienstleistern Leute dazukommen und die in den Teams mitarbeiten, sodass ich dann eben nicht dieses Problem habe, dass die im Wettbewerb zueinander stehen, sondern dann müssen sie halt kollaborieren, weil sie eben in gemischten Teams arbeiten und entweder sie gewinnen gemeinsam oder sie verlieren gemeinsam.
Das Team da drüben hat schweder Mist gebaut.
Wir sind ja viel besser.
In unserem Bereich sieht es super aus, gibt uns doch noch diesen Bereich da drüben, weil wir sind die Besseren, sondern die sind dann halt zum gemeinsamen Erfolg sozusagen oder zum gemeinsamen Verlieren verdammt.
Das ist, glaube ich, vielleicht ein anderes Setting dort.
Und vielleicht nur noch zwei Ergänzungen.
Ich finde, das ist auch nochmal ein gutes Beispiel für Strukturschaft behalten.
Wenn ich jetzt in einem Team bin und das ist so angelegt, dass in meinem Team alle meine Homies sind aus meiner Beratung und in dem anderen die anderen, dann ist ja auch wieder klar so angelegt, dass wir halt in Feindschaft existieren.
Könnte man denen mal wenigstens ein gemeinsames Ziel geben, das würde schon helfen.
Aber wie du sagst, so etwas Basales wie Teams durchmischen und nicht von den gleichen Dienstleistern irgendwie getrennte Teams, schon mal eine gute Idee.
Was ich aber auch spannend finde, sind zwei andere Dinge.
Das eine ist, ich kann mit Team Topologies oder auch mit anderen solchen Organisationsframeworks eben den Betrachtungsgegenstand durchaus auch über meine eigene Organisation hinweg machen.
Ich könnte sagen, für meine Entwicklungsarbeit gibt es folgende Streams, folgende Plattformen, folgende Enabling-Fähigkeiten, die wir eigentlich haben müssen.
Und aktuell sind die halt nicht mit eigenen Leuten hauptsächlich besetzt.
Und was ich dann machen kann, ist den Entwicklungspfad dahin.
Das wäre zum Beispiel eine gute Idee, Stream-Aligned-Teams hauptsächlich intern besetzen zu können, weil da ist ja mein Know-how.
Wenn mir da die Leute abwandern, dann ist alles, womit ich Wert schöpfe, weg.
Und deswegen wäre es smart, zu sagen, wie viel sind wir denn abhängig in den Streams von externen Dienstleistenden und ist das eine gute Idee?
Wollen wir das so lassen?
Und wenn nicht, sollten wir das ändern?
Und das kann ich eben auch.
Ich kann so eine Art Transitionsarchitekturen aufbauen und sagen, das ist mein Zielbild.
Da sind wir heute.
Das ist die Entwicklung.
Und das macht es einfach noch mal sehr viel greifbarer und transparenter, weil es einfach modelliert ist und eine Sprache ist, um diese Konsequenzen abzuleiten.
Was ich natürlich dann trotzdem machen muss, ist, die Leute dann zu begleiten, dass die nicht gegeneinander arbeiten.
Aber genau, also auch da hilft uns die Struktur und die Explizitheit dessen, was wir da entscheiden, und nicht einfach laufen lassen.
Guter Punkt.
Marc M. hat gerade bei YouTube eine Frage gestellt.
Ich muss gestehen, ich habe die, glaube ich, nicht verstanden.
Von daher würde ich da sozusagen noch mal um Klärung bitten.
Die andere Sache, weil du es gerade sagtest, von wegen, ich finde, es gibt auch diese sozialen Experimente, wo man sagt, ich bilde eine Gruppe und ich differenziere die Gruppe von der anderen dadurch, dass ich sie irgendwas tragen lasse oder so.
Und das kann, wenn man es für eine bestimmte Definition von geschickt einsetzt, zu ganz krassen Auseinandersetzungen zwischen diesen Teams führen.
Das ist meiner Ansicht nach tatsächlich ein soziales Experiment, was wirklich auch belastbar und beobachtbar ist.
Und ein bisschen muss ich daran gerade denken, also ich sitze bei mir mit meinen Leuten, mit meinen Kollegen von meiner Firma zusammen, da drüben ist die andere Firma.
Und wenn es schiefgeht, kann das eben genau zu diesem Pfad führen.
Das ist so ein Mechanismus, über den man sich da, glaube ich, im Klaren sein muss.
Das ist auch das, was in sehr funktionalen Organisationen passiert.
Wenn ich zum Beispiel den Einkauf danach belohne, dass er Geld einspart und die Leute, die dann irgendwas bauen müssen, mit sehr wenig Ressource dafür bestrafe, dass die mit wenig Dinge auskommen müssen, dann habe ich automatisch Einkauf und diese Umsetzungsmenschen gegeneinander aufgebracht.
Dumme Idee.
Deswegen, grundsätzliche Idee von Team Topologies, mach es so cross-funktional, wie es eben geht.
Aber vor allen Dingen arbeitet gemeinsam an einer Sache und nicht schon in der eigenen Organisation gegeneinander.
Das wäre nicht so smart.
Genau.
Ein guter Mensch schafft seine Zahlen, auch wenn die Firma darüber pleite geht.
Gut, genau.
Okay, also Mark M. hat gefragt, welche Struktur muss gegeben sein, damit konkurrenzpositive Ergebnisse herbeiführt?
Und wie muss sie sein für negative Ergebnisse?
Wenn ich sagen sollte, ich würde sagen, Konkurrenz ist nicht positiv.
Mit der einen Ausnahme vielleicht, also ich interpretiere jetzt einfach, was Mark da fragt, aber vielleicht passt es ja.
Wenn ich jetzt diese Situation habe, die wir ja schon durch die Prinzipien gegeben haben, also ich kann als Streamline-Team selber Sachen bauen oder ich kann das nutzen, was die Plattform mir zur Verfügung stellt, dann kann sozusagen diese Möglichkeit, in Konkurrenz zu gehen mit meinen eigenen Teams, zumindest was bestimmte Services angeht, ja schon dazu führen, dass in Summe die Qualität unserer Lösung besser wird.
Wenn ich jetzt das nicht als Konkurrenz werte und sage, wieso müsstet ihr die ganze Zeit selber Sachen bauen?
Warum habt ihr nicht das an der Plattform genommen?
Das ist doch auch okay.
Sondern wenn ich den Freiraum lasse, dass Experimente technologisch gemacht werden, dass Erkenntnisse gewonnen werden, die dann wieder zurückfließen ins große Ganze, das könnte ich noch frame als eine positive Konkurrenzsituation.
Das, was wir gerade eben beschrieben haben, würde also, wenn ich Menschen in eine direkte Konkurrenzsituation bringe, und das ist häufig aus Versehen passiert, ich glaube nicht, dass Leute das absichtlich so nicht überlegen und die Transparenz darüber herstellen, das wäre nicht so smart.
Ja, also guter Punkt.
Dieser Wettbewerb, von dem wir gesprochen haben, von dem insbesondere du gesprochen hattest, bei diesem Plattform-Team, dass ich sage, ihr könnt es benutzen oder eben auch nicht, das ist tatsächlich etwas, was in gewisser Weise positiv ist.
Ich glaube, ich störe mich immer noch an den Konkurrenzgedanken, weil für mich ist das tatsächlich zu negativ besetzt.
Ich würde da auch behaupten, ich weiß nicht, ob das eine Konkurrenz ist, das ist eher, ich bin das Plattform-Team, wie bekomme ich es hin, möglichst gut meinen Job zu machen.
Ich stehe nicht in einem direkten Wettbewerb, weil du gerade sagtest, dass das sozusagen niemand anstrebt.
Also ich bin sehr sicher, nein, also es ist offensichtlich so, dass beispielsweise in Elite-Unis mit wirklich guten Forschungen es so ist, dass man sagt, okay, da gibt es etwas, was erforscht werden soll.
Dann setzt man zwei Doktoranden darauf und die haben dieselbe Aufgabe und arbeiten gegeneinander.
Das heißt also, dass man tatsächlich sagt, viel Spaß dabei.
Entweder du gewinnst das Paper oder die andere Person gewinnt das Paper.
Viel Spaß.
Was dann auch absehbar dazu führt, dass die sich gegenseitig manipulieren und sich eher im Weg setzen, also Ergebnisse kaputt machen und dafür sorgen, dass die andere Person behindert wird.
Auf einer gewissen Ebene funktioniert das, weil tatsächlich dabei offensichtlich Forschungsergebnisse produziert werden.
Das ist glaube ich das exakte Gegenteil von dem, was wir hier diskutieren.
Jetzt aber trotzdem ein wichtiger Punkt.
Ich finde, das darf man bei diesen ganzen Sachen nicht vergessen.
Man kann mit unmenschlichen Methoden – ich halte das für unmenschliche Methoden – erfolgreich sein.
Was eben auch bedeutet, dass ich es bei diesen Sachen immer wichtig finde, darauf hinzuweisen, dass das zu erfüllender Arbeit führen sollte und dass das auch ein Kriterium ist, unabhängig davon, ob das zu kommerziellem Erfolg führt.
Ich habe auf der einen Seite keinen Zweifel daran, dass das, was diese Elito und dieses Tun tatsächlich zu Erfolg führt.
Ich würde davon Abstand nehmen, das meiner Kunden zu raten, weil ich das für ethisch indiskutabel halte.
Absolut.
Ich glaube, dass es zwei Extreme gibt.
Es gibt solche Organisationen, die habe ich auch von innen gesehen, die so ein Setup kreiert haben, ob jens absichtlich oder nicht, aber wo es auf jeden Fall nützlich ist, gegeneinander zu agieren oder Sachen voreinander fernzuhalten, weil die Struktur das eben irgendwie belohnt, wenn man es nicht macht oder macht.
Das ist, glaube ich, aber zumindest bei vielen klassischen gewachsenen Organisationen einfach irgendwann so passiert, und es guckt sich jemand von draußen an und sagt, Leute, warum macht ihr das?
Das ist irgendwie nicht schön, so zu arbeiten, und es ist auch nicht so smart, und manchmal wird es vielleicht auch absichtlich laufen gelassen.
Es gibt aber auch die anderen Extreme, die so ultra-agilisiert, ultra-selbstorganisiert und alles geht nur um, wie geht es uns allen gut, und dann gibt es gar nicht mehr Wirtschaftlichkeit.
Für mich persönlich ist was in der Mitte sinnvoll, und zwar in der Mitte von, wir haben irgendwie was Wirtschaftliches, eine Sache, an die wir glauben.
Wir tun das so, dass es den Leuten dabei nicht schlecht geht und dass bestimmte Werte, die uns wichtig sind, auch gelebt werden können, und in einer Struktur, die das eben möglichst enabelt.
Ich glaube, alle drei dieser Modelle kann man mit Team Topologies auch bauen.
Es kommt eben darauf an, mit welcher Haltung man da reingeht, aber die Prinzipien, die dahinterstecken, wenn man die bewirkt, glaube ich, ist es schon nützlich, mal bestimmte Sachen in Frage zu stellen zumindest, oder bestimmte Symptome auch zu stoßen, wenn man Struktur baut.
Gut, hervorragend.
Mark hat gesagt, das waren gute Antworten, und er hat Unternehmen kennengelernt, die auch solche Konkurrenzsituationen ausnutzen.
Ich glaube, damit sind wir am Ende.
Ich packe nochmal den Link zu dem schon zitierten Training in den Chat, und dann hoffen wir, dass wir uns dort vielleicht wiedersehen, und vielleicht sonst am Donnerstag oder am Freitag bei den Folgestreams.
Bis dahin, und vielen Dank.