Anmelden

Becoming CTO Secrets· Folge 76

KI macht schneller. Und den Kopf voller - mit Chaos' Deputy CTO Christian Radowski

Dienstag, 3. November 2026 · 49 min

MP3

Shownotes

Send us Fan Mail (buzzsprout.com/2402174/fan_mail/new)
KI nimmt Entwicklern Schreibarbeit ab. Christian Radowski erlebt gleichzeitig, dass die Arbeit im Kopf zunimmt: mehr generierter Code, mehr Prüfung und ständig neue Möglichkeiten, die eingeordnet werden müssen.
Christian ist Deputy CTO bei Chaos. Im Gespräch mit Philipp Deutscher erklärt er, wie sein Team Coding Agents in die Entwicklung integriert und warum zur Einführung auch Wissen in Repositories und klare Qualitätsregeln gehören. Besonders deutlich wird er bei der Verantwortung: Auch wenn eine KI bei Entscheidungen hilft, bleiben Menschen für deren Folgen zuständig.
Wir sprechen über die Belastung nach dem KI-Rollout und darüber, wie Führung funktioniert, wenn das Ziel klarer ist als der Weg dorthin. Christian beschreibt, wann er Teams experimentieren lässt, an welchen Entscheidungen er wieder einsteigt und woran er erkennt, dass weitere Veränderung gerade zu viel wird.
Außerdem geht es um die Grenzen nachgebauter Software: Wer kümmert sich um Updates und kritische Fehler, wenn die erste Kopie steht? Und warum sind gewachsene Kundenbeziehungen für ein Softwareunternehmen weiterhin relevant?
Eine Folge für CTOs und Engineering Leader, die KI bereits einsetzen und jetzt die Konsequenzen für ihren Arbeitsalltag gestalten müssen.
In dieser Folge:
• Coding Agents strukturiert einführen und ihre Wirkung beobachten
• Review-Aufwand, Wartbarkeit und menschliche Verantwortung
• Mehr Output bei höherer kognitiver Belastung
• Führung mit Zielbild und bewussten Entscheidungspunkten
• Warnsignale für Überlastung durch Veränderung
• Die Deputy-CTO-Rolle und ein veränderter Blick auf Unternehmenspolitik
Support the show (buzzsprout.com/2402174/support)
🚀 Becoming CTO Secrets ist ein Podcast von Philipp Deutscher Consulting
→ deutscherconsulting.com
📘 Whitepaper „Entwickler Heute, CTO Morgen“
→ whitepaper.becomingctosecrets.com
📑 CTO Report 2025: Archetypen, Technologien, Zukunftsszenarien
→ ctoreport.becomingctosecrets.com
🤝 Becoming CTO Community
→ deutscherconsulting.com/becoming-cto-community
🎯 CTO Coaching Programm
→ deutscherconsulting.com/cto-coaching
💬 Vernetze dich mit Philipp auf LinkedIn
→ linkedin.com/in/philippdeutscher

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Du sollst deinem Team erklären, wo es hingeht. Gleichzeitig weißt du selbst gerade nur die grobe Richtung. Und während du noch versuchst, die letzte Veränderung vernünftig umzusetzen, kommt mit AI schon die nächste dazu. Da reicht es nicht, einmal eine Richtung vorzugeben. Du musst Entscheidungen treffen, mit denen die Leute arbeiten können und offen damit umgehen, dass du manches davon später korrigieren musst.

Genau darum geht es heute. Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es noch werden wollen. Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO Community. Heute ist Christian Radowski bei mir. Er ist Deputy CTO bei CARS.

Toller Name übrigens. Chris hat zwei Themen mitgebracht, die eng zusammenhängen, nämlich wie verändert AI die tägliche Arbeit und wie führst du eine Organisation durch Veränderungen, wenn du selbst erst die grobe Richtung kennst. Darüber sprechen wir heute anhand seiner Erfahrungen. Christian, herzlich willkommen.

Ja, hi Philipp, danke, dass du mich hier hast. Sehr gut. Christian, du bist Deputy-CTO bei Chaos. Vielleicht zuerst mal die grobe Begriffsklärung. Deputy CTO hatten wir hier noch keinen in der Show. Du bist einer. Was ist denn ein Deputy-CTO? Worin unterscheidet er sich von einem normalen CTO, wenn man das so sagen darf.

Ja, es ist ein bisschen eine spezielle Rolle tatsächlich an der Stelle. Also bei Chaos, wir haben, also ich habe einen Vorgesetzten, meinen CTO, den Wladimir Kajetsow, das ist auch einer der Gründer der Firma. Und der ist tatsächlich nach wie vor auch im Amt. Allerdings fokussiert er sich heutzutage sehr, sehr stark auf Recherche, auf Dinge, die Bleeding Edge aus dem Vakuum sozusagen kommen.

Und das ist also vielmehr eine Forschungsrolle an dieser Stelle und auch so eine Art technische Speerspitze, während man aber natürlich noch ein riesengroßes Business hat, das man jeden Tag gerade vorantreiben muss und bei dem man auch sicherstellen muss, dass alles in graudenden Baden läuft. Und wir haben irgendwann einfach für uns aufgeteilt, wer was macht und das ist, wie diese Rolle passiert ist.

Also hört sich auf dem Papier an, als würde ich jetzt unterstützen. Und in der Tat, das tue ich zum großen Teil auch, aber es ist eine vollumfängliche CTO-Rolle, nur hat sie halt eben einen spezifischen Fokus. Und der Fokus ist das Daily Business und die ganzen Abteilungen, die hinter unseren Produkten sind.

Das heißt, der CTO bei euch hat eine eher Research-Funktion und du bist dann eher derjenige, der für die Lieferung, für die Umsetzung und auch für die Führung der Organisation zuständig ist. Kann man das so sagen? Oder wofür hast du heute Verantwortung?

Also das sind grundsätzlich mal alle Entwicklungsabteilungen bei Chaos, also alles, was in irgendeiner Form Softwareentwicklung, äh Softwareentwicklung ist, unsere Produkte macht, testet, zaint, läuft unter meiner Führung. Allerdings gibt es da noch so ein ausgestürztes, man könnte es sagen, wie so ein Innovationslabor, in dem halt eben vor allem in erster Linie Forschungsarbeit, Papers, Experimente und sowas beschrieben werden.

Und die sollen und müssen ja auch vom irgendwie Tagesgeschäft getrennt sein, weil das ja in einer komplett anderen Taktung läuft. Und so haben wir uns halt eben auch aufgetrennt. Sehr gut.

Das heißt, wie groß ist eure Organisation bei Chaos?

Ich müsste lügen, weil es ändert sich tatsächlich relativ häufig. Wir stellen auch ein Wort ein. Es ist, sind U 500 Leute, glaube ich, 560 in der Organisation.

Insgesamt oder auch oder jetzt auf Engineering bezogen?

Auf Engineering sind wir eher so in den 200, 250. Ich bin deswegen mit den Zahlen so ein bisschen schwammig, weil es ist eine internationale Firma. Es gibt viele verschiedene Firmenbestandteile, denen sich dauernd irgendwas ändert. Und also in der Entwicklung kann ich so ziemlich genau sagen, wäre es um die 250 Leute, plus minus.

Sobald wir da heraustreten, GTM und so weiter haben ihre eigene Org. Weiß ich es nicht, bis auf die Kaltung genau.

