# Sustainable Software Engineering in the AI Era

**Podcast:** Becoming CTO Secrets
**Published:** 2026-10-06

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und natürlich diejenigen, die es noch werden wollen.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community.
Heute spreche ich mit Govinda Fichtner.
Er ist der CTO bei Qanus.
Was Qanus macht, kann er gleich selber erzählen.
Und er hat rund 30 Jahre Erfahrung in der Softwareentwicklung.
Wir sprechen darüber.
warum nachhaltige Softwareentwicklung weit mehr ist als guter Code, in Brackets würde ich das jetzt mal setzen, warum Architektur immer auch Organisationsdesign ist, ganz wichtig natürlich, und weshalb AI Engineering Exzellenz nicht ersetzt.
Und ich liebe ja das Wort Exzellenz, sondern natürlich sogar verstärkt.
Govinda, herzlich willkommen.
Wunderbar, hier zu sein.
Freut mich auf unser Gespräch.
Und ich freue mich auch.
Es hat ja ein bisschen gedauert, bis wir es hinbekommen haben, aber dafür wird es heute umso besser, haben wir uns vorgenommen.
Deswegen freue ich mich wirklich sehr, dass du da bist.
Ich habe gerade schon angekündigt, du bist der CTO bei Qanus.
Vielleicht kannst du irgendwie schon mal ein, zwei Sätze dazu sagen, was macht Qanus, was ist deine Aufgabe?
Qanus ist eine Firma in einer Nische, nämlich der technischen Dokumentation und dem After-Sales-Service.
Wir haben da eine Reihe von Produkten in unserem Produktportfolio.
Das ist ein B2B-Geschäft.
Kunden sind für uns sehr stark im deutschsprachigen Raum Maschinenbauer zum Beispiel, Deutsche.
Und wir bauen Software, die ihnen hilft, Dokumentationsprobleme zu lösen, Aufgaben zu lösen und im Service dieser Maschinen, die in unterschiedlichsten Konstellationen genutzt werden, zu unterstützen mit Informationen, zum Beispiel für Servicetechniker.
Wir sind eine mittelständische Firma mit ca.
400 Mann.
Und davon ungefähr 120 in der Technik, die ich leite.
Das heißt, du verantwortest auch all diese 120 Leute im Bereich IT-Software-Entwicklung und so weiter.
So ist es.
Sehr gut.
Govinda, du blickst ja auch auf rund 30 Jahre Software-Entwicklung zurück.
Und davon waren es über 20 Jahre als Individual Contributor, wenn ich das richtig sehe.
Ich habe jetzt auch in der Einleitung, sage ich ja immer, der Podcast ist von CTOs für CTOs und diejenigen, die es noch werden wollen.
Ich habe auch heute erlebt, es gibt ja ganz viele, die hören den Podcast gerne und stellen dann trotzdem fest, sie wollen gar nie CTO werden.
Du hast jetzt aber nach einer sehr langen Zeit in der IC-Rolle, hast du dann doch jetzt gesagt, jetzt will ich CTO werden oder wie genau war das?
Das hat sich über die Jahre so entwickelt.
In gewisser Weise gab es nie eine Anleitung darüber, wie man CTO wird.
Im Grunde sind die Aufgaben größer geworden.
Ich habe mich immer dafür interessiert, wie Architektur aussieht, auch in meiner Individual Contributor-Rolle und dann mit der Zeit festgestellt, dass Architektur und Organisation sehr eng verbunden sind.
Und so hat sich das dann Richtung, ich sage mal, Architekturrollen entwickelt, Chefarchitekturrollen in größeren Kontexten und irgendwann gab es dann den Sprung quasi in die erste CTO-Rolle.
Was hat damals den Ausschlag gegeben dazu?
sehr erfüllende Aufgabe.
Ich stelle mir auch mal wieder die Frage und ich glaube viele da draußen auch, was bedeutet denn eigentlich gute Software zu bauen?
Du warst ja auch in verschiedenen Kontexten unterwegs.
Du hast es gerade selber auch schon angedeutet.
Konzern, Consulting, kleinere Firmen, Startups, Webentwicklung, Cloud, DevOps, war ja ganz eine Menge dabei.
Also A, was bedeutet für dich gute Softwareentwicklung und wo hast du dieses Verständnis davon, was gute Softwareentwicklung sein soll?
am meisten entwickelt oder wo hast du sie am meisten verstanden?
Ich denke, das, was für mich gute Softwareentwicklung ausmacht, ist tatsächlich nachhaltige Softwareentwicklung.
Systeme, wo man in der Lage ist, über viele Jahre hinweg mit einer nachhaltigen Geschwindigkeit, mit einer nachhaltigen, gleichbleibenden, guten Qualität zu liefern.
Und das, was das für mich zu einem bedeutenden Thema gemacht hat, ist, dass ich über die Jahre natürlich viele Situationen erlebt habe, viele Umstände, wo man gesehen hat, wie Systeme quasi über die Jahre, manchmal Jahrzehnte, Stück für Stück verfallen sind und damit dann ganz viele, ich sage mal, Probleme einhergegangen sind, die man dann, ich sage mal, als Organisation, als Teams kompensieren musste und wo man gegen diese Strukturen und gegen Versäumnisse oftmals dann anarbeiten musste.
Wie sieht das dann konkret aus?
Ich meine, die meisten Entwickler, die fangen ja nicht an, von heute auf morgen einfach so schlechten Code zu schreiben.
Ganz viele, also die meisten zumindest nicht, weil ganz vielen ist dann natürlich schnell, wird die Hand gehoben und gesagt, ja, wir würden ja gerne, aber wir kriegen immer so viel Druck und wir müssen ja schnell machen und deswegen haben wir ganz viele technische Schulden.
Und in dieser Gemengelage zwischen der Manager, der schreibt am Ende keinen Code, der macht vielleicht Druck, aber der Entwickler ist derjenige, der den Code schreibt und der die Legacy-Software dann am Ende des Tages auch.
mit zu verantworten hat.
In dieser Gemengelage ist es ja schwierig, einen Schuldigen auszumachen, an dem man jetzt festmacht, wie man jetzt aus diesem Teufelskreis rauskommt.
Wie gehst du denn damit um zwischen Anforderungen, die auch manchmal unfair sind vor dem zeitlichen Horizont und der Verantwortung, die Entwickler auch mit übernehmen müssen für die Software, die sie entwickeln, auch wenn sie mal zu technischen Schulden führt?
Ich denke, dass viele dieser Herausforderungen dadurch entstehen, dass natürlich verschiedene Stakeholder in so einer Gemengelage, also in der Gemengelage der Softwareentwicklung miteinander zusammenarbeiten aus unterschiedlichen Blickwinkeln, aus unterschiedlichen Funktionen des Unternehmens, von der Sales-Seite über die Marketing-Seite hin zu Customer-Support-Seite, dann den technischen Teams, die diese Dinge bauen.
Und jeder sieht natürlich immer nur einen Teil des größeren Ganzen.
Und ich sage mal, dabei werden oft ich sag mal, wird das System nicht ganzheitlich gesehen und betrachtet und entwickelt, das ist das eine und das andere ist, dass natürlich auch zu unterschiedlichen Zeiten unterschiedliche Prioritäten existieren, die quasi Teams in eine bestimmte Richtung drücken und das muss, ich sag mal, aus meiner Sicht Teil einer nachhaltigen Softwareentwicklungsstrategie, diese immer auszubalancieren.
Und ich sag mal, das mentale Bild, was für mich da ganz wesentlich ist, Oft für viele Stakeholder, die nicht direkt aus der Technik kommen.
Was sie sehen, sind die Features, die Produkteigenschaften.
Das ist die Spitze des Eisbergs.
Aber tatsächlich die Dinge, die nachhaltige Softwareentwicklung wesentlich beeinflussen, das sind die Elemente, die unterhalb der Wasserlinie sind.
Und das ist der weit größere Teil des Eisbergs.
Und das, was oft passiert, ist, dass der sichtbare Teil viel Aufmerksamkeit bekommt, strategisch bearbeitet wird.
Aber unter der Wasserlinie liegende Anteil nicht.
Woran merkt man das konkret?
Also ich meine, woran merkt man, dass Softwareentwicklung dann nicht nachhaltig ist?
Ist das dann einfach, wenn die Teile, die unter der Wasseroberfläche liegen, nicht bearbeitet werden oder gibt es da noch mehr?
Merkt man vor allem daran, dass Entwicklungsgeschwindigkeit, die vielleicht zum Start einer Produktentwicklung hoch ist, über die Jahre langsamer wird, signifikant langsamer wird.
Änderungen, die vorher...
möglicherweise eine Woche gebraucht haben, dann plötzlich drei Wochen brauchen oder noch länger brauchen, vielleicht gar nicht mehr sinnvoll, also kommerziell und in der Aufwandsgesichtspunkten überhaupt nicht mehr möglich sind.
Teams Angst haben vor Veränderungen.
Das sind alles so Aspekte.
Und dann sind so Aspekte vielleicht auch von Dingen, die nur dann relevant wären, wenn sie plötzlich nicht mehr da sind, wie zum Beispiel Sicherheit.
In Sicherheit zu investieren regelmäßig, Mag verlieren gegen andere, ich sag mal, Wünsche, wie schnell ein Feature zu bauen, aber wenn dann mal ein System gehackt wird, Daten verloren oder kompromittiert ein System ist, dann ist das natürlich ein großes Ding und hat tatsächlich auch eine aktuelle Relevanz.
Wir haben den Cyber Resilience Act, der jetzt aktiv wird.
wo quasi Unternehmen, die IT-Produkte produzieren, auch in der Verantwortung sind, Sicherheitslücken, die bekannt werden, zu kommunizieren und dann auch zeitnah zu beheben.
Und damit wird es dann auch aus juristischer Sicht ein wesentliches Anliegen.
Wie kommunizierst du jetzt diese...
Dieses nachhaltige Softwareentwicklungsmodell oder auch das Eisbergmodell, das du jetzt gerade genannt hast, wie kommunizierst du das mit einem CEO oder mit einem Product Leader, der vielleicht nicht immer auf dem Schirm hat, dass Architektur, Modularität, nicht funktionale Anforderungen, dass das Aufwand erfordert, dass das Kosten verursacht.
Wie gehst du damit um?
Man kann es sich vorstellen wie ein Schiff.
Da gibt es den Teil des Schiffs, der unter der Wasseroberfläche ist, der nicht gesehen wird, wo man nicht möglicherweise leicht bereitwillig rein investiert.
Aber in dem Moment, wo quasi dieser Teil beschädigt ist, dann geht das ganze Schiff unter.
Ziele, die man hat, kann man nicht mehr erfüllen.
Sicherheit ist zum Beispiel ein Thema da sicherlich, Skalierbarkeit ist ein Thema, Wartbarkeit, Erweiterbarkeit, das sind alles Themen, die mögen in den Anfängen, in den ersten Jahren vielleicht von komplexer Produktentwicklung keine Rolle spielen, aber über die Jahre hinweg werden sie dann ganz wesentlich.
Und am Ende führt es dann möglicherweise dazu, dass man ein Produkt komplett ersetzen muss und dann all die möglicherweise Risiken eines Big Bangs, releases hat, wo man das eine System komplett durch ein neues System ersetzen muss.
Wie machst du denn sowas sichtbar dann gegenüber dem CEO?
Gerade wenn es um das Thema Wartbarkeit geht oder Erweiterbarkeit, ist das, ja, du kannst ja sagen, ja, wir sind jetzt auf einmal nicht mehr so gut erweiterbar wie vorher.
Dann sagt er, ja, aber wo sehe ich denn das?
Wie kann ich denn unterscheiden, wann sind wir denn wieder gut?
Aus meiner Sicht ist das natürlich ein Spektrum.
Da gibt es nicht eine Antwort darauf für jede Situation, was funktioniert.
Aber ich sage mal, ein Aspekt, der mir tatsächlich wichtig ist, sind die DORAMetriken.
Und quasi Metriken, die Geschwindigkeit ausdrücken auf der einen Seite.
Das sind zwei der üblichen vier DORAMetriken.
Und Stabilität, also betriebliche Stabilität.
Und dann ist es natürlich in dem Kontext auch eine Frage, ist es jetzt eine klassische On-Prem-Software, die quasi der Kunde kauft und dann selbst sich darum kümmert, um den Betrieb, oder ist es quasi ein SaaS-Kontext, wo man sowohl als Team für die Entwicklung als auch für den Betrieb zuständig ist.
Also die Dora-Metriken und ich sag mal, die entsprechenden Industrie- also die Einordnung unserer Industrie, was quasi hier gute Performance ist und was Schlechte darstellt.
Und in den letzten Jahren habe ich angefangen, auch noch ein weiteres metrigen Framework als nützlich zu achten, was das Northstar Framework ist, von einer Firma bekannt gemacht, die sich Amplitude nennt.
die im Grunde das, was Dora für die Engineering-Arbeit ist, ausweitet auf den Produktmanagement-Aspekt.
Bauen wir tatsächlich, ich sage mal, Funktionalität, Produktaspekte, die einen echten Wert für Kunden haben und sind wir in der Lage, das zu artikulieren, zu messen, zu tracken und können wir das dann in Relation setzen zu unseren...
eigentlich am Ende immer beständigen Trade-off, also Abwägungsentscheidungen, die wir machen, aus einer technischen Sicht.
Siehst du da immer wiederkehrende Muster?
Also gerade wenn du sagst, am Anfang sind Teams immer sehr schnell, gerade so in den ersten ein bis zwei Jahren und danach werden sie immer langsamer.
So was passiert denn in diesen Phasen typischerweise im System?
Ist das etwas, wo du immer wiederkehrende Muster siehst?
Es ist dann doch immer sehr stark kontextabhängig und situationsbezogen, warum sie langsamer werden.
Naja, ich sage mal, wiederkehrende Muster sind da sicherlich sichtbar.
Ich persönlich denke, dass es Aspekte, Praktiken, Methodiken gibt, wenn man die von Anfang an, auch wenn das System klein ist, das Produkt in den Anfängen ist, wenn man die anwendet und da das Niveau immer auf einem hohen Level hält.
dann erodiert im Grunde nie der Teil unter dem Eisberg wirklich, sondern wächst in seiner Qualität mit dem, was quasi als Spitze des Eisbergs über der Wasseroberfläche zu sehen ist.
Also das ist ein Aspekt.
Dann denke ich, ein weiterer Aspekt ist sicherlich die Organisation, die Teamstruktur und damit quasi das Thema Conway's Law, also dass quasi die Kommunikationsstrukturen von Teams am Ende auch die Architektur maßgeblich beeinflussen.
Also das sind aus meiner Sicht ganz, ganz wesentliche Aspekte.
Und der Umgang mit technischer und wenn man so will auch organisatorischer Schuld, dass man quasi bewusst dieses Spielfeld betrachtet, wenn man, ich sag mal, technische Schuld beständig quasi eingeht, Abkürzungen nimmt, ohne dann je ein Verständnis dafür zu haben, was man an Schuld angehäuft hat und was das für, ich sag mal, Zinszahlungen sind, die sich dadurch ergeben.
dann hat man natürlich auch kein Verständnis dafür und keine Chance, das wieder auch abzutragen.
Und dann erschlägt einen irgendwann diese Zinslast.
Ähnlich wie möglicherweise manche Volkswirtschaften zu viel Schulden anheufen und dann, so wie jetzt die USA, feststellen, dass die Zinszahlungen immer größer werden.
und ihren Handlungsspielraum einschränken.
Also ich denke, das ist tatsächlich ein gutes Beispiel.
Der Handlungsspielraum wird sukzessive mehr und mehr eingeschränkt, wenn man diese technischen Schuld und organisatorischen Schuldaspekte nicht managt.
Oft, denke ich, ist das auch ein Artikulationsthema.
Also erstens eine Wahrnehmung dafür zu haben und B, das dann zu artikulieren und zwischen verschiedenen Stakeholdergruppen sichtbar zu machen und dann zu einem beständigen, kontinuierlichen, neu ausbalancieren zu bringen.
Wie schmal ist der Grad zwischen Overengineering und nachhaltiger Softwareentwicklung?
Weil Engineers auch immer wieder dazu tendieren, auch mal in Overengineering abzurutschen und nach der perfekten Lösung zu streben.
Und dabei wäre eine andere Lösung good enough gewesen und wäre vielleicht sogar auch nachhaltig gewesen.
Also aus meiner Sicht ganz wesentlich, das ist ein Fakt.
Wir als Techniker, wir haben eine gewisse Verspieltheit, wir haben eine Faszination mit Technik und wir wollen natürlich wissen, was möglich ist.
Und ich denke, das ist ein wesentlicher Aspekt von Erfahrung und Seniorität beurteilen zu können, wie viel man braucht, dass man da iterativ, inkrementell an Phasenweise, an Aspekte herangeht.
Es gibt ja dieses Wurzel auch, Jagni, you ain't gonna need it.
Ich denke, das ist ganz wesentlich.
Also im Grunde, wenn man davon ausgeht, dass ein System skalieren muss, dann ist es möglicherweise die richtige Entscheidung zu sagen, okay, ich gehe davon aus, dass es um den Faktor 10 skalieren muss, muss es um den Faktor 100 skalieren können, muss ich entsprechend, bevor ich tatsächlich...
die Datenlage habe, das System weiter optimieren.
Ich glaube nicht.
Wichtig aus meiner Sicht ist eher, dass man ein Messsystem hat, ein Observability-Setup, in dem man frühzeitig erkennt, was die Faktoren sind, die zum Beispiel Skalierbarkeit oder Performance ausmachen und dass man mit diesen Informationen dann systematisch und frühzeitig erkennen kann, in welche Richtung die Reise geht und man reagieren kann.
Also die Reaktionsfähigkeit, die Lernfähigkeit des Systems erscheint mir da der wichtige Aspekt zu sein.
Ja, Observability-Setup hast du genannt.
Was nutzt du denn dafür typischerweise?
Observability, gut, das hat sich über die Jahrzehnte sehr stark auch verändert, zusammen mit den großen Trends unserer Industrie.
Früher gab es quasi diese sehr infrastrukturserverseitig getriebene Monitoring-Lösung, wie zum Beispiel auch die von der Firma Pessler, für die ich eine Zeit lang gearbeitet habe.
Und irgendwann kam dann mit New Relic die, ich sag mal, application-zentrierten Monitoring-Systeme, die entwicklerzentrierten Monitoring-Systeme.
Und die bevorzuge ich deswegen, weil sie im Grunde einzahlen auf, ich sag mal, das DevOps-Modell.
Also you build it, you run it.
Die quasi Auflösung von Silos zwischen Entwicklung und Betrieb.
Das heißt, wenn die Entwickler quasi in der Lage sind, für die wesentlichen Aspekte dessen, was eine gut funktionierende Anwendung ist, ein Observability Setup haben, ein Feedback Loop haben, dann ist das am Ende das, was sicherstellt, dass das System gut funktioniert.
Benutzt.
Ich sag mal, in meiner Karriere und die Teams, mit denen ich gearbeitet habe, haben vieles, ob das Datadog war, New Relic war, Scout war, es gibt auch immer wieder neue Systeme, Open-Source-Systeme, Looks-Good-To-Me-Stack, also Loki, Grafana, solche Sachen zum Beispiel, mit dem ganzen, ich sag mal, Entwicklungen rund um Container aus den letzten Jahren.
Da gibt es nicht das eine Tool, sind quasi Werkzeuge in einem Werkzeug.
Werkzeugkiste.
Man muss halt das wählen, was in dem jeweiligen Kontext am besten passt.
Von den Non-Functional Requirements, welche würdest du denn jetzt in einem wachsenden Softwareunternehmen besonders früh ernst nehmen?
Definitiv Sicherheit, dann die Wartbarkeit und die Testbarkeit.
Also Testbarkeit aus meiner Sicht ist natürlich eines der wichtigsten Dinge, weil die am Ende darüber entscheidet, ob das System gut designt ist.
Wenn es sich nicht gut testen lässt, also wenn Testen quasi eher ein Nachgedanke ist als von Anfang an dabei, dann ist es viel, viel schwieriger, gute Testing-Strategie, Testautomatisierung-Strategie zu definieren und am Ende quasi auch die Qualität des Produktes sicherzustellen.
Und das ist ein wesentlicher Faktor, der dann später darüber bestimmt, mit welcher Geschwindigkeit man das System verändern kann, mit welcher Zuversicht man das System verändern kann und ob man so Praktiken wie Continuous Delivery einführen kann und wo man da in dem Spektrum im Sinne von Geschwindigkeit man sich bewegt.
Released man alle drei Monate, released man jeden Monat, released man wöchentlich oder released man möglicherweise mehrfach am Tag.
Und aus meiner Sicht, das bevorzugte Modell wäre definitiv in der Regel zu sagen, ich kann mehrmals am Tag releasen.
Und das ist am Ende dann auch wieder ein Hinweis darauf, dass das Setup hinten dran, das CICD-Setup, die Qualitätssicherung, die Testautomatisierung, dass diese Aspekte alle einen gewissen Reifegrad haben, eine Qualität.
Du hast jetzt eben schon von Conway's Law gesprochen.
Und ich habe dich ja auch so verstanden, auch im Vorgespräch, dass Architektur früher für dich noch viel stärker...
code-orientiert war.
Also es ging dann um Methoden, es ging um Klassenmodule.
Heute betrachtest du das eher stärker über die Organisation und Teamstrukturen, deswegen eben Convace Law.
Was war denn da der entscheidende Perspektivwechsel?
Ja, der entscheidende Perspektivwechsel war im Grunde zu sehen, dass man möglicherweise immer wieder die gleichen Probleme, auch wenn man ein System refactored hat, bekommen hat.
Und dass diese Probleme gar nicht technischer Natur waren, sondern dass die eher damit zu tun hatten, wie quasi die Systeme geschnitten waren und die Systeme sind oft quasi nach den Team-Kommunikationswegen geschnitten und wenn das dann dazu führt, dass wenn man Veränderungen machen muss in einem Bereich, aber am Ende mit drei Teams zusammenarbeiten muss, einen großen Koordinations- und Kommunikations- Bedarf und Aufwand hat und wesentlich Probleme nur sehr, sehr zäh und schwierig zu lösen sind, dann ist das ein Hinweis darauf, dass tatsächlich das Ganze eben nicht nur ein technisches Problem ist, sondern auch ein organisatorisches Thema, wie die Teams geschnitten sind.
Wie zeigt sich denn Conway's Law in einer realen Engineering-Organisation?
Naja, so wie ich es gerade sagte, einerseits quasi Koordinierungsaufwand, dass einfache Veränderungen nicht an einer Stelle durch ein Team bewirkt werden können, sondern möglicherweise über mehrere Teams hinweg passieren müssen, dass es dort einen hohen Koordinierungsaufwand gibt, Friktion.
Prinzipiell ist sowieso in meiner Erfahrung so, dass ich zusammenarbeite.
üblicherweise vergleichsweise einfach und gut funktioniert innerhalb von einem Team, aber in dem Moment, wo es über Teamgrenzen hinweg geht, wird es schwieriger.
Und dann ist das natürlich auch ein Aspekt davon, wie quasi diese Software entwickelt und betrieben und ausgerollt wird.
In einem, ich sag mal, SaaS-Cloud-Setup ist es dann so, dass man die Software am Ende auch deployt und die Frage ist dann, müssen da wieder drei Teams zusammenarbeiten, um was zu deployen oder können diese Deployments unabhängig passieren?
Hat es eine Art von Microservice-Architektur oder zumindest eine Art von Modularisierung oder ist alles im Grunde ein Monolith, ein Big Ball of Mud und das macht diese Art von Arbeitszeilung schwer.
Ich rede ja tagtäglich mit CTOs in allen möglichen Kontexten und ich kenne nicht wenige, die sagen, dass es ihnen schwer fällt zu verstehen, wenn jetzt dann Teamstruktur gegen die gewünschte Systemarchitektur arbeitet.
Also ihnen fällt das schwer, sowas zu erkennen und auch sichtbar zu machen und dann darauf zu reagieren.
Hast du einen Vorschlag, wie man sich dem Thema nähern kann?
Weil das ist für viele doch recht abstrakt zu entscheiden, wann meine Organisation sich negativ auf meine Architektur niederschlägt oder nicht.
Das sind wahrscheinlich auch verschiedene Antworten, aber ich sage mal, das, wo für mich eine große Hilfe ist, wie ich darüber denke, ist quasi Domain-Driven Design.
Also quasi die Idee, wie ich ein komplexeres, großes System in Teildomänen zerteile.
und wie ich dann quasi diese Teildomänen, möglicherweise Services, die das Gesamtsystem ausmachen, wie die verteilt sind über die Teams und wie die Verantwortlichkeit da gestaltet ist.
Also das ist aus meiner Sicht ein wesentlicher Aspekt.
Ich persönlich bin auch sehr beeinflusst durch die Ideen von Team Topologies.
Das ist ein Buch.
was in den letzten Jahren sehr populär geworden ist, was quasi von sogenannten Stream-Aligned Teams spricht, also genau auch so vor dem Hintergrund von Conway's Law, Domain-Driven Design, diesem Domainverständnis, wie designe ich quasi Organisation und Architektur und die Services zusammen.
Und was sind möglicherweise Themen, die nicht in einem Stream-Aligned Team organisiert sein sollten, sondern in einem Plattform-Team zum Beispiel, was quasi spezialisierte Produktaspekte verantwortet, auf die dann andere Teams aufbauen.
Und gewisserweise ist das auch ein Trend der letzten zwei, drei Jahre, nämlich sogenannte Internal Developer Platforms zu kreieren.
Ich denke, das ist auch eine Entwicklung der letzten 20 Jahre, die kognitive Last, die Komplexität dessen, was wir an Technik...
verantworten als Teams, die ist massiv gewachsen.
Ist das für dich auch ein gutes Beispiel für so eine Art Reverse Conway, was du da gerade beschrieben hast mit den Team Topologies, also dass die Teams ganz bewusst dann so zu strukturieren, dass eine gewünschte Architektur wahrscheinlicher wird?
Ja, absolut.
Also ich bin, das ist ein wesentlicher Unterschied, ich sage mal, in der Art, wie ich über diese Architekturaspekte denke, wie du vorhin schon sagtest, in den ersten Vielleicht sogar Jahrzehnten meiner Karriere habe ich Architektur als eine technische Sache betrachtet.
Die Modularisierung, die Klassen, die Methoden, alles, was man so mit Clean Code verbindet, als wesentlichen Einflussfaktor zu sehen.
Aber tatsächlich bin ich heute an dem Punkt, wo ich sage, das geht nicht ohne Organisation.
Man muss die Teams bei größeren Herausforderungen quasi auch mit berücksichtigen und anders formen ausprägen.
Wie gestaltest du denn als CTO das Thema?
Du hast ja eben schon von Kommunikationsgesprochen und wie Kommunikation auch dazu beiträgt oder sich in technischen Entscheidungen niederschlägt, in Architekturentscheidungen und so weiter.
Das ist natürlich auch geprägt durch Organisation.
Welches Team darf mit welchem reden?
Wie gestaltest du das als CTO?
Du musst ja erstmal Kommunikationsmuster erkennen, um danach auch sagen zu können, das hat jetzt den Einfluss auf diese und jene Architekturentscheidungen und das gefällt mir nicht, in welche Richtung das geht, also greife ich ein.
Oder wie machst du das?
Ich denke, es ist gut, wenn man was hat, was ich als technische Führung bezeichnen würde, die klar ausgeprägt ist in der Organisation.
Eine Organisation mit 120 Mann, mit 14 Teams in meinem Fall, braucht ein gewisses Maß an gemeinsames Verständnis dessen, was das Spielfeld ist.
Also was sind die technischen Standards, was macht Qualität aus, was sind unsere Herausforderungen als Organisation in Bezug auf die Produkte und wie die Produkte technisch realisiert werden.
Das muss klar artikuliert und abgestimmt sein.
Das ist für mich ein wesentlicher Aspekt.
Und dann, ich sag mal, wesentliche Player zu haben, die für Aspekte wie Architektur, Security, Compliance, Ways of Working zuständig sind und die prägen.
Also quasi, ich sag mal, Guardrails, Leitplanken etablieren.
gewisse Grundstandards, nicht mit dem Ziel, dass die einzelnen Teams am Ende überhaupt keine Entscheidungsspielräume mehr haben, sondern dass quasi das Maß der Standardisierung, die Qualitätserwartungen, dass die klar sichtbar sind.
Und die Strategie, weil am Ende ist alles immer auch ein Faktor, wo die Dinge sich über den Zeitstrahl hinweg verändern.
Und das, was möglicherweise vor drei Jahren wesentliche Aspekte waren, sind jetzt ganz andere.
Und das muss überall sichtbar werden.
Vielleicht noch als letzte Frage zu dem Punkt, weil da beschäftigt mich tatsächlich auch die Frage, wann ist denn ein Problem wirklich ein Architekturproblem und wann ist es ein Organisationsproblem?
Oder lässt sich das gar nicht so klar voneinander trennen?
Ich denke, manchmal lässt sich das nicht so klar voneinander trennen.
Ich denke, das ist immer sehr abhängig vom Kontext.
komplexes System haben, wo es Sinn macht, zum Beispiel eine Bankreservice-Architektur zu haben, damit man quasi eine größere Arbeitsteilung realisieren kann, eine größere Parallelisierung, das unabhängige Bewegen einzelner Teams.
Aber möglicherweise macht es genauso Sinn, in anderen Konstellationen ein Majestic Monolith zu haben, wie die letzten zwei, drei Jahre wieder von bestimmten Größen unserer Industrie.
quasi postuliert wird.
Und ich denke, das ist völlig korrekt.
Es gibt nicht quasi die eine Lösung, die für alle Konstellationen passt.
Es gibt immer nur Trade-off-Entscheidungen, weil auch eine Microsoft-Architektur bringt eine Komplexität mit.
Container-Architekturen bringen eine Komplexität von verteilten Architekturen, Netzwerk-Aspekten mit, die möglicherweise nicht in allen Fällen sinnvoll sind.
Monorepo versus eine Repolandschaft von 20, 30 Repos für ein Produkt.
Und auch das ist nicht nur in der Vergangenheit wesentlich gewesen, sondern ist jetzt tatsächlich auch mit AI.
AI wieder ein Thema.
Wenn man mit AI und Cloud-Code arbeitet, dann ist die Frage, sind all die Informationen, die ich habe, in einem Repo oder sind die verteilt über 20?
Eine Frage auch, die darüber entscheidet, wie effizient die Zusammenarbeit mit AI an der Code-Basis sein kann.
Also aus meiner Sicht, es gibt nicht die eine Antwort.
Ja, und wenn wir auch jetzt schon so viel über Softwareentwicklung auch philosophieren oder Das versuchen abzugrenzen.
So ab dem Jahr, ich glaube es war 2005, kann man glaube ich sagen, war das Thema Cloud sehr stark populär geworden.
Du warst sehr früh bei den Themen dabei, bei AWS, bei Cloud-Themen und so weiter.
Wie hat denn das Thema Cloud Softwareentwicklung grundsätzlich verändert?
Eine wunderbare Veränderung in gewisser Weise, aufbauend eigentlich für mich in der Wahrnehmung auf den Fortschritten rund um Virtualisierung und nicht zufälligerweise.
Offensichtlich waren auch die ersten Cloud-Dienste, zum Beispiel EC2 oder S3 bei AWS und das hat eine große Veränderung bewirkt, weil man vorher Infrastruktur quasi als Deployment-Ziel für ein Software-Produkt zur Verfügung stellen musste, dann waren damit oft, ich sag mal, wochenlange Prozesse verbunden, quasi diese Infrastruktur zu planen, zu bestellen, zur Verfügung zu stellen, aufzubauen, in Betrieb zu nehmen und das hat sich natürlich massiv gehandelt mit Cloud.
Da ist das quasi Nur noch dann eine Frage von einem API-Call gewesen und möglicherweise ein paar Minuten, bis ein System dann quasi einsatz- und betriebsbereit war.
Und das hat dann dazu geführt, dass die Automatisierungsmöglichkeiten quasi massiv größer geworden sind.
Alle Aspekte, wie man das zur Verfügung stellen von Infrastruktur.
automatisiert machen kann, testen kann, wieder abreißen kann.
Das bedeutet am Ende auch, dass man natürlich viel schneller experimentieren kann, also dass quasi das Lernen günstiger geworden ist, dass solche Infrastruktur hoch und runter skalieren konnte, on demand, je nachdem, was halt quasi die Workload war zu einem bestimmten Zeitpunkt.
Und das hat dann aus meiner Sicht Natürlich auch beigetragen dazu, dass man agile Methoden besser einsetzen konnte, ich sage mal, auf Basis von agilen Methoden iterativ, inkrementell arbeiten konnte, weil man viele Dinge nicht mit einem längeren Zeithorizont vorhersehen und planen musste, sondern sich das entwickeln lassen konnte.
Und wie hängen die denn aus deiner Sicht zusammen, diese Themen?
Also es ist ja nicht nur Cloud und Agilität, ist das Thema DevOps auch noch mit dazu.
Die hängen zusammen und die sind sehr stark miteinander verknüpft, das sagst du ja auch.
Wie hängen die denn zusammen?
Absolut.
Die hängen aus meiner Sicht sehr stark zusammen, weil in dem Moment, wo ich diese Infrastruktur automatisiert deployen kann und dazu dann das entsprechende Observability-Harness deployen kann, dann habe ich immer eine sehr gute Feedback-Qualität, habe einen engen Feedback-Loop.
Es ermöglicht, dass das, was Quasi Infrastruktur bedeutet, das zu programmieren, ja, Infrastructure as a Code, war plötzlich eine Programmieraufgabe und keine Administrationsaufgabe, nichts, was manuell war.
Es hat im Grunde die Mauer entfernt, die zwischen Entwicklungs- und Betriebseinheiten existiert, hat die Silos aufgelöst und am Ende war quasi das, was vorher zwei Funktionen waren, zwei Teams waren, es ist zu einem verschmolzen.
Und das gibt es natürlich in unterschiedlichen Ausprägungen, manchmal in der, dass ein Team einen DevOps-Ingenieur hat, der für diese operativen Aspekte mehr verantwortlich ist, aber ich persönlich bevorzuge das Modell, wo quasi Entwickler, also wo der Hut, den man aufhat als Ingenieur in einem Team, ständig wechselt zwischen Entwicklungs- und operativen Aspekten, mehrmals täglich, vielleicht dutzende Male am Tag und man diese Aspekte, in dem Betreiben des Produktes fließend ineinander übergehen.
Und das bedeutet, dass natürlich auch der Schmerz, den man hat im Betrieb von Systemen, dass der sichtbar ist und dass man dann sehr schnell auch quasi sieht, wie das, was man entwickelt hat, zu gewissen Problemen in Betrieb führt.
Und das ist dann quasi ein wesentlicher Teil von dem Wert für mich, was DevOps ausmacht, dass diese diese Signalwirkung stark ist, dass man das Signal sofort aufnehmen kann und umsetzen kann in eine Lösung, in einer Person, die quasi nach dem DevOps-Modell arbeitet.
Wie siehst du denn das Thema Agilität?
Da hast du es jetzt eben auch nochmal angesprochen, dass es auch wichtig ist und so.
Wie siehst du das jetzt gerade auch im Jahr 2026?
Wird das immer wichtiger?
Verliert es aktuell so ein bisschen an Bedeutung oder gerät deinen Hintergrund vor der immer krasser um sich greifenden Agentic AI SDLC Invasion?
Ja, für mich ist das genauso relevant wie vor 20 Jahren.
Ich habe meine Karriere ja in Zeiten gestartet, wo wir nach Wasserfall gearbeitet haben, komplexe Projekte bei T-Systems, bei Telekom gemacht haben mit Wasserfall, mit V-Modellen, mit Rational Unified Process und All die Probleme, die da existieren, die habe ich aus erster Hand kennengelernt und für mich sind nach wie vor die Prinzipien agiler Entwicklung wesentlich und relevant.
Der wesentliche Grund dafür ist, dass wir oft als Menschen als Anforderer schlecht sind, alle Aspekte, die wir von einem System erwarten, klar zu artikulieren.
Manchmal glauben wir, wir wissen es und am Ende stellt sich dann doch heraus, wenn unsere Nutzer, unsere Kunden es benutzen, dass es doch ganz anders ist.
Und deswegen glaube ich, das ist ein wesentlicher Aspekt von inkrementeller, iterativer Entwicklung, sich dem Stück für Stück anzunähern, was tatsächlich das ist, was gebraucht wird.
Das ist der eine Faktor.
Und dann da, wo man lernt, dass bestimmte Aspekte wichtig sind, die man noch nicht berücksichtigt hat, dass man die schnell hinzufügen kann.
Und ich glaube, dass dieser Aspekt auch...
in einem Zeitalter von AI unterstützter Entwicklung ganz wesentlich ist, weil wir bewegen uns noch schneller.
Code-Generierung geht noch schneller.
Aber dieses grundsätzliche menschliche Problem, quasi Anforderungen zu artikulieren, Systeme zu bauen, die Jobs erfüllen, die sie erfüllen sollen, diese Problematik geht nicht weg.
Gerade was die Anforderungen angeht, gibt es jetzt ja einige, die sagen würden, naja, aber die Anforderungen, die macht mir jetzt die AI, die kann sie vollständiger und lückenloser erstellen wie vorher auch.
Klar, da stellt sich die Frage, ist das alles immer notwendig und haben wir dadurch nicht ganz viel Scope Creep.
Aber was jetzt die Anforderungen angeht, da hat sich doch jetzt vieles vereinfacht oder würdest du das anders sehen?
Anforderungen im Sinne von Requirements Engineering, also im Sinne von dem, was ein Kunde von einem Produkt will.
Woher weiß die AI, was die ganzen Jobs sind, die ein technischer Redakteur in der Nische der technischen Dokumentation benötigt, wie das Produkt dort eingesetzt wird bei Kunden, wie sich verschiedene Kunden unterscheiden in ihren jeweiligen Handlungsfeldern.
Die AI braucht Kontext dafür, genau.
Die AI braucht Kontext.
So ist es.
Und deswegen bin ich auch der Meinung, für mich hat Kontext, Bei AI unterstützt die Entwicklung zwei Komponenten.
Das eine ist Engineering-Kontext, also Architektur, Qualitätsstandards, Ways of Working, all diese Aspekte zum Beispiel.
Aber es ist auch Produkt-Kontext, also quasi was ist die Produkt-Mission, was ist die UX-UI-Erfahrung, die realisiert werden soll, was ist der Markt, die Domäne, die Kunden, die Probleme, die sie lösen wollen.
Und erst wenn all diese Dinge zusammenkommen, aus meiner Sicht, wird AI ihr echtes, ihr volles Potenzial realisieren können.
Okay.
Jetzt ist natürlich Scrum nicht gleich Agile, aber...
Das ist ein wichtiger Punkt, ja.
Genau, das ist aber, was ich erlebe gerade in der Industrie, ist ein massiver Rückgang von Scrum-Teams, speziell dort.
wo das Level an Autonomie und Automatisierung mit Agentic-AI-Workflows zunimmt.
Siehst du das auch oder glaubst du, das ist nur ein vorübergehender Effekt, der sich wieder einstellen wird?
Also ich glaube, ich sehe das genauso, dass Scrum vielfach im Moment kritisiert wird oder auch abgelehnt wird.
Ich denke, man muss da sehr stark unterscheiden zwischen Agilität, also agile Entwicklungsmethodiken und den Prinzipien des agilen Manifests und den Frameworks, mit denen man das quasi betreibt.
Und ob das jetzt Scrum ist, ob das Kanban ist oder ob das sowas ist wie...
Ja, ein anderes Framework, das ist aus meiner Sicht nicht das Entscheidende.
Für mich sind die entscheidenden Dinge tatsächlich die Prinzipien des agilen Manifests, die für mich nach wie vor gültig sind.
Und das, was oftmals kritisiert wird an Scrums, ist ja eher so die Art und Weise, wie Scrum quasi die Arbeit organisiert, was für Rollen sie vorsieht.
Vielleicht wie Scrum...
ich sage mal, nach dem Buch gelebt wird.
Und ich habe viele Umfelder auch kennengelernt, in denen Scrum quasi draufstand.
Aber am Ende war es eigentlich nur alter Wein in neuen Schläuchen.
Das heißt, die Organisationen haben trotzdem wasserfallartig gearbeitet, haben aber sich den Anstrengen gegeben, dass sie in der Scrum arbeiten, haben gewisse Rituale und Zeremonien gehabt.
Aber die Prinzipien haben sie eigentlich tatsächlich nicht gelebt, die des agilen Manifests.
Was wird denn an Agilität heute noch am häufigsten falsch verstanden?
Ich denke, das, was falsch laufen kann, ist, dass die Rituale wichtiger sind als eigentlich die drunterliegenden Prinzipien.
Wesentliche Prinzipien sind für mich eben das iterative, inkrementelle, dass das, was in Produktion ist, am Ende der echte Beweis ist, dass was funktioniert, wenn es von Kunden genutzt wird und die bestätigen, dass das funktioniert, dass man nicht monatelang an irgendwelchen Funktionalitäten feilt und die dann vielleicht ausrollt, sondern dass diese Inkremente kleiner sind, dass der Blastradius für Veränderungen kleiner ist, damit man schneller und souveräner reagieren kann, wenn das nicht funktioniert, das frühzeitig erkennt.
Also im Grunde sind das sehr stark Validierungsaspekte von Scrum technisch oder auch aus Produktsicht.
Die enge Zusammenarbeit mit dem Kunden, Lernaspekte, dass man das Lernen optimiert, was dann automatisch natürlicherweise dazu führt, dass man gute Produkte baut.
Produkte, die den Job erfüllen, die die Kunden erwarten.
Weißt du, was spannend ist?
Wir sind jetzt auch bei der ganzen, wir haben natürlich jetzt über Cloud gesprochen, über Agilität gesprochen, so das Thema DevOps hast du zwar jetzt genannt, aber ich bin ja auch noch gar nicht so arg darauf eingegangen, weil Ich stelle fest, dass DevOps sehr oft auf Tools reduziert wird, auf Pipelines, auf Automatisierung und so weiter.
Das ist auch ein wichtiger Teil davon.
Aber was ist denn aus deiner Sicht der kulturelle oder organisatorische Kern von DevOps, der so wichtig ist?
Naja, ich denke, für mich tut er sich ganz klar ausprägen in diesem Satz, you build it, you run it.
Also es ist Verantwortlichkeit für beide Aspekte, etwas zu bauen und das zu betreiben.
Das ist ganz wesentlich.
Und dann die Nähe, das Entfernen von quasi Silos.
Was im idealsten Fall dazu führt, dass ein Team und die Personen, die da agieren, beständig diese Hüte mehrfach am Tag weg sind zwischen Entwicklungsaufgaben und Betriebsaufgaben.
Und das führt natürlich dazu, dass Koordinierungskosten reduziert werden, Friktionen reduziert werden.
Kommunikations, ich sag mal, die nötig wäre vielleicht, wenn das über mehrere Teams verteilt ist, reduziert wird.
Also das sind alles wesentliche Aspekte für mich in DevOps.
Und natürlich dieser Automatisierungsaspekt, den wir vorhin berührt haben, der durch Cloud möglich geworden ist.
Das heißt, die Reduzierung der Kosten, Dinge auszurollen und zu verändern.
und die Fähigkeit beständig, Informationen darüber zu bekommen, wie das ganze Setup funktioniert.
Also im Sinne von Observability, SLOs, SLIs, SLAs.
Und das funktioniert natürlich auch dann nur gut, wenn es da den Schulterschluss gibt, ich sage mal, mit Produkt, was klar artikuliert, was diese Rahmenbedingungen sind, die dann in so einem Setup entscheidend sind, die realisiert werden, im Sinne von SLAs zum Beispiel.
Ja, was jetzt viele Unternehmen gerade machen, jetzt ganz aktuell, ist sie, ich springe jetzt nochmal zur AI-Adoption, weil das ist die Welt, in der wir jetzt mittlerweile leben, die starten das ganze Thema über Code-Generierung.
So, du hast jetzt aber auch gesagt, jetzt auch wieder, Engpass verschiebt sich halt weiter Richtung Validierung.
Es ist ja auch, you build it, you ship it, you run it, das ist auch ein Teil eines Prinzips, wo Ja, wo zeigt sich denn dann dieses Bottleneck?
dass man quasi Outcome verwechselt mit Output.
Man kann unheimlich viel bauen, ohne dass man Wert schafft.
Das Entscheidende ist eigentlich das Verhältnis, wie viel von dem, was man baut, wie viel Wert schafft es für den Kunden.
Und damit ist das die neue Engstelle.
Das ist auch bestätigt durch eine ganze Reihe von Studien mittlerweile und ich sage mal Firmen, die quasi CI, CD Dienstleistungen anbieten, CircleCI zum Beispiel hat vor ein paar Monaten eine größere Studie veröffentlicht, wo sie quasi aus ihrem Kundenstamm und dem, was sie da an CI, CD Arbeit sehen, ganz klar artikuliert haben, Generierung ist nicht das Bottleneck, sondern ist die Validierung.
Und genauso.
guten Freund, der bei GitHub arbeitet, die haben das gleiche Problem.
Die sind überschwemmt worden mit Code und haben Probleme mit ihrer Stabilität viel mehr im letzten Jahr als vorher GitHub.
Und das betrifft insbesondere auch die GitHub-Actions-Anteile.
Und auch ich persönlich habe das jetzt immer wieder gesehen.
Ich bekenne mich ausschuldig.
Ich habe mit Sicherheit dazu beigetragen.
Genau.
Und das ist quasi ein deutliches Zeichen, ja.
Das Generieren von Code hat massiv zugenommen.
kreiert Skalierungsprobleme und führt zu Validierungsproblemen.
Und deswegen ist es auch für wesentlich, dass wir quasi im Zusammenspiel mit AI artikulieren können, wie die Validierung passiert.
Und das sind im einfachsten Fall, das sind es die Code Reviews.
Und jeder, der mit AI, ich sag mal, gearbeitet hat, kennt vielleicht die Situation, dass da, wo er an einem Tag ein PR kreiert hat, plötzlich 20 PRs kreiert.
PRs, die dann nicht mehr vielleicht nur 400 Codezeilen betreffen, sondern möglicherweise tausende Codezeilen über dutzende Files hinweg.
Und die kognitive Last, die sich daraus ergibt, die ist natürlich enorm.
Weil wenn man den Code selber nicht mehr erstellt hat und dann aber verstehen muss, was da passiert und es bewerten muss, dann ist das...
eine andere Nummer im Vergleich zu früher.
Ja, absolut.
Wie ist das denn jetzt?
Bevor wir jetzt gleich noch zu den Rapid-Fire-Fragen kommen, wir sind nämlich auch schon fast am Ende, beschäftigt mich jetzt noch die Frage, wir sind mit nachhaltiger Softwareentwicklung gestartet und jetzt sind wir in einer Welt, in der AI immer mehr Code produziert und du sagst es selber, Review, Testing, Integration, Deployment, das kann vielleicht gar nicht mithalten.
Was passiert denn dann mit...
einem Engineering-System und mit nachhaltiger Entwicklung, wenn wir uns jetzt in dieser Situation befinden.
Wie stelle ich das denn noch sicher?
Aus meiner Sicht ist es ganz wesentlich, dass wir, ganz wesentlich ist Engineering Excellence eine wesentliche Zutat, also quasi, dass wir im Sinne von Inner- und Outer-Loop, also Inner-Loop betrifft so Dinge, wie der Entwickler quasi mit der AI am Code arbeitet, dass wir da Qualitätsstandards artikulieren im Sinne von Linting.
Style Guides im Sinne von Qualitätsstandards, Code-Qualitätsstandards, wie zum Beispiel zyklomatische Komplexität, dass wir Tooling haben, was Sicherheit sicherstellt.
Das kann alles im Innerloop passieren und das kann aber auch im Outerloop, also in der CICD-Pipeline, selbst als zweites Sicherungsnetz passieren.
Und ich denke, das ist ganz wesentlich, wenn wir quasi...
wenig Reife haben in der Art und Weise, wie wir diesen Code produzieren, wie wir das System entwickeln, dann wird die durch AI nur verstärkt.
Und wenn wir aber umgedreht quasi ein hohes Maß an Engineering-Qualität haben in diesem Prozess, dann wird das durch die AI verstärkt.
Also es bewegt sich in beide Richtungen, dieser Verstärkungseffekt.
Sehr gut nachvollziehbar und das sehe ich tatsächlich auch.
Govinda, wir sind tatsächlich, die Zeit ist uns auch davongerannt.
Wir haben sogar noch eigentlich viel mehr Themen noch auf der Liste gehabt, wie wir es am Ende geschafft haben.
Aber die Rapid-Fire-Fragen, die lassen wir uns nicht entgehen.
Dafür müssen wir uns noch Zeit nehmen.
Was ist denn der größte Mythos über technische Schulden?
Dass es ein rein technisches Problem ist?
Aus meiner Sicht sind es oft Geschäftsentscheidungen.
Und der zweite Mythos damit ist, dass Schulden immer schlecht sind.
Bewusst eingegangene Schulden, geplante Schulden sind ein legitimes Werkzeug.
Gefährlich ist nur die leichtsinnige Variante, die man unsichtbar anhäuft und die man nicht dann wieder abträgt, bewusst.
Das unterstütze ich sehr, was du da sagst.
Und das trifft den Nagel auf den Kopf.
Die am meisten unterschätzte Fähigkeit eines CTOs?
Übersetzung.
Quasi Übersetzung zwischen Penthouse, C-Level, Board und dem Maschinenraum.
Und quasi in beide Richtungen.
Und dieser ständige Wechsel, also quasi mit all den Ebenen, die dazwischen sich befinden und den unterschiedlichen Abstraktionsebenen und Details.
Ich glaube, wenn du im richtigen Unternehmen bist, dann sitzen auch die Engineers im Penthouse.
Frag mal bei OpenAI nach.
Ein Architekturprinzip, das fast immer hilft.
Lose Kopplung und klare Grenzen.
Also saubere Bounded Contexts und Team-ARPs.
Ein bisschen verbunden mit dem Domain-Driven-Design-Aspekten, über die wir vorher gesprochen haben.
Sehr gut.
Und dann noch eine Faustregel, Bau für das Zehnfache, nicht für das Hundertfache.
You ain't gonna need it, wie wir auch vorhin hatten.
Richtig.
Das ist richtig.
Auch eine Frage, die mir sehr gefällt und ich bin auf deine Antwort sehr gespannt.
Cloud, DevOps und Agilität in einem Satz.
Drei Ermöglicher für ein und dieselbe Sache.
Schnelle Feedback-Loops mit echtem Ownership.
Schön gelöst.
Sehr gelöst.
Finde ich sehr gut.
Letzte Frage für heute, Govinda.
Die erste Frage, die ein CTO stellen sollte, bevor AI-Coding-Tools wirklich breit ausgerollt werden.
Würden unsere Tests, unser Review und unser Observability-Hahn es heute einen schlechten Change zuverlässig abfangen?
Wenn die Antwort Nein ist, dann ist das nicht die eigentliche Baustelle, nicht das Tool.
Ja, dann musst du eher wieder an den Review-Prozess ran und musst dann gucken, wie du den absicherst, oder?
Engineering Excellence und all die Prinzipien, die da drin realisiert sind, ja.
Sehr gut.
Govinda, wir haben heute eine schöne Reise, sind wir angetreten, von technischen Schulden über nachhaltige Softwareentwicklung.
DevOps mit drin gehabt und so weiter.
Wir haben auch über Agilität gesprochen und am Ende natürlich auch noch sind wir bei AI angelangt und haben dann nochmal den schönen Bogen geschlagen.
Vielen Dank für deine Insights.
Ich glaube, das hat auch nochmal das sehr gut geholfen einzuordnen und das ist durchaus noch genauso relevant im Jahr 2026.
Das darf man nicht vergessen, auch wenn da ganz viel Software da draußen gerade gebaut wird.
Wie blöde, dass es immer noch die Notwendigkeit gibt, einen nachhaltigen Softwareentwicklungsprozess zu haben.
Vielen Dank für deine Insights und Vielleicht kommst du dann nochmal zu mir in den Podcast und dann holen wir noch die anderen Fragen oder anderen Themengebiete.
Das sind so ganze Themengebiete, die wir ausgelassen haben.
Die holen wir danach.
Das wäre wunderbar.
Super.
Vielen Dank für das tolle Gespräch.
Danke, Gewinner.
Mach's gut.
Bis dann.
Ciao, ciao.
Ciao.