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

Episode Transcript

Speaker 1 (00:00):
Du hast es schon implizit gesagt, nämlich das
implizite explizit machen unddas regelmäßig tun.
Also genauso wie ich nichtüberrascht sein darf, wenn ich
jetzt nicht in Qualität, inmeine Software investiere, dass
quasi dieses berühmte TechnicalDebt immer weiter anwächst und
ich dann irgendwannQualitätsprobleme gebe, Oh,
Überraschung, Überraschung.
Wir haben jetzt zwei Jahre langunser Produkt aufgebaut.

(00:20):
Wir sind ein Startup, wir habenhalt nur Features gebaut.
Ja, dann ist es halt so, dass,wenn man mal drauf guckt, dann
irgendwann sieht oh hoppla, damüssen wir jetzt was tun.

Speaker 2 (00:31):
Money, money.
I want more money.
I don't even know why.

Speaker 3 (00:38):
Hallo und herzlich willkommen.
Zurück zu Corporate Therapy.
Ich versuche, heute mal ganzdiszipliniert zu sein.
Wir sollen ja immer mal wiederzu Anfang sagen, wer wir
eigentlich sind, falls Leuteerst einsteigen in den Podcast
und uns nicht seit Folge 1gehört haben.
Uns ist das irgendwann beiFolge ich weiß gar nicht 100
aufgefallen, dass wir nie sagen,was wir eigentlich tun.

(00:58):
Also hier ist es.
Corporate Therapy ist einkritischer Management-Podcast,
in dem wir mal mit und mal ohneGäste Fragen aus der Arbeitswelt
diskutieren, und manchmal istes dabei sehr globalgalaktisch
und geht um die gesamteWirtschaft und den gesamten
Zustand der Welt, und manchmalist es ganz praktisch, und wir
sprechen über Methoden undFrameworks, und ich glaube,

(01:21):
heute landen wir irgendwomittendrin.
Ich bin Mary Jane, und mit mirist in der Regel auch immer
einer meiner Kollegen mit dabeioder die Kollegen unter sich,
und ich bin nicht dabei.
Und heute ist das Human.
Hallo, human.
Guten Tag Mary, wie geht's Sehrgut.
Ich freue mich sehr, denn esgibt ein Thema, über das denke
ich schon ganz lange nach, oder?

(01:41):
nee, stimmt nicht.
Das ist falsch.
Ich denke darüber nicht schonganz lange nach, aber ich denke
darüber zurzeit sehr viel nach.
So rum ist das richtig.
Und ich mache auch direkt zuAnfang hier mal einen Aufruf an
alle Hörerinnen und Hörer, anunsere Zuhörer.
Ich äußere mal einen Wunsch.
Ich wünsche mir von euchAnekdoten und Gedanken zur Frage

(02:03):
wie verändert KI eurenArbeitsalltag?
Wo verwendet ihr das?
Ändert sich irgendwasgrundsätzlich?
Wo steckt ihr da in eurenOrganisationen gerade Ich möchte
das wissen.
Das ist ein bisschen geradeeine persönliche Obsession von
mir, aber so ganz alleine binich damit nicht.
Unser Gast, der heute da ist,war nämlich schon zweimal bei
uns im Podcast, und einmal davonhaben wir genau zu diesem Thema

(02:25):
AI gesprochen.
Aber heute wollen wir nochmalgrundsätzlicher an die Frage
gehen was kommt eigentlichzuerst, die Technik oder die
Organisation?
Und dazu haben wir hier BjörnSchotte.
Hallo Björn, schön, dass du dabist.

Speaker 4 (02:38):
Hallo Mary, hallo Roman, schön, dass ich wieder
hier sein darf.
Hi, ich freue mich.

Speaker 3 (02:43):
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 undGeschäftsführer der Mayflower
GmbH.
Das ist einBeratungsunternehmen, oder?

Speaker 4 (02:56):
auch Softwareunternehmen,
IT-Dienstleister.
Hauptsache Software ja.

Speaker 3 (02:59):
Genau, der sich auf die Entwicklung moderner
Softwarelösungen spezialisierthat, der sich auf die
Entwicklung modernerSoftwarelösungen spezialisiert
hat, so habe ich mir das hierschön notiert.
Also, ihr seid mittendrin inder digitalen, in der agilen
Transformation, in allem, wasdazu gehört, und man kann dich
nicht nur hier im Podcast hören,sondern eigentlich auf
verschiedenen Plattformen.
Du bloggst, du bist aktiv aufLinkedIn, du tauschst dich auch
viel aus.
Unter anderem hast du auf einenPost von mir reagiert.

(03:23):
Ich weiß gar nicht mehr,welcher Post das war, ich weiß
nur noch, deine Reaktion, habeich mir notiert.
Deine Aussage war Organisationfolgt Technologie, nicht
umgekehrt.
Den Weg machen vieleUnternehmen falsch und
straucheln dann.
Richtig, und ich würde jetzteinfach diese Frage umdrehen und
sie dir zurückstellen, richtig.

Speaker 4 (03:40):
Ja, na klar, Und schon ist der Podcast vorbei.
Wie ich es im Vorfeld gesagthabe, das Ding ist auserzählt.
Ja, natürlich kommt die Technikzuerst.
Ja, wie soll ich sagen?
es ist erstmal sehr, sehrkontraintuitiv, weil man denkt
natürlich, wieso, abteilungen,bereiche, ich baue doch jetzt

(04:00):
erstmal meine wohlberühmtenagilen, teams und ähnliches, und
dann kommt geile Software raus.
Aber eigentlich muss ich esandersherum machen, bin ich der
Meinung, und mit der Meinungstehe ich zum Glück nicht
alleine da.
Tja, bin gespannt, was wir indieser Folge alles so ausgraben
werden.

Speaker 3 (04:11):
Zu dem Thema Jetzt hast du gerade schon gesagt,
dann kommt geile Software raus.
Was ist denn der Gedanke, derdir da immer so entgegenschwappt
, wo Leute sagen, jetzt machenwir agile Teams, und dann kommt
geile Software raus?
Also, was glaubst du, steckt dadahinter?

Speaker 4 (04:26):
Naja, da steckt so ein bisschen der
Vereinfachungsgedanke, derSimplifizierungsgedanke dahinter
Im Sinne von ich muss nur dasund das machen im Rahmen meiner
Organisation, weil die Leutemeistens dann auch nicht so tief
in der Entwicklung drin sind,weil sie selber keine
Softwareentwickler drin sind.
Dadurch entsteht halt dereinfache Gedanke naja, wenn ich
meine Teams so und so baue undso und so strukturiere, dann
wird das schon irgendwie passen.

(04:48):
Und dann wundern sie im Sinnevon naja, die Software macht
nicht das, was sie soll.
Wir wollen hierinternationalisieren, aber

(05:08):
irgendwie kriegen wir das nichthin mit unserer Plattform.
Was können wir denn da tun?
Und dann gucken wir drauf undsehen okay, da ist klar, warum,
weil die Teamstruktur passtnicht.
Und dann gehen wir eigentlicheher erstmal den umgekehrten Weg
, dass wir gucken, wie soll denneigentlich die Software sein?
Also im Kontext, wie soll dieZielarchitektur sein, damit ich

(05:29):
überhaupt erst sowas wiebeispielsweise eine
Internationalisierung machenkann?
Und erst dann überlege ich mirwie muss ich denn meine Teams
dafür strukturieren, damit amEnde das rauskommt, was ich von
der Software her brauche?
Und das machen vieleOrganisationen nicht, die gehen
den anderen Weg.

Speaker 3 (06:01):
Die sagen ja, ich habe die und die Köpfe, ich
struktur erstmal vonSoftwareentwicklung.
Auch Ich glaube, das müssen wirerstmal als Voraussetzung
machen, und dann später könnenwir gucken sind unsere
Erkenntnisse übertragbar?
Also du sagst im Prinzip, esgibt zwei Ansätze.
Der eine Ansatz ist der ichplane das vom Ziel her, also ich

(06:21):
möchte eine bestimmte Sachehaben, und dann muss ich meine
Organisation entsprechendaufbauen.
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 damitkomme.
Und du sagst, wenn man aberSoftware baut, dann sollte man
erstmal gucken, was man bauenmöchte, und dann das rückwärts
aufrollen?

Speaker 4 (06:38):
Ja, genau, weil da kommt ein kleines Gesetz, das
eigentlich keinnaturwissenschaftliches Gesetz
ist, aber trotzdem ein Gesetzist.
Ich glaube, wir hatten das beieinem der anderen Podcasts, wo
ich schon mal bei euch zuGastarchitektur und rechnet dann
rückwärts wie muss denneigentlich meine Teamstruktur
sein, damit ich, wie sie damalswar, als die Software entstanden
ist Und das kann ich mirwiederum nach vorne gedacht

(07:27):
zunutze machen?
diese Archäologie Und ich seheschon, der Human wird ganz
ungeduldig auf seinem Sesselwird mir jetzt gleich Paroli
bieten, freue ich mich schondrauf Und kann dann auf der Art
und Weise dann wirklich auch dieOrganisation planen, die ich
dafür brauche, damit am Ende dieSoftware rauskommt oder die
Software-Richtung von derArchitektur herauskommt, die ich
benötige, und zwar aufgrundmeiner Business-Voraussetzungen,

(07:49):
die ich habe.
Also, ich denke da ganz simpelin drei Schritten.
Der erste Schritt ist erstmalgucken, was brauche ich
Business-seitig.
Ich hatte es gerade eingangsgesagt okay, die Plattform, die
ich habe, die ist in Deutschlandgroß geworden.
Ich muss ich gucken, wie baueich die Plattform so um, dass
sie diesen Businessgrund und dasist jetzt nur ein simpler

(08:10):
Businessgrund dass sie daraufeinzahlen kann?
Und dann gucke ich, wie mussdenn die Softwarearchitektur,
wie muss die Plattform aufgebautsein, damit sie diese
Businesskriterien erfüllt?
Und erst dann überlege ich,wenn ich jetzt diese
Zielarchitektur habe, für dieich mich entschieden habe, wie
müssen dann meine Teamsstrukturiert sein?
Also bestes Beispiel baue ichjetzt Monolithen oder baue ich
einen Microservice?

(08:30):
Bei Microservice weiß ich, wennich mehrere Microservices habe,
die genügend groß sind, dannkann es hilfreich sein, dass ich
da mehrere Teams dafür brauche,weil ein Team macht den
Microservice XYZ, der für dieSuche in der Plattform ist, das
andere Team macht das ThemaUser-Registrierung und so weiter
und so fort, und dann habe ichentsprechend mehrere Teams, die
ich vielleicht dafür benötige,um das Produkt aufzubauen oder

(08:51):
weiterzutreiben.

Speaker 5 (08:53):
Also, ich glaube, ich wurde unter falschen Tatsachen
in diesen Podcast eingeladen.

Speaker 3 (08:57):
Wie.

Speaker 5 (08:58):
Denn so wie man mir das nahe getragen hat, war ja
sozusagen die Frage ich habejetzt mal angenommen, im Kontext
einer Veränderung, über wassollte man zuerst reden?
Über die Organisation und überTechnologie.
Und ich stelle gerade fest, indiesem Podcast hier ich glaube,
ich würde ein paarBegrifflichkeiten anpassen.
Also die Frage wäre, über wassollte man zuerst nachdenken?