Ja, ich habe ja eben schon gesagt, Chaos ist ja ein toller Name auch für eine Company, ganz definitiv. Was macht es Chaos denn? Ja, genau. Und ich hoffe, ihr lebt es nicht ganz so sehr, wie der Name das vielleicht vermuten lässt, aber der Diabetic CQCTO bei Chaos zu sein, was macht Chaos?

Also ganz viele Dinge, das ist das Interessante dran. Wir sind ursprünglich eine Gruppe von Firmen, die alle einen Schwerpunkt im Bereich Visualisierung hatten. Und ich sage hatten, weil sich natürlich mit den technologischen Veränderungen der letzten Monate und Jahre natürlich herausgestellt hat, dass Visualisierung als solches zumindest jetzt Table Stake sind.

Visualisierung ist aber nicht gleich Visualisierung. Wir haben sehr, sehr viele eigene Technologie, eigene Engines, sehr, sehr viele Erfahrungen und auch einfach Kompetenz in dem Bereich. Nun ist es aber jetzt so, dass das Visualisierungsproblem als solches mehr oder minder gelöst ist. Das gilt nicht nur für uns, das gilt für ziemlich jeden.

Man schaue einmal Richtung die Userzahlen von so Modellbestandteilen wie Nano Banana oder ähnliches. Das ist sehr, sehr deutlich abzuzeichnen. Nur haben wir aber auch noch ganz viele andere Expertisen und das ist das Schöne dran. Also es ist sehr, sehr viel AC-Business, also aus Architektur, Engineering, Construction.

Viel, viel Daten betrieben, viel BIM, viel Dokumentation, viel Analysen auch. Also zum Beispiel gerade bei Gebäudeprojekten bieten wir auch Software an aus Teilen unseres Portfolios, wo man die Energieeffizienz von Gebäuden zum Beispiel sich analysieren lassen kann, aufzeigen kann, welche Faktoren damit reinspielen und wie man bessere Entscheidungen treffen kann.

Also das ist ein Teil des Businesses, es ist sehr viel Design und Entscheidungshilfe. Und die Visualisierung ist das Vehicle, also die Sprache dazu. Und dann gibt es natürlich auch viele Teile, die eher so im WFX, Movie- und Entertainment-Bereich sind, dass es dann so wirklich einfach Kerntechnologie, die ausgeliefert wird für Filmstudios, für alles mögliche.

Und diese beiden Tracks gibt es so mehr der Mitte. Und wir fokussieren uns aktuell natürlich stärker auf diesen analytischen Part, also Analyse, Dokumentation, wie teilt man Daten und Informationen, wie macht man das greifbar für einen Nutzer, über die Branchen, in denen wir, in denen wir uns bewegen.

Und es ist also eine sehr spannende Phase. Wir machen sehr viele Dinge, also der Name erneut, der Name passt. Es sind sehr, sehr viele verschiedene Dinge. Und wir können aber auch sehr, sehr viele verschiedene Dinge machen, eben wegen diesen ganzen verschiedenen Parts, die in der Firma über die Jahre aufgebaut wurden und wo wir die Gruppen kennen, die Nutzer kennen und so weiter und so fort.

Und deren Prozesse vor allem kennen. Das ist das Allerwichtigste, das Know-how, über wie Leute eigentlich arbeiten. Und wo man das auch nicht mehr ist.

Im Grunde ist es ja trotzdem Software as a Service. Jetzt haben wir natürlich, ich habe ja, wir haben es ja schon im Intro auch ein bisschen angekündigt, wir werden uns natürlich heute auch über das Thema AI unterhalten. Und wo wir gerade beim Thema AI sind und Software as a Service, da ist die SARS-Pocalypse natürlich nicht weit.

Inwiefern seid ihr denn davon betroffen, mit eurem Business, mit den Lösungen, die ihr baut? Wie viele Kunden kommen mittlerweile auf euch zu, die sagen, ah, wisst ihr was, wir bauen das, was wir mit euch jetzt gemacht haben, das bauen wir jetzt selber. Wir Vibecoden das oder wir haben ja einen tollen Vibecode-Freelancer, wer macht das für uns?

Wie oft seht ihr das und wie, oder wie seht ihr den Impact von dieser Entwicklung bei euch und bei eurem Businessmodell?

Es ist zweierlei. Einerseits hat man den Vorteil, dass bei beiden Tracks, also bei, ich werde jetzt kurz mal AC oder Arch Design und diesen reinen Visualisierungs- oder wir nennen das mal VFX oder wo wir nämlich der Termintrack mal trennen. Für, also die Architekturbranche ist eine Branche, die sehr, sehr langsam sich verändert.

Es ist eine sehr, sehr veränderungsresiliente Branche, weil Entscheidungen sehr, sehr teuer werden und einen sehr, sehr langen Horizont haben, in dem man sie halt austragen muss. Wenn man sich bei einer Gebäudeplanung irgendwie vertut oder irgendwas am Ende halt anders aussieht, als man es fahren möchte, ist es halt nicht in fünf Minuten geändert.

Leute sind also tendenziell eher konservativer, was das angeht, aber nicht konservativ, was Technologie angeht. Das ist das Interessante. Das heißt, man ist sehr vorsichtig, man hat einen sehr hohen Qualitätsanspruch, weil man sich darauf verlassen muss, dass das, was man da sieht, auch tatsächlich der Realität entsprechen wird, wenn man sich nicht tan hat.

Gleichzeitig, wenn man sich das komplette Spektrum anschaut von der Branche, ist es dann so, dass es sehr, sehr viele Leute gibt, die auch versuchen, so eine kleine Insolösung zu bauen und ihr eigenes Tooling zu tabieren. Also es ist eine sehr heterogene Landschaft, die sich A langsam verändert, aber in der es trotzdem solche Pockets, solche Enklavungen gibt, wo sehr, sehr starke technologische Veränderungen passieren und Leute alles Mögliche ausprobieren, was vor die Linse kommt, je nachdem, wie groß die Firma ist.

Sind wir betroffen? Genauso wie der andere, würde ich sagen. Allerdings ist der Mode hier wirklich einfach den Prozess zu verstehen, also zu verstehen, wie arbeitet jemand in dieser Industrie und wo kann dieser Person in Form von Arbeitserleichterung irgendwie angeboten oder für die umgesetzt werden.

Denn die leiden ja auch darunter. Also das ist das Interessante. AI für SARS ist ein Problem in alle Richtungen für jeden. Aber auch AI für alle anderen Branchen ist ein Problem in diese Richtung, weil man sich so stark drauf verfestigt, da jetzt überall Effizienzverbesserung zu haben, jetzt wo dieses Tooling existiert.

Und so wie man in allen Branchen schauen kann, ist es dann so, dass das Erste, woran liebe verschiedene Firmen natürlich drehen, ist, kann ich irgendwie Tooling abbauen und das ging was anderes austauschen. Kann ich irgendwie meine Org umändern? Brauchen die das alles noch? Brauche ich viele Lizenzen?

Also wir haben all diese Fragen natürlich auch. Aber glücklicherweise haben wir halt auch genügend Mittel, das zu mitigaten. Und ich würde sagen, wir sind nicht so stark getroffen, wie wir sein könnten. Also es ist durch die Industrie und durch die lange Zusammenarbeit auch mit den Firmen ist das Mode stärker.

