Corporate Therapy
Noch ein Business Podcast! Juhu! Wer braucht denn sowas?
Corporate Therapy ist ein kritischer Management Podcast – und der Name ist Programm: Wir legen darin „die Corporate” und gelegentlich auch uns selbst auf die sprichwörtliche Couch. Gemeinsam versuchen wir, Probleme und Phänomene rund um Arbeit und Organisation besser zu verstehen und vielleicht ab und an auch eine Lösungsstrategie zu entwickeln – jedoch ohne Garantie auf Genesung!
Wir sind Human Nagafi, Mary-Jane Bolten und Patrick Breitenbach.
Neben den Beiträgen unserer großartigen Gäste aus Wissenschaft, Politik und Wirtschaft freuen wir uns auch sehr über Fragen, Kritik und Anregungen von euch. Dazu könnt ihr uns entweder per Mail oder LinkedIn schreiben oder euch direkt zu einem unserer Live-Podcasts einschalten und mitdiskutieren. Viel Spaß und gute Erholung.
Corporate Therapy
Episode 127 // Conway’s Law in der Praxis: Technik vs. Organisation // mit Björn Schotte
Schickt uns euer Feedback zur Episode
In Episode 127 fragen wir uns (mal wieder) warum so viele digitale Transformationsprojekte scheitern. Björn Schotte, Mitgründer und Geschäftsführer der Mayflower GmbH, bringt in dieser Folge eine provokante These mit: “Organisation folgt Technologie, nicht umgekehrt.”
Während viele Unternehmen zuerst Teams bilden und dann hoffen, dass “geile Software” entsteht, zeigt die Praxis, dass dieser Ansatz oft zum Scheitern verurteilt ist. Stattdessen sollten wir uns zunächst fragen: Welche Geschäftsanforderungen haben wir? Welche Softwarearchitektur brauchen wir dafür? Und erst dann: Wie müssen unsere Teams strukturiert sein, um diese Architektur optimal umzusetzen?
Wir erkunden das faszinierende Conway’s Law, das besagt, dass die Struktur einer Software die Kommunikationsstrukturen der Organisation widerspiegelt, und diskutieren moderne Ansätze wie Team Topologies. Diese bieten Frameworks, wie Teams in einer zunehmend komplexen Softwarewelt organisiert werden können, um sowohl Autonomie als auch Alignment zu gewährleisten.
Doch die eigentliche Herausforderung liegt in der Transformation: Wie können wir in gewachsenen Strukturen mit informellen Netzwerken und mikropolitischen Interessen solche Veränderungen umsetzen? Und welchen Einfluss wird künstliche Intelligenz auf dieses Zusammenspiel haben? Werden Junior-Entwickler überflüssig oder verändert sich nur, wie wir zusammenarbeiten?
Eine gedankenprovozierende Folge, die die Grenzen zwischen Technologie und Organisation neu auslotet und praktische Einblicke gibt, wie digitale Transformation wirklich gelingen kann.
Shownotes:
- Manuel Pais und Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow, Buch
Du hast es schon implizit gesagt, nämlich das implizite explizit machen und das regelmäßig tun. Also genauso wie ich nicht überrascht sein darf, wenn ich jetzt nicht in Qualität, in meine Software investiere, dass quasi dieses berühmte Technical Debt immer weiter anwächst und ich dann irgendwann Qualitätsprobleme gebe, Oh, Überraschung, Überraschung. Wir haben jetzt zwei Jahre lang unser Produkt aufgebaut. Wir sind ein Startup, wir haben halt nur Features gebaut. Ja, dann ist es halt so, dass, wenn man mal drauf guckt, dann irgendwann sieht oh hoppla, da müssen wir jetzt was tun.
Speaker 2:Money, money. I want more money. I don't even know why.
Speaker 3:Hallo und herzlich willkommen. Zurück zu Corporate Therapy. Ich versuche, heute mal ganz diszipliniert zu sein. Wir sollen ja immer mal wieder zu Anfang sagen, wer wir eigentlich sind, falls Leute erst einsteigen in den Podcast und uns nicht seit Folge 1 gehört haben. Uns ist das irgendwann bei Folge ich weiß gar nicht 100 aufgefallen, dass wir nie sagen, was wir eigentlich tun. Also hier ist es. Corporate Therapy ist ein kritischer Management-Podcast, in dem wir mal mit und mal ohne Gäste Fragen aus der Arbeitswelt diskutieren, und manchmal ist es dabei sehr globalgalaktisch und geht um die gesamte Wirtschaft und den gesamten Zustand der Welt, und manchmal ist es ganz praktisch, und wir sprechen über Methoden und Frameworks, und ich glaube, heute landen wir irgendwo mittendrin.
Speaker 3:Ich bin Mary Jane, und mit mir ist in der Regel auch immer einer meiner Kollegen mit dabei oder die Kollegen unter sich, und ich bin nicht dabei. Und heute ist das Human. Hallo, human. Guten Tag Mary, wie geht's Sehr gut. Ich freue mich sehr, denn es gibt ein Thema, über das denke ich schon ganz lange nach, oder? nee, stimmt nicht. Das ist falsch. Ich denke darüber nicht schon ganz lange nach, aber ich denke darüber zurzeit sehr viel nach.
Speaker 3:So rum ist das richtig. Und ich mache auch direkt zu Anfang hier mal einen Aufruf an alle Hörerinnen und Hörer, an unsere Zuhörer. Ich äußere mal einen Wunsch. Ich wünsche mir von euch Anekdoten und Gedanken zur Frage wie verändert KI euren Arbeitsalltag? Wo verwendet ihr das? Ändert sich irgendwas grundsätzlich? Wo steckt ihr da in euren Organisationen gerade Ich möchte das wissen. Das ist ein bisschen gerade eine persönliche Obsession von mir, aber so ganz alleine bin ich damit nicht. Unser Gast, der heute da ist, war nämlich schon zweimal bei uns im Podcast, und einmal davon haben wir genau zu diesem Thema AI gesprochen. Aber heute wollen wir nochmal grundsätzlicher an die Frage gehen was kommt eigentlich zuerst, die Technik oder die Organisation? Und dazu haben wir hier Björn Schotte. Hallo Björn, schön, dass du da bist.
Speaker 4:Hallo Mary, hallo Roman, schön, dass ich wieder hier sein darf. Hi, ich freue mich.
Speaker 3:Ich freue mich auch total, und ich stelle dich auch nochmal vor, weil wir wissen ja, nicht alle haben alle Episoden gehört. Björn, du bist Mitgründer und Geschäftsführer der Mayflower GmbH. Das ist ein Beratungsunternehmen, oder?
Speaker 4:auch Softwareunternehmen, IT-Dienstleister. Hauptsache Software ja.
Speaker 3:Genau, der sich auf die Entwicklung moderner Softwarelösungen spezialisiert hat, der sich auf die Entwicklung moderner Softwarelösungen spezialisiert hat, so habe ich mir das hier schön notiert. Also, ihr seid mittendrin in der digitalen, in der agilen Transformation, in allem, was dazu gehört, und man kann dich nicht nur hier im Podcast hören, sondern eigentlich auf verschiedenen Plattformen. Du bloggst, du bist aktiv auf LinkedIn, du tauschst dich auch viel aus. Unter anderem hast du auf einen Post von mir reagiert. Ich weiß gar nicht mehr, welcher Post das war, ich weiß nur noch, deine Reaktion, habe ich mir notiert. Deine Aussage war Organisation folgt Technologie, nicht umgekehrt. Den Weg machen viele Unternehmen falsch und straucheln dann. Richtig, und ich würde jetzt einfach diese Frage umdrehen und sie dir zurückstellen, richtig.
Speaker 4:Ja, na klar, Und schon ist der Podcast vorbei. Wie ich es im Vorfeld gesagt habe, das Ding ist auserzählt. Ja, natürlich kommt die Technik zuerst. Ja, wie soll ich sagen? es ist erstmal sehr, sehr kontraintuitiv, weil man denkt natürlich, wieso, abteilungen, bereiche, ich baue doch jetzt erstmal meine wohlberühmten agilen, teams und ähnliches, und dann kommt geile Software raus. Aber eigentlich muss ich es andersherum machen, bin ich der Meinung, und mit der Meinung stehe ich zum Glück nicht alleine da. Tja, bin gespannt, was wir in dieser Folge alles so ausgraben werden.
Speaker 3:Zu dem Thema Jetzt hast du gerade schon gesagt, dann kommt geile Software raus. Was ist denn der Gedanke, der dir da immer so entgegenschwappt, wo Leute sagen, jetzt machen wir agile Teams, und dann kommt geile Software raus? Also, was glaubst du, steckt da dahinter?
Speaker 4:Naja, da steckt so ein bisschen der Vereinfachungsgedanke, der Simplifizierungsgedanke dahinter Im Sinne von ich muss nur das und das machen im Rahmen meiner Organisation, weil die Leute meistens dann auch nicht so tief in der Entwicklung drin sind, weil sie selber keine Softwareentwickler drin sind. Dadurch entsteht halt der einfache Gedanke naja, wenn ich meine Teams so und so baue und so und so strukturiere, dann wird das schon irgendwie passen. Und dann wundern sie im Sinne von naja, die Software macht nicht das, was sie soll. Wir wollen hier internationalisieren, aber irgendwie kriegen wir das nicht hin mit unserer Plattform. Was können wir denn da tun? Und dann gucken wir drauf und sehen okay, da ist klar, warum, weil die Teamstruktur passt nicht. Und dann gehen wir eigentlich eher erstmal den umgekehrten Weg, dass wir gucken, wie soll denn eigentlich die Software sein?
Speaker 4:Also im Kontext, wie soll die Zielarchitektur sein, damit ich überhaupt erst sowas wie beispielsweise eine Internationalisierung machen kann? Und erst dann überlege ich mir wie muss ich denn meine Teams dafür strukturieren, damit am Ende das rauskommt, was ich von der Software her brauche? Und das machen viele Organisationen nicht, die gehen den anderen Weg.
Speaker 3:Die sagen ja, ich habe die und die Köpfe, ich struktur erstmal von Softwareentwicklung. Auch Ich glaube, das müssen wir erstmal als Voraussetzung machen, und dann später können wir gucken sind unsere Erkenntnisse übertragbar? Also du sagst im Prinzip, es gibt zwei Ansätze. Der eine Ansatz ist der ich plane das vom Ziel her, also ich möchte eine bestimmte Sache haben, und dann muss ich meine Organisation entsprechend aufbauen. Und das andere, das wäre, glaube ich, effectuation Ansatz, eigentlich zu sagen, das ist, was ich habe, und jetzt gucke ich mal, wie weit ich damit komme. Und du sagst, wenn man aber Software baut, dann sollte man erstmal gucken, was man bauen möchte, und dann das rückwärts aufrollen?
Speaker 4:Ja, genau, weil da kommt ein kleines Gesetz, das eigentlich kein naturwissenschaftliches Gesetz ist, aber trotzdem ein Gesetz ist. Ich glaube, wir hatten das bei einem der anderen Podcasts, wo ich schon mal bei euch zu Gastarchitektur und rechnet dann rückwärts wie muss denn eigentlich meine Teamstruktur sein, damit ich, wie sie damals war, als die Software entstanden ist Und das kann ich mir wiederum nach vorne gedacht zunutze machen? diese Archäologie Und ich sehe schon, der Human wird ganz ungeduldig auf seinem Sessel wird mir jetzt gleich Paroli bieten, freue ich mich schon drauf Und kann dann auf der Art und Weise dann wirklich auch die Organisation planen, die ich dafür brauche, damit am Ende die Software rauskommt oder die Software-Richtung von der Architektur herauskommt, die ich benötige, und zwar aufgrund meiner Business-Voraussetzungen, die ich habe. Also, ich denke da ganz simpel in drei Schritten. Der erste Schritt ist erstmal gucken, was brauche ich Business-seitig.
Speaker 4:Ich hatte es gerade eingangs gesagt okay, die Plattform, die ich habe, die ist in Deutschland groß geworden. Ich muss ich gucken, wie baue ich die Plattform so um, dass sie diesen Businessgrund und das ist jetzt nur ein simpler Businessgrund dass sie darauf einzahlen kann? Und dann gucke ich, wie muss denn die Softwarearchitektur, wie muss die Plattform aufgebaut sein, damit sie diese Businesskriterien erfüllt? Und erst dann überlege ich, wenn ich jetzt diese Zielarchitektur habe, für die ich mich entschieden habe, wie müssen dann meine Teams strukturiert sein? Also bestes Beispiel baue ich jetzt Monolithen oder baue ich einen Microservice? Bei Microservice weiß ich, wenn ich mehrere Microservices habe, die genügend groß sind, dann kann es hilfreich sein, dass ich da mehrere Teams dafür brauche, weil ein Team macht den Microservice XYZ, der für die Suche in der Plattform ist, das andere Team macht das Thema User-Registrierung und so weiter und so fort, und dann habe ich entsprechend mehrere Teams, die ich vielleicht dafür benötige, um das Produkt aufzubauen oder weiterzutreiben.
Speaker 5:Also, ich glaube, ich wurde unter falschen Tatsachen in diesen Podcast eingeladen.
Speaker 3:Wie.
Speaker 5:Denn so wie man mir das nahe getragen hat, war ja sozusagen die Frage ich habe jetzt mal angenommen, im Kontext einer Veränderung, über was sollte man zuerst reden? Über die Organisation und über Technologie. Und ich stelle gerade fest, in diesem Podcast hier ich glaube, ich würde ein paar Begrifflichkeiten anpassen. Also die Frage wäre, über was sollte man zuerst nachdenken? Prozesse und Strukturen oder Personal? Weil ich bin komplett bei dir, was soll ich denn da parolibinden? Also hättest du gesagt, man sollte Technologie zuerst sich angucken und dann Strukturen und Prozesse. Hätte ich gesagt, stopp, wait a minute, das macht keinen Sinn. Aber natürlich, ich würde ja so weit gehen, das ist ja wahr, unabhängig von irgendwelchen Softwareentwicklungen.
Speaker 5:Die Frage ist ja also Conways Law, law würde man ja so weit gehen und den Satz formulieren müssen, dass die eigene Struktur muss eine gleiche Komplexität aufweisen wie das Problemsystem, was man lösen will. Das bedeutet ja auch, die Microservice-Architektur ist ja eine Architekturentscheidung bezogen auf das Problemsystem, was man im Markt identifiziert hat, und dementsprechend würde man ja die Strukturen, die hinter der Microsoft-Architektur kommen, dementsprechend aufbauen, sozusagen, dass man eine konsequente Architektur hat, auch aus der Organisationslogik. Da wäre ich halt so weit und würde ja sagen, technologie ist da ein Element, aber am Ende reden wir über Strukturen, die über.
Speaker 4:Technologie laufen Ja nicht ganz so. Also, ich meine, die Technologie ist dann halt der, die gibt den Rhythmus sozusagen vor. Also wenn du das als Motor betrachtest und je nachdem, wie komplex du deine Technologie aufbaust, ob du einen Monolithen hast, wo du sagst, okay, du hast eine Codebase, ein starres System, oder du teilst es stärker auf, oder du hast ein Plattform-Team, das sag ich mal, die Plattform sozusagen betreibt und anderen Teams zur Verfügung stellt, und ich jetzt an Data Integration Platforms und so weiter denke, dann sind ja diese Überlegungen, die man macht, im Kontext der Systemarchitektur, die haben Einfluss auf die Art und Weise, wie die Teams geschnitten sind, wie ich die Teams brauche. Und was wir halt häufig sehen im Markt und auch bei Unternehmen, ist, dass du halt auf bestimmten Management-Ebenen hast du natürlich Personen, die jetzt nicht so vertraut mit der Softwareentwicklung sind. Ist ja logisch, weil es sind Manager, die verfolgen bestimmte andere Ziele, die kümmern sich eher um die Business-Ziele.
Speaker 4:Also, welche Capabilities muss meine Softwareplattform zur Verfügung stellen, damit ich in der Lage bin, jetzt in den nächsten zwölf Monaten in fünf Ländern aktiv zu sein, und ähnliches. Und da wird dann häufig auf dem Reißbrett von Teamstrukturen gedacht, ohne die Software-Architektur zu berücksichtigen. Und das ist der Grund, warum ich sage, dass ein praktikableres Vorgehen ist, zunächst mal im Rahmen der Software-Architektur und der Zielarchitektur zu denken, und wenn ich das habe, dann kann ich hingehen und kann meine Teamstruktur dafür aufbauen. Ich setze noch eins drauf Ich will ja auch keine starre Softwarearchitektur haben, also das, was man früher hatte mit Enterprise-Architektur. Ich definiere mal so die Architektur, wie sie die nächsten fünf Jahre laufen soll. Ich meine, jeder, der sich mit Agilität und Dynamik beschäftigt, weiß, dass das nicht haltbar ist. Das heißt, wir haben auch das Thema evolutionäre Softwarearchitektur. Also, architektur ist veränderlich, und daraus folgt zwingend, dass dann auch die Teamstruktur dynamisch und veränderlich sein muss, weil sie sich den Gegebenheiten der Software, die gezogen wird von den Business-Kriterien und der Dynamik des Marktes entsprechend anpassen muss, und das ist leider noch nicht in allen Unternehmen angekommen.
Speaker 3:Ich würde das vielleicht noch ergänzen, bevor ich dann in ein Aber kommen werde. Es gibt ein großartiges Buch von Matthew Skelton und Manuel Pais, glaube ich, spricht man ihm aus Team Topologies heißt das also quasi die Landkarte der Teams, wie stehen die zueinander? Und darin machen sie im Prinzip eigentlich eine ähnliche Argumentation auf, dass sie sagen, es gibt bestimmte Anforderungen, die Funktionalitäten an ihre Softwarearchitektur stellen, und entsprechend muss man das auch berücksichtigen in der Teamstruktur, damit die das überhaupt abbilden können, und machen dazu dann aber ja noch weitere Argumente auf und sagen zum Beispiel wir wollen ja auch als Unternehmen sicherstellen, dass wir Software schnell liefern können, dass wir die mit einer gewissen Qualität liefern können, also nicht nur, dass wir es überhaupt machen können, und sagen, als Organisationsziel sollten wir immer haben ein Fast Flow, also quasi dann zu gucken, wie schneiden wir die Teams auch, so, dass sie nicht überlastet sind oder sich zu viele Gedanken machen, und daraus ergeben sich dann aber vielleicht auch nochmal Subteams, die in bestimmten Beziehungen zueinander stehen. Das ist, glaube ich, das, was du meintest, dass man das dynamisch anpassen kann.
Speaker 3:Wie das läuft So. Und jetzt kommt mein großes Aber, weil die erste Frage, die sich daraus stellt ich glaube, ich habe einfach Anschlussfragen heute Nicht so sehr Einwände, sondern eher so? wie machen wir das? Frage Nummer eins wäre für mich können wir das von vornherein wissen, was die Architektur oder was die Softwareveranforderung an die Organisation stellt? Wer kann das überhaupt überblicken?
Speaker 2:Hey Patrick, hier Patrick Breitenbach von 1789 Consulting. Sorry, dass ich diesen Podcast hier unterbreche, aber ich wollte nur sagen, wenn du diesen Podcast wirklich, wirklich liebst, dann wirst du ganz sicher auf Spotify oder Apple Podcast eine Fünf-Sterne-Bewertung hinterlassen und das Ganze noch mit einem positiven Kommentar garnieren. Und wenn du dich dafür interessierst, was wir als Unternehmensberatung so machen, dann schau doch mal auf unserer Website vorbei, www.1789consultingde. Oder spreche uns direkt bei LinkedIn an. Wir freuen uns, und jetzt geht's weiter mit den Erkenntnissen.
Speaker 4:Viel Spaß das kollaborativ zusammen zu machen. Also, wenn wir in solche Situationen reingerufen werden, egal, was der Auslöser ist, ob das jetzt Modernisierung ist, ob das die Entwicklung einer komplett neuen Plattform ist dann gehen wir zunächst mal her und gucken uns die sogenannten Business-Treiber an. Das heißt, wir machen einen kollaborativen Workshop mit dem Kunden zusammen und gucken mal in einem halben Tag drauf was sind denn die Business-Bewegründe, dass du jetzt in eine bestimmte Richtung gehen möchtest? Weil das versuchen wir explizit zu greifen und auch untereinander gegeneinander zu gewichten, weil du hast so das typische Problem in Organisationen Leiter XYZ sagt, das ist aber wichtig. Leiter ABC sagt ja, aber was anderes ist viel wichtiger. Das heißt, du hast hier Ziele, die unter Umständen gegensätzlich sind, die in Konkurrenz zueinander laufen, und das sortieren wir nach Wichtigkeit oder nach Kritikalität entsprechend ein.
Speaker 4:Und dann gehen wir über bestimmte Zwischenschritte, gehen wir in Richtung Architekturszenarien, dass man halt überlegt was gibt es denn da so für Architekturen? Also beispielsweise macht man das rein in der Microsoft Welt, macht man rein Open Source, geht man in der Cloud, macht man Hybrid und und und Also das hängt jetzt so von Software-Thema ab. Deswegen bin ich da jetzt eher auf generischer Beschreibung unterwegs, und dann, wenn ich meine Architekturen gegeneinander verglichen habe, gegen die Business-Kriterien, weiß ich grob auch noch weitere Aspekte habe. Du hast es gerade genannt entlang von Team Topologies die Mental Load und damit quasi in Folge die Mental Health. Was geht in so ein Entwicklergehirn eigentlich rein? Was kann ich denn überblicken, wenn man jetzt ganz zurückguckt? nach Extreme Programming hat damals 1995 Collective Code Ownership propagiert. Das heißt, jeder kennt sich überall im System gleichmäßig aus, sodass man überall eingreifen kann.
Speaker 4:Bei der heutigen Komplexität der Software-Plattform ist das nicht immer gewährleistet. Deswegen macht Team Topologies beispielsweise diese vier oder fünf unterschiedlichen Teamtypen, nach denen organisiert wird. Es gibt noch weitere Systematiken, wenn du bei der Cloud Native Computing Foundation beispielsweise guckst. Da gibt es nicht nur die Architektur-Patterns und technischen Patterns, es gibt auch Organisations-Patterns, wie bestimmte Dinge aufgebaut werden sollten, beispielsweise Pioneers-Team und ähnliches. Es gibt von Google das SRE-Team, das in Team-Topologies eher so dem Plattform-Team entspricht.
Speaker 4:Also da gibt es unterschiedliche Vokabulare, die aber auf ähnliche Teamtypen sozusagen abzielen, und all das dient dazu, diese Aspekte gut miteinander aufzubauen, um am Ende sicherzustellen, dass ich eine gute Software baue und in einen guten Flow komme, also nicht nur die Lieferfähigkeit gewährleiste, sondern tatsächlich auch ein Stück Software aufbaue, was die Business Needs erfüllt, weil das ist, glaube ich, auch ganz wichtig zu betonen.
Speaker 4:Das machen wir ja nicht aus Spaß an der Freude Softwareentwicklung, sondern Unternehmen und Organisationen wollen damit typischerweise Geld verdienen, margen erhöhen im Wettbewerbsdruck oder jetzt 2025, wir haben erhöhten Druck durch AI, eine Weltwirtschaft, die sich einigermaßen erholt, aber Deutschland nicht so gut, und so weiter und so fort. Nun muss man halt gucken, wie komme ich jetzt an die Pole Position, und das muss man dann übersetzen in die Business Needs, die ich brauche, um dann auf der Basis dann auch die passende Software bauen zu können. Und deswegen, glaube ich, bringt es nichts, umgekehrt zu denken. Das ist so ein klassischer Weg. Ja, ich habe mal Aufbau, ablauf, organisation, ich gucke halt, wie ich meine Teams strukturiere, und dann gib ihm und jetzt programmiert mal. Das ist halt nicht so von Erfolg gegründet, glaube ich.
Speaker 5:Aber ist das wirklich so eine Differenz? Also, es gibt ja immer eine Aufbauorganisation das ist unabhängig von der.
Speaker 5:Man kann ja Organisation in Prozessen denken, so eine Prozessorganisation. Am Ende sind ja Leute immer noch aufbauorganisatorisch verortet. Ich kenne ja dieses Konzept auch sehr gut, und ich verstehe auch den Reiz da drin. Aber würdest du wirklich beschreiben, das ist so eine prinzipielle Herausforderung? Weil ich drehe mal die Situation und würde sagen, ich kenne ganz viele Projekte, wo das Thema also klassischerweise eher so große ERP-Einführungen oder CRM-Einführungen, und man kommt mit der Technologie und ist da sehr so, wir haben unsere Standardprozesse, die müssen jetzt umgesetzt werden. Und man erlebt ja eher in solchen Situationen, dass man eher sagen würde naja, ein Blick auf die Organisation und den Strukturen wäre ja auch sinnvoll bei dieser Form von Technologie.
Speaker 4:Das auf jeden Fall. Aber die Frage ist doch, wenn du in solche Projekte reinguckst, die dauern relativ lange, kosten viel Geld und sind dann am Ende nicht von Erfolg gekrönt. Projektereien, die dauern relativ lange, kosten viel Geld und sind dann am Ende nicht von Erfolg gekrönt, oftmals, weil sie einfach zu langsam vonstatten gehen. Also mit anderen Worten esilen Teams, agile Teams jetzt mal salopp gesagt, war ja immer das Credo autonome Teams, in Anführungszeichen. Der Sinn hinter dieser Autonomie ist nicht, dass jeder machen darf, was er will, darum geht es nicht, sondern dass, wenn ich meine Ziele kenne, dass ich in der Lage bin, schnell Entscheidungen zu treffen, mein Produkt nach vorne zu entwickeln, und ERP-Einführung ist ein super, super Beispiel. Das sind dann immer so, diese Mehrjahresprojekte, ah, jetzt steht das ganze Unternehmen still. Wir können jetzt erstmal uns nicht mit AI beschäftigen, weil wir führen jetzt erstmal zwei Jahre lang ein ERP-System ein, wo ich dann sage ja, viel Spaß. Ein AI-Jahr sind vier Wochen in der realen Welt. Jetzt übertrag das mal auf zwei echte Jahre, dann weißt du, wie viele Jahrhunderte du verpasst hast verpasst hast.
Speaker 5:Aber sag mal also, die Herausforderung bei dezentralerer Struktur, wie zum Beispiel bei Team Topologies, ist ja das Thema Alignment. Also, je mehr du ja dezentralisierst, desto schwieriger ist es, ein Alignment sich darzustellen, und zwar und das ist vielleicht so meine Kernkritik. also ich muss das mal ein bisschen ausholen. Ich glaube, die Art, wie wir Organisationen betrachten, ist immer eine ingenieurshafte, zweckrationale Logik. Wir können Organisationen, wenn wir sie auf Papier beschreiben wollen, ja nicht irrational beschreiben. Unsere Denkformen zwingen uns dazu zu sagen, was ist denn das Optimale, optimale? Und deswegen glaube ich, ist jetzt an dem Konzept prinzipiell jetzt keine Herausforderung.
Speaker 5:Allerdings ist es ja so, du hast es vorhin gesagt, organisationen sind widersprüchlich. Also das ist die Kernlogik von Organisationen ist ja, dass eben Ziele doch in Konflikt sind, dinge unterschiedlich priorisiert werden. Mikropolitik ist ein Thema, ich hatte einen schlechten Tag. Also all diese Dinge, interaktionen finden in der Organisation statt und so weiter führen ja dazu, dass auch wenn wir eine zweckrationale Fantasie haben, die so sein muss, aber die Alltag der Organisation ja davon geprägt ist, okay, wie schaffen wir das, diese ganzen Wust irgendwie in eine Richtung zu bringen? Und das funktioniert ja nicht zweckrational. Und je mehr wir in die Dezentralität plädieren, desto schwieriger wird ja genau dieses Thema.
Speaker 3:Kann ich ganz kurz noch einhaken, weil ich nicht sicher bin, ob alle Leute auf dem gleichen Stand sind, die hier zuhören, quasi. Das weiß ich auch nicht.
Speaker 3:Deswegen würde ich jetzt einmal ganz, ganz knapp versuchen zu erklären, zumindest dieses Team-Topology Konzept zu erklären. Also der Gedanke ist, software wird immer komplexer. Deswegen kann man das nicht mehr monolithisch quasi abbilden und sagen, alles kommt aus einer Hand, sondern wir brauchen, wie du vorher gesagt hast, sogenannte Microservices oder eben verschiedene Anwendungsteile, die aber selbstständig entwickelt werden können und dann wieder zusammengeführt werden in was auch immer Endanwendung das dann ist. Und der Gedanke von Team Topologies ist quasi es gibt sogenannte Stream-Aligned Teams, das sind, ich sag mal, das Hauptteam sozusagen, oder die verschiedenen Hauptteams, die kümmern sich um eine Sache, die haben die Verantwortung für diese Sache, die decken auch so viel, wie sie können, selbstständig ab, aber eben mit der Begrenzung, dass man sagt, maximal irgendwie zwölf Leute, weil sonst wird es zu verwirrend da drin.
Speaker 3:Und wenn es bestimmte Dinge gibt, die super kompliziertes Expertenwissen brauchen, lass uns das auslagern in ein Experten-Team, oder die nennen das ein Complicated Subsystem-Team, die sich dann quasi um diesen Teil kümmern. Oder lass uns eine Komponente auslagern, wo man sagt, da kümmern sich Leute drum. Und dann gibt es Plattform-Teams, die Sachen für ganz viele Teams bereitstellen, auf denen, die dann wieder arbeiten können. Und dann gibt es Enabling-Teams, die Fähigkeiten vermitteln und unterstützen, und im Prinzip ist das quasi dann. Es gibt. Die Verantwortung ist sozusagen so eine Pull-Verantwortung, also aus der quasi aus diesem Need heraus, wir verantworten dieses Stück, und das Wissen wird aus der Organisation sozusagen über die Peripherie rausgezogen. Das ist quasi der Gedanke, und deswegen spricht Human jetzt quasi von der dezentralen Organisation, weil es eben viele Teams gibt, die eigenverantwortlich ihre Sachen da beschreiben. Und dann gibt es jetzt eben dieses Alignment versus Autonomie Problem, und da könnt ihr jetzt wieder einsteigen.
Speaker 4:Ja, also danke nochmal für die Erläuterung. Ich würde da nochmal als Zwischenruf einwerfen wollen Ich glaube, in der AI-Zeit müsste das Buch Team Topologies vielleicht auch nochmal neu geschrieben werden, weil AI das Thema Geschwindigkeit auf eine ganz andere Art und Weise nochmal deutlich beschleunigt. Vielleicht kommen wir noch drauf oder als Cliffhanger für eine andere Podcast-Folge sozusagen Zu der Frage dezentral, zentral, selbst wenn jetzt diese Teams so aufgeteilt sind. Am Ende wird ja ein Produkt entwickelt, also für den Endanwender. Das heißt, du hast gemeinsame Ziele, die dafür sorgen und sicherstellen, dass die Ziele bekannt sind, dass die Ziele verfolgt werden und dass trotz der Autonomie, der Unabhängigkeit auf diese Ziele eingezahlt wird. Also da gibt es auch einen ganz, ganz alten Comic vom Henrik Knieberg Da ging es um das Spotify-Modell, was ja auch missbräuchlich eingesetzt worden ist der damals auch schon sehr früh das Thema Autonomie und Alignment in so einem Vier-Felder-Modell dargestellt hatte, was dazu eigentlich notwendig ist.
Speaker 4:Ich gehe jetzt einfach mal davon aus, wir haben ein Produkt zu entwickeln, und die Frage ist doch also wenn das Produkt hinreichend komplex ist ich rede jetzt nicht von einem Produkt, wo zwei Leute daran arbeiten, sondern wo typischerweise mehrere Teams daran arbeiten müssen, weil die Komplexität einfach so groß ist und das Produkt so umfangreich ist dann glaube ich ganz fest daran, dass es hilfreich ist, sich von dem Thema Systemarchitektur, softwarearchitektur zu nähern und dann zu überlegen wie muss der Teamschnitt sein, damit am Ende das, was du gerade beschrieben hast, mary, mit den unterschiedlichen Teamtypen, worauf zahlt das ein Auf Fast Flow, damit am Ende das auch gewährleistet werden kann Und nicht umgekehrt, weil am Ende die klassische Organisationsstruktur uns da vielleicht auch im Weg steht, um eine gute Software zu bauen.
Speaker 3:Was ich an dem Thema faszinierend finde auch so, wie du das beschreibst, braucht eine gewisse Flexibilität in der Organisationsstruktur. Auch quasi Art, wie die Teams strukturiert sind, gibt es bereits eine Priorisierung, also weil es gibt Teams, die bestimmte Dinge bearbeiten, und andere Dinge, für die gibt es kein Team. Damit werden die nicht bearbeitet. Und ich finde, das ist ein signifikanter Gedanke irgendwie. Das muss man sich irgendwie vor Augen halten, weil das ja auch bedeutet, also das überhaupt, wie die Organisation zugeschnitten wird, ist überhaupt das Strukturierungsmerkmal für was passiert überhaupt Bedeutet. Aber auch, man muss da eigentlich immer ein Auge drauf haben und das ja auch konstant anpassen.
Speaker 4:Genau.
Speaker 3:Und ich glaube, das ist etwas, was in Organisationen ja notorisch schwerfällt. quasi Die rationale Anpassung an Gegebenheiten ist nicht unbedingt immer das Nummer eins Kriterium. Und genauso glaube ich, häufig gibt es ja bereits Dinge, die über Zeit gewachsen sind.
Speaker 2:Auch Software wächst ja über.
Speaker 3:Zeit. Also ich stelle mir jetzt einfach ein Startup vor, das macht eine App, und die sind fünf Leute, und dann machen die erst mal, und man hat ja nicht immer quasi den Luxus und die Ressourcen zu sagen okay, großer Wurf, unser digitales Ding soll jetzt international werden wie machen wir das am besten?
Speaker 3:Also, es sind jetzt zwei Sachen. Es ist einmal quasi so wie ändern wir denn diese Struktur, wenn sie einmal schon mal besteht? ist sie wirklich so flexibel? Und das andere ist wie ändern wir denn überhaupt eine Struktur, die gewachsen ist, um dann zu sagen ach so, und jetzt müssen wir aber nochmal umdenken und dieses Konstrukt logisch umbauen.
Speaker 4:Also ich glaube, was da hilfreich ist du hast es schon implizit gesagt nämlich das implizite explizit machen und das regelmäßig tun. Also genauso wie ich nicht überrascht sein darf, wenn ich jetzt nicht in Qualität in meine Software investiere, dass quasi dieses berühmte Technical Debt immer weiter anwächst und ich dann irgendwann Qualitätsprobleme gebe, oh, überraschung, überraschung. Wir haben jetzt zwei Jahre lang unser Produkt aufgebaut. Wir sind ein Startup, wir haben halt nur Features gebaut. Ja, dann ist es halt so, dass, wenn man mal drauf guckt, dannbenheiten mit dem Wissen, was wir haben, und der Zielsetzung, die wir haben, kommen wir jetzt gerade nicht weiter und dann einfach mal frei diskutiert, organisationsstruktur zu bauen, nur weil die Organisation gewohnt ist, ihre Strukturen jetzt beispielsweise entlang von Abteilungen zu bauen Marketing, vertrieb, administration, product Marketing und und und unterschiedlichen Abteilungen sich nicht grün sind, sondern wirklich zu gucken.
Speaker 4:Okay, ich habe jetzt einen bestimmten Business Need. Dementsprechend schaue ich wie kann ich diesen Business Need softwareseitig herführen, also architektonisch und von der Implementierung, und dann daraus zu Schluss folgern wie muss ich meine Teams aufbauen? und das bedeutet dann als Konsequenz was muss ich jetzt in meiner Organisationseinheit, wenn ich jetzt ein klassisches Unternehmen bin, das hat dann halt irgendwie eine IT-Abteilung mit 60, 70 Leuten wie muss ich da die Teams entsprechend strukturieren und aufbauen, und dann wird es erst mal so gemacht, und dann gucke ich vielleicht ein halbes Jahr später drauf passt die Architektur? noch Muss ich vielleicht die Architektur abändern, weil die Business-Gegebenheiten haben sich geändert.
Speaker 4:Also muss ich diese Teams wieder neu strukturieren, neu zusammenführen. Der kennt das bestimmt auch. Früher gab es im agilen Umfeld den Dynamic Teams, approach und Ähnliches. Das geht alles in diese Richtung hinein. Jetzt nicht so sehr, dass man fluide Teams jetzt irgendwie propagiert, weil Teamaufbau kommt auch mit einem Preis einher, also mit impliziten Kosten im Rahmen des Changes, im Rahmen des Changes. Aber am Ende geht es darum, ich muss gucken, was baue ich da für ein Software-System? Weil, wenn ich weiß oder wenn ich jetzt mal annehme, als Hypothese, dass Conway's Law gültig ist, dann weiß ich, dass meine Organisationsstruktur Auswirkungen auf das Software-System hat. Also kann ich zurückrechnen und sagen, wenn ich weiß, wie mein Software-System sein muss, weiß ich im umgekehrten Schluss auch, wie die Organisationsstruktur dafür auch aussehen muss.
Speaker 5:Also, das mit Conway's Law ist natürlich sehr zugänglich. Ich bin bei einer Sache so noch nicht ganz dabei, eine Sache, die du auch gesagt hast, Mary, und zwar, dass Organisationen nicht immer rational handeln. Und ich würde sagen, das stimmt nur aus der Beobachterposition heraus. Womit ich dachte, wofür wir diskutieren dieses, was kommt? zuerst Technologie, Organisation muss man aus der systemtheoretischen Perspektive sagen, das ist eine Scheinfrage.
Speaker 5:Diese Frage stellt sich gar nicht in Organisationen. Organisationen sind ja autopolitisch, sie sind selbstreferenziell, und damit sind sie auch gar keine lineare Entwicklung, sondern sie entwickeln sich ja immer erstmal anhand ihrer inneren Operation. und dann stellt sich ja also bei der Frage um Veränderung ist ja, wie die Organisation ist und wohin sie zweckrational gestalten konnte, ist ja die Kernfrage, ist, wie kann man ein Thema, etwas Neues übersetzen in die Logik der Organisation, dass sie sie überhaupt operativ verwerten kann? Wir wissen ja, Organisationen sind ja nichts anderes als die Strukturierung von Entscheidungen. So funktioniert Organisationen, Also die Entscheidung. wir wollen unsere Organisation von einer funktionalen Aufbauorganisation hin zu einer prozessorientierten, mehr ablauforientierteren Logik bringen, Und deswegen verstehe ich also, bei dem Team Topology ist es so, ich verstehe das auch so kognitiv und so weiter. Aber ich glaube, was oft die Herausforderung sein wird, ist ja, wie schaffe ich es, diese Logik operativ für eine Organisation anzuwenden, Weil ich glaube, die meisten Ideen scheitern genau an dieses. okay, wir können jetzt damit arbeiten.
Speaker 4:Ja also was einfach mal so aus dem Nähkästchen geplaudert, warum wir auch diese Workshops ganz gerne machen? weil das oftmals die erste Gelegenheit ist in der Organisation, dass mal die einzelnen Abteilungsleiter zusammenkommen und sich nicht über Word-Dokumente austauschen, indem sie ihre jeweiligen lokalen Ziele als Forderungen eingespeist haben, sondern indem sie tatsächlich gezwungen sind, mal in einem Raum zusammenzukommen, ihre Stakes niederzuschreiben und gemeinsam zu priorisieren und am Ende zu einem Ergebnis zu kommen. Das heißt, der Prozessfluss des Workshops ist so angelegt, dass am Ende tatsächlich auch eine Entscheidung, eine gemeinsame Entscheidung herauskommt, Und selbst wenn es Uneinigkeit gibt, ist auch völlig in Ordnung, weil die es dann wenigstens explizit dokumentiert. Das ist so der eine Aspekt, den es bräuchte, Und das andere, was es aus meiner Sicht auch immer dabei braucht, sind die passenden Personen mit Macht, also mit Entscheidungsmacht im Unternehmen, die in der Lage sind, dann auch die Entscheidungen in der Organisation oder in dem Teilbereich durchzudrücken.
Speaker 5:Das sind die zwei Komponenten, die es meines Erachtens braucht zu machen, weil das ist das, was ich sozusagen in meiner Praxis erlebe. Wir arbeiten ja immer im Zwischenraum zwischen hier ist ein auf dem Papier gute Idee, die muss so sein, also weil ich kann ja keine schlechte Idee auf dem Papier malen, und das sind die Gegebenheiten. Und von mir aus der Chef, der würde gerne das, aber das geht nicht, weil da ist nochmal das da, und die beiden haben mikropolitische Herausforderungen an dem hängen, aber viele Kunden, und wenn der geht, gehen drei Mitarbeiter mit, bla, bla, bla. Also ich glaube, das ist ja dann, wo Realität und Papier aufeinander prallen. Und dann ist die Frage wie muss einen Weg nach vorne gestalten, schauen, wie insbesondere auch auf dieser Management-Ebene gemeinsam über das Design in so einem Meeting dafür zu sorgen, dass es dann halt heißt okay, der macht aber nicht mit, der zieht nicht mit.
Speaker 4:Und da sage ich halt, da braucht es halt einen Obermufti und wenn es der CEO ist, der irgendwie ein paar Millionen im Jahr verdient, dann soll er jetzt mal für sein Schmerzensgeld arbeiten und halt jetzt mal eine Entscheidung treffen. Und die Entscheidung ist dann aber nicht die Personalentscheidung, sondern die Entscheidung ist die Systementscheidung. In diese Richtung gehen wir, weil dann am Ende entscheidet idealerweise der eine Manager selbst, indem er sagt na gut, da kann ich nicht mitgehen, da gehe ich jetzt.
Speaker 3:Beispielsweise Ich glaube, wir haben erst bisher quasi über den Grundsatz gesprochen, und jetzt kommen wir ja quasi wieder in die Transformationsfrage. Also, ich glaube, auch wir müssen unterscheiden zwischen so wäre es gut, und weil wir ja dann solche Themen haben, wird es auch nicht perfekt dann so sein. Also, wenn wir damals mittendrin sind, gibt es ja immer Abweichungen von dem, was man als Ziel sich mal gesetzt hatte. Ich glaube, da trifft ja dann einfach die Realität Auch die Informalität schlägt ja dann zu. Also weil diese Konzepte, die wir bis jetzt besprochen haben, das sind ja immer Sachen, die sehr auf der formalen Seite der Organisation verortet sind, und quasi Leute setzen sich ja gerne auch über die formalen Themen hinweg oder bauen selber Sachen da drauf, und das ganze Thema Informalität ist in diesen Konzepten ja gar nicht so sehr verarbeitet.
Speaker 4:Kann sie auch nicht, geht gar nicht. genau Das ist ein wichtiger Teil. das kann ich mögen.
Speaker 5:Vielleicht zu dem, was du gesagt hast. Ich glaube, was auch wichtig ist eine neue Informalität lehnt sich da an. Also, es ist ja sozusagen, auch die informale Struktur wird sich ändern. Nur natürlich, als Gestaltungselement können wir ja nur schwer sagen. Also ihr wahrscheinlich auch ja, dann lass mal versuchen, diese Informalität zu erzeugen. Das ist ja nicht möglich.
Speaker 3:Dann macht doch ihr mal total gut. Kollegialität, wie wär's Das funktioniert? nicht Hä, was willst du von mir?
Speaker 4:Ne, so typische Themen. Jetzt gerade bei dynamischer Teamzusammensetzung, die wir oftmals in Unternehmen vorfinden, ist halt, der eine Abteilungsleiter hat so und so viele Mitarbeiter in dem Verantwortungsbereich, der andere so und so viele Mitarbeiter in dem Verantwortungsbereich, weil es funktional getrennt ist, und dann sagt aber plötzlich der Blick auf eine gute Softwarearchitektur nee, nee, nee, nee. Einfaches Beispiel. Dann gibt es halt da oft Diskussionen ja, aber der Mitarbeiter, dem gebe ich jetzt extra Zeit dafür, dass der in der anderen Abteilung mitspielen darf. Das ist totaler Quatsch. Also, er ist auch nicht mehr modern, sozusagen seine Struktur so aufzubauen. Und das ist halt genau der Punkt, auf den ich hinaus will.
Speaker 4:Wenn die Art und Weise, wie du eine gute Software baust, dir dann am Ende zeigt, naja, eine Gesamt-Team-Struktur wäre vielleicht besser, ja, dann ist das halt so, und dann kannst du dich immer noch dafür entscheiden, das anders zu lassen, dann hast du aber Schmerzen auf dem Weg dahin worden sind, die Kommunikation nachgebildet haben, so typischerweise Schaufel-PC. In der Nacht wurde vom alten ERP-System, wurde dann irgendwie Daten rübergeworfen über einen sogenannten Schaufel-PC, der auch nur von der einen Abteilung angefasst werden darf, weil die beiden Abteilungsleiter nicht miteinander gut gesprochen haben. Solche Beispiele Und sowas gibt es mit Sicherheit auch heute noch irgendwo im typisch deutschen Mittelstand, von oben nach unten, an jeder Ecke, und das ist halt einfach nicht wertschöpfend.
Speaker 3:Mit Sicherheit. Ich frage mich da manchmal wirklich ich finde, auch dieses Thema das kommt zurzeit auch sehr häufig vor. Wir haben da mit Stefan Schulz drüber geredet, mit Judith Muster und diversen anderen, jetzt ihr gerade mit Klaus Dörre Dieses Thema werden Führungskräfte in ihrer Rolle als Führungskraft zur Verantwortung gezogen? Ich finde das sehr, sehr spannend, auch aktuell, quasi diese gerade auch in dieser ganzen Debatte mit Leute sollen länger arbeiten, also zwei Stunden mehr die Woche und später in Rente gehen und so weiter. Wir müssen jetzt alle hier unsere Verantwortung tragen, und dann hat man manchmal so Sachen, wo man denkt, wer hält die jetzt dafür verantwortlich? dass es eigentlich quasi im Unternehmenskontext Quatsch ist, was hier gerade passiert, und dann hat man so diese Befindlichkeiten gegeben.
Speaker 3:Ich glaube, darüber sprechen wir auch häufig. Ich würde gerne einen draufsetzen und quasi eine Frage formulieren für eine Extrasituation. Wir haben jetzt vermehrt in Unternehmen die Situation, dass der Digitalisierungsbedarf so groß ist, dass die IT-Abteilungen sagen, das können wir nicht leisten, das ist nicht möglich, und auch, dass man sagt naja, also dafür jetzt überall noch eine Beratung reinholen. Das wird auch ganz schön happig. Wir müssen also und da spielt uns ja AI jetzt in die Karten Leute enablen, dass sie selbst digitale Lösungen machen können, und dann hat man sowas, das nennt sich Citizen Developer.
Speaker 4:Ja, Low-Code und so.
Speaker 3:Genau also, wo Menschen ohne Programmierungserfahrung auf No-Code oder Low-Code-Plattformen, ohne selbst programmieren zu müssen, so Drag-and-Drop-Sachen selbst zum Beispiel Applikationen bauen können Und das passiert aber jetzt überall in der Organisation theoretisch möglich. Ich glaube, auch das ist ein bisschen leichter gesagt als getan. Also, man stößt da, glaube ich, sehr schnell an seine Grenzen quasi, was so eine Plattform dann tatsächlich irgendwie abbilden kann, durchaus, und die kennen wir auch sehr erfolgreiche Beispiele, wo Leute sich dann reingefuchst haben, ihr Herzblut reingesteckt haben, was gebaut haben, und diese ich sag mal, wie so kleine Pilze, die kommen jetzt halt irgendwo raus, wo der Nährboden gut genug war, und das ist jetzt irgendwie einfach da. Wie verarbeiten wir jetzt sowas in der Organisation? Weil das ist ja nicht in der regulären Organisation, das ist auch nicht in der reguluren ITler mehr bezahlen, sondern der Sachbearbeiter aus Abteilung XYZ.
Speaker 4:Der kann jetzt einfach mit Drag Drop sich die 80 Prozent war ja immer so ein Thema selber designen. Der kann auch gut mit Excel Ja genau kann auch gut mit VBA und so weiter ist ja das klassische Thema. Ist ja programmiert, oder hier diese Windows-Formular Geschichten, auch von vor 20 Jahren. Jetzt merke ich gerade, wie alt ich bin.
Speaker 5:Wir alle sind alt außer. Harry.
Speaker 4:Genau. Dazu kann man einfach sagen AI macht diese Branche kaputt, Ich wollte gerade ein Hot-Take raushauen. Aber ist so. AI wird Code kaputt machen.
Speaker 5:AI wird Code kaputt machen.
Speaker 4:Nee, das glaube ich jetzt nicht, aber so ungefähr, weil das ist ja die große spannende Frage. Jeder will immer den Senior-Developer haben. Aber wie wird ein Senior-Developer zum Senior? durch viel Erfahrung.
Speaker 5:Wie er alt wird.
Speaker 4:Ja, genau Ja genau, und wenn die AI sozusagen die Arbeit der Juniors oder der etwas Midterm, also bis in die Midterms hineinreicht, dann hat der Mensch ja gar keine Entwicklungsmöglichkeiten mehr einerseits, Dann entwickelt sich niemand dadurch, was er machen können muss, um ein Senior zu werden.
Speaker 3:Genau das ist das eine.
Speaker 4:Und wenn man aber jetzt sagt okay, ai kann diese Junior-Geschichten, das ist ja der City, der ist ein Developer, der ja gar nicht programmieren kann. Also ist für mich die logische Gleichung und die logische Folge das wird die Code Plattform kaputt machen. Ja, ich meine, wir derailen mal komplett, aber ich will einen drauflegen, ich will jetzt mal einen drauflegen.
Speaker 5:Ja mach, weil ich lege da noch einen drauf, Und zwar vielleicht ist ja gut, dass Deutschland die Digitalisierung der letzten 20 Jahre verpasst hat. Jetzt können sie auf den AI-Zug aufschwingen und so einen Leapfrog machen.
Speaker 4:Ja voll.
Speaker 5:Fingers crossed.
Speaker 4:Ja, weil es gibt. Jetzt, tatsächlich hat mir mein CTO-Kollege Johann schöne Grüße an dich vorhin auch nochmal erzählt, wir hatten es letzte Woche. Davon gibt es einen AI-UI-Ansatz, also ein System, wo die AI GUIs bedienen kann. Und damit sind wir schon bei Low-Code-Systemen. Was ist ein GUIs? Graphical User Interface, also quasi Benutzeroberflächen von Web-Anwendungen, das, was du gerade reinguckst, genau. Und da kannst du eine AI steuern, weil die kann interpretieren, was passiert denn da? Ich sehe da hier irgendwie drei Screens mit Menschen drauf, und da oben rechts gibt es den Button, da steht Rack drauf. Wenn ich da jetzt draufklicken würde, würde das passieren. Das kann die interpretieren, und die Logik kann man sich zunutze machen, indem man der AI halt Befehle gibt oder sagt, ich will das und das Resultat machen, und dann findet die sich selber in den Anwendungen zurecht. Also, solche Sachen bauen wir zum Beispiel auch hatte ich ja beim letzten Podcast ja auch schon erzählt. Das hat mittlerweile eine Reife erreicht, wo man sagen kann okay, jetzt wird es spannend für genau diese Anwendungsfälle.
Speaker 3:Also, das löst für mich das Citizen Developer Thema so weit, dass sie selber nicht diesen Sprung machen müssen von Drag Drop zu. Doch ich muss doch selber ein bisschen was machen, weil da unterstützt ein AI. Aber das löst ja nicht das Problem, dass trotzdem irgendwo Anwendungen aufploppen.
Speaker 4:Ja, genau Das war der andere Punkt, wo ich noch wir sind ja gerade so ein bisschen derailed- Ja, lass uns gerne derailen.
Speaker 4:Nochmal hier zurück zum Thema Das. Nochmal hier zurück zum Thema Das. Was du meintest, mary, war das Thema, dass halt dezentral überall Sachen aufploppen. Und die Frage, die dahinter steckt, ist wie kann ich jetzt als Unternehmen dann das Ganze wieder auf den richtigen Pfad der Erleuchtung bringen, sozusagen, dass das alles gut läuft in Anführungszeichen unter gewissen Zielsetzungen, und dann immer wieder regelmäßig nachzugucken und ins gemeinsame Gespräch zu gehen? Das heißt, alignment erzeugst du ja durch übergreifenden Austausch und durch übergreifende gemeinsame Zielentwicklung. Da gehen ja alle Frameworks, methoden, egal was du dir anguckst, ob das OKA ist oder andere Dinge, die basieren ja alle darauf, dass man sagt okay, man hat zwar einen gewissen Freiheitsgrad in der Dezentralität, weil das einfach unweigerlich so ist, dass an der Ecke da drüben, weil ich da den Markt bearbeite, irgendwas entsteht, und an der Ecke da drüben, wo ich auch den Markt, aber einen ganz anderen bearbeite, entsteht auch irgendwas. Nachgucken und Gelegenheiten schaffen, an denen man quasi zentral oder zentraler zusammenkommt, sich austauscht und gemeinsame Erkenntnisse schafft und auf der Basis die Erkenntnisse wieder einspielt in das lokale dezentrale System. Und es gibt Techniken. Wenn ich jetzt mal gucke wir bauen ich hatte es ja eingangs gesagt beispielsweise große Datenintegrationsplattformen. Auch da ein typisches Beispiel in der Vergangenheit hat man immer gedacht ja, ich muss dann alles zentralisieren, riesige Datenzentralisierungsprojekte, die nicht geholfen haben. Wir bauen solche Sachen nach dem Data-Mesh-Prinzip.
Speaker 4:Data-mesh bedeutet dezentral-zentral, das heißt, ich habe die Governance, die Guidelines habe ich zentral, ich habe zentral eine Streaming-Architektur, und ich lasse die Datentöpfe. Dezentral lasse ich sie sein, wie sie sind, weil in der Dezentralität gibt es eine Verantwortlichkeit, also quasi Data as a Product sozusagen, und die Zwischenschicht sorgt dafür, dass die Daten harmonisiert werden, dass sie gut zur Verfügung gestellt werden und ähnliches, obwohl ich die dezentralen Datentöpfe habe. Und damit bin ich erstens schneller, weil ich kann das Dezentrale erstmal so sein lassen, wie es ist, und ich habe aber trotzdem einen zentralen Zugriff ermöglicht, sogar noch mit Dingen wie Datenharmonisierung und ähnliche Geschichten, und bin einfach in meiner Time-to-Market deutlich schneller am Markt. Und das sind so Grundprinzipien, die Organisationen fahren müssen. Und da geht dann eben halt auch diese Überlegung mit einher wie muss meine Teamstruktur dafür aussehen, meine Organisationsstruktur?
Speaker 4:Weil gerade bei dem Thema ist es dann wichtig zu gucken, wenn es jetzt heißt, data is a Product, ja, was heißt das denn für die einzelnen Betreiber der einzelnen ERP-Systeme oder was auch immer? Dann muss ich natürlich gucken, wie komme ich da in einen guten Change entsprechend rein? Aber am Ende gucke ich, und da komme ich wieder zum Ursprung zurück. Ich gucke auf meine Systemarchitektur Wie sieht mein System aus? Und auf der Basis organisiere ich mich.
Speaker 3:Das stimmt Yay wo wir uns inspirativ inspirieren lassen. So, Sachen wie zum Beispiel Team Topologies, wo man da ja drüber geht. Ich glaube, der ganze Softwarebereich ist eben ein Bereich, weil da alles man sieht wie die Sachen miteinander zusammenhängen.
Speaker 3:Ich weiß nicht, wie plakativ das ist, aber wenn eine Komponente fehlt, dann gibt es diese Funktion nicht, und dann ist das am Ende nicht da und nicht benutzbar, weil es wurde nicht hergestellt, sozusagen. Und ich glaube, dieser Ansatz zu gucken, quasi wir gehen vom Business-Need über den technologischen Need zur Organisation, ist ja schon was, was wir genauso machen, auch also nicht unbedingt da, ist nicht unbedingt die Technologie immer noch dazwischen, weil es sind halt vielleicht auch andere Sachen, aber man guckt ja schon quasi, was ist der Zweck und was sind die Gegebenheiten, in denen man das machen muss, und was ergeben sich daraus für Anforderungen an die Organisation.
Speaker 3:Und ich finde das immer so schön, weil das Software quasi, weil da weiß ich, da fehlt es aber in anderen Bereichen irgendwie. Da wird so viel verschwinden die Kanten aus ein bisschen, und dann macht jemand da noch ein bisschen mehr, und da noch ein bisschen, und dann weiß man gar nicht so richtig. ist das jetzt richtig oder ist das nicht richtig?
Speaker 5:Und ja, Humanoid, du wolltest einsteigen. Genau, ich wollte sagen, ich würde das ganze Ding aber nicht so linear sehen, sondern ich bin schon dabei.
Speaker 3:Geht ja auch nicht, weil es ist ja alles schon da Ja guck mal, ich glaube, die Logik ist auch vielmehr so.
Speaker 5:Es gibt eine Außenwelt, und die können wir mal einfach wenn wir bei dieser Sprache bleiben wollen als ein Problemsystem betrachten, und die gilt es ja darum, erstmal zu umreißen und zu verstehen, was ist das? Und dann sind wir ja bei Conway's Law und sagen, damit wir dieses Problem gut lösen können, brauchen wir ja nach innen ein System, das dem ganz einfach gesagt gewappnet ist. Baue ich ein minder komplexes System, dann können wir dieser Problemlösung gar nicht gerecht werden.
Speaker 5:Das ist ja wie man über Conway so argumentieren könnte, und dann ist es ja im Grunde ganz viel hin und her. Ich glaube, dann ist es Struktur und Technologie, also die Möglichkeiten, strukturelle Gegebenheiten, und dann glaube ich, dort, wo Organisationen heute nicht gut sind, ist, diesen Diskursraum konsequent zu halten, sachen zu benennen und Abweich. Wir können nicht den idealen Weg gehen, deswegen gehen wir den anderen Weg. Das sind die Trade-offs, das sind die Widersprüche, da ist sozusagen das Scheitern, aber lass uns damit produktiv umgehen. Und ich glaube, hier ist für mich dort, wo Organisationen weil das Lustige ist sogar im Scheitern, sind Organisationen mir zu technokratisch. Also da müsste man wirklich sozusagen, man versucht, das dann irgendwie einzuhegen und so also anders, man versucht, es nicht vernünftig einzuhegen, sondern dann versucht man immer noch zu sagen ja, es ist immer noch optimal. Also man redet sich, vereinfacht gesagt, dinge schön an.
Speaker 4:Also du, hast gerade für mich was ganz Wichtiges gesagt, nämlich Trade-Off. Also am Ende ist jede Entscheidung, die ich treffe, hat einen Trade-Off, und das ist wichtig, diese Trade-Off-Entscheidung, weil man kann das dann im Rahmen von einer gewichteten Entscheidungsmatrix ausrechnen. und trotzdem kann ich mich immer noch gegen die optimale Architektur entscheiden, aus diversen Gründen. Aber dann sind die Gründe explizit, und dann habe ich sie bewusst auf den Tisch gebracht, und ich glaube, das ist das, was in vielen Organisationen mangels Zeit, mangels was auch immer nicht passiert, dass eben genau diese Gründe, diese Trade-offs, nicht explizit und bewusst gemacht werden.
Speaker 5:Ja, 100 Prozent. Und ich finde es mega lustig, weil so wie du über die System oder Softwarearchitektur Thematiken sprichst, genauso arbeiten wir auf der Organisationsstruktur. Das ist tatsächlich identisch. Ich glaube, das Spannende bei Organisationsstrukturen ist aber der Impact von Fehlern ist ein schleichender Impact.
Speaker 3:Das meine ich mit dem quasi bei der Software.
Speaker 5:Da fehlt dann halt ein Stück, und bei den anderen ist es so.
Speaker 3:Ist das jetzt ganz oder gar nicht, oder irgendwo dazwischen?
Speaker 5:Ich glaube, die Fehler in der Organisationsgestaltung oder die Versäumnisse oder die Inkonsistenzen und Inkoherenzen und das Nicht-Beachten von Widersprüchen wird in Organisationen dann im Grunde kaschiert. auf der Arbeitsebene Leute schauen, dass der Laden irgendwie läuft, da werden Überstunden gemacht, dann reden zwei miteinander. irgendwie kriegt man das Gedeichsel 17 Meetings oder Projekt dauert zwei Jahre länger.
Speaker 4:Der klassische Kram? Ja, auf jeden Fall. Ich meine, bei der Argumentationskette, die ich vorhin gebracht habe, da fehlt natürlich ein Teil. Jetzt bist du dann am Ende rausgekommen. Für diese Softwarearchitektur, für diesen Zielzustand unseres Systems in den nächsten sechs bis zwölf Monaten brauchen wir folgende Teamstruktur, Und dann fängt ja die eigentliche Arbeit erst an. Also, da ist ja unter Umständen ein Change-Prozess drin, natürlich, und deswegen meinte ich vorhin, es braucht Leute mit Macht einfach mit dabei, mit Entscheidungsmacht, damit dann gesagt werden kann okay, das ist die neue Teamstruktur.
Speaker 4:Optimalerweise waren alle in der Kette, die Untermacht hatten sozusagen, waren mit beteiligt, haben diese gemeinsame Struktur erarbeitet, weil dann ist es am leichtesten, aber nicht immer hast du die mit dabei. Dann hast du halt Folgefragen im Change im Sinne von okay, jetzt bauen wir die Struktur auf und ähnliches. Und da ist glaube auch nochmal ganz wichtig zu sagen die Zielstruktur, die stellst du auch nicht einfach so hin. Also, wenn ich jetzt beispielsweise an eine Modernisierung von einer Plattform denke, dann ist es oftmals so wir kommen dann rein über diese Workshops, da gibt es sich so eine gewisse Zielarchitektur, und dann ist es oftmals so, als Pattern nimmt man dann sowas wie das Pioneersteam, das heißt, wir bauen erstmal die neue Grundstruktur des Systems auf, und dann holen wir sukzessive Menschen aus den anderen Bestandsteams holen wir entsprechend mit rein. Also, es ist quasi, ist halt ein Team zu groß, dann musst du Zellteilung machen, musst dich untereinander aufteilen, und dann ist irgendwann nach Zeit X gibt es die alten Teams nicht mehr, weil die sind in der neuen Struktur sozusagen iterativ aufgegangen, weil du kannst dir nicht sofort das neue System hinstellen, sondern das neue System ergibt sich und entwickelt sich draus. Und das ist jetzt nur ein Szenario, weil es jetzt ein Szenario bei einer Softwaremodernisierung ist.
Speaker 4:Wenn ich jetzt ein neues Produkt entwickle, ist das Vorgehen ähnlich, weil ich gucke, wie brauche ich die Zielarchitektur? Aber da habe ich vielleicht die Teams noch gar nicht, muss die neuer Markt heiern oder sowas? Also, da muss man auch immer gucken, wie sind die jeweiligen Gegebenheiten. Nur, das Wichtige ist ist, glaube ich, einfach drauf zu schauen. Das, was ich erreichen will, ist ja nicht die Teamstruktur X, weil mit der Teamstruktur X verdiene ich kein Geld, sondern ich will ja das Produkt, den Service, die Software, die ich aufbaue. Das gucke ich doch als erstes an Was bringt den Mehrwert? Und dann schaue ich wie müssen meine Teams gestaltet sein, damit die diesen Mehrwert generieren können oder erstellen können, aufbauen können, damit dann am Ende ein Schuh draus wird. Und das muss ich dynamisch halten und mich nicht in starren Strukturen ergeben.
Speaker 5:Ich hätte nur eine lustige Anmerkung im Sinne von das ist schon verrückt, dass das etwas Kontroverses sein soll. Diese Leute sind so say shit.
Speaker 3:Naja, aber es ist ja schwierig. Es leuchtet ein, aber es ist nicht einfach.
Speaker 5:Die Frage ist halt was ist der schwierige Teil?
Speaker 3:Es ist vor allem kontraintuitiv.
Speaker 4:Genau die Konsequenz.
Speaker 3:Also dieses, wie du sagst, da muss jemand die Entscheidung treffen, oder wie du sagst, huma, da muss man dann auch gucken, woran scheitern wir gerade? no-transcript, und das braucht halt einfach Arbeit. Das ist ein Ding.
Speaker 4:Bevor du deine Frage stellst, wollte ich nochmal einhaken Roman, du hattest vorhin auch diesen informellen Teil auch noch mitgebracht oder mit in die Waagschale geworfen. Ich glaube, auch da ist es wichtig, das zu benennen. Also im Rahmen von solchen Workshops man hat irgendwie die Zielarchitektur vor sich entwickelt, jetzt gemeinsam, wie müssten jetzt die Teams sein, dass man dann auch die Widerstände sichtbar macht, die es vielleicht gibt, je nach Kultur, vielleicht erstmal in einem geschützten Raum, damit man damit arbeiten kann. Also deswegen arbeiten ja die ganzen agilen Leute das, was viele Unternehmen nicht verstanden hatten in der Vergangenheit. Also viele dachten ja, wir machen ein Lab in Berlin auf einen Kicker hin, drei Whiteboards und ganz viele Post-its, und schon sind wir agil.
Speaker 4:Das ist ja nicht der Zweck von agil. Der Zweck von agil ist auch, die Dinge visuell sichtbar zu machen, weil nur, wenn du in der Visualität arbeitest, kannst du auch damit arbeiten. Und wenn ich in der Lage bin, meine Befindlichkeit aufzuschreiben, dann bin ich der Meinung, dann habe ich schon mal den ersten Schritt zur Versachlichung der Befindlichkeit getan und bin einen Schritt aus der Emotionalität raus, und damit sind die Punkte besser bearbeitbar für die Gesamtorganisation. Und da muss ich halt gucken, dass die Raum finden und ich sie einarbeiten kann.
Speaker 3:Ja, das ist natürlich immer schwer zu machen, weil viele Dinge der Informalität sind ja oft nicht ansprechbar.
Speaker 1:Deswegen sind sie ja informell, und das ist dann natürlich auch nochmal eine Herausforderung.
Speaker 4:Aber dafür hat es ja ein Beobachter von außen, wie wir ja wissen.
Speaker 3:Genau da können wir helfen. Exakt, Meine Frage war so ein bisschen, weil du jetzt vorhin nochmal von der Zellteilung und wenn das dann größer wird, gesprochen hast, und vorher hatten wir das Thema Alignment, weil, je mehr Zellen oder Teams es gibt, dann gibt es ja auch immer wieder diese Alignment-Frage, das, was wir am Anfang hatten, autonomie versus Alignment, und Und Nils Pfleging hat mal irgendwann gesagt, eine Organisation kann nur irgendwann so und so groß sein, sonst sagen wir halt Organisation dazu, aber eigentlich ist es eine Stadt oder so, also eigentlich ist es irgendwas anderes mit ganz vielen Organisationen da drin. Das ist dann auch nicht mehr gut zusammenführbar. Gibt es für dich irgendwo so eine Grenze, wo du sagst ab, da sagst du, eigentlich, das macht keinen Sinn, dass wir an der gleichen Software arbeiten, sondern vielleicht sind es einfach zwei. Also sagst du, irgendwo bricht das.
Speaker 4:Ganze. Ja, es gibt ja diese berühmte Grenze mir fällt jetzt leider der Name nicht mehr ein vor lauter Fachbegriffen von 150 Personen, ab denen du in der Lage bist, überhaupt noch mental zu begreifen, wer ist denn die Person, und die zu kennen. Ist das Dunbar's Number? Ja, genau, danke, danke, dunbar's Number. exakt, nachdem ja auch diverse Unternehmen, die man so in diesem Beta-Codex-Network und so weiter als Case-Study findet, hire und so weiter, die sich ja alle quasi teilen, wo dann gesagt wird okay, ab 150 machen wir also in Vor-Corona-Zeiten einen neuen Standort auf, oder wir machen ein neues Subunternehmen.
Speaker 3:Ja, Gore-Tex ist zum Beispiel super bekannt die immer so maximal 150 Leute an einem Standort haben.
Speaker 4:Also grundsätzlich würde ich mir die Frage stellen, warum ich beispielsweise 2000 Personen für ein Softwareprodukt benötige. Das geht jetzt für mich mental nicht unbedingt überein und würde ich sagen okay, ist vielleicht das Produkt zu komplex? Also, bei Word würde ich vielleicht nochmal nachgucken, warum Erzähl das nicht Microsoft, genau, Genau. Und ansonsten ist das halt diese Autonomie, dass man halt sagt naja, okay, dann ist halt ein Team dafür verantwortlich. Nehmen wir jetzt mal als plastisches Beispiel, amazon bei der Website dafür verantwortlich zu zeichnen, wie die Such nicht einfach machen und tun, was sie wollen, sondern Amazon möchte logischerweise Geld damit verdienen. Also muss die Product Discovery jetzt als ganz, ganz einfache Metrik darauf ausgerichtet sein, und dann können die halt tun und lassen, was sie wollen.
Speaker 4:Und wenn sie schlau sind oder das systemisch so angelegt ist, dann lernen sie halt über Product Feedback. Das heißt, sie kriegen Feedback. Ist die Suche jetzt scheiße oder ist sie nicht scheiße? Und wir wissen alle, dass die Suche auf Amazon ziemlich doof ist. Aber Amazon hat es halt vielleicht an ein paar Stellen nicht nötig, weil sie so eine Marktmacht haben, dass sie dann nichts großartig verbessern müssen. Aber am Ende des Tages sind das halt independent Teams, die dann halt entlang von einer groben Metrik arbeiten, und der Rest ist halt Eigenverantwortlichkeit, und damit kriegst du es skaliert.
Speaker 3:Also im Prinzip ist es eine rekursive Struktur, wo du sagst, es gibt Teams, die kümmern sich um Sachen, die haben einen Auftraggeber, dann gibt es eine Gruppe von Auftraggebern, die haben einen Auftraggeber, und so weiter, und da quasi geht das dann so weiter.
Speaker 4:Nein, also bitte keine Menschen rein, weil Mensch ist immer langsam, sondern ich brauche irgendwelche KPI-Met. Ich sage okay, da müsst ihr hin optimieren, also beispielsweise Umsatz oder Profit. Also es muss quasi einen Wertbeitrag liefern, und dann kann das Team, das Subsystem-Team, das für die Suche verantwortlich ist, tun und lassen, was es will, technologien nutzen und lassen, was es will, hauptsache, es hält sich an bestimmte übergreifende Metriken, wie jetzt System. Also technologisch gesprochen wir arbeiten in Self-Contained Systems, wir haben Stateless und so weiter und so fort mit dabei. Das sind dann so technische übergreifende Kriterien oder auch keine Ahnung. Wir müssen natürlich einen Wertbeitrag schaffen, dass wir den Umsatz steigern oder dass wir die Auffindbarkeit von bestimmten Produkten steigern, aber ich würde das nicht als Verkettung von menschengemachten Zielen machen, weil das ist per se immer langsam.
Speaker 3:Ich glaube, mensch muss es gar nicht sein, aber irgendjemand gibt dir jetzt Entität oder irgendwo kommen diese Zahlen her und müssen sozusagen entschieden worden sein, und das würde ich jetzt als eine Auftraggeberstruktur bezeichnen.
Speaker 4:Aber ob das ein Mensch ist oder ob das eine übergeordnete Funktion ist oder ein Kunde Oder eine AI. Unter Vorlage der folgenden Daten und Metriken ist eure neue Zielvorgabe folgendes Lass uns da doch schon mal nochmal rein teasern.
Speaker 3:Du meintest ja vorher, wer weiß, AI wird das sowieso alles über den Haufen werfen.
Speaker 4:Ja, wird es.
Speaker 3:Low.
Speaker 4:Code.
Speaker 3:Noch da ganz davor meintest du mit der Geschwindigkeit. Das wird quasi sowieso so einen Einfluss darauf haben, dass das vielleicht nochmal ganz eine neue Frage aufwirft.
Speaker 4:Also unabhängig davon, ob es jetzt stimmt oder nicht stimmt oder nur zu 50 Prozent stimmt oder so, wenn wir wissen, dass die AI vieles möglich machen kann, dann bedeutet das, Vorgänge, die vorher Tage gedauert haben, dauern vielleicht jetzt nur noch Stunden oder ähnliches. Also ich hatte ja im AI-Podcast von einem konkreten Projekt erzählt. Da haben wir jetzt mittlerweile auch eine ganze Reihe an Metriken. Wo vorher ganz viele Menschen gebraucht worden sind, wird eine bestimmte Menge von einer sechsstelligen Zahl in wenigen Stunden quasi bearbeitet. Das heißt, ich habe einfach eine gewisse Beschleunigung. Das heißt nicht, dass ich auf die Menschen und Mitarbeiter verzichte, sondern dass einfach die Dauer von Problemstellung bis zum Ergebnis, dass die, kürzer wird.
Speaker 4:Deswegen sagt man auch also ich habe vor kurzem auf LinkedIn war ich in der Diskussion drin, da ging es darum, irgendjemand fand das so toll, dass irgendjemand anders gesagt hat Jan, eine KI, die muss auch eine Personalakte kriegen und Zielvereinbarung und so weiter. Wo ich? dann meinte du, es macht überhaupt keinen Sinn, mit den Instrumenten, mit denen wir Menschen vielleicht führen oder nicht führen, eine KI zu führen, weil, bis du die Personalakte aufgeschlagen hast, quasi auch bildlich gesprochen, ist die KI schon fünfmal fertig, weil einfach das Maschinen sind. Da sind keine Menschen involviert, wo Befindlichkeiten, kommunikationsschwierigkeiten und so weiter dazwischen sind.
Speaker 4:Und das ist der Grund, weswegen man auch eher vom Resulting nennt und weswegen wir uns auf diese Agentensysteme spezialisiert haben in der Entwicklung, weil wir gesagt haben ja, okay, am Ende geht es darum, ich habe eine Problemstellung, und der Agent liefert mir ein Resultat, und wie er dahin kommt, hängt eigentlich nur davon ab, wie er Zugriff auf die einzelnen internen Systeme hat, und ansonsten macht er einfach. Und die Idee ist ja, das zu beschleunigen, weil wenn ich, geht es darum, wie schaffe ich es dadurch, schneller zu agieren? Und deswegen wird KI halt einfach vieles verändern, umwälzen. Und die beste Möglichkeit ist wie bei agiler Transformation, wo wir auch damals gesagt haben, du musst die Welle reiten. Nur, da haben Menschen die Welle geritten. Jetzt ist es so, dass Maschinen die Welle reiten.
Speaker 5:Ja, ich glaube auch ist es so, dass Maschinen die Welle reiten. Ja, ich glaube auch, wir wollen jetzt kein KI oder AI-Podcast draus machen, aber ich glaube, der Impact auf Organisationen und dazu werden wir demnächst mal einen Podcast machen, mary, ich bin da schon bei jemandem dran ist so immens aus meiner Sicht. also ich nehme mal ein technisches Thema, vielleicht kannst du mir das einordnen. Heutzutage zum Beispiel im Bereich Enterprise-Architektur Unternehmen, die immer wieder Anwendungen entwickeln, und so weiter, ist es ja so, dass die Enterprise-Architektur eher so ein Showstopper ist. Die machen so ein Architekturfeld, passt das oder passt das nicht? dafür müssen die Leute Kapazitäten haben und so weiter und so weiter. eine künstliche Intelligenz ihr kennt ja den Architekturfett, klar, eine Person muss drüber gucken, das freigeben. aber das wird ja die Logik, wie Entscheidungen und so weiter in Organisationen getroffen werden, ja signifikant verändern. Da hast du ja eine ganz andere Time-to-Market-Ebene, dass ein KI überhaupt sieht, geht das in die richtige Richtung oder nicht?
Speaker 5:Das ist ja eine ganz andere Logik, als wir heute agieren.
Speaker 4:Auf jeden Fall, vor allem, weil Architekturparadigmen oder Methodiken, weil die ja kodifiziert sind, und alles, was kodifiziert ist, lässt sich ja gut verarbeiten von der Maschine.
Speaker 5:Das ist ja radikal. Also überleg mal heutzutage so ein Architekturgremium trifft sich alle zwei Wochen, einmal im Monat. Da tauschen sie sich mal aus, da kommt das mal rein. Das ist Nein, das ist ja so ein Entscheidungsstopper. Die Richtung, in der sich dort die Dinge entwickeln, ist unglaublich. Also ich bin da sehr begeistert.
Speaker 4:Ja, vor allem widerspricht das auch jeglicher Agilität. Also im Agilen sagt man ja auch, dass diese zentralen Architekturgremien von Bedeutung verloren haben, wenn man seine Teamstruktur richtig gesetzt hat, weil man sagt, man hat nur die übergreifenden Architekturparadigmen, auf die man sich gemeinsam vereinbart, und ansonsten willst du ja diese autonomen Teams quasi haben, damit die schnell arbeiten können. Und AI beschleunigt, glaube ich, diesen Change, weil AI halt eine Technologie ist, die das möglich macht. Und dann komme ich am Ende irgendwann drauf, dass ich sage, ja, ich brauche dieses zentrale Gremium gar nicht, unabhängig davon, ob das eine AI oder Menschen sind, weil der eigentliche, die eigentliche Idee ja ist, die Architekturentscheidungen lokal im Team zu machen und nur übergreifend gemeinsam sich zu vereinbaren. Aber eine AI könnte beispielsweise die Code Repositories der einzelnen Teams analysieren und auf Basis dessen also ich spinne jetzt mal wirr, keine Ahnung, wie viele Weine ich jetzt gerade intus habe aber auf Basis dessen vielleicht Vorschläge machen, wie übergreifende Architektur Vereinbarungen lauten sollten, weil es einfach Code und die Bewegungen im Code also durch die Commits und so weiter gemeinsam analysiert worden sind und daraus Vorschläge entstehen für die Teams.
Speaker 3:Du hattest es vorher kurz angesprochen, dass theoretisch die Juniors ja ersetzt werden könnten. Aber die Frage ist können die Seniors irgendwann auch ersetzt werden? Also jetzt, ohne das irgendwie als Teufelsbild an die Wand zu malen, sondern eher quasi die Frage ist für mich was bedeutet das auch für einen Kompetenzaufbau oder eine Wissenssicherung in einem Unternehmen, wenn wir jetzt sagen, eigentlich sind die unteren und mittleren Rollen, das ist ersetzbar Und das, was wir dann brauchen ich glaube, das hattest du im letzten Podcast gesagt jetzt fragen wir gerade die KI, weil die da irgendwie Wissen hat, das wir nicht haben, und in Zukunft wird es vielleicht so sein, dass die KI uns als Experten fragt. Aber das bedeutet auch, da müssen auch Experten sitzen Sein.
Speaker 4:ja genau. Also, ich glaube, nichts wird erstmal so heiß gegessen, wie es gekocht wird. Das ist so Punkt eins. Punkt zwei ist, glaube ich also, was wir beispielsweise schon seit langer Zeit machen, ist, dass wir unseren Entwicklern auch AI-Tools einfach schlichtweg zur Verfügung stellen und sagen bitte, damit arbeiten. Bei uns ist halt eher so das Thema, dass unsere Kunden das nicht unbedingt immer wollen. Das heißt, da schlägt auch so ein bisschen die Realität mit rein.
Speaker 4:also zwischen dem, was technisch möglich ist, und dem, wie die Organisationen ticken und funktionieren, weil da vielleicht noch Ängste sind. oh, meine wichtige Codebase geht es jetzt in die Allgemeinheit über Datenschutz und so weiter und so fort. Das sind so Themen, die kann man klären. Und dann ist es, glaube ich, hilfreich, wenn einem unserer letzten Blogbeiträge Agentic Mesh genannt, also quasi ein Netz an dezentralen Agenten, die sich aber trotzdem miteinander austauschen, die man da draußen kauft Ich habe es neulich mal gesagt im Sinne von naja wenn jetzt jede Abteilung ihr Spezial-Tool fertig von der Stange eingekauft, bekommt ihr AI-Spezial-Tben, weil du im Prinzip nur die gleiche Scheiß-Organisationsstruktur in digital einfach nachbaust, um es mal salopp zu sagen.
Speaker 5:Und ich glaube, die Frage stellt sich nicht in dem Sinne gehen uns sozusagen die Senioren verloren, weil wir die Junioren nicht mehr ausbilden, weil ich glaube das hat es ja schon immer in Professionen gegeben dass ja im Grunde die Fähigkeiten sich verändern und wir mehr dann Leute in bestimmten anderen Fähigkeiten fokussieren werden. Die Herausforderung aber das ist eine grundsätzliche Technologiekritik ist, dass die Technologie sich ja immer mehr über Layer der Abstraktionen entwickelt und wir immer weniger die Fähigkeit insgesamt haben, als Gesellschaft die unterste Ebene nachzuvollziehen. Also die Fähigkeit zu.
Speaker 3:Aber ich sag, mal, Aber das ist nicht was, was eine einzelne Organisation macht.
Speaker 5:Ja, aber die Büchse ist offen, dass Leute heutzutage vielleicht nicht mehr Assembler verstehen oder auch sogar wenn sie es verstehen die.
Speaker 4:Komplexität der Software nicht mehr greifen kann. Aber das hatten wir vor 20 Jahren auch schon.
Speaker 3:Also mir fällt ja, ja, ja, der Zug ist abgefahren. Ich weiß auch nicht, wie Word funktioniert, ich weiß nur, wie man es benutzt Als Beispiel.
Speaker 4:Ich bin ja ein alter Mann, und mir fällt ja gerade ein Beispiel ein von 2005, 2006. Thema Datenbank, datenbank SQL. Kann man sich die SQL-Abfragen selber zusammenb bauen, oder nutze ich ein UI-Tool, um mir das zusammen zu klicken, meine Abfrage an die Datenbank? Und damals gab es auch so einen Trend. Da haben dann die Leute auch angefangen, sich irgendwelche Click-Me-Tools zu installieren, um mit der Datenbank zu interagieren.
Speaker 4:Und du hast dann sofort gemerkt okay, das sind halt eher die Junior-Entwickler, weil eigentlich musst du wissen, wie du an die Datenbank rangehst, und so ähnlich würde sehen, das heißt, die AI als Companion nutzen und natürlich mit einem kritischen Blick auch drauf gucken kommt da jetzt stochastischer Nonsens hin, oder ist das jetzt wirklich guter Code, der gebaut wird? Das heißt, die AI hilft dir, den ganzen Boilerplate-Code und so weiter zu bauen, und hilft dir auch bei komplexeren Szenarien. Aber du brauchst trotzdem, musst du halt trotzdem noch rangehen und gucken okay, passt das jetzt, passt das jetzt, passt das nicht, weil ansonsten kommst du vielleicht mal auf eine Problemstellung, wo du entweder vielleicht dein AI-Tool gerade nicht mit in der Tasche dabei hast oder das AI-Tool dir hier gerade nicht weiterhelfen kann in einer komplexen Situation, und dann stehst du da, sollst ein Problem lösen und kannst es nicht, und das ist genau das Ziel. Deswegen sage ich Companion.
Speaker 4:Du hast Teams an Menschen, die AI integriert haben als Companions, als Coworker, und damit arbeiten und dann insgesamt produktiver werden. Der feuchte Traum des Managements, dass man auf die teure IT verzichten kann Es braucht es jetzt mal hier als Megafon. Vergiss das, das wird nicht passieren. Mehr Budget in die IT? Yes, und weil jetzt jeder wahrscheinlich im Geiste Mark Zuckerberg zitiert, der sagt ja, die Mitlevels, die phasen wir aus, wir ersetzen die durch AI. Ja, weil halt in San Francisco ein Mitlevel-Software so viel Wert zu schaffen wie ein mittlerer sechsstelliger Betrag pro Jahr Und schon habe ich tatsächlich meinen Entwickler ersetzt Das kannst du ja mit deutschen Gehältern oder Dierschau-Gehältern, das ist anders vergleichbar an der Stelle.
Speaker 3:Hervorragend. Jetzt sind wir aber abgedriftet, oder?
Speaker 5:Super. Ich finde, das Driften war super E super.
Speaker 4:Ich finde, das Driften war super, echt Okay, ich bin ein großer Fan vom Driften.
Speaker 3:Wir driften gerne immer nur auf Kurs. Das ist ja langweilig.
Speaker 5:Ja, das stimmt.
Speaker 4:Wir sind ja nicht die Mayflower. Ja, aber du musst ja schon ein Ziel vor. Augen haben, und ich glaube, das haben wir ganz gut erreicht.
Speaker 3:Also wer sich jetzt beschweren möchte, bitte kontaktiert uns. Auch die Metapher, quasi die Metapher, quasi also die Metapher, die wir gebraucht haben für diesen Podcast. Weil wir haben uns ja auch gesagt, wäre schön, wenn wir uns so organisieren würden.
Speaker 3:Kriegen wir das so hin, weiß ich nicht. Manchmal hat man ja auch schon gewisse Vorbedingungen, oder manchmal kommt was von der Seite rein, ein Gedanke zum Beispiel Sehr gut. Aber wir haben über viele Dinge gesprochen. Die Frage war quasi was kommt zuerst, technologie oder Organisation? Wir haben gesprochen über Conway's Law, über Business Needs, über Dunbar's Number, über die Probleme, die dann in der Transformation auftauchen, das Alignment-Autonomie-Dilemma, die Größe von Organisationen. Wir sind gegangen zu was hat KI da für einen Impact drauf, und werden wir irgendwann alle selber coden können? Und was sind Scheinfragen, was ist Resulting? Und so weiter und so weiter. Wir haben ganz, ganz viele Sachen besprochen. Ich fand das wahnsinnig spannend.
Speaker 5:Vielen Dank. Mir ist vielleicht eine Sache noch eingefallen, dieses Alignment-Problem Sozusagen. wie kriegt man mehrere, eine Dezentralität aligned, auch so ein KI-Thema. Was KI-Organisationen unterstützen könnte, aber dazu in weiteren Podcasts, vielleicht mal mehr In späteren.
Speaker 4:Folgen genau. Vielen Dank, björn, sehr sehr gerne Bis bald Ciao.
Speaker 2:Ciao, bis zum nächsten Mal.