(09:19):
Prozesse und Strukturen oderPersonal?
Weil ich bin komplett bei dir,was soll ich denn da
parolibinden?
Also hättest du gesagt, mansollte Technologie zuerst sich
angucken und dann Strukturen undProzesse.
Hätte ich gesagt, stopp, wait aminute, das macht keinen Sinn.
Aber natürlich, ich würde ja soweit gehen, das ist ja wahr,
unabhängig von irgendwelchenSoftwareentwicklungen.
Die Frage ist ja also ConwaysLaw, law würde man ja so weit

(09:42):
gehen und den Satz formulierenmüssen, dass die eigene Struktur
muss eine gleiche Komplexitätaufweisen wie das Problemsystem,
was man lösen will.
Das bedeutet ja auch, dieMicroservice-Architektur ist ja

(10:02):
eine Architekturentscheidungbezogen auf das Problemsystem,
was man im Markt identifizierthat, und dementsprechend würde
man ja die Strukturen, diehinter der Microsoft-Architektur
kommen, dementsprechendaufbauen, sozusagen, dass man
eine konsequente Architektur hat, auch aus der
Organisationslogik.
Da wäre ich halt so weit undwürde ja sagen, technologie ist
da ein Element, aber am Endereden wir über Strukturen, die
über.

Speaker 4 (10:19):
Technologie laufen Ja nicht ganz so.
Also, ich meine, dieTechnologie ist dann halt der,
die gibt den Rhythmus sozusagenvor.
Also wenn du das als Motorbetrachtest und je nachdem, wie
komplex du deine Technologieaufbaust, ob du einen Monolithen
hast, wo du sagst, okay, duhast eine Codebase, ein starres
System, oder du teilst esstärker auf, oder du hast ein
Plattform-Team, das sag ich mal,die Plattform sozusagen

(10:43):
betreibt und anderen Teams zurVerfügung stellt, und ich jetzt
an Data Integration Platformsund so weiter denke, dann sind
ja diese Überlegungen, die manmacht, im Kontext der
Systemarchitektur, die habenEinfluss auf die Art und Weise,
wie die Teams geschnitten sind,wie ich die Teams brauche.
Und was wir halt häufig sehenim Markt und auch bei
Unternehmen, ist, dass du haltauf bestimmten Management-Ebenen

(11:04):
hast du natürlich Personen, diejetzt nicht so vertraut mit der
Softwareentwicklung sind.
Ist ja logisch, weil es sindManager, die verfolgen bestimmte
andere Ziele, die kümmern sicheher um die Business-Ziele.
Also, welche Capabilities mussmeine Softwareplattform zur
Verfügung stellen, damit ich inder Lage bin, jetzt in den
nächsten zwölf Monaten in fünfLändern aktiv zu sein, und
ähnliches.
Und da wird dann häufig auf demReißbrett von Teamstrukturen

(11:27):
gedacht, ohne dieSoftware-Architektur zu
berücksichtigen.
Und das ist der Grund, warumich sage, dass ein
praktikableres Vorgehen ist,zunächst mal im Rahmen der
Software-Architektur und derZielarchitektur zu denken, und
wenn ich das habe, dann kann ichhingehen und kann meine
Teamstruktur dafür aufbauen.
Ich setze noch eins drauf Ichwill ja auch keine starre
Softwarearchitektur haben, alsodas, was man früher hatte mit

(11:49):
Enterprise-Architektur.
Ich definiere mal so dieArchitektur, wie sie die
nächsten fünf Jahre laufen soll.
Ich meine, jeder, der sich mitAgilität und Dynamik beschäftigt
, weiß, dass das nicht haltbarist.
Das heißt, wir haben auch dasThema evolutionäre
Softwarearchitektur.
Also, architektur istveränderlich, und daraus folgt
zwingend, dass dann auch dieTeamstruktur dynamisch und
veränderlich sein muss, weil siesich den Gegebenheiten der

(12:12):
Software, die gezogen wird vonden Business-Kriterien und der
Dynamik des Marktes entsprechendanpassen muss, und das ist
leider noch nicht in allenUnternehmen angekommen.

Speaker 3 (12:22):
Ich würde das vielleicht noch ergänzen, bevor
ich dann in ein Aber kommenwerde.
Es gibt ein großartiges Buchvon Matthew Skelton und Manuel
Pais, glaube ich, spricht manihm aus Team Topologies heißt
das also quasi die Landkarte derTeams, wie stehen die
zueinander?
Und darin machen sie im Prinzipeigentlich eine ähnliche

(12:45):
Argumentation auf, dass siesagen, es gibt bestimmte
Anforderungen, dieFunktionalitäten an ihre
Softwarearchitektur stellen, undentsprechend muss man das auch
berücksichtigen in derTeamstruktur, damit die das
überhaupt abbilden können, undmachen dazu dann aber ja noch
weitere Argumente auf und sagenzum Beispiel wir wollen ja auch
als Unternehmen sicherstellen,dass wir Software schnell

(13:07):
liefern können, dass wir die miteiner gewissen Qualität liefern
können, also nicht nur, dasswir es überhaupt machen können,
und sagen, als Organisationszielsollten wir immer haben ein
Fast Flow, also quasi dann zugucken, wie schneiden wir die
Teams auch, so, dass sie nichtüberlastet sind oder sich zu
viele Gedanken machen, unddaraus ergeben sich dann aber
vielleicht auch nochmal Subteams, die in bestimmten Beziehungen

(13:28):
zueinander stehen.
Das ist, glaube ich, das, wasdu meintest, dass man das
dynamisch anpassen kann.
Wie das läuft So.
Und jetzt kommt mein großesAber, 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 michkönnen wir das von vornherein

(13:48):
wissen, was die Architektur oderwas die Softwareveranforderung
an die Organisation stellt?
Wer kann das überhauptüberblicken?

Speaker 2 (13:58):
Hey Patrick, hier Patrick Breitenbach von 1789
Consulting.
Sorry, dass ich diesen Podcasthier unterbreche, aber ich
wollte nur sagen, wenn du diesenPodcast wirklich, wirklich
liebst, dann wirst du ganzsicher auf Spotify oder Apple
Podcast eineFünf-Sterne-Bewertung
hinterlassen und das Ganze nochmit einem positiven Kommentar

(14:18):
garnieren.
Und wenn du dich dafürinteressierst, was wir als
Unternehmensberatung so machen,dann schau doch mal auf unserer
Website vorbei,www.1789consultingde.
Oder spreche uns direkt beiLinkedIn an.
Wir freuen uns, und jetztgeht's weiter mit den
Erkenntnissen.

Speaker 4 (14:35):
Viel Spaß das kollaborativ zusammen zu machen.
Also, wenn wir in solcheSituationen reingerufen werden,
egal, was der Auslöser ist, obdas jetzt Modernisierung ist, ob
das die Entwicklung einerkomplett neuen Plattform ist
dann gehen wir zunächst mal herund gucken uns die sogenannten
Business-Treiber an.
Das heißt, wir machen einenkollaborativen Workshop mit dem

(15:00):
Kunden zusammen und gucken malin einem halben Tag drauf was
sind denn dieBusiness-Bewegründe, dass du
jetzt in eine bestimmte Richtunggehen möchtest?
Weil das versuchen wir explizitzu greifen und auch
untereinander gegeneinander zugewichten, weil du hast so das
typische Problem inOrganisationen Leiter XYZ sagt,
das ist aber wichtig.
Leiter ABC sagt ja, aber wasanderes ist viel wichtiger.
Das heißt, du hast hier Ziele,die unter Umständen
gegensätzlich sind, die inKonkurrenz zueinander laufen,

(15:22):
und das sortieren wir nachWichtigkeit oder nach
Kritikalität entsprechend ein.
Und dann gehen wir überbestimmte Zwischenschritte,
gehen wir in RichtungArchitekturszenarien, dass man
halt überlegt was gibt es dennda so für Architekturen?
Also beispielsweise macht mandas rein in der Microsoft Welt,
macht man rein Open Source, gehtman in der Cloud, macht man
Hybrid und und und Also dashängt jetzt so von
Software-Thema ab.

(15:42):
Deswegen bin ich da jetzt eherauf generischer Beschreibung
unterwegs, und dann, wenn ichmeine Architekturen
gegeneinander verglichen habe,gegen die Business-Kriterien,
weiß ich grob auch noch weitereAspekte habe.
Du hast es gerade genanntentlang von Team Topologies die

(16:08):
Mental Load und damit quasi inFolge die Mental Health.
Was geht in so einEntwicklergehirn eigentlich rein
?
Was kann ich denn überblicken,wenn man jetzt ganz zurückguckt?
nach Extreme Programming hatdamals 1995 Collective Code
Ownership propagiert.
Das heißt, jeder kennt sichüberall im System gleichmäßig
aus, sodass man überalleingreifen kann.
Bei der heutigen Komplexität derSoftware-Plattform ist das

(16:29):
nicht immer gewährleistet.
Deswegen macht Team Topologiesbeispielsweise diese vier oder
fünf unterschiedlichen Teamtypen, nach denen organisiert wird.
Es gibt noch weitereSystematiken, wenn du bei der
Cloud Native ComputingFoundation beispielsweise guckst
.
Da gibt es nicht nur dieArchitektur-Patterns und
technischen Patterns, es gibtauch Organisations-Patterns, wie
bestimmte Dinge aufgebautwerden sollten, beispielsweise

(16:50):
Pioneers-Team und ähnliches.
Es gibt von Google das SRE-Team, das in Team-Topologies eher so
dem Plattform-Team entspricht.
Also da gibt es unterschiedlicheVokabulare, die aber auf
ähnliche Teamtypen sozusagenabzielen, und all das dient dazu
, diese Aspekte gut miteinanderaufzubauen, um am Ende
sicherzustellen, dass ich einegute Software baue und in einen

(17:12):
guten Flow komme, also nicht nurdie Lieferfähigkeit
gewährleiste, sonderntatsächlich auch ein Stück
Software aufbaue, was dieBusiness Needs erfüllt, weil das
ist, glaube ich, auch ganzwichtig zu betonen.
Das machen wir ja nicht aus Spaßan der Freude
Softwareentwicklung, sondernUnternehmen und Organisationen
wollen damit typischerweise Geldverdienen, margen erhöhen im
Wettbewerbsdruck oder jetzt 2025, wir haben erhöhten Druck durch

(17:35):
AI, eine Weltwirtschaft, diesich einigermaßen erholt, aber
Deutschland nicht so gut, und soweiter und so fort.
Nun muss man halt gucken, wiekomme ich jetzt an die Pole
Position, und das muss man dannübersetzen in die Business Needs
, die ich brauche, um dann aufder 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.

(17:56):
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 vonErfolg gegründet, glaube ich.

Speaker 5 (18:07):
Aber ist das wirklich so eine Differenz?
Also, es gibt ja immer eineAufbauorganisation das ist
unabhängig von der.
Man kann ja Organisation inProzessen denken, so eine
Prozessorganisation.
Am Ende sind ja Leute immernoch aufbauorganisatorisch
verortet.
Ich kenne ja dieses Konzeptauch sehr gut, und ich verstehe
auch den Reiz da drin.
Aber würdest du wirklichbeschreiben, das ist so eine