Was ist denn deine Einschätzung dazu? Glaubst du, das kommt noch? Also gerade bei den Branchen, die ihr bedient, dass sie vielleicht weniger früh im Hypecycle unterwegs sind, jetzt schon an einer solchen Stelle zu sein? Also erwartest du, dass das in den nächsten Monaten kommt? Oder denkst du, diese Branchen sind doch relativ, also du hast es ja schon gerade als konservativ bezeichnet und vielleicht sogar Risikoavers, dass sie gar nicht in diesen Bereich versuchen zu gehen.

Also den Bereich, dass wir ersetzen eine bestehende Softwarelösung, weil wir der Meinung sind, wir haben schon das Domainwissen und wir können mit relativ geringem Aufwand und vor allen Dingen natürlich auch mit sehr geringen Kosten eine solche Lösung, die ein externer Anbieter uns bereitstellt, einfach ersetzen.

Ich glaube, ich glaube, es ist tatsächlich schon da. Ich glaube, was einen da rettet, ist halt die Branche selbst. Also es gibt von vielen gängigen Architektur-CAD-Systemen mittlerweile durch sowas wie Reverse Engineer Anything und so weiter Klone, die effektiv baugleich sind. Und das Ding ist, dass das Vertrauen einen sozusagen, glaube ich, es sind Kundenbeziehungen, letzten Endes ist es Vertrauen und Kundenbeziehungen, denke ich, die, die ein guter Mode sind, immer für solche Technologiedisruptionen.

Weil letzten Endes, wenn Sachen unsicher sind, dann schauen Leute natürlich, okay, wo habe ich schlecht denn die Sicherheit? Du kann ich mich da drauf verlassen, dass Dinge funktionieren. Es bauen definitiv Leute ihr Software nach. Also sowohl unsere als auch, wie gesagt, die gängigen CRD-Systeme oder die ganzen Architektursysteme?

Funktionieren die denn auch genauso? Also ich meine, wir haben ja auch die Seiten alle gesehen, wo jetzt eine ganze Adobe und Microsoft-Tool-Suite zu kostenlos zum Download steht, weil das Reverse-engineert wurde und funktioniert. Also gesehen habe ich es, ausprobiert habe ich es nicht. Ich stelle mir die Frage, funktioniert das wirklich in einer ähnlichen Qualität, mit einem ähnlichen Funktionsumfang wie die ursprünglichen Produkte?

Oder ist das mehr Schein als sein?

Also ich bin ein großer Fan von Reha. Ich habe es nämlich vor kurzem auch selber an mehreren Projekten ausprobiert, weil ich einfach wissen wollte. Also ich kann es jedem CTO tatsächlich empfehlen, es zumindest einmal zu probieren, um mal seine eigenen Produkte dadurch zu jagen und zu schauen, wie gut ist es denn?

Kernaussage meiner Meinung nach ist, hat man das entsprechende Token-Budget, kommt man wahrscheinlich zu einer Software, die sich analog verhält, bedienen lässt, einem analog Dinge erlaubt zu tun und wie es präsentiert ist. Ist die Software komplex genug? Also mit der Komplexität der Software, die man sozusagen versucht zu reverse engineeren, steigt dann aber auch die Fehlerwahrscheinlichkeit von jedem Attempt, das zu tun und die Wahrscheinlichkeit, dass man aus dem Kontext rausgeht.

Je komplexer euer System, desto unwahrscheinlicher, dass das tatsächlich wirklich eins zu eins abgebildet wird. Das ist das eine. Und das andere ist, okay, jetzt sagen wir mal, wir reverse engineieren alles, was Microsoft heute anbietet. Also ich nehme jetzt Microsoft willkürlich. Also alle Office-Lösungen, vielleicht sogar das OS.

Wer wartet das denn? Also das ist immer so, ich finde das immer so eine kurzsichtige Art, Dinge zu betrachten, wenn Leute da panikieren, weil okay, ich kann jetzt dieses System duplizieren. Und was mache ich? Also dupliziere ich jetzt für immer jedes Update, was auf dieses System kommt. Mit welchen Leuten mache ich das?

Und wie? Und wie halte ich das aufrecht? Und wenn es dasselbe ist, nur halt für umsonst. Der psychologische Effekt von Dingen, die umsonst sind, ist auch sowas, was weiterhin bekannt ist. Also ich schaue da nicht komplett Seelenruhig hin, aber es gibt genügend Dinge, die dagegen sprechen, jetzt sämtliche Software durch Freeware-Klone per Rea oder per welchem Modell man auch immer benutzen möchte, hergestellt werden.

Ich glaube nicht, dass es passiert. Ich glaube, Leute wollen Vertrauen darin haben, dass zum Beispiel irgendwelche kritischen Bugs, irgendwelche kritischen Angriffsvektoren zum Beispiel, ist jetzt auch so viel disclosed worden in die letzten Wochen, dass das halt auch gepflegt, gefixt, sich angesehen wird, dass Leute das warten.

Also Wartbarkeit ist super, super relevant in meinen Augen.

Du hast auch vorgeschlagen, also dass wir darüber sprechen sollen heute, über Hürden, die trotz erfolgreicher AI-Transformationen, die ihr anscheinend auch schon gemacht habt, zu sprechen. Also A, was habt ihr denn erfolgreich eingeführt oder erfolgreich transformiert in Bezug auf AI und was heißt denn erfolgreich für dich in dem Fall?

So, auf welchen Teil der Arbeit beziehst du dich da?

Also erfolgreich zum einen, denke ich, ist es sich, ich muss ein kleines bisschen ausholen, erfolgreich ist an der Stelle, dass man erstens die Tools, die Möglichkeiten, die Veränderungen auf die Arbeitsweise erstmal angenommen hat, sie intern dann entsprechend auch ausgerollt hat und geschaut hat, was das mit dem System macht.

Also der einzige erfolglose Move oder die einzige Handlung, die meinen Augen wirklich komplettes Failure wäre, ist, okay, wir machen gar nichts. Wir sitzen einfach da und lassen Leute, das irgendwie für sich selbst sortieren. Und wer irgendwie mit Agente-Clubs arbeiten möchte oder wer immer noch von Hand mit einer magnetisierten Nadel auf der Festplatte irgendwie programmieren möchte, der kann das tun, es ist alles egal, macht, was ihr wollt und dann wird die Excellenz schnurgespült.

Das funktioniert nicht. Es ist definitiv wichtig, das gut strukturiert auszurollen, Entscheidungen zu treffen, welches Tooling, welcher die ganze Informationsarchitektur dahinter auch. Also nicht nur einfach nur einen Agenten ausrollen und sagen, so, ihr habt jetzt alle klaut, total toll. Sondern wie verändert das die Repos, wie verändert das die Arbeitsweisen, wo muss Wissen dokumentiert werden, wo kann Wissen verfestigt als Skill, als Connector, als was auch immer ausgerollt werden.

Also wie strukturell integriert man das in seine eigenen Entwicklungssysteme und Prozesse? Und dann schaut man, was macht das jetzt. Also dann beobachtet man das halt mindestens so drei bis sechs Monate. Und siehe da, okay, man merkt, die Akzeptanz ist hoch. Jeder effektiv benutzt den Agent beim Programmieren, um sich die Arbeit zu erleichtern.

Die initiale Buchwelle an irgendwie das Romot dann immer so ein bisschen weg. Schön, was haben wir jetzt? Also haben wir jetzt mehr Code, besseren Code, mehr PRs, ist die Cycletime runtergegangen. Das Erfolgreiche für mich ist sozusagen, nachdem man es ausgerollt hat, ist zu tracken und anzuschauen. Das haben wir gemacht.

Ich glaube, mittlerweile ist es wirklich so, dass wenn ich es richtig im Kopf habe, das ist keine letzte Enklave. Also es gibt nicht dieses kleine Dorf in Gallien oder sowas, das sich noch wehrt. Es gibt mittlerweile ist es flächendeckend ausgerollt. Es ist überall sogar das gleiche Tooling mit wenigen Ausnahmen.

Unsere eigenen Leute verwenden noch ein bisschen was anderes. Und was wir gemerkt haben, ist, ja, es ist, also es ist produktiver, es wird mehr umgesetzt. Was wir aber auch gemerkt haben, und das meine ich mit, also eine Hürde, die selbst bei einer erfolgreichen Umsetzung passiert. Und was machen wir jetzt mit dem ganzen Code?

Also das war auch so eine Sache, die wir uns überlegen mussten. Jetzt produzieren Leute unfassbar viel Code. Der Output ist gigantisch, es wird unglaublich viel gemacht. Wie review ich das, wie teste ich das? Also man kann sozusagen nicht bei dem Produktionsprozess aufhören zu sagen, jetzt haben wir das optimiert, Leute verwenden AI, ist total toll, hier ist unser Token-Budget, sondern ich muss ja immer noch sicherstellen, dass das, was da, was da produziert ist, korrekt ist und im besten Fall sicher und wartbar.

Ich weiß von Firmen, mit denen ich in Kontakt war, die teilweise vollautomatisiert haben. Also da gibt es schon Prozesse, wo man auch über ein Modell abschätzt, also über ein Decision Model abschätzt, wie wahrscheinlich ist es, dass wenn diese Pull-Requests, Match-Requests zurückkommen, dass das zu defekten Problemen führt.

Wo man mit Conversary Reviews arbeitet, dass quasi zwei Agenten sich versuchen gleichzeitig zu widerlegen und zu reviewen, was mit dem Code stimmt, nicht stimmt. Und wo man das vollautomatisiert. Also wo man gesagt hat, okay, kleinere Tickets fest, solange das Decision-Modell sagt, es ist okay, keine Entwickler mehr haben.

Soweit sind wir leider noch nicht. Ich weiß auch nicht, ob das bei der Komplexität unserer Software wirklich Sinn ergibt. Also das ist die andere Frage.

Also Dark Factory ist nicht euer Ziel oder nicht das erklärte Ziel.

Nicht das erklärte Ziel. Ich glaube, das Problem ist dabei halt, dass das sehr, sehr gut funktioniert, wenn man den 5000. Webshop gemacht hat oder irgendwelche Web-Worst-Plattformen, bei denen halt das sehr derivative Logik ist. Wenn man sehr viel Mathematik, sehr viel Hardware in den Systemen hat, dann ist es nochmal deutlich schwerer, das zu machen.

Aber was wir jetzt zum Beispiel anschauen, ist, okay, was machen wir mit den Reviews? Also QA lässt sich relativ leicht lösen, man automatisiert halt einfach viel von den Regression-Tests. Das ist ja alles eh immer irgendwie das gleiche, wenn man testen möchte, dass Dinge nach wie vor funktionieren nach einer Änderung, lässt sich sehr gut mit AI lösen.

Reviews sind das Problem. Ich habe, also Pull-Requests auseinanderzunehmen, die für einen Menschen vernünftig kognitiv bearbeitbar zu machen und dann eine saubere Entscheidung treffen zu können.

Sind dann Menschen immer noch in den Review-Prozess involviert? Oder zumindest mal, ist der Mensch dafür verantwortlich, oder ich stelle die Frage ein bisschen anders, ist der Mensch dafür verantwortlich, den Code zu lesen, den DI in großer, in sehr vielen Zeilen erstellt hat?

Nicht alleine, aber ja. Also es ist immer noch so, dass, und ich glaube, es ist auch wichtig, dass jemand muss ja verantwortlich sein. Eine Entscheidung wird hier nicht irgendwie im Vakuum getroffen. Und egal welche KI ich nehme, ich kann die Entscheidung auslagern, aber die Verantwortung trage ich ja mal noch dann selbst.

Also wenn ich auf TikTok gedrückt habe und es zurück in Production gekommen ist und es ist kaputt, dann kann ich nicht sagen, oh nein, ein DIE-Agent hat es für mich gemacht, der ist jetzt schon. Das heißt am Ende.

Na klar, also die Entscheidung liegt beim Menschen, aber das Lesen des Codes, das übernimmt der Mensch dann wahrscheinlich nicht in Gänze selber, sondern das wird AI unterstützt, ablaufen.

Weil die Stiermasse wäre sonst, glaube ich, einfach nicht kerngelaufen.

Okay. Was sind denn, was hat sich denn daraus dann für eine Konsequenz ergeben? Also ich bin völlig klar, du führst AI ein, du sagst, ihr habt das halt für alle durchweg mit einem gleichen oder sehr ähnlichen Tooling gemacht. Ich nehme an, du beziehst dich jetzt dann in erster Linie mal auf die Entwickler und nicht auf die gesamte Organisation in allen Teilen.

Er wird an Cloud Code beispielsweise nutzen, er wird seine Tickets abarbeiten, er wird das Ganze dadurch. So, an welcher Stelle musstest du weitere Regeln, Verantwortlichkeiten einführen? Und was war die Konsequenz daraus? Was hat wie viel mehr an Qualität ist denn dabei hinten rausgekommen? Oder ist die Qualität dann auch signifikant erstmal nach unten gegangen?

Was musste man denn darauf dann verändern?

Also glücklicherweise ist die Qualität nicht nach unten gegangen, sondern weil wir eine sehr, sehr starke QR-Organisation haben und auch eine Kulturell tatsächlich wurde es abgefahren. Die Entwickler scheuen sich einfach Zeug zurückzumerchen, dass das für sie nicht robust aussieht. Das ist das eine. Also es wurde kulturell stark abgefahren.

Die Codequalität ist also nicht unbedingt gesungen. Es gibt Teile natürlich, wo Leute, also Menschen sind unterschiedlich, es gibt Teile natürlich, wo Leute dann doch etwas laxer waren. Und dort ist es uns dann relativ frühzeitig aufgefallen, dass wenn wir nicht strengere Regeln einführen, der Code halt irgendwie in mehreren Jahren nicht behartbar wäre.

Also wenn Leute wirklich eine, man nimmt eine historische Codebase, man geht mit AI drüber, jetzt hat man diese Mischkalkulation. Viele von diesen tollen Aircode-Projekten und Produkten sind Greenfield. Wenn die von vornherein mit AI gemacht sind, sieht die Codebase sehr, sehr anders aus. Dann ist sie quasi gar nicht wirklich dafür gebaut.

Meiner Meinung nach, zumindest, dass ein Mensch primär sie liest, sondern dass sie von Agenten für Agenten mehr oder minder gebaut. Wenn man aber eine bestehende sehr reife Codebase hat und man da mit einem Agenten drüber geht, fällt einem dann schon der Unterschied auf. Also dann sieht man es relativ deutlich.

An welcher Stelle ist es irgendwie über die Jahre historisch gehegt und gepflegt und gewachsen worden, an welcher Stelle kommt plötzlich.

Kann man das nicht selber beeinflussen? Also ich kann ja meinem Coding-Agent sagen, wie ich möchte, wie der Output auszusehen hat. Also nicht nur löse mir das Problem auch in einer bestehenden Codebase oder in einer neuen Codebase, sondern ich kann mir auch sagen, ich möchte, dass dein Output bestimmten Regeln oder Kriterien entspricht, die ich vorher festlege.

Du kannst ja so weit gehen, du kannst sagen, hier ist das Clean Code-Manifest, ich möchte, dass dein Output dem Clean Code-Manifest entspricht. Wenn ich bereit bin, dafür Token auszugeben, okay, dann kann ich das ja tun.

Das ist richtig. Und die Antwort, wie man das tatsächlich, oder unsere Antwort darauf ist letzten Endes, dass man mehr und mehr von dem Kontext in, dass man, dass man das Repo quasi mit der korrekten Menge an Kontext spickt, was Standards, Nomenklatur, Designentscheidung und so weiter angeht und das halt auch hierarchisch macht.

Also einfach nur um den Kontext für den Agenten handelbar zu halten, hat an einer Stelle explodiert natürlich und leidet effektiv random, wenn man weiß, wie sie unter der Haube funktionieren, was es tut, wenn man den Kontext sprengt. Also es ist wichtig, da sehr starke Guardrails zu haben und es das auch wirklich strukturell durchzuziehen.

Das andere Problem ist, dass das natürlich auch wieder eine Transformation ist. Also das passiert nicht über Nacht. Man muss da Entscheidungen treffen. Die Teams haben teilweise unterschiedliche Standards. Wir haben ein relativ großes Produktportfolio. Kurzum, bis das alles überall ausgerollt ist und perfekt ist, dauert das noch ein bisschen.

Aber das ist die Lösung. Also die Lösung meiner Meinung nach ist dem Agenten korrekt Kontext und Gedächtnis sozusagen vorzudiktieren. Also wo platzierst du Zusammenfassung von Designentscheidungen, Designrestriktionen, wo haben wir eine Cyberterminologie aufgebaut? Warum sind Dinge so, wie sie sind, so dass das erklärbar ist?

Witzigerweise ist es für den Menschen halt auch besser erklärbar, weil man sich einfach durch die Files durchhageln kann, wenn man neue Leute an einem anderen Produkt onboardet. Also es hat andere Fortale.

Du, du, ihr seid ja jetzt auch keine kleine Organisation. Wer hat denn diese Einführung von Agents oder da Agentic AI in eurem Softwareentwicklungsprozess? Wer hat das denn initiiert? Wer hat es angeleitet? Wer hat es koordiniert? Wer hat denn den Plan gemacht? Waren das auch verschiedene Personen in verschiedenen Rollen, die hierzu beigetragen haben?

Ist das dann eher von eurem CTO ausgegangen? Ist das von dir ausgegangen als Deputy-CTO, der das hier das Steering betrieben hat und auch sichergestellt hat, dass man alle auf das gleiche Ziel hinarbeitet? Oder war das einzelne Leuchtturm-Engineers in der Organisation, die hier Führung übernommen haben und das initiiert und vorangetrieben haben?

Die kurze Antwort ist ja, also alles davon tatsächlich.

Mein voller Ernst ist. Wir haben relativ früh gemerkt, dass wenn wir warten, bis es einen Clear Winner gibt, also man dreht die Uhr irgendwie zwölf Monate zurück, da war es noch nicht ganz so absehbar, okay, das ist jetzt das Modell für Softwareentwicklung und das ist jetzt das Modell für alles andere und das ist jetzt das beste Visual Language Model und was auch immer, sondern wenn man zwölf oder vierzehn Monate zurückgeht, dann sah die Tooling-Landschaft noch sehr, sehr anders aus und es war halt nicht so komplett eindeutig, in welche Richtung es geht.

Aber wir waren relativ früh der Meinung, auch das war sogar noch, als ich auf Director-Ebene war, bevor ich in die Deputy-CT-Hall reinkommen bin. Als wir als die Ticklungsabteilung uns darüber jetzt Gedanken machen müssen. Also während alles quasi noch so läuft, während wir ein virtuelles System haben, wie wir arbeiten, ist es Zeit, uns irgendwie jetzt selbst zu disrupten.

Es führt keinen Weg dran vorbei, wir müssen jetzt anfangen in der Entscheidung zu hätten. Glücklicherweise gibt es einen Firmenbestandteil, der auch zu dem Zeitpunkt schon ein Pocket, ein sehr kleines Pocket von wirklich so AI-Native Engineers waren. Und mit denen haben wir uns dann sehr, sehr stark auseinandergesetzt und aufunterhalten und angeschaut, okay, ihr seid da am Enthusiastischen dran, schaut euch das jetzt irgendwie schon schon jeden Tag an und probiert alle neue Modelle aus und ändert eure Arbeitsweisen, weil es euch Spaß macht, interessiert.

Was seht ihr denn? Und dann haben wir die Kreise weiter und weiter gezogen. Irgendwann fand dann eine Entscheidung statt, tatsächlich auf der Entwicklungsabteilungsebene, weil wir so als Erste betroffen waren und als erste auch ready sein wollten. Okay, wir wollen jetzt folgende Tools einführen, also folgende Tools einführen.

Probiert die aus, fangt an, euch sozusagen auch damit anzufreunden und aufzulärmen, wie jetzt letzten Endes die Arbeit aussehen könnte in der Zukunft. Gleichzeitig gab es natürlich einen größeren organisatorischen Push, also auf dem C-Level, dass man gesagt hat, okay, es ist eigentlich nicht die Entwicklungsabteilung, es ist eigentlich alle Abteilungen betroffen in irgendeiner Form, aber verschiedene Domänen brauchen verschiedenes Tooling.

Wir haben sogar im C-Level jemanden, dessen das Aufgabe ist, spezifisch AI in der Firma zu tracken, also wie AI-Use.

Ein CAIO oder wer ist das?

Quasi, ja. Also unser COO ist auch unser CAIO. Okay.

Aber du hast jetzt eben was interessant gesagt, du hast gesagt, ja, es ist ein disruptiver Prozess oder es ist etwas passiert oder etwas Disruptives mit der Arbeit in bestimmten Teilen der Organisation, vielleicht sogar in allen Teilen einer Organisation, wie disruptiv ist denn das Ergebnis geworden oder wie maßgeblich hat es denn auch das Ergebnis verändert im Positiven?

Was ist der Impact davon?

Also meinst du den Endzustand jetzt oder wie nach der Zug?

Jetzt, das ist ja wenn schon der Zwischenstand jetzt, würde ich behaupten, aber wer, also im Bereich of Engineering, wie viel schneller könnt ihr denn jetzt mit AI bauen? Oder habt ihr nur mehr Regeln, mehr automatisierte Prozesse und mehr Token-Verbrauch für einen vielleicht sogar nahezu identischen Outcome?

Das ist tatsächlich, es ist tatsächlich ehrlicherweise schwierig zu sagen. Und ich glaube, ich war vor kurzem auf einer Konferenz für CTOs und CPOs und wir haben alle mehr oder minder das gleiche Problem. Es ist relativ schwierig, direkt, außer man geht komplett, wie du sagst, Dark Factory, da lässt sich sehr, sehr leicht abbilden.

Aber sofern Menschen sich in dieser Gleichung befinden, und ich persönlich glaube fest daran, dass Menschen immer noch Teil von Software-Entwicklung sein sollten, ist es sehr schwierig, es zu qualifizieren. Was ich sehe, oder was ich definitiv sagen kann, ist, dass dort, wo Leute es vollends annehmen, ich Output sehe, der 4x, 5x, teilweise 10x ist, von dem, was ich an den Stellen sehe, wo Leute es nicht vollends annehmen.

Also das Delta, was ich nur selber intern sehe, kann massiv sein. Dass man Produkte, für den man früher zum Beispiel eine Entwicklungszeit von 12 bis 18 Monaten hätte, hat man halt jetzt teilweise in 2 bis 3.

Aber das ist ja eine sehr konkrete Messung, oder wenn ihr es konkret messt, ist das doch eine sehr konkrete Verbesserung von der Lieferfähigkeit, oder nicht?

Ich kann es nämlich generalisieren, also das ist das Schwierige. Es funktioniert halt eben nicht für alles genau gleich. Also es kommt sehr, sehr stark drauf, was man da baut, wie gut man auch selber die Domain-Knowledge mitbringt. Je besser man weiß, für wen man was baut und je besser man die Industrie kennt, in der das in der Männer eingesetzt wird, desto besser ist sozusagen das qualitative Ergebnis.

Ist das nicht maximal unbefriedigend für ein CTO? Also oder auch für das C-Level, wenn sie jetzt sagen, wir müssen jetzt einen nicht signifikanten Teil unseres Budgets jetzt in Token investieren und planen. Und wir sind, wir haben eine immer noch große Ungewissheit, was denn der Outcome davon sein wird.

Ja, ja und nein. Also das Schöne daran ist, dass wenn man sich anschaut, also es ist ein Satz, den der Chief of Innovation von OpenAI gesagt hat tatsächlich, im Raum. Was jetzt schwierig ist für die Modelle, ist in vielen Fällen in sechs Monaten nicht mehr schwierig. Und was jetzt teuer ist, auch was token-mäßig teuer ist, ist in sechs Monaten wahrscheinlich deutlich günstiger.

Das heißt, man hat gar nicht die Wahl. Man muss sich innerhalb von diesen Tools und diesen Prozessen und dieser Maschine bewegen, um überhaupt vernünftig abschätzen zu können, was richtige Entscheidungen sind. Also die Inaktivität ist erneut wieder das Einzige, was ein Fail-State wäre in meiner Um. Es ist für uns nicht unbefriedigend tatsächlich.

Also erstens sind, das klingt jetzt sehr, sehr harsch, aber die Token-Kosten sind sehr, sehr predictable. Also man kann es sehr, sehr, sehr, sehr gut vorausrechnen. Und dementsprechend man könnte es, da kann man verschiedene Modelle machen, aber man weiß ja, was seine Packs sind, dann ist das halt sein O-Packs, das obendrauf kommt.

Oder man kann sie einfach direkt in Packs mit reinrechnen, weil man weiß, so die und die Rolle wird wahrscheinlich dessen das Token-Budget in etwa haben mit so einem spelen Top-Ups. Es ist also sehr, sehr predictable, was es kostet. Der Outcome ist nicht ganz so predictable, aber immer noch ein definitiver Multiplikator.

Also selbst an den Stellen, wo es falsch verwendet wird, wenn man jetzt falsch verwendet sagen könnte, ich kann jetzt ein paar Monate zurückschauen, war der Lerneffekt, zu dem es dann am Ende geführt hat, ist wert, das Geld zu verbraten, schlicht und ergreifend, weil Leute daraus lernen, ihre Prozesse anpassen und dann am Ende des Tages halt eben auch diese Effizienzsteigerung in irgendeiner Form dann zurückkommt.

Sie kommt halt nicht sofort.

Aber es ist ja auch eine Phase, wenn ich dich richtig verstanden habe, eine Phase von viel Research und Ausprobieren und man investiert hier auch einen Tokenspend und man weiß vielleicht jetzt noch nicht, was der Outcomes sein wird. Man sieht aber definitiv einen Return-on-Invest. Man weiß vorher natürlich vielleicht nicht immer, wie hoch der Return on Invest sein wird.

Aber du sagst ja auch selber, das wird sich vielleicht in den nächsten Monaten vielleicht nochmal ändern. Vielleicht werden dann auch die Outcomes nochmal mehr predictable. Wo hat sich denn deine ursprüngliche Erwartung an AI im Bereich der Softwareentwicklung nicht bestätigt? Und was hast du dann anders gemacht?

Bisher muss ich sagen, bin ich eigentlich nur positiv überrascht gewesen. Also ich bin. Ich war ursprünglich sehr skeptisch, was AI angeht. Also ganz, ganz, ganz am Anfang war ich sehr, sehr skeptisch, weil ich mir zum Zeitpunkt noch nicht vorstellen konnte, dass der Fortschritt so schnell sein würde.

Es ist wirklich eine Zeit rapiden Fortschritt, durch die wir irgendwie gegangen sind, die letzten zwölf, neun Monate, wie ich auch. Ich hätte nicht gedacht, dass es so schnell passiert. Meine Erwartungen wurden eigentlich meistens übertroffen. Vorausgesetzt, man verwendet es korrekt. Es ist eine unfassbar nützliche Entscheidungshilfe und es ist unfassbar nützlich für eher derivative Arbeit.

Also einfach nur Arbeit, die mehr und mehr Arbeit wird Boilerplate sozusagen. Was ich nicht erwartet hätte tatsächlich, ist, dass die kognitive Last so stark hochgehen würde. Also das ist tatsächlich eine Prediction, bei der ich falsch lag. Die kognitive Last hat zugenommen statt abgenommen. Das heißt, es kommt viel mehr bei rum, viel mehr kann automatisiert werden, aber statt sich Gedanken darüber zu machen, was jetzt die Syntax genau war und was die Notation sein sollte, dann habe ich die richtige Version dieser Library, ist es jetzt überhaupt zu lesen und zu verstehen, was da passiert und das abzuschätzen gegen das Zielbild, das man eigentlich hat.

Und gleichzeitig ändert sich die Möglichkeit, mit der man das machen kann, alle vier bis sechs Wochen. Und jetzt muss man irgendwie immer wieder auf seinen Zehenspitzen bleiben und schauen, okay, ist dieses Modell jetzt besser, ist das Modell jetzt besser, was verwende ich hier, wo? Und diese kognitive Last aus diesem Toolchain-Änderungen, dem konstanten Lernen und der Fähigkeit, das zu analysieren und zu lesen und zu verstehen und abzuschätzen, was da generiert wird, das ist was, was Leute tatsächlich mehr auslastet als die Arbeit vorher.

Einfach wegen dem Pace.

Ja, das ist richtig. Und ich glaube, dass die Artweise zu denken und zu arbeiten, die verändert sich, natürlich ist, ich glaube, diejenigen, die jetzt schon mit einer hohen, oder die vor AI auch mit einer hohen kognitiven Last gearbeitet haben, die sogenannten High-Performer vielleicht dann auch, die werden vielleicht jetzt noch mehr High-Performer werden, die werden vielleicht jetzt noch mehr kognitive Last tragen müssen.