(18:28):
prinzipielle Herausforderung?
Weil ich drehe mal dieSituation und würde sagen, ich
kenne ganz viele Projekte, wodas Thema also klassischerweise
eher so große ERP-Einführungenoder CRM-Einführungen, und man
kommt mit der Technologie undist da sehr so, wir haben unsere
Standardprozesse, die müssenjetzt umgesetzt werden.
Und man erlebt ja eher insolchen Situationen, dass man

(18:49):
eher sagen würde naja, ein Blickauf die Organisation und den
Strukturen wäre ja auch sinnvollbei dieser Form von Technologie
.

Speaker 4 (19:07):
Das auf jeden Fall.
Aber die Frage ist doch, wenndu in solche Projekte reinguckst
, die dauern relativ lange,kosten viel Geld und sind dann
am Ende nicht von Erfolg gekrönt.
Projektereien, die dauernrelativ lange, kosten viel Geld
und sind dann am Ende nicht vonErfolg gekrönt, oftmals, weil
sie einfach zu langsamvonstatten gehen.
Also mit anderen Worten esilenTeams, agile Teams jetzt mal
salopp gesagt, war ja immer dasCredo autonome Teams, in

(19:28):
Anführungszeichen.
Der Sinn hinter dieserAutonomie ist nicht, dass jeder
machen darf, was er will, darumgeht es nicht, sondern dass,
wenn ich meine Ziele kenne, dassich in der Lage bin, schnell
Entscheidungen zu treffen, meinProdukt nach vorne zu entwickeln
, und ERP-Einführung ist einsuper, super Beispiel.
Das sind dann immer so, dieseMehrjahresprojekte, ah, jetzt
steht das ganze Unternehmenstill.
Wir können jetzt erstmal unsnicht mit AI beschäftigen, weil

(19:49):
wir führen jetzt erstmal zweiJahre lang ein ERP-System ein,
wo ich dann sage ja, viel Spaß.
Ein AI-Jahr sind vier Wochen inder realen Welt.
Jetzt übertrag das mal auf zweiechte Jahre, dann weißt du, wie
viele Jahrhunderte du verpassthast verpasst hast.

Speaker 5 (20:03):
Aber sag mal also, die Herausforderung bei
dezentralerer Struktur, wie zumBeispiel bei Team Topologies,
ist ja das Thema Alignment.
Also, je mehr du jadezentralisierst, desto
schwieriger ist es, einAlignment sich darzustellen, und
zwar und das ist vielleicht someine Kernkritik.
also ich muss das mal einbisschen ausholen.
Ich glaube, die Art, wie wirOrganisationen betrachten, ist

(20:27):
immer eine ingenieurshafte,zweckrationale Logik.
Wir können Organisationen, wennwir sie auf Papier beschreiben
wollen, ja nicht irrationalbeschreiben.
Unsere Denkformen zwingen unsdazu zu sagen, was ist denn das
Optimale, optimale?
Und deswegen glaube ich, istjetzt an dem Konzept prinzipiell
jetzt keine Herausforderung.
Allerdings ist es ja so, du hastes vorhin gesagt,

(20:49):
organisationen sindwidersprüchlich.
Also das ist die Kernlogik vonOrganisationen ist ja, dass eben
Ziele doch in Konflikt sind,dinge unterschiedlich
priorisiert werden.
Mikropolitik ist ein Thema, ichhatte einen schlechten Tag.
Also all diese Dinge,interaktionen finden in der
Organisation statt und so weiterführen ja dazu, dass auch wenn

(21:09):
wir eine zweckrationale Fantasiehaben, die so sein muss, aber
die Alltag der Organisation jadavon geprägt ist, okay, wie
schaffen wir das, diese ganzenWust irgendwie in eine Richtung
zu bringen?
Und das funktioniert ja nichtzweckrational.
Und je mehr wir in dieDezentralität plädieren, desto

(21:31):
schwieriger wird ja genau diesesThema.

Speaker 3 (21:34):
Kann ich ganz kurz noch einhaken, weil ich nicht
sicher bin, ob alle Leute aufdem gleichen Stand sind, die
hier zuhören, quasi.
Das weiß ich auch nicht.
Deswegen würde ich jetzt einmalganz, ganz knapp versuchen zu
erklären, zumindest diesesTeam-Topology Konzept zu
erklären.
Also der Gedanke ist, softwarewird immer komplexer.
Deswegen kann man das nichtmehr monolithisch quasi abbilden
und sagen, alles kommt auseiner Hand, sondern wir brauchen

(21:55):
, wie du vorher gesagt hast,sogenannte Microservices oder
eben verschiedeneAnwendungsteile, die aber
selbstständig entwickelt werdenkönnen und dann wieder
zusammengeführt werden in wasauch immer Endanwendung das dann
ist.
Und der Gedanke von TeamTopologies ist quasi es gibt
sogenannte Stream-Aligned Teams,das sind, ich sag mal, das
Hauptteam sozusagen, oder dieverschiedenen Hauptteams, die

(22:16):
kümmern sich um eine Sache, diehaben die Verantwortung für
diese Sache, die decken auch soviel, wie sie können,
selbstständig ab, aber eben mitder Begrenzung, dass man sagt,
maximal irgendwie zwölf Leute,weil sonst wird es zu verwirrend
da drin.
Und wenn es bestimmte Dinge gibt, die super kompliziertes
Expertenwissen brauchen, lassuns das auslagern in ein
Experten-Team, oder die nennendas ein Complicated

(22:36):
Subsystem-Team, die sich dannquasi um diesen Teil kümmern.
Oder lass uns eine Komponenteauslagern, wo man sagt, da
kümmern sich Leute drum.
Und dann gibt esPlattform-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 Prinzipist das quasi dann.
Es gibt.
Die Verantwortung ist sozusagenso eine Pull-Verantwortung,

(22:58):
also aus der quasi aus diesemNeed heraus, wir verantworten
dieses Stück, und das Wissenwird aus der Organisation
sozusagen über die Peripherierausgezogen.
Das ist quasi der Gedanke, unddeswegen spricht Human jetzt
quasi von der dezentralenOrganisation, weil es eben viele
Teams gibt, dieeigenverantwortlich ihre Sachen
da beschreiben.
Und dann gibt es jetzt ebendieses Alignment versus

(23:19):
Autonomie Problem, und da könntihr jetzt wieder einsteigen.

Speaker 4 (23:22):
Ja, also danke nochmal für die Erläuterung.
Ich würde da nochmal alsZwischenruf einwerfen wollen Ich
glaube, in der AI-Zeit müsstedas Buch Team Topologies
vielleicht auch nochmal neugeschrieben werden, weil AI das
Thema Geschwindigkeit auf eineganz andere Art und Weise
nochmal deutlich beschleunigt.
Vielleicht kommen wir nochdrauf oder als Cliffhanger für

(23:51):
eine andere Podcast-Folgesozusagen Zu der Frage dezentral
, zentral, selbst wenn jetztdiese Teams so aufgeteilt sind.
Am Ende wird ja ein Produktentwickelt, also für den
Endanwender.
Das heißt, du hast gemeinsameZiele, die dafür sorgen und
sicherstellen, dass die Zielebekannt sind, dass die Ziele
verfolgt werden und dass trotzder Autonomie, der

(24:11):
Unabhängigkeit auf diese Zieleeingezahlt wird.
Also da gibt es auch einen ganz, ganz alten Comic vom Henrik
Knieberg Da ging es um dasSpotify-Modell, was ja auch
missbräuchlich eingesetzt wordenist der damals auch schon sehr
früh das Thema Autonomie undAlignment in so einem
Vier-Felder-Modell dargestellthatte, was dazu eigentlich
notwendig ist.
Ich gehe jetzt einfach mal davonaus, wir haben ein Produkt zu

(24:33):
entwickeln, und die Frage istdoch also wenn das Produkt
hinreichend komplex ist ich redejetzt nicht von einem Produkt,
wo zwei Leute daran arbeiten,sondern wo typischerweise
mehrere Teams daran arbeitenmüssen, weil die Komplexität
einfach so groß ist und dasProdukt so umfangreich ist dann
glaube ich ganz fest daran, dasses hilfreich ist, sich von dem
Thema Systemarchitektur,softwarearchitektur zu nähern

(24:57):
und dann zu überlegen wie mussder Teamschnitt sein, damit am
Ende das, was du geradebeschrieben hast, mary, mit den
unterschiedlichen Teamtypen,worauf zahlt das ein Auf Fast
Flow, damit am Ende das auchgewährleistet werden kann Und
nicht umgekehrt, weil am Endedie klassische
Organisationsstruktur uns davielleicht auch im Weg steht, um
eine gute Software zu bauen.

Speaker 3 (25:16):
Was ich an dem Thema faszinierend finde auch so, wie
du das beschreibst, braucht einegewisse Flexibilität in der
Organisationsstruktur.
Auch quasi Art, wie die Teamsstrukturiert sind, gibt es
bereits eine Priorisierung, alsoweil es gibt Teams, die
bestimmte Dinge bearbeiten, undandere Dinge, für die gibt es

(25:37):
kein Team.
Damit werden die nichtbearbeitet.
Und ich finde, das ist einsignifikanter Gedanke irgendwie.
Das muss man sich irgendwie vorAugen halten, weil das ja auch
bedeutet, also das überhaupt,wie die Organisation
zugeschnitten wird, istüberhaupt das
Strukturierungsmerkmal für waspassiert überhaupt Bedeutet.
Aber auch, man muss daeigentlich immer ein Auge drauf

(25:57):
haben und das ja auch konstantanpassen.

Speaker 4 (26:01):
Genau.

Speaker 3 (26:02):
Und ich glaube, das ist etwas, was in Organisationen
ja notorisch schwerfällt.
quasi Die rationale Anpassungan Gegebenheiten ist nicht
unbedingt immer das Nummer einsKriterium.
Und genauso glaube ich, häufiggibt es ja bereits Dinge, die
über Zeit gewachsen sind.

Speaker 2 (26:21):
Auch Software wächst ja über.

Speaker 3 (26:22):
Zeit.
Also ich stelle mir jetzteinfach ein Startup vor, das
macht eine App, und die sindfünf Leute, und dann machen die
erst mal, und man hat ja nichtimmer quasi den Luxus und die
Ressourcen zu sagen okay, großerWurf, unser digitales Ding soll
jetzt international werden wiemachen wir das am besten?
Also, es sind jetzt zwei Sachen.
Es ist einmal quasi so wieändern wir denn diese Struktur,

(26:43):
wenn sie einmal schon malbesteht?
ist sie wirklich so flexibel?
Und das andere ist wie ändernwir denn überhaupt eine Struktur
, die gewachsen ist, um dann zusagen ach so, und jetzt müssen
wir aber nochmal umdenken unddieses Konstrukt logisch umbauen
.