Also ich stelle fest, Entscheider mit AI jetzt viel mehr auf einmal entscheiden müssen, in viel kürzeren Zeitabständen und zwischendurch müssen sie eine ganze Menge mehr an Informationen nochmal neu verarbeiten, um wieder eine nächste Entscheidung zu treffen. Das ist, das sorgt auch für eine Ermüdung im Bereich des Arbeitens mit AI.

Vielleicht ist der normale Mitarbeiter klingt so despektierlich, das meine ich gar nicht. Ich meine aber so, der durchschnittliche User mit AI, der wird vielleicht Produktivitätsgewinne haben, aber vielleicht auch seine Entlastung verspüren. Ich glaube, diejenigen, die sich sehr intensiv damit auseinandersetzen, die erleben genau das Gegenteil gerade.

Ja, das würde ich 100% unterschreiben. Ich habe einen Kollegen der Firma, der treibt das tatsächlich auf die Spitze an, der hat effektiv diesen Versuch angestellt, okay, ich mache jetzt alles nur noch Regentic und meine Kernaufgabe ist, das Ganze zu steuern und zwar alle relativ hoh und fällt. Das heißt, es werden wirklich Tasks genommen und man experimentiert damit, dass die halt mehr oder minder autonom durch korrekt gepromptete Agents dann halt eben umgesetzt werden.

Was genau bedeutet das, an welcher Stelle muss ich eigentlich wieder zurück in den Loop zu reviewen? Also das ist ja auch so eine Frage, wenn ich Dinge vollautomatisiere, möchte ich trotzdem immer noch wissen, was da passiert. Ich kann meine PS so viel stacken, wie ich möchte. Wenn ich die falsche Entscheidung, also wenn ich zwischen eine Entscheidung falsch treff oder verpasse, dann ist ja all dieser Aufwand am Ende für die Cuts.

Dann muss man das alles wieder mühsam auseinanderdividieren.

Das ist richtig. Wenn wir, wenn wir nochmal auf deine persönliche Entwicklung kommen, welche so, du bist ja auch in deiner Entwicklung von einer Director-Rolle, einer Senior-Director-Rolle hin zur Deputy-CTO-Rolle. Was hat das denn im Laufe der Zeit mit dir gemacht? Also nicht nur das Thema AI, sondern aber auch, welche eigenen Gewohnheiten oder Habits musstest du als Führungskraft verändern, um Situationen, wenn es auch darum ging, einen solchen Change in einer Organisation auszurollen, wirksamer zu werden und wirksamer wahrgenommen zu werden?

Das ist eine gute Frage. Und die Antwort ist tatsächlich, es ist ein höheres Unsicherheitsmaß, einfach einfach zu akzeptieren. Also es gibt häufig Situationen, in denen ich mich jetzt befinde, die mir früher den, also nicht den Angststreuess hätten ausbrechen lassen, aber die mich deutlich, deutlich nervöser gemacht hätten.

Weil es so diffus ist. Also uns ist das Zielbild klar, uns ist klar, wo wir hinwollen, uns ist klar, was wir erreichen wollen. Es gibt so viele Möglichkeiten, dass der beste Weg, meiner Meinung nach, euch diese Sachen auszuholen, ist, dieses Zielbild vorzugeben und dann, ähnlich wie das mit den Erkennten, Leute machen zu lassen und an den richtigen Entscheidungen sozusagen sich wieder einzulopen, um zu schauen, ob das in dem Sinne läuft, wie man es am Ende haben wollte.

Aber es ist alles Unsicherheitsgomment. Das heißt, man muss teilweise Leuten sagen, ihr probiert das jetzt einfach aus. Und dann schauen wir, haben wir uns in die richtige oder in die falsche Richtung bewegt. Und dieses, ihr probiert jetzt einfach aus, ist was, was ich damals selber nicht gern gehört habe, aber ich jetzt extrem leben muss, weil es unmöglich ist, dass man eine komplett Ende zu Ende ausdefinierte Lösung vorgibt und die dann einfach einmal durch PowerPoint irgendwie durchtanzt.

Und dann hier, hier ist der Zehn-Jahres-Plan, macht das einfach. Es ändert sich so schnell und niemand hat alle Antworten parat. Es gibt kein. Die Industrie ist so schnell drumherum gewachsen, es gibt jetzt eigentlich keine Experten. Jeder, der mir sagt, er ist eine EI-Experte. Es ist sehr, sehr, sehr schwierig, das zu glauben, außer man arbeitet bei irgendwie Entropic, Open AI oder sonst irgendwo.

Das heißt, es ist noch viel mehr Führung unter Unsicherheit, wie es vorher der Fall war.

Ja, es ist Maximalführung unter Unsicherheit. Man weiß nicht, die nächsten zwei Tage könnte, also Astra ist ein hervormes Beispiel. Astras gedroppt und man schaut sich das an und stellt so fest, okay, was bedeutet das jetzt für die Produkte? Und was bedeutet das halt irgendwie für die Flows, die wir abbilden können?

Und ist das, was wir gerade bauen, ist das in line damit oder ist das nicht in line damit? Oder sollten die vielleicht Dinge pausieren und nochmal kurz Redesign machen und das jetzt damit umsetzen? Also diese Capabilities, die konstant aufkommen, die verlangen mir ein hohes Maß an Flexibilität ab. Und dementsprechend muss ich leider der Organisation ein hohes Maß an Flexibilität abverlangen.

Und das ist halt nicht immer einfach. Also es ist häufig echt ein, probiert es aus, sagt mir, was dabei rumgekommen ist, lasst uns hinterher einen groben Plan machen. Wir sünken das wieder in vier Wochen ab, die schauen, was bis dahin passiert ist.

Woher weißt du, ob du der Organisation gerade zu viel zumutest? Also ich meine, jede Veränderung ist ein Change, den du in der Organisation erstmal durchbringen musst. Jetzt ist AI ein sehr großer, ein sehr disruptiver Change, deswegen reden wir auch von einer Transformation. Trotzdem führst du die in Wellen durch, führst du die in Chargen durch?

Oder wie gehst du damit um? Woher weißt du, wenn, na, jetzt muss ich vielleicht mal auf die Bremse treten, noch eine Veränderung, kauft mir gerade keiner ab?

Es ist schwierig. Also es ist einerseits einerseits ist es schlicht und ergreifend gut vernetzt zu sein und die Grundstimmung in den ganzen Entwicklungsabteilungen, Entwicklungsteams zu verstehen und vor allem sich auch erstmal anzuhören. Also wirklich zu verstehen, okay, wie weit ist der Apparat jetzt halt eben schon strapaziert?

Also können die Leute noch oder ist es jetzt schon so viel, dass man eine kleine Pause einlegen muss, damit es sich setzt. Verschiedene Menschen haben natürlich verschiedene Toleranz für Veränderungen und auch Akzeptanz für Veränderungen und man will sie alle mitnehmen, letzten Endes. Gleichwohl ab und zu ist die Frage gar nicht, kann die Organisation diese Veränderungen noch quasi akzeptieren, sondern wie kann man sicherstellen, dass diese Veränderung noch akzeptierbar ist?

Man muss sich ja fragen, wie kriegt man diese Veränderungen, wenn man davon fest überzeugt ist, dass die gut ist und nachhaltig ist und vielleicht auch einfach notwendig ist. Wie bekommt man das transportiert, dass Leute verstehen, das Ganze ist jetzt nicht irgendwie für irgendwelche diffusen KPIs oder irgendwelche OKRs oder sowas, sondern das ist eine Notwendigkeit.

Wir müssen das machen, wir müssen unsere Prozesse so ändern, damit wir im richtigen Pace arbeiten können. Ich versuche Leuten immer klar zu machen, was am Ende für sie dabei sozusagen rausspringt. Also warum das eigentlich in ihrem eigenen Interesse ist. Häufig hilft das schon als Appell. Weiß ich, wann es zu viele Änderungen sind.

Ja, ich weiß, wann es zu viele Änderungen sind ab dem Zeitpunkt, wo ich sehe, dass Dinge nicht mehr wirklich ausgerollt werden. Also wenn man trackt, was man da irgendwie umsetzt, und seien es, das können Tools sein, Metriken, Prozesse, was auch immer, umstrukturieren. Und Dinge werden so verschleppt, dann hat man sehr, sehr wahrscheinlich, dass das Ding überstrapaziert.

Ja, das macht natürlich Sinn. Wir sind fast am Ende der heutigen Aufnahme angekommen. Wir haben natürlich noch ein bisschen Zeit für die obligatorischen, aber gerne gehörten Rapid-Fire-Fragen. Welchen Satz über AI kannst du nicht mehr hören?

Kann Modell XYZ machen. Also einfach diese Frage, was kann was, kann ich nicht mehr hören. Ich will das auch nicht mehr hören. Die Modelle konvergieren in verschiedene Richtungen. Diese Frage, kann das eigentlich auch noch? Keine Ahnung, meine Steuer machen oder sonst irgendwas. Kann ich nicht mehr hören.

Weil jedes Modell alle Kann, also gerade von den Größen, oder was ist der Punkt, der dich dran stört?

Der Punkt, der mich dran stört, ist, dass Leute dieses, es ist so eine Boomer-Mentalität, die mich dran stört, dass man einfach das technische Verständnis nicht davon hat, was dieser Agent eigentlich ist.

Welche Frage stellst du heute häufiger als früher? Brauchen wir das in einem Monat noch? Sehr gut. Hast du dann, hast du gemerkt, wo dann die Antwort war, nee, brauchen wir nicht? Und dann habt ihr es sein gelassen?

Ja, ich habe buchstäblich teilweise Dinge gestoppt, weil mir klar war, dass zu dem Zeitpunkt, wenn das zu dem Zeitpunkt, bei dem dieses Arbeitspaket fertig werden würde, ist es eigentlich schon absolut.

Okay. Deswegen welches Warnsignal für zu viel Veränderung nimmst du besonders ernst? Du hast gerade eben schon eins genannt, aber vielleicht fällt dir trotzdem noch was dazu ein.

Ich glaube, das größte Warnsignal ist, wenn Leute, wenn die Diskussionskultur shiftet, wenn Leute von Fragen und Erklärungen einfach in so eine fast schon Blockadehaltung gehen. Also ich höre sehr stark einfach drauf, wie Menschen sozusagen emotional mit diesen Veränderungen umgehen. Und ich frage Leute einfach nach sehr direktem Feedback und Leute werden dann irgendwann shiftet es.

Irgendwann shiftet es von, hey, warum machen wir das jetzt eigentlich zu einem, wirklich einem eine Äußerung von Unmut und die nehme ich dann sehr, sehr ernst. Solange Leute noch fragen, haben sie Interesse. Sobald Leute anfangen, dann einfach nur aufzulisten, was sie schon alles tun, ist es normalerweise ein deutliches Signal, dass es zu viel ist.

Sehr gut. Was fällt dir denn selbst beim Delegieren noch schwer?

Ich bin super schlechterin, Leuten nicht in regelmäßigen Abständen dann kurz mal so ein Ping zu schicken und zu sagen, wo sind wir denn jetzt damit? Und manchmal ist es, glaube ich, zu häufig. Also mir fällt es schwer, Geduld zu haben. Meine größte Charakterschwäche wahrscheinlich ist, dass ich kein geduldiger Mensch bin.

Das heißt, du gibst jemandem meine Aufgabe und dann bist du aber trotzdem ständig am Ping?

Nicht ständig, aber es ist so, wenn ich jemanden eine Deadline gebe, ist es sehr wahrscheinlich, dass ich jemanden vor dieser Deadline nochmal kontaktieren werde und einfach fragen werde, wie es läuft, wenn ich nichts höre. Also ich bin schlechteren einfach zu sagen, ja, okay, das ist jetzt in zwei Wochen so fertig sein und in zwei Wochen wird es fertig sein.

Was würdest du deinem früheren Engineering Leader Ich in einem Satz mitgeben?

Ich glaube, es ist tatsächlich, dass Politik, also, okay, ich hatte, wir hatten das ja auch im Coaching. Schön, dass der leicht länger ist, aber Politik ist erstmal nichts Schlimmes. Es ist einfach nur der Weg, ganz, ganz viele Interessen und Wünsche und Incentives und Zielbilder irgendwie miteinander verhandelbar zu kriegen.

Und ich hatte vor zwölf Monaten ein deutlich anderes Bild darauf, wie Politik im positiven Sinne wohl gemerkt, Politik funktioniert, als wie ich es jetzt sehe. Also ich würde einfach mal mal eigentlich sagen, nicht alles, was politisch ist, ist automatisch hinterhältig oder eine Falle oder sonst irgendwas, sondern manchmal ist es auch einfach nur der Weg, Konsens zu schaffen.

Das heißt, du hast jetzt mittlerweile, du hast akzeptiert, dass es unterschiedliche Interessen im Unternehmen gibt, die natürlich auf Management-Ebene ja, vielleicht auch mit unterschiedlichen Machthebeln oder guten wie weniger guten Argumentationsversuchen versucht werden, zu verhandeln oder durchzusetzen.

Da fühle ich sehr mit dir, weil das A geht es vielen so, B ging es mir genauso. Und das ist manchmal einfach auch schwierig zu akzeptieren. Man denkt dann immer, man selber hat die viel hereren Ziele als die anderen. Aber ja, im Grunde ist das eine Notwendigkeit. Sehr schön. Christian, vielen lieben Dank.

Wir haben einen guten Anschlag hinbekommen. Wir haben gesagt, wir müssen halt rechtzeitig aufhören, weil wir beide noch Termine haben und das haben wir jetzt mit Bravour bestanden. Christian, ich habe heute viel gelernt darüber, wie ihr bei Chaos das Thema AI und die AI-Transformation angegangen seid, wie du sie immer noch angehst, wie du vielleicht auch den Blick nach vorne richtest, auch weißt, dass die aktuelle Situation nicht der Endzustand ist, sondern maximal ein Zwischenschritt und wir alle ja auch mit einer gewissen Neugierde immer noch rangehen müssen an das Thema, was dann die nächsten Monate oder Jahre bringt.

Wir wissen es alle nicht, wir können nur spekulieren oder halt versuchen, educated Guests zu machen und adaptieren, lernen. Und ich höre und ich sehe, du machst das bei Chaos an der richtigen Stelle. Vielen Dank und bis bald. Dacka. Mach's gut. Ciao, ciao.

Anmelden oder registrieren

Jetzt

0:00 / 0:00