Speaker 4 (26:56):
Also ich glaube, was da hilfreich ist du hast es
schon implizit gesagt nämlichdas implizite explizit machen
und das regelmäßig tun.
Also genauso wie ich nichtüberrascht sein darf, wenn ich
jetzt nicht in Qualität in meineSoftware investiere, dass quasi
dieses berühmte Technical Debtimmer weiter anwächst und ich
dann irgendwannQualitätsprobleme gebe, oh,
überraschung, überraschung.
Wir haben jetzt zwei Jahre langunser Produkt aufgebaut.

(27:17):
Wir sind ein Startup, wir habenhalt 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 freidiskutiert,
organisationsstruktur zu bauen,nur weil die Organisation
gewohnt ist, ihre Strukturenjetzt beispielsweise entlang von
Abteilungen zu bauen Marketing,vertrieb, administration,

(27:39):
product Marketing und und undunterschiedlichen Abteilungen
sich nicht grün sind, sondernwirklich zu gucken.
Okay, ich habe jetzt einenbestimmten Business Need.
Dementsprechend schaue ich wiekann ich diesen Business Need

(28:18):
softwareseitig herführen, alsoarchitektonisch und von der
Implementierung, und dann darauszu Schluss folgern wie muss ich
meine Teams aufbauen?
und das bedeutet dann alsKonsequenz was muss ich jetzt in
meiner Organisationseinheit,wenn ich jetzt ein klassisches
Unternehmen bin, das hat dannhalt irgendwie eine IT-Abteilung
mit 60, 70 Leuten wie muss ichda die Teams entsprechend
strukturieren und aufbauen, unddann wird es erst mal so gemacht

(28:40):
, und dann gucke ich vielleichtein halbes Jahr später drauf
passt die Architektur?
noch Muss ich vielleicht dieArchitektur abändern, weil die
Business-Gegebenheiten habensich geändert.
Also muss ich diese Teams wiederneu strukturieren, neu
zusammenführen.
Der kennt das bestimmt auch.
Früher gab es im agilen Umfeldden Dynamic Teams, approach und
Ähnliches.
Das geht alles in dieseRichtung hinein.
Jetzt nicht so sehr, dass manfluide Teams jetzt irgendwie

(29:03):
propagiert, weil Teamaufbaukommt auch mit einem Preis
einher, also mit implizitenKosten im Rahmen des Changes, im
Rahmen des Changes.
Aber am Ende geht es darum, ichmuss gucken, was baue ich da
für ein Software-System?
Weil, wenn ich weiß oder wennich jetzt mal annehme, als
Hypothese, dass Conway's Lawgültig ist, dann weiß ich, dass

(29:24):
meine OrganisationsstrukturAuswirkungen auf das
Software-System hat.
Also kann ich zurückrechnen undsagen, wenn ich weiß, wie mein
Software-System sein muss, weißich im umgekehrten Schluss auch,
wie die Organisationsstrukturdafür auch aussehen muss.

Speaker 5 (29:37):
Also, das mit Conway's Law ist natürlich sehr
zugänglich.
Ich bin bei einer Sache so nochnicht ganz dabei, eine Sache,
die du auch gesagt hast, Mary,und zwar, dass Organisationen
nicht immer rational handeln.
Und ich würde sagen, das stimmtnur aus der Beobachterposition
heraus.
Womit ich dachte, wofür wirdiskutieren dieses, was kommt?

(29:57):
zuerst Technologie,Organisation muss man aus der
systemtheoretischen Perspektivesagen, das ist eine Scheinfrage.
Diese Frage stellt sich garnicht in Organisationen.
Organisationen sind jaautopolitisch, sie sind
selbstreferenziell, und damitsind sie auch gar keine lineare
Entwicklung, sondern sieentwickeln sich ja immer erstmal
anhand ihrer inneren Operation.
und dann stellt sich ja alsobei der Frage um Veränderung ist

(30:22):
ja, wie die Organisation istund wohin sie zweckrational
gestalten konnte, ist ja dieKernfrage, ist, wie kann man ein
Thema, etwas Neues übersetzenin die Logik der Organisation,
dass sie sie überhaupt operativverwerten kann?
Wir wissen ja, Organisationensind ja nichts anderes als die

(30:43):
Strukturierung vonEntscheidungen.
So funktioniert Organisationen,Also die Entscheidung.
wir wollen unsere Organisationvon einer funktionalen
Aufbauorganisation hin zu einerprozessorientierten, mehr
ablauforientierteren Logikbringen, Und deswegen verstehe
ich also, bei dem Team Topologyist es so, ich verstehe das auch
so kognitiv und so weiter.
Aber ich glaube, was oft dieHerausforderung sein wird, ist

(31:05):
ja, wie schaffe ich es, dieseLogik operativ für eine
Organisation anzuwenden, Weilich glaube, die meisten Ideen
scheitern genau an dieses.
okay, wir können jetzt damitarbeiten.

Speaker 4 (31:17):
Ja also was einfach mal so aus dem Nähkästchen
geplaudert, warum wir auch dieseWorkshops ganz gerne machen?
weil das oftmals die ersteGelegenheit ist in der
Organisation, dass mal dieeinzelnen Abteilungsleiter
zusammenkommen und sich nichtüber Word-Dokumente austauschen,
indem sie ihre jeweiligenlokalen Ziele als Forderungen
eingespeist haben, sondern indemsie tatsächlich gezwungen sind,

(31:37):
mal in einem Raumzusammenzukommen, ihre Stakes
niederzuschreiben und gemeinsamzu priorisieren und am Ende zu
einem Ergebnis zu kommen.
Das heißt, der Prozessfluss desWorkshops ist so angelegt, dass
am Ende tatsächlich auch eineEntscheidung, eine gemeinsame
Entscheidung herauskommt, Undselbst wenn es Uneinigkeit gibt,
ist auch völlig in Ordnung,weil die es dann wenigstens

(31:59):
explizit dokumentiert.
Das ist so der eine Aspekt, denes bräuchte, Und das andere,
was es aus meiner Sicht auchimmer dabei braucht, sind die
passenden Personen mit Macht,also mit Entscheidungsmacht im
Unternehmen, die in der Lagesind, dann auch die
Entscheidungen in derOrganisation oder in dem
Teilbereich durchzudrücken.

Speaker 5 (32:15):
Das sind die zwei Komponenten, die es meines
Erachtens braucht zu machen,weil das ist das, was ich
sozusagen in meiner Praxiserlebe.
Wir arbeiten ja immer imZwischenraum zwischen hier ist

(32:37):
ein auf dem Papier gute Idee,die muss so sein, also weil ich
kann ja keine schlechte Idee aufdem Papier malen, und das sind
die Gegebenheiten.
Und von mir aus der Chef, derwürde gerne das, aber das geht
nicht, weil da ist nochmal dasda, und die beiden haben
mikropolitischeHerausforderungen an dem hängen,
aber viele Kunden, und wenn dergeht, gehen drei Mitarbeiter
mit, bla, bla, bla.

(32:57):
Also ich glaube, das ist jadann, wo Realität und Papier
aufeinander prallen.
Und dann ist die Frage wie musseinen Weg nach vorne gestalten,
schauen, wie insbesondere auchauf dieser Management-Ebene
gemeinsam über das Design in soeinem Meeting dafür zu sorgen,
dass es dann halt heißt okay,der macht aber nicht mit, der

(33:17):
zieht nicht mit.

Speaker 4 (33:18):
Und da sage ich halt, da braucht es halt einen
Obermufti und wenn es der CEOist, der irgendwie ein paar

(33:56):
Millionen im Jahr verdient, dannsoll er jetzt mal für sein
Schmerzensgeld arbeiten und haltjetzt mal eine Entscheidung
treffen.
Und die Entscheidung ist dannaber nicht die
Personalentscheidung, sonderndie Entscheidung ist die
Systementscheidung.
In diese Richtung gehen wir,weil dann am Ende entscheidet
idealerweise der eine Managerselbst, indem er sagt na gut, da
kann ich nicht mitgehen, dagehe ich jetzt.

Speaker 3 (34:15):
Beispielsweise Ich glaube, wir haben erst bisher
quasi über den Grundsatzgesprochen, und jetzt kommen wir
ja quasi wieder in dieTransformationsfrage.
Also, ich glaube, auch wirmüssen unterscheiden zwischen so
wäre es gut, und weil wir jadann solche Themen haben, wird
es auch nicht perfekt dann sosein.
Also, wenn wir damalsmittendrin sind, gibt es ja
immer Abweichungen von dem, wasman als Ziel sich mal gesetzt

(34:36):
hatte.
Ich glaube, da trifft ja danneinfach die Realität Auch die
Informalität schlägt ja dann zu.
Also weil diese Konzepte, diewir bis jetzt besprochen haben,
das sind ja immer Sachen, diesehr auf der formalen Seite der
Organisation verortet sind, undquasi Leute setzen sich ja gerne
auch über die formalen Themenhinweg oder bauen selber Sachen
da drauf, und das ganze ThemaInformalität ist in diesen

(34:58):
Konzepten ja gar nicht so sehrverarbeitet.

Speaker 4 (35:01):
Kann sie auch nicht, geht gar nicht.
genau Das ist ein wichtigerTeil.
das kann ich mögen.

Speaker 5 (35:07):
Vielleicht zu dem, was du gesagt hast.
Ich glaube, was auch wichtigist eine neue Informalität lehnt
sich da an.
Also, es ist ja sozusagen, auchdie informale Struktur wird
sich ändern.
Nur natürlich, alsGestaltungselement 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 (35:28):
Dann macht doch ihr mal total gut.
Kollegialität, wie wär's Dasfunktioniert?
nicht Hä, was willst du von mir?

Speaker 4 (35:36):
Ne, so typische Themen.
Jetzt gerade bei dynamischerTeamzusammensetzung, die wir
oftmals in Unternehmen vorfinden, ist halt, der eine
Abteilungsleiter hat so und soviele Mitarbeiter in dem
Verantwortungsbereich, derandere so und so viele
Mitarbeiter in demVerantwortungsbereich, weil es
funktional getrennt ist, unddann sagt aber plötzlich der
Blick auf eine guteSoftwarearchitektur nee, nee,
nee, nee.
Einfaches Beispiel.
Dann gibt es halt da oftDiskussionen ja, aber der

(36:15):
Mitarbeiter, dem gebe ich jetztextra Zeit dafür, dass der in
der anderen Abteilung mitspielendarf.
Das ist totaler Quatsch.
Also, er ist auch nicht mehrmodern, sozusagen seine Struktur
so aufzubauen.
Und das ist halt genau derPunkt, auf den ich hinaus will.
Wenn die Art und Weise, wie dueine gute Software baust, dir
dann am Ende zeigt, naja, eineGesamt-Team-Struktur wäre
vielleicht besser, ja, dann istdas halt so, und dann kannst du

(36:37):
dich immer noch dafürentscheiden, das anders zu
lassen, dann hast du aberSchmerzen auf dem Weg dahin
worden sind, die Kommunikationnachgebildet haben, so
typischerweise Schaufel-PC.
In der Nacht wurde vom altenERP-System, wurde dann irgendwie
Daten rübergeworfen über einensogenannten Schaufel-PC, der

(36:59):
auch nur von der einen Abteilungangefasst werden darf, weil die
beiden Abteilungsleiter nichtmiteinander gut gesprochen haben
.
Solche Beispiele Und sowas gibtes mit Sicherheit auch heute
noch irgendwo im typischdeutschen Mittelstand, von oben
nach unten, an jeder Ecke, unddas ist halt einfach nicht
wertschöpfend.

Speaker 3 (37:17):
Mit Sicherheit.
Ich frage mich da manchmalwirklich ich finde, auch dieses
Thema das kommt zurzeit auchsehr häufig vor.
Wir haben da mit Stefan Schulzdrüber geredet, mit Judith
Muster und diversen anderen,jetzt ihr gerade mit Klaus Dörre
Dieses Thema werdenFührungskräfte in ihrer Rolle
als Führungskraft zurVerantwortung gezogen?

(37:37):
Ich finde das sehr, sehrspannend, auch aktuell, quasi
diese gerade auch in dieserganzen Debatte mit Leute sollen
länger arbeiten, also zweiStunden mehr die Woche und
später in Rente gehen und soweiter.
Wir müssen jetzt alle hierunsere Verantwortung tragen, und
dann hat man manchmal so Sachen, wo man denkt, wer hält die
jetzt dafür verantwortlich?
dass es eigentlich quasi imUnternehmenskontext Quatsch ist,
was hier gerade passiert, unddann hat man so diese

(37:57):
Befindlichkeiten gegeben.
Ich glaube, darüber sprechen wirauch häufig.
Ich würde gerne einendraufsetzen und quasi eine Frage
formulieren für eineExtrasituation.
Wir haben jetzt vermehrt inUnternehmen die Situation, dass
der Digitalisierungsbedarf sogroß ist, dass die

(38:17):
IT-Abteilungen sagen, das könnenwir nicht leisten, das ist
nicht möglich, und auch, dassman sagt naja, also dafür jetzt
überall noch eine Beratungreinholen.
Das wird auch ganz schön happig.
Wir müssen also und da spieltuns ja AI jetzt in die Karten
Leute enablen, dass sie selbstdigitale Lösungen machen können,

(38:39):
und dann hat man sowas, dasnennt sich Citizen Developer.

Speaker 4 (38:41):
Ja, Low-Code und so.

Speaker 3 (38:42):
Genau also, wo Menschen ohne
Programmierungserfahrung aufNo-Code oder
Low-Code-Plattformen, ohneselbst programmieren zu müssen,
so Drag-and-Drop-Sachen selbstzum Beispiel Applikationen bauen
können Und das passiert aberjetzt überall in der
Organisation theoretisch möglich.
Ich glaube, auch das ist einbisschen leichter gesagt als
getan.
Also, man stößt da, glaube ich,sehr schnell an seine Grenzen

(39:04):
quasi, was so eine Plattformdann tatsächlich irgendwie
abbilden kann, durchaus, und diekennen wir auch sehr
erfolgreiche Beispiele, wo Leutesich 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 genugwar, und das ist jetzt

(39:26):
irgendwie einfach da.
Wie verarbeiten wir jetzt sowasin der Organisation?
Weil das ist ja nicht in derregulären Organisation, das ist
auch nicht in der regulurenITler mehr bezahlen, sondern der
Sachbearbeiter aus AbteilungXYZ.

Speaker 4 (39:56):
Der kann jetzt einfach mit Drag Drop sich die
80 Prozent war ja immer so einThema selber designen.
Der kann auch gut mit Excel Jagenau kann auch gut mit VBA und
so weiter ist ja das klassischeThema.
Ist ja programmiert, oder hierdiese Windows-Formular
Geschichten, auch von vor 20Jahren.
Jetzt merke ich gerade, wie altich bin.

Speaker 5 (40:17):
Wir alle sind alt außer.
Harry.

Speaker 4 (40:18):
Genau.
Dazu kann man einfach sagen AImacht diese Branche kaputt, Ich
wollte gerade ein Hot-Takeraushauen.
Aber ist so.
AI wird Code kaputt machen.

Speaker 5 (40:30):
AI wird Code kaputt machen.

Speaker 4 (40:32):
Nee, das glaube ich jetzt nicht, aber so ungefähr,
weil das ist ja die großespannende Frage.
Jeder will immer denSenior-Developer haben.
Aber wie wird einSenior-Developer zum Senior?
durch viel Erfahrung.

Speaker 5 (40:43):
Wie er alt wird.

Speaker 4 (40:44):
Ja, genau Ja genau, und wenn die AI sozusagen die
Arbeit der Juniors oder deretwas Midterm, also bis in die
Midterms hineinreicht, dann hatder Mensch ja gar keine
Entwicklungsmöglichkeiten mehreinerseits, Dann entwickelt sich
niemand dadurch, was er machenkönnen muss, um ein Senior zu
werden.

Speaker 3 (40:56):
Genau das ist das eine.

Speaker 4 (40:57):
Und wenn man aber jetzt sagt okay, ai kann diese
Junior-Geschichten, das ist jader City, der ist ein Developer,
der ja gar nicht programmierenkann.
Also ist für mich die logischeGleichung und die logische Folge
das wird die Code Plattformkaputt machen.
Ja, ich meine, wir derailen malkomplett, aber ich will einen
drauflegen, ich will jetzt maleinen drauflegen.

Speaker 5 (41:16):
Ja mach, weil ich lege da noch einen drauf, Und
zwar vielleicht ist ja gut, dassDeutschland die Digitalisierung
der letzten 20 Jahre verpassthat.
Jetzt können sie auf den AI-Zugaufschwingen und so einen
Leapfrog machen.

Speaker 4 (41:26):
Ja voll.

Speaker 5 (41:27):
Fingers crossed.

Speaker 4 (41:28):
Ja, weil es gibt.
Jetzt, tatsächlich hat mir meinCTO-Kollege Johann schöne Grüße
an dich vorhin auch nochmalerzählt, wir hatten es letzte
Woche.
Davon gibt es einenAI-UI-Ansatz, also ein System,
wo die AI GUIs bedienen kann.
Und damit sind wir schon beiLow-Code-Systemen.
Was ist ein GUIs?
Graphical User Interface, alsoquasi Benutzeroberflächen von

(41:49):
Web-Anwendungen, das, was dugerade reinguckst, genau.
Und da kannst du eine AIsteuern, weil die kann
interpretieren, was passiertdenn da?
Ich sehe da hier irgendwie dreiScreens mit Menschen drauf, und
da oben rechts gibt es denButton, da steht Rack drauf.
Wenn ich da jetzt draufklickenwürde, würde das passieren.
Das kann die interpretieren,und die Logik kann man sich
zunutze machen, indem man der AIhalt Befehle gibt oder sagt,

(42:09):
ich will das und das Resultatmachen, und dann findet die sich
selber in den Anwendungenzurecht.
Also, solche Sachen bauen wirzum Beispiel auch hatte ich ja
beim letzten Podcast ja auchschon erzählt.
Das hat mittlerweile eine Reifeerreicht, wo man sagen kann
okay, jetzt wird es spannend fürgenau diese Anwendungsfälle.

Speaker 3 (42:26):
Also, das löst für mich das Citizen Developer Thema
so weit, dass sie selber nichtdiesen Sprung machen müssen von
Drag Drop zu.
Doch ich muss doch selber einbisschen was machen, weil da
unterstützt ein AI.
Aber das löst ja nicht dasProblem, dass trotzdem irgendwo
Anwendungen aufploppen.

Speaker 4 (42:42):
Ja, genau Das war der andere Punkt, wo ich noch wir
sind ja gerade so ein bisschenderailed- Ja, lass uns gerne
derailen.
Nochmal hier zurück zum ThemaDas.
Nochmal hier zurück zum ThemaDas.
Was du meintest, mary, war dasThema, dass halt dezentral
überall Sachen aufploppen.
Und die Frage, die dahintersteckt, ist wie kann ich jetzt
als Unternehmen dann das Ganzewieder auf den richtigen Pfad
der Erleuchtung bringen,sozusagen, dass das alles gut

(43:07):
läuft in Anführungszeichen untergewissen Zielsetzungen, und
dann immer wieder regelmäßignachzugucken und ins gemeinsame
Gespräch zu gehen?
Das heißt, alignment erzeugstdu ja durch übergreifenden
Austausch und durchübergreifende gemeinsame
Zielentwicklung.
Da gehen ja alle Frameworks,methoden, egal was du dir

(43:32):
anguckst, ob das OKA ist oderandere Dinge, die basieren ja
alle darauf, dass man sagt okay,man hat zwar einen gewissen
Freiheitsgrad in derDezentralität, weil das einfach
unweigerlich so ist, dass an derEcke da drüben, weil ich da den
Markt bearbeite, irgendwasentsteht, und an der Ecke da
drüben, wo ich auch den Markt,aber einen ganz anderen
bearbeite, entsteht auchirgendwas.
Nachgucken und Gelegenheitenschaffen, an denen man quasi

(43:52):
zentral oder zentralerzusammenkommt, sich austauscht
und gemeinsame Erkenntnisseschafft und auf der Basis die
Erkenntnisse wieder einspielt indas lokale dezentrale System.
Und es gibt Techniken.
Wenn ich jetzt mal gucke wirbauen ich hatte es ja eingangs
gesagt beispielsweise großeDatenintegrationsplattformen.
Auch da ein typisches Beispielin der Vergangenheit hat man

(44:13):
immer gedacht ja, ich muss dannalles zentralisieren, riesige
Datenzentralisierungsprojekte,die nicht geholfen haben.
Wir bauen solche Sachen nachdem Data-Mesh-Prinzip.
Data-mesh bedeutetdezentral-zentral, das heißt,
ich habe die Governance, dieGuidelines habe ich zentral, ich
habe zentral eineStreaming-Architektur, und ich
lasse die Datentöpfe.
Dezentral lasse ich sie sein,wie sie sind, weil in der

(44:35):
Dezentralität gibt es eineVerantwortlichkeit, also quasi
Data as a Product sozusagen, unddie Zwischenschicht sorgt dafür
, dass die Daten harmonisiertwerden, dass sie gut zur
Verfügung gestellt werden undähnliches, obwohl ich die
dezentralen Datentöpfe habe.
Und damit bin ich erstensschneller, weil ich kann das
Dezentrale erstmal so seinlassen, wie es ist, und ich habe

(44:56):
aber trotzdem einen zentralenZugriff ermöglicht, sogar noch
mit Dingen wieDatenharmonisierung und ähnliche
Geschichten, und bin einfach inmeiner Time-to-Market deutlich
schneller am Markt.
Und das sind so Grundprinzipien, die Organisationen fahren
müssen.
Und da geht dann eben halt auchdiese Überlegung mit einher wie
muss meine Teamstruktur dafüraussehen, meine
Organisationsstruktur?

(45:16):
Weil gerade bei dem Thema ist esdann wichtig zu gucken, wenn es
jetzt heißt, data is a Product,ja, was heißt das denn für die
einzelnen Betreiber dereinzelnen 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 dakomme ich wieder zum Ursprung
zurück.
Ich gucke auf meineSystemarchitektur Wie sieht mein
System aus?
Und auf der Basis organisiereich mich.

Speaker 3 (45:38):
Das stimmt Yay wo wir uns inspirativ inspirieren
lassen.
So, Sachen wie zum BeispielTeam Topologies, wo man da ja
drüber geht.
Ich glaube, der ganzeSoftwarebereich ist eben ein

(45:59):
Bereich, weil da alles man siehtwie die Sachen miteinander
zusammenhängen.
Ich weiß nicht, wie plakativ dasist, aber wenn eine Komponente
fehlt, dann gibt es dieseFunktion nicht, und dann ist das
am Ende nicht da und nichtbenutzbar, weil es wurde nicht
hergestellt, sozusagen.
Und ich glaube, dieser Ansatzzu gucken, quasi wir gehen vom

(46:21):
Business-Need über dentechnologischen Need zur
Organisation, ist ja schon was,was wir genauso machen, auch
also nicht unbedingt da, istnicht unbedingt die Technologie
immer noch dazwischen, weil essind halt vielleicht auch andere
Sachen, aber man guckt ja schonquasi, was ist der Zweck und
was sind die Gegebenheiten, indenen man das machen muss, und
was ergeben sich daraus fürAnforderungen an die
Organisation.
Und ich finde das immer so schön, weil das Software quasi, weil

(46:43):
da weiß ich, da fehlt es aber inanderen Bereichen irgendwie.
Da wird so viel verschwindendie Kanten aus ein bisschen, und
dann macht jemand da noch einbisschen mehr, und da noch ein
bisschen, und dann weiß man garnicht so richtig.
ist das jetzt richtig oder istdas nicht richtig?

Speaker 5 (46:58):
Und ja, Humanoid, du wolltest einsteigen.
Genau, ich wollte sagen, ichwürde das ganze Ding aber nicht
so linear sehen, sondern ich binschon dabei.

Speaker 3 (47:07):
Geht ja auch nicht, weil es ist ja alles schon da Ja
guck mal, ich glaube, die Logikist auch vielmehr so.

Speaker 5 (47:12):
Es gibt eine Außenwelt, und die können wir
mal einfach wenn wir bei dieserSprache bleiben wollen als ein
Problemsystem betrachten, unddie gilt es ja darum, erstmal zu
umreißen und zu verstehen, wasist das?
Und dann sind wir ja beiConway's Law und sagen, damit
wir dieses Problem gut lösenkönnen, brauchen wir ja nach

(47:32):
innen ein System, das dem ganzeinfach gesagt gewappnet ist.
Baue ich ein minder komplexesSystem, dann können wir dieser
Problemlösung gar nicht gerechtwerden.
Das ist ja wie man über Conwayso argumentieren könnte, und
dann ist es ja im Grunde ganzviel hin und her.
Ich glaube, dann ist esStruktur und Technologie, also
die Möglichkeiten, strukturelleGegebenheiten, und dann glaube

(47:56):
ich, dort, wo Organisationenheute nicht gut sind, ist,
diesen Diskursraum konsequent zuhalten, sachen zu benennen und
Abweich.
Wir können nicht den idealenWeg gehen, deswegen gehen wir
den anderen Weg.
Das sind die Trade-offs, dassind die Widersprüche, da ist

(48:17):
sozusagen das Scheitern, aberlass uns damit produktiv umgehen
.
Und ich glaube, hier ist fürmich dort, wo Organisationen
weil das Lustige ist sogar imScheitern, sind Organisationen
mir zu technokratisch.
Also da müsste man wirklichsozusagen, man versucht, das
dann irgendwie einzuhegen und soalso anders, man versucht, es
nicht vernünftig einzuhegen,sondern dann versucht man immer
noch zu sagen ja, es ist immernoch optimal.
Also man redet sich,vereinfacht gesagt, dinge schön

(48:39):
an.

Speaker 4 (48:39):
Also du, hast gerade für mich was ganz Wichtiges
gesagt, nämlich Trade-Off.
Also am Ende ist jedeEntscheidung, die ich treffe,
hat einen Trade-Off, und das istwichtig, diese

(49:03):
Trade-Off-Entscheidung, weil mankann das dann im Rahmen von
einer gewichtetenEntscheidungsmatrix ausrechnen.
und trotzdem kann ich michimmer noch gegen die optimale
Architektur entscheiden, ausdiversen Gründen.
Aber dann sind die Gründeexplizit, und dann habe ich sie
bewusst auf den Tisch gebracht,und ich glaube, das ist das, was
in vielen Organisationenmangels Zeit, mangels was auch

(49:23):
immer nicht passiert, dass ebengenau diese Gründe, diese
Trade-offs, nicht explizit undbewusst gemacht werden.

Speaker 5 (49:29):
Ja, 100 Prozent.
Und ich finde es mega lustig,weil so wie du über die System
oder SoftwarearchitekturThematiken sprichst, genauso
arbeiten wir auf derOrganisationsstruktur.
Das ist tatsächlich identisch.
Ich glaube, das Spannende beiOrganisationsstrukturen ist aber
der Impact von Fehlern ist einschleichender Impact.

Speaker 3 (49:50):
Das meine ich mit dem quasi bei der Software.

Speaker 5 (49:51):
Da fehlt dann halt ein Stück, und bei den anderen
ist es so.

Speaker 3 (49:55):
Ist das jetzt ganz oder gar nicht, oder irgendwo
dazwischen?

Speaker 5 (50:01):
Ich glaube, die Fehler in der
Organisationsgestaltung oder dieVersäumnisse oder die
Inkonsistenzen und Inkoherenzenund das Nicht-Beachten von
Widersprüchen wird inOrganisationen dann im Grunde
kaschiert.
auf der Arbeitsebene Leuteschauen, dass der Laden
irgendwie läuft, da werdenÜberstunden gemacht, dann reden
zwei miteinander.
irgendwie kriegt man dasGedeichsel 17 Meetings oder
Projekt dauert zwei Jahre länger.

Speaker 4 (50:22):
Der klassische Kram?
Ja, auf jeden Fall.
Ich meine, bei derArgumentationskette, die ich
vorhin gebracht habe, da fehltnatürlich ein Teil.
Jetzt bist du dann am Enderausgekommen.
Für diese Softwarearchitektur,für diesen Zielzustand unseres
Systems in den nächsten sechsbis zwölf Monaten brauchen wir
folgende Teamstruktur, Und dannfängt ja die eigentliche Arbeit
erst an.
Also, da ist ja unter Umständenein Change-Prozess drin,

(50:44):
natürlich, und deswegen meinteich vorhin, es braucht Leute mit
Macht einfach mit dabei, mitEntscheidungsmacht, damit dann
gesagt werden kann okay, das istdie neue Teamstruktur.
Optimalerweise waren alle in derKette, die Untermacht hatten
sozusagen, waren mit beteiligt,haben diese gemeinsame Struktur
erarbeitet, weil dann ist es amleichtesten, aber nicht immer
hast du die mit dabei.
Dann hast du halt Folgefragenim Change im Sinne von okay,

(51:05):
jetzt bauen wir die Struktur aufund ähnliches.
Und da ist glaube auch nochmalganz wichtig zu sagen die
Zielstruktur, die stellst duauch nicht einfach so hin.
Also, wenn ich jetztbeispielsweise an eine
Modernisierung von einerPlattform denke, dann ist es
oftmals so wir kommen dann reinüber diese Workshops, da gibt es
sich so eine gewisseZielarchitektur, und dann ist es
oftmals so, als Pattern nimmtman dann sowas wie das

(51:28):
Pioneersteam, das heißt, wirbauen erstmal die neue
Grundstruktur des Systems auf,und dann holen wir sukzessive
Menschen aus den anderenBestandsteams holen wir
entsprechend mit rein.
Also, es ist quasi, ist haltein Team zu groß, dann musst du
Zellteilung machen, musst dichuntereinander aufteilen, und

(51:57):
dann ist irgendwann nach Zeit Xgibt es die alten Teams nicht
mehr, weil die sind in der neuenStruktur sozusagen iterativ
aufgegangen, weil du kannst dirnicht sofort das neue System
hinstellen, sondern das neueSystem ergibt sich und
entwickelt sich draus.
Und das ist jetzt nur einSzenario, weil es jetzt ein
Szenario bei einerSoftwaremodernisierung ist.
Wenn ich jetzt ein neues Produktentwickle, ist das Vorgehen

(52:17):
ähnlich, weil ich gucke, wiebrauche ich die Zielarchitektur?
Aber da habe ich vielleicht dieTeams noch gar nicht, muss die
neuer Markt heiern oder sowas?
Also, da muss man auch immergucken, 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 Xverdiene ich kein Geld, sondern
ich will ja das Produkt, denService, die Software, die ich

(52:40):
aufbaue.
Das gucke ich doch als erstesan Was bringt den Mehrwert?
Und dann schaue ich wie müssenmeine Teams gestaltet sein,
damit die diesen Mehrwertgenerieren können oder erstellen
können, aufbauen können, damitdann am Ende ein Schuh draus
wird.
Und das muss ich dynamischhalten und mich nicht in starren
Strukturen ergeben.

Speaker 5 (52:58):
Ich hätte nur eine lustige Anmerkung im Sinne von
das ist schon verrückt, dass dasetwas Kontroverses sein soll.
Diese Leute sind so say shit.

Speaker 3 (53:09):
Naja, aber es ist ja schwierig.
Es leuchtet ein, aber es istnicht einfach.

Speaker 5 (53:12):
Die Frage ist halt was ist der schwierige Teil?

Speaker 3 (53:15):
Es ist vor allem kontraintuitiv.

Speaker 4 (53:17):
Genau die Konsequenz.

Speaker 3 (53:18):
Also dieses, wie du sagst, da muss jemand die
Entscheidung treffen, oder wiedu sagst, huma, da muss man dann
auch gucken, woran scheiternwir gerade?
no-transcript, und das brauchthalt einfach Arbeit.

(53:45):
Das ist ein Ding.

Speaker 4 (53:47):
Bevor du deine Frage stellst, wollte ich nochmal
einhaken Roman, du hattestvorhin auch diesen informellen
Teil auch noch mitgebracht odermit in die Waagschale geworfen.
Ich glaube, auch da ist eswichtig, das zu benennen.
Also im Rahmen von solchenWorkshops man hat irgendwie die
Zielarchitektur vor sichentwickelt, jetzt gemeinsam, wie
müssten jetzt die Teams sein,dass man dann auch die
Widerstände sichtbar macht, diees vielleicht gibt, je nach

(54:08):
Kultur, vielleicht erstmal ineinem geschützten Raum, damit
man damit arbeiten kann.
Also deswegen arbeiten ja dieganzen agilen Leute das, was
viele Unternehmen nichtverstanden hatten in der
Vergangenheit.
Also viele dachten ja, wirmachen ein Lab in Berlin auf
einen Kicker hin, dreiWhiteboards und ganz viele
Post-its, und schon sind wiragil.
Das ist ja nicht der Zweck vonagil.
Der Zweck von agil ist auch,die Dinge visuell sichtbar zu

(54:29):
machen, weil nur, wenn du in derVisualität arbeitest, kannst du
auch damit arbeiten.
Und wenn ich in der Lage bin,meine Befindlichkeit
aufzuschreiben, dann bin ich derMeinung, dann habe ich schon
mal den ersten Schritt zurVersachlichung der
Befindlichkeit getan und bineinen Schritt aus der
Emotionalität raus, und damitsind die Punkte besser
bearbeitbar für dieGesamtorganisation.
Und da muss ich halt gucken,dass die Raum finden und ich sie

(54:51):
einarbeiten kann.

Speaker 3 (54:52):
Ja, das ist natürlich immer schwer zu machen, weil
viele Dinge der Informalitätsind ja oft nicht ansprechbar.

Speaker 1 (54:59):
Deswegen sind sie ja informell, und das ist dann
natürlich auch nochmal eineHerausforderung.

Speaker 4 (55:02):
Aber dafür hat es ja ein Beobachter von außen, wie
wir ja wissen.

Speaker 3 (55:05):
Genau da können wir helfen.
Exakt, Meine Frage war so einbisschen, weil du jetzt vorhin
nochmal von der Zellteilung undwenn das dann größer wird,
gesprochen hast, und vorherhatten wir das Thema Alignment,
weil, je mehr Zellen oder Teamses gibt, dann gibt es ja auch
immer wieder dieseAlignment-Frage, das, was wir am
Anfang hatten, autonomie versusAlignment, und Und Nils
Pfleging hat mal irgendwanngesagt, eine Organisation kann

(55:28):
nur irgendwann so und so großsein, sonst sagen wir halt
Organisation dazu, abereigentlich ist es eine Stadt
oder so, also eigentlich ist esirgendwas anderes mit ganz
vielen Organisationen da drin.
Das ist dann auch nicht mehrgut zusammenführbar.
Gibt es für dich irgendwo soeine Grenze, wo du sagst ab, da
sagst du, eigentlich, das machtkeinen Sinn, dass wir an der
gleichen Software arbeiten,sondern vielleicht sind es

(55:48):
einfach zwei.
Also sagst du, irgendwo brichtdas.

Speaker 4 (55:51):
Ganze.
Ja, es gibt ja diese berühmteGrenze mir fällt jetzt leider
der Name nicht mehr ein vorlauter Fachbegriffen von 150
Personen, ab denen du in derLage bist, überhaupt noch mental
zu begreifen, wer ist denn diePerson, und die zu kennen.
Ist das Dunbar's Number?
Ja, genau, danke, danke,dunbar's Number.
exakt, nachdem ja auch diverseUnternehmen, die man so in
diesem Beta-Codex-Network und soweiter als Case-Study findet,
hire und so weiter, die sich jaalle quasi teilen, wo dann

(56:15):
gesagt wird okay, ab 150 machenwir also in Vor-Corona-Zeiten
einen neuen Standort auf, oderwir machen ein neues
Subunternehmen.

Speaker 3 (56:22):
Ja, Gore-Tex ist zum Beispiel super bekannt die immer
so maximal 150 Leute an einemStandort haben.

Speaker 4 (56:27):
Also grundsätzlich würde ich mir die Frage stellen,
warum ich beispielsweise 2000Personen für ein Softwareprodukt
benötige.
Das geht jetzt für mich mentalnicht unbedingt überein und
würde ich sagen okay, istvielleicht das Produkt zu
komplex?
Also, bei Word würde ichvielleicht nochmal nachgucken,
warum Erzähl das nicht Microsoft, genau, Genau.
Und ansonsten ist das haltdiese Autonomie, dass man halt
sagt naja, okay, dann ist haltein Team dafür verantwortlich.

(56:50):
Nehmen wir jetzt mal alsplastisches Beispiel, amazon bei
der Website dafürverantwortlich zu zeichnen, wie
die Such nicht einfach machenund tun, was sie wollen, sondern
Amazon möchte logischerweiseGeld damit verdienen.
Also muss die Product Discoveryjetzt als ganz, ganz einfache

(57:12):
Metrik darauf ausgerichtet sein,und dann können die halt tun
und lassen, was sie wollen.
Und wenn sie schlau sind oderdas systemisch so angelegt ist,
dann lernen sie halt überProduct Feedback.
Das heißt, sie kriegen Feedback.
Ist die Suche jetzt scheißeoder ist sie nicht scheiße?
Und wir wissen alle, dass dieSuche auf Amazon ziemlich doof
ist.
Aber Amazon hat es haltvielleicht an ein paar Stellen
nicht nötig, weil sie so eineMarktmacht haben, dass sie dann

(57:34):
nichts großartig verbessernmüssen.
Aber am Ende des Tages sind dashalt independent Teams, die
dann halt entlang von einergroben Metrik arbeiten, und der
Rest ist haltEigenverantwortlichkeit, und
damit kriegst du es skaliert.

Speaker 3 (57:45):
Also im Prinzip ist es eine rekursive Struktur, wo
du sagst, es gibt Teams, diekümmern sich um Sachen, die
haben einen Auftraggeber, danngibt es eine Gruppe von
Auftraggebern, die haben einenAuftraggeber, und so weiter, und
da quasi geht das dann soweiter.

Speaker 4 (57:57):
Nein, also bitte keine Menschen rein, weil Mensch
ist immer langsam, sondern ichbrauche irgendwelche KPI-Met.
Ich sage okay, da müsst ihr hinoptimieren, also beispielsweise
Umsatz oder Profit.
Also es muss quasi einenWertbeitrag liefern, und dann
kann das Team, dasSubsystem-Team, das für die
Suche verantwortlich ist, tunund lassen, was es will,

(58:17):
technologien nutzen und lassen,was es will, hauptsache, es hält
sich an bestimmte übergreifendeMetriken, wie jetzt System.
Also technologisch gesprochenwir arbeiten in Self-Contained
Systems, wir haben Stateless undso weiter und so fort mit dabei
.
Das sind dann so technischeübergreifende Kriterien oder
auch keine Ahnung.
Wir müssen natürlich einenWertbeitrag schaffen, dass wir

(58:37):
den Umsatz steigern oder dasswir die Auffindbarkeit von
bestimmten Produkten steigern,aber ich würde das nicht als
Verkettung von menschengemachtenZielen machen, weil das ist per
se immer langsam.

Speaker 3 (58:49):
Ich glaube, mensch muss es gar nicht sein, aber
irgendjemand gibt dir jetztEntität oder irgendwo kommen
diese Zahlen her und müssensozusagen entschieden worden
sein, und das würde ich jetztals eine Auftraggeberstruktur
bezeichnen.

Speaker 4 (59:01):
Aber ob das ein Mensch ist oder ob das eine
übergeordnete Funktion ist oderein Kunde Oder eine AI.
Unter Vorlage der folgendenDaten und Metriken ist eure neue
Zielvorgabe folgendes Lass unsda doch schon mal nochmal rein
teasern.

Speaker 3 (59:17):
Du meintest ja vorher , wer weiß, AI wird das sowieso
alles über den Haufen werfen.

Speaker 4 (59:22):
Ja, wird es.

Speaker 3 (59:24):
Low.

Speaker 4 (59:25):
Code.

Speaker 3 (59:27):
Noch da ganz davor meintest du mit der
Geschwindigkeit.
Das wird quasi sowieso so einenEinfluss darauf haben, dass das
vielleicht nochmal ganz eineneue Frage aufwirft.

Speaker 4 (59:35):
Also unabhängig davon , ob es jetzt stimmt oder nicht
stimmt oder nur zu 50 Prozentstimmt oder so, wenn wir wissen,
dass die AI vieles möglichmachen kann, dann bedeutet das,
Vorgänge, die vorher Tagegedauert haben, dauern
vielleicht jetzt nur nochStunden oder ähnliches.
Also ich hatte ja im AI-Podcastvon einem konkreten Projekt
erzählt.
Da haben wir jetzt mittlerweileauch eine ganze Reihe an
Metriken.

(59:56):
Wo vorher ganz viele Menschengebraucht worden sind, wird eine
bestimmte Menge von einersechsstelligen Zahl in wenigen
Stunden quasi bearbeitet.
Das heißt, ich habe einfacheine gewisse Beschleunigung.
Das heißt nicht, dass ich aufdie Menschen und Mitarbeiter
verzichte, sondern dass einfachdie Dauer von Problemstellung
bis zum Ergebnis, dass die,kürzer wird.
Deswegen sagt man auch also ichhabe vor kurzem auf LinkedIn war

(01:00:18):
ich in der Diskussion drin, daging es darum, irgendjemand fand
das so toll, dass irgendjemandanders gesagt hat Jan, eine KI,
die muss auch eine Personalaktekriegen und Zielvereinbarung und
so weiter.
Wo ich?
dann meinte du, es machtüberhaupt keinen Sinn, mit den
Instrumenten, mit denen wirMenschen vielleicht führen oder
nicht führen, eine KI zu führen,weil, bis du die Personalakte

(01:00:39):
aufgeschlagen hast, quasi auchbildlich gesprochen, ist die KI
schon fünfmal fertig, weileinfach das Maschinen sind.
Da sind keine Menscheninvolviert, wo Befindlichkeiten,
kommunikationsschwierigkeitenund so weiter dazwischen sind.
Und das ist der Grund, weswegenman auch eher vom Resulting
nennt und weswegen wir uns aufdiese Agentensysteme
spezialisiert haben in derEntwicklung, weil wir gesagt

(01:01:00):
haben ja, okay, am Ende geht esdarum, ich habe eine
Problemstellung, und der Agentliefert mir ein Resultat, und
wie er dahin kommt, hängteigentlich nur davon ab, wie er
Zugriff auf die einzelneninternen Systeme hat, und
ansonsten macht er einfach.
Und die Idee ist ja, das zubeschleunigen, weil wenn ich,
geht es darum, wie schaffe iches dadurch, schneller zu agieren
?
Und deswegen wird KI halteinfach vieles verändern,

(01:01:32):
umwälzen.
Und die beste Möglichkeit istwie bei agiler Transformation,
wo wir auch damals gesagt haben,du musst die Welle reiten.
Nur, da haben Menschen dieWelle geritten.
Jetzt ist es so, dass Maschinendie Welle reiten.

Speaker 5 (01:01:45):
Ja, ich glaube auch ist es so, dass Maschinen die
Welle reiten.
Ja, ich glaube auch, wir wollenjetzt kein KI oder AI-Podcast
draus machen, aber ich glaube,der Impact auf Organisationen
und dazu werden wir demnächstmal einen Podcast machen, mary,
ich bin da schon bei jemandemdran ist so immens aus meiner
Sicht.
also ich nehme mal eintechnisches Thema, vielleicht
kannst du mir das einordnen.
Heutzutage zum Beispiel imBereich Enterprise-Architektur

(01:02:06):
Unternehmen, die immer wiederAnwendungen entwickeln, und so
weiter, ist es ja so, dass dieEnterprise-Architektur eher so
ein Showstopper ist.
Die machen so einArchitekturfeld, passt das oder
passt das nicht?
dafür müssen die LeuteKapazitäten haben und so weiter
und so weiter.
eine künstliche Intelligenz ihrkennt ja den Architekturfett,
klar, eine Person muss drübergucken, das freigeben.

(01:02:27):
aber das wird ja die Logik, wieEntscheidungen und so weiter in
Organisationen getroffen werden, ja signifikant verändern.
Da hast du ja eine ganz andereTime-to-Market-Ebene, dass ein
KI überhaupt sieht, geht das indie richtige Richtung oder nicht
?
Das ist ja eine ganz andereLogik, als wir heute agieren.

Speaker 4 (01:02:44):
Auf jeden Fall, vor allem, weil
Architekturparadigmen oderMethodiken, weil die ja
kodifiziert sind, und alles, waskodifiziert ist, lässt sich ja
gut verarbeiten von der Maschine.

Speaker 5 (01:02:55):
Das ist ja radikal.
Also überleg mal heutzutage soein Architekturgremium trifft
sich alle zwei Wochen, einmal imMonat.
Da tauschen sie sich mal aus,da kommt das mal rein.
Das ist Nein, das ist ja so einEntscheidungsstopper.
Die Richtung, in der sich dortdie Dinge entwickeln, ist
unglaublich.
Also ich bin da sehr begeistert.

Speaker 4 (01:03:12):
Ja, vor allem widerspricht das auch jeglicher
Agilität.
Also im Agilen sagt man ja auch, dass diese zentralen
Architekturgremien von Bedeutungverloren haben, wenn man seine
Teamstruktur richtig gesetzt hat, weil man sagt, man hat nur die
übergreifendenArchitekturparadigmen, auf die
man sich gemeinsam vereinbart,und ansonsten willst du ja diese
autonomen Teams quasi haben,damit die schnell arbeiten

(01:03:33):
können.
Und AI beschleunigt, glaube ich, diesen Change, weil AI halt
eine Technologie ist, die dasmöglich macht.
Und dann komme ich am Endeirgendwann drauf, dass ich sage,
ja, ich brauche dieses zentraleGremium gar nicht, unabhängig
davon, ob das eine AI oderMenschen sind, weil der
eigentliche, die eigentlicheIdee ja ist, die
Architekturentscheidungen lokalim Team zu machen und nur

(01:03:56):
übergreifend gemeinsam sich zuvereinbaren.
Aber eine AI könntebeispielsweise die Code
Repositories der einzelnen Teamsanalysieren und auf Basis
dessen also ich spinne jetzt malwirr, keine Ahnung, wie viele
Weine ich jetzt gerade intushabe aber auf Basis dessen
vielleicht Vorschläge machen,wie übergreifende Architektur

(01:04:17):
Vereinbarungen lauten sollten,weil es einfach Code und die
Bewegungen im Code also durchdie Commits und so weiter
gemeinsam analysiert worden sindund daraus Vorschläge entstehen
für die Teams.

Speaker 3 (01:04:27):
Du hattest es vorher kurz angesprochen, dass
theoretisch die Juniors jaersetzt werden könnten.
Aber die Frage ist können dieSeniors irgendwann auch ersetzt
werden?
Also jetzt, ohne das irgendwieals Teufelsbild an die Wand zu
malen, sondern eher quasi dieFrage ist für mich was bedeutet
das auch für einenKompetenzaufbau oder eine
Wissenssicherung in einemUnternehmen, wenn wir jetzt

(01:04:48):
sagen, eigentlich sind dieunteren und mittleren Rollen,
das ist ersetzbar Und das, waswir dann brauchen ich glaube,
das hattest du im letztenPodcast gesagt jetzt fragen wir
gerade die KI, weil die dairgendwie Wissen hat, das wir
nicht haben, und in Zukunft wirdes vielleicht so sein, dass die
KI uns als Experten fragt.
Aber das bedeutet auch, damüssen auch Experten sitzen Sein
.

Speaker 4 (01:05:08):
ja genau.
Also, ich glaube, nichts wirderstmal 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 einfachschlichtweg zur Verfügung
stellen und sagen bitte, damitarbeiten.
Bei uns ist halt eher so dasThema, dass unsere Kunden das
nicht unbedingt immer wollen.
Das heißt, da schlägt auch soein bisschen die Realität mit

(01:05:31):
rein.
also zwischen dem, was technischmöglich ist, und dem, wie die
Organisationen ticken undfunktionieren, weil da
vielleicht noch Ängste sind.
oh, meine wichtige Codebasegeht es jetzt in die
Allgemeinheit über Datenschutzund so weiter und so fort.
Das sind so Themen, die kannman klären.

(01:06:10):
Und dann ist es, glaube ich,hilfreich, wenn einem unserer
letzten Blogbeiträge AgenticMesh genannt, also quasi ein
Netz an dezentralen Agenten, diesich aber trotzdem miteinander
austauschen, die man da draußenkauft Ich habe es neulich mal
gesagt im Sinne von naja wennjetzt jede Abteilung ihr
Spezial-Tool fertig von derStange eingekauft, bekommt ihr

(01:06:31):
AI-Spezial-Tben, weil du imPrinzip nur die gleiche
Scheiß-Organisationsstruktur indigital einfach nachbaust, um es
mal salopp zu sagen.

Speaker 5 (01:06:55):
Und ich glaube, die Frage stellt sich nicht in dem
Sinne gehen uns sozusagen dieSenioren verloren, weil wir die
Junioren nicht mehr ausbilden,weil ich glaube das hat es ja
schon immer in Professionengegeben dass ja im Grunde die
Fähigkeiten sich verändern undwir mehr dann Leute in
bestimmten anderen Fähigkeitenfokussieren werden.
Die Herausforderung aber dasist eine grundsätzliche

(01:07:17):
Technologiekritik ist, dass dieTechnologie sich ja immer mehr
über Layer der Abstraktionenentwickelt und wir immer weniger
die Fähigkeit insgesamt haben,als Gesellschaft die unterste
Ebene nachzuvollziehen.
Also die Fähigkeit zu.

Speaker 3 (01:07:33):
Aber ich sag, mal, Aber das ist nicht was, was eine
einzelne Organisation macht.

Speaker 5 (01:07:37):
Ja, aber die Büchse ist offen, dass Leute heutzutage
vielleicht nicht mehr Assemblerverstehen oder auch sogar wenn
sie es verstehen die.

Speaker 4 (01:07:43):
Komplexität der Software nicht mehr greifen kann
.
Aber das hatten wir vor 20Jahren auch schon.

Speaker 3 (01:07:47):
Also mir fällt ja, ja , ja, der Zug ist abgefahren.
Ich weiß auch nicht, wie Wordfunktioniert, ich weiß nur, wie
man es benutzt Als Beispiel.

Speaker 4 (01:07:52):
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-Abfragenselber zusammenb bauen, oder
nutze ich ein UI-Tool, um mirdas zusammen zu klicken, meine
Abfrage an die Datenbank?
Und damals gab es auch so einenTrend.
Da haben dann die Leute auchangefangen, sich irgendwelche
Click-Me-Tools zu installieren,um mit der Datenbank zu

(01:08:14):
interagieren.
Und du hast dann sofort gemerktokay, das sind halt eher die
Junior-Entwickler, weileigentlich musst du wissen, wie
du an die Datenbank rangehst,und so ähnlich würde sehen, das
heißt, die AI als Companionnutzen und natürlich mit einem
kritischen Blick auch draufgucken kommt da jetzt
stochastischer Nonsens hin, oderist das jetzt wirklich guter
Code, der gebaut wird?
Das heißt, die AI hilft dir,den ganzen Boilerplate-Code und

(01:08:36):
so weiter zu bauen, und hilftdir auch bei komplexeren
Szenarien.
Aber du brauchst trotzdem,musst du halt trotzdem noch
rangehen und gucken okay, passtdas jetzt, passt das jetzt,
passt das nicht, weil ansonstenkommst du vielleicht mal auf
eine Problemstellung, wo duentweder vielleicht dein AI-Tool
gerade nicht mit in der Taschedabei hast oder das AI-Tool dir
hier gerade nicht weiterhelfenkann in einer komplexen
Situation, und dann stehst du da, sollst ein Problem lösen und

(01:08:58):
kannst es nicht, und das istgenau das Ziel.
Deswegen sage ich Companion.
Du hast Teams an Menschen, dieAI integriert haben als
Companions, als Coworker, unddamit arbeiten und dann
insgesamt produktiver werden.
Der feuchte Traum desManagements, dass man auf die
teure IT verzichten kann Esbraucht es jetzt mal hier als
Megafon.
Vergiss das, das wird nichtpassieren.

(01:09:20):
Mehr Budget in die IT?
Yes, und weil jetzt jederwahrscheinlich im Geiste Mark

(01:09:41):
Zuckerberg zitiert, der sagt ja,die Mitlevels, die phasen wir
aus, wir ersetzen die durch AI.
Ja, weil halt in San Franciscoein Mitlevel-Software so viel
Wert zu schaffen wie einmittlerer sechsstelliger Betrag
pro Jahr Und schon habe ichtatsächlich meinen Entwickler
ersetzt Das kannst du ja mitdeutschen Gehältern oder
Dierschau-Gehältern, das istanders vergleichbar an der
Stelle.

Speaker 3 (01:09:59):
Hervorragend.
Jetzt sind wir aber abgedriftet, oder?

Speaker 5 (01:10:03):
Super.
Ich finde, das Driften warsuper E super.

Speaker 4 (01:10:05):
Ich finde, das Driften war super, echt Okay,
ich bin ein großer Fan vomDriften.

Speaker 3 (01:10:08):
Wir driften gerne immer nur auf Kurs.
Das ist ja langweilig.

Speaker 5 (01:10:11):
Ja, das stimmt.

Speaker 4 (01:10:15):
Wir sind ja nicht die Mayflower.
Ja, aber du musst ja schon einZiel vor.
Augen haben, und ich glaube,das haben wir ganz gut erreicht.

Speaker 3 (01:10:19):
Also wer sich jetzt beschweren möchte, bitte
kontaktiert uns.
Auch die Metapher, quasi dieMetapher, quasi also die
Metapher, die wir gebrauchthaben für diesen Podcast.
Weil wir haben uns ja auchgesagt, wäre schön, wenn wir uns
so organisieren würden.
Kriegen wir das so hin, weiß ichnicht.
Manchmal hat man ja auch schongewisse Vorbedingungen, oder
manchmal kommt was von der Seiterein, ein Gedanke zum Beispiel
Sehr gut.

(01:10:39):
Aber wir haben über viele Dingegesprochen.
Die Frage war quasi was kommtzuerst, technologie oder
Organisation?
Wir haben gesprochen überConway'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 KIda für einen Impact drauf, und

(01:10:59):
werden wir irgendwann alleselber coden können?
Und was sind Scheinfragen, wasist Resulting?
Und so weiter und so weiter.
Wir haben ganz, ganz vieleSachen besprochen.
Ich fand das wahnsinnigspannend.

Speaker 5 (01:11:10):
Vielen Dank.
Mir ist vielleicht eine Sachenoch eingefallen, dieses
Alignment-Problem Sozusagen.
wie kriegt man mehrere, eineDezentralität aligned, auch so
ein KI-Thema.
Was KI-Organisationenunterstützen könnte, aber dazu
in weiteren Podcasts, vielleichtmal mehr In späteren.

Speaker 4 (01:11:27):
Folgen genau.
Vielen Dank, björn, sehr sehrgerne Bis bald Ciao.

Speaker 2 (01:11:33):
Ciao, bis zum nächsten Mal.