# Flix CIO on AI Strategy and Tech Leadership

**Podcast:** Becoming CTO Secrets
**Published:** 2026-07-14

## Transcript

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 der Gründer der Becoming CTO-Community.
Mein heutiger Gast ist Daniel Kraus.
Er ist der Co-Founder, CIO und CHRO von Flix.
Das ist die Dachorganisation von Marken wie Flixbus und FlixTrain.
Viele kennen es und ein spannendes Gegenbeispiel.
Zur Idee, dass ein CTO immer der beste Programmierer im Raum sein muss.
Wir sprechen heute über Organisation, wir sprechen über Architektur, über AI-Adoption und die wichtige Frage, warum KI viel mehr ist als nur ein Engineering-Thema.
Daniel, herzlich willkommen.
Philipp, schön, dass ich das sein darf.
Freut mich.
Grüß dich.
Freut mich umso mehr, Daniel.
Du bist offiziell, und jetzt zitiere ich mal LinkedIn, als Chief Organizational Plumber hast du dich da angekündigt.
Du bist offiziell Co-Founder, du bist der CIO der CHRO.
In meinem Podcast sprechen wir oft über die CTO-Rolle.
Wie würdest du denn deine Rolle selbst beschreiben?
Wo ist sie vielleicht größer oder sogar anders als die klassische CTO-Rolle oder das klassische CTO-Bild?
Weißt du, ich bin bei uns dreien schon immer der Techie gewesen und ganz, ganz früher war ich auch offiziell CTO.
Jetzt ist es so, dass wir über die Zeit ja uns immer weiter vergrößert haben, auch anorganisch, Thema M&A und in einer solchen Situation haben wir mal einen externen CTO dazubekommen, der eben nicht Teil des Gründerteams war und der musste zu dem Zeitpunkt schon sein C-Level abgeben.
weil eben nur Gründer damals das C getragen hatten und war aber ein geiler Typ, ein Top-CTO.
Und dann habe ich mir gedacht, weißt du was, wenn ich ihm jetzt seinen Titel abnehme und ihn quasi einfach formal zurücksetze, VP Engineering, das fand ich irgendwie eine kack Message.
Und dann habe ich mir gedacht, weißt du was, dann...
dann gibt es diesen CTO-Titel bei uns gar nicht mehr.
Und dann habe ich mir die T-Flügelchen gestutzt sozusagen und war von dem Zeitpunkt CIO, weil, wie gesagt, ich hätte das als unangemessen empfunden, jetzt zu sagen, weißt du, es gibt zwei CTOs und nur, weil ich zufällig das Privileg des Mitgründers hatte, bist du jetzt VP-Engineering und ich bin Kapo.
Dann haben wir das, glaube ich, salomonisch sehr gut gelöst und seitdem bin ich CIO.
Und über die Zeit habe ich dann die Verantwortung für die People-Funktion mit übernommen und im Zuge dessen habe ich mich immer mehr gefragt, was machst du eigentlich den ganzen Tag so?
Die Antwort ist, programmieren war es schon lange nicht mehr, was aus Sicht von Flix bestimmt etwas Gutes ist.
Und dann habe ich mir gedacht, eigentlich bin ich den ganzen Tag damit beschäftigt, Herausforderungen zu erkennen und abzubauen, dass unser Team so schnell wie möglich agieren kann.
Das sind ja hunderte brillante Leute und vor allem bin ich sehr stolz auf die FlixTech, weil mit der Hand oder mit der Flasche großgezogen.
Und da muss ich natürlich dafür Sorge tragen, dass die so schnell wie möglich laufen können.
Und da habe ich mir gedacht, eigentlich komme ich mir vor wie Luigi.
Und Luigi deswegen und nicht Mario, weil Luigi grün ist.
Offensichtlich ein großer Vorteil gegenüber Mario.
Und das Resultat war, dass ich der Chief-O-Marsch-Hallplammer bin.
Und André findet das immer ein bisschen albern.
Ich finde, es beschreibt am besten, was ich tagtäglich tue.
Aber das bedeutet, der VP Engineering reportet trotzdem an dich und du bist dann quasi, auch wenn du die Rolle nicht offiziell hast, dann der inoffizielle CTO weiterhin?
Ja, das kann man so sagen, wobei wir mittlerweile ja sehr viel größer sind.
Das heißt, es gibt die CTO-Rolle bei uns.
Das macht die Hanna Huber und wie du korrekt sagst, die ist einer meiner beiden Directs.
Der andere Direct ist, unsere CHRO quasi, unsere People-Chefin.
Und innerhalb der Tech-Organisation gibt es mittlerweile einige VP-Engineerings.
Und inoffiziell ist es schon noch so, dass die großen Themen, wenn wir darüber sprechen, wie bauen wir unsere Tech-Organisation, wie bauen wir die unserer Plattform zugrunde liegende Architektur.
Und welche großen Leitplanken schlagen wir ein, um sozusagen dann auch die fast schon alltäglichen technischen Entscheidungen richtig einzuordnen.
Da mische ich mich schon noch ein, aus Spaß, aber auch, weil ich denke, dass ich da noch mehr Wert bieten kann.
Sehr gut.
Ich habe tatsächlich ja im Vorfeld nochmal so ein paar kleine digitale Helferlein losgeschickt.
Manche sagen LLMs dazu, um nochmal zu dir zu recherchieren.
Und eine Sache ist mir aufgefallen, die verschweigen alle konsequent, dass du mal CTO von Flix warst.
Selbst auf Nachfrage, wo ich sage, das kann nicht sein, sind sie der Meinung, nein, es gibt keine Hinweise mehr darauf, dass du jemals diese Rolle hattest.
Da hatte mich mein Gedächtnis nämlich noch nicht im Stich gelassen, aber die LLMs mittlerweile haben diesen Teil deiner Geschichte anscheinend getilgt.
Das ist ja eine Frage, wie die nachgucken.
Und es gibt ja so Menschen, die dann die einzelnen Schritte und Veränderungen beispielsweise in LinkedIn-Kund tun.
Das habe ich ja nie.
Bei mir steht ja quasi ein Volkzeitraum drin und ich habe oben immer an dem Titel rumgeschraubt.
Das heißt, es gibt da keine Stufen, die sich verändert haben.
Das heißt, so wie LLMs funktionieren, Kann ich zumindest die Antwort nachvollziehen.
Ja, genau, wenn Sie nur da reingucken würden.
Aber normalerweise, es gibt ja mit Sicherheit auch andere Publikationen, wo du aus der damaligen Zeit dann noch als CTO geführt wirst.
Also ich war trotzdem einigermaßen überrascht, dass das dann nicht mehr auftritt.
Aber dann sind wir wieder bei dem Punkt, wir dürfen nicht allem trauen, was wir da vorgesetzt bekommen.
Bei Mitarbeitern übrigens auch nicht.
Aber reden wir mal über die CTO-Rolle selber.
Denn viele Entwickler haben...
ein sehr eindimensionales Bild vom CTO.
Ich weiß nicht, ob du das ebenfalls wahrgenommen hast aus deiner Zeit noch, so der beste Coder, Tiefstar, Techie oder auch die höchste Eskalationsinstanz.
Was ist an diesem Bild aus deiner Sicht falsch oder zumindest unvollständig?
Die Eskalationsinstanz ist schon was, was in der Art des Jobs liegt, weil das C kommt ja mit dem Chief und meinem Tag.
ist schon dadurch geprägt, dass Probleme, die nicht weiter gelöst werden können von der Organisation, dann auf meinem Tisch liegen und deswegen ist das okay.
Aber der beste Programmierer kann ich ja schon gar nicht sein, weil wenn du das C innehast, ob durch Karriere oder durch Gründung, dann musst du ja unter anderem meiner Meinung nach in der Zwischenzeit in der Lage gewesen sein, eine sehr gut funktionierende Organisation zu bauen, die wiederum aus Leuten besteht.
Und mein Ziel war von Anfang an immer Leute zu finden für die einzelnen Tätigkeiten und es gibt ja ganz viele Rollen, die signifikant besser sind als ich.
Das heißt, im klassischen Engineering musste ich ja, und da habe ich sogar mit unserem ersten damaligen Praktikanten, der mittlerweile Principal bei uns ist, schon angefangen, die Leute mussten besser sein als ich, weil sonst hast du irgendwann so eine Art Zwergenstaat und in der Konsequenz führt es dazu, dass ich jetzt mittlerweile eher wahrscheinlich einer der schlechtesten oder vielleicht sogar der schlechteste Coder bin, was ganz gut passt, weil Coding war nie das, was mir wirklich viel Spaß gemacht hat.
Und was das technische Wissen angeht, ist immer eine Frage des Kontextes.
In so einer Tech-Organisation haben wir Teams, die sich mit einem Produkt beschäftigen oder wir haben Bereiche, die sich mit einer Seite der Plattform beschäftigen.
Und da haben wir natürlich Spezialisten, die die Details mit Sicherheit besser kennen als ich.
Aber das Gesamtbild, wo geht die Reise hin, teilweise auch mit, man kann es als Informationen bezeichnen, aber wenn ich als Gründer mir überlege, wo wir die Firma gemeinsam hinführen, dann sind es ja keine fachlichen Informationen oder sachlichen Informationen, die ich vorenthalte, sondern einfach was, was bei Jochen andré mir im Kopf ist.
Das ist halt, das entsteht da.
Damit habe ich aber im Tagesgeschäft mit Informationsvorteilen.
Und diesen gesamtgalaktischen Informationsvorteil in technische Gedanken zu übersetzen, die dann am Schluss zu einer Architektur führen, aber vor allem auch zu einer Organisation, die das begünstigt.
Da gibt es ja das Convays Law, das die beiden Dinge zusammenbindet.
Das ist natürlich was, was du in dem C, also als CTO, schon können musst.
Aber genau da liegt auch der Hase im Pfeffer.
Wie du es gesagt hast, ein CTO muss den Kontext des Geschäfts und schlussendlich des Geschäfts auch wirklich gut verstehen, weil die wenigsten Geschäfte sind reine Tech-Plays.
Also wir verdienen uns ja Geld, indem wir Menschen, unsere Kundinnen und Kunden von A nach B transportieren.
Und wir machen es besser als alle anderen mithilfe von Tech.
Aber ich verdiene mit Tech nicht direkt Geld.
Und das ist in vielen Fällen eben so.
Und dann musst du als CTO vor allem auch diesen Kontext verstanden haben.
Richtig.
Und das ist natürlich jetzt die Haltung oder die Meinung, die du zum Lauf der Jahre entwickelt hast.
Du hast im Vorgespräch erzählt, dass du auch schon sehr früh und gerne an Rechnern gebastelt hast, aber das Programmieren selbst, und du hast es jetzt eben auch nochmal gesagt, hat dir ja nie so den meisten Spaß gemacht.
Trotzdem hat sich daraus ein Weg in die Tech-Rolle ergeben.
Wie kommt es dann dazu?
Und hast du dann auch am Anfang bei Flix selbst mitprogrammiert oder warst du von Anfang an eher in der Business-Tech-Funktion unterwegs?
Ganz am Anfang habe ich das, aber vor allem infrastrukturnah.
Das war das und da kommt vielleicht, vielleicht schließt da der Bogen zu ganz früher, wo wir einen Rechner rumgeschraubt haben, wo ich irgendwie selbst mit dem Lötkolben an Grafikkarten unterwegs war, was bisweilen erfolgreich war.
wo es blinkt und so, das hat mich immer gereizt.
Das heißt, diese DevOps-Rolle war was, da habe ich mich noch am ehesten gesehen, auch nicht immer super erfolgreich.
Jetzt muss ich schmunzeln, da kommen Gedanken hoch.
Wir hatten mal so eine 1-Euro-Aktion und da mussten wir, weil wir natürlich Traffic erwartet hatten und damals war das alles noch irgendwie beim Hetzen und da musste sich da an der Apache-Konfiguration was ändern.
Naja, schlussendlich hat mich meine Frau abgeholt und wir haben den Freitagnachmittag nicht irgendwie am Tegernsee verbracht, sondern im Büro, weil die Konfig nicht so von Erfolg gekrönt war.
Also solche Sachen, da war ich schon noch tief mit drin.
Und so Kleinigkeiten, aber die großen Dinge, da habe ich frühzeitig entweder...
Leute, die ich schon kannte, die ich vertraut habe, mit reingeholt oder auch mit externen, was nicht immer erfolgreich war, zusammengearbeitet, weil ich das während des Studiums, weißt du, wenn du Programmieren ist ja wie eine Sprache lernen und ich hatte immer eine Herausforderung, einen sehr guten Weg zu finden, der Maschine meine Gedanken zu übersetzen.
Aber ich habe auch dieselbe Herausforderung, meine Gedanken auf Papier zu bringen.
Mittlerweile geht das, du lernst das alles.
Aber ich würde jetzt kein Poet werden.
Und deswegen hat mich das relativ schnell gelangweilt, weil ich halt nicht, weißt du, wenn du so, das ist jetzt geil mit Cloud Code und den LLMs, weil dann fällt einem das viel einfacher.
Aber früher war ich so selbstlimitiert.
Und das stresst dann und dann hast du dich halt auf andere Dinge konzentriert.
Und wenn du alles nur mit If-Schleifen löst, dann weißt du auch irgendwann, dass du nicht der beste Programmierer auf dem Planeten bist.
Auf der anderen Seite hat mich schon immer das Zusammenspiel von Menschen und Organisationen gereizt, ob das in der Jugend war als Sportcoach oder als Zeltlagerbetreuer.
Das fand ich schon immer toll, Menschen so zu motivieren und zu animieren, dass sie gemeinsam mit einem größeren Ziel arbeiten.
Und dann hatte ich das Privileg, beides quasi zusammenzubinden und bin quasi mit ausreichend wenig hartem Programmieren.
Und wie viel technische Tiefe braucht man denn am Ende des Tages dann noch wirklich, um eine Tech-Organisation wie bei euch zu führen?
Wo ist denn fundiertes technisches Verständnis unverzichtbar?
Gibt es den noch oder sagst du, es ist alles nur Organisation und Business?
rausziehen kannst.
Das ist schon wichtig aus zweierlei Gründen.
A, um Entscheidungen hinterfragen zu können, sinnvoll und nicht immer nur mit warum, wie meine vierjährige Tochter.
Und B, um auch so ein bisschen eine Kredit...
zu haben, weil ich habe ja gesagt, du musst schon dafür Sorge tragen, eine Organisation zu bauen, die dann schlussendlich dir auch folgt und sagt, okay, wir machen das so, weil das sinnig klingt und nicht nur, weil das der Kapo ist oder aus Prinzip oder sowas.
Und dann brauchst du schon ein bisschen auch Street Credit.
Gerade wenn du im Eifer des Tagesgeschäfts oder gegenüber dem Board, dem Aufsichtsrat, manchmal abkürzt, dann ist es ganz witzig bei uns, weil da wäre ich gleich zu Ressort gerufen.
Ich habe neulich was über APIs kundgetan, weil ich eigentlich nur beschreiben wollte, wie unsere zukünftige sehr offene Architektur aussieht.
Und dann gab es gleich Feedback, weil sie ist ja, das ist aber nicht richtig.
weil wir haben vor einigen Jahren auf eine eventbasierte Architektur umgestellt mit Kafka.
Also technisch gesehen sind das ja Events und da sage ich, ja, okay, ich weiß.
Und dann ist es ganz gut, dass du A, in dem Fall Feedback bekommst und B, aber auch zur Ressent gerufen wirst und das aber auch alles verstehst, weil die Leute, die sehr eng mit mir arbeiten, die haben sofort verstanden, was ich wollte, auch wenn ich es innerlich falsch kundgetan habe.
Aber es gibt halt hunderte andere Menschen, die dann sagen, oh nee, dann ist jetzt halt vielleicht die Zeit von Events und Kafka vorbei.
Wenn der Alte sagt, wir machen das wieder irgendwie more on the API-Level, dann schrauben wir jetzt halt wieder so rum an den Dingen.
Und deswegen ist es schon, glaube ich, unabdingbar, so ein bisschen zumindest zu wissen, worüber man spricht, gerade was sozusagen die Grundlagen angeht.
Und insbesondere, und das ist das Gleiche, was du gerade gesagt hast, wird es auch jetzt wichtiger im Umgang mit den LLMs, um die zu callen, würde man beim Poker sagen, wenn sie halluzinieren, oder auch da wieder die Ergebnisse einordnen zu können.
Und deswegen sollte man auch meiner Meinung nach, egal wie wenig ich jetzt, wenn ich einmal alle Jubiläare bei uns im Git unterwegs bin, ist das viel.
Aber dennoch...
muss man sich natürlich damit beschäftigen, wie sich Technologien weiterentwickeln, damit du in der Diskussion beispielsweise, welches Modell wir jetzt wie einsetzen, damit du da zumindest sinnvolle Fragen stellen kannst.
Das musst du, glaube ich, gewährleisten.
Und im technischen Kontext sind es halt häufig auch technisch sinnvolle Fragen.
Auf der anderen Seite ist gerade in dem LLM-Kontext, es sind ja nicht nur technische Fragen, die das nach sich zieht, sondern durchaus auch.
Fragen nach Kosten, nach Guardrails, nach Data, Privacy und so weiter.
Also auch Fragen, die natürlich dann auf einen größeren Business Impact haben können.
Und gut zu wissen und zu hören, dass du trotzdem den Anspruch hast, in diesen Meetings nicht nur dabei zu sein, sondern auch die richtigen Fragen zu stellen und dich nicht bullshitten zu lassen.
Ich glaube, das ist auch in dem Kontext mit anderen CTOs, mit denen ich spreche, eine Eigenschaft, die selbst wenn man...
irgendwann sagt, ich habe nicht mehr den Anspruch, alles in der technischen Tiefe verstehen zu wollen, zu müssen, aber auf einem höheren Level da schon und da will ich auch noch mit in the loop sein.
Und so höre ich das bei dir eigentlich auch raus, dass du das immer noch so praktizierst.
Hast du irgendwie ein Beispiel für eine schlechte Entscheidung aus deiner CTO- oder CIO-Reise, die dich geprägt hat?
Ich meine, du hast eben das Beispiel gebracht, dass hier irgendwas...
eine 1-Euro-Aktion hattet und du saßt dann da und konntest dann dein Wochenende erst mal streichen.
Das sind alles kleine Entscheidungen.
Also wenn du mal irgendwie irgendwas halbfertig committed hast und Augen zugedrückt hast oder wenn du einfach selber noch in der Config so halbwissend irgendwas reingeschrubbelt hast, weil du gedacht hast, er wird schon halten, hebt schon.
Das sind aber alles nicht die Dinge, die In der hindsight, also wir hatten an der einen oder anderen Stelle uns auf Externe verlassen, verlassen müssen, auch in Bereichen, die für uns kriegsentscheidend sind.
Und zwar ist es natürlich in unserem Fall alles, was die Kernplattform angeht, was das Pricing angeht, was den Vertrieb angeht, die Art und Weise, wie wir unsere Routen planen.
Das sind Dinge, die schlussendlich kind of the secret source sind.
Und da dich von Dritten abhängig zu machen, halte ich für schwierig.
Und die Ursache, warum wir das damals gemacht haben und machen mussten, liegt auch daran, dass ich am Anfang bei Entscheidungen zu lange gehadert habe, ein bisschen links rum probiert, ein bisschen rechts rum probiert, vielleicht auch bei einigen Designfragen zu groß angefangen habe, also direkt irgendwie versucht habe, eine Wunscharchitektur aufzumalen.
Aber dann dauert es halt ewig.
Und am Schluss die Zeit davon gelaufen, dann musstest du liefern und dann hast du halt, ne?
So.
Das heißt, du hast dann das Ganze an Extern geben müssen, aus Zeitgründen und hast dann Dinge an Nearshoring, Offshoring abgegeben und die haben dann nicht geliefert?
Ja, genau.
Ja, okay.
Also, was heißt nicht geliefert?
Das ist ja witzig, weil wenn du dir das mal auf der Zunge zergehen lässt, habe ich am Anfang nicht sauber das MVP definiert, es war alles viel zu groß und so.
Und das hat dazu geführt, dass ich dann kurz vor knapp war und konnte es selbst nicht mehr liefern.
Ist ja auch naiv zu denken, dann kann ein Externer liefern.
Ich meine, how dare?
Ja, du hast da mehr Capacity, aber du musst die auch briefen, du musst auch ein sauberes MVP definieren, weil das ist ja immer quasi immer ein Dreieck.
Und dann hast du noch die Abhängigkeit dazu und die anderen bauen das nur auf, das in deinem Kernbereich eigentlich du und deine Mannschaft ausbauen sollten.
Also da hatte ich dann zwei, drei Situationen, wo wir uns quasi wieder befreien mussten.
wo ich mir gedacht habe, da hast du dich ja vorher auch einfach selber in den Knast gesperrt.
Das hättest du auch anders lösen können.
Und ich glaube, die Ursache war, wie gesagt, immer nicht genug Entscheidungsfreudigkeit und so diesen Hang zum Perfektionismus, was Techies ja auch häufig haben.
Ich will es halt wirklich geil bauen, aber am Schluss ist das nicht ausschlaggebend, sondern läuft es und macht es, was es soll.
In unserem Fall halt ganz am Anfang Tickets verkaufen.
Ja, super simpel.
Und nicht ist es schon das schönste Stück Software, das die Welt je gesehen hat.
Interessiert nämlich keinen.
Du hast auch gesagt, größere Tech-Rollen bestehen aus ganz viel Organisationsaufbau, vielleicht sogar vor fünf Jahren noch mehr wie jetzt aktuell.
Was bedeutet das denn für euch in so einer großen Tech-Organisation, wie ihr das seid?
Vielleicht auch gerade vom Hinblick, wie es 2020, 2021 war und was sich da bis jetzt halt hin verändert hat.
Du denkst ja mit Sicherheit anders über das Thema Organisationsaufbau nach wie noch so zur Corona-Zeit oder davor.
Ja, also A, es ist so, es ist nie viel, hilft viel.
Und B, hat man gleich die Tendenz dann eher übers Ziel hinaus zu schießen.
Und die Frage ist ja immer, wenn du jetzt auf deine Organisation guckst, wo entstehen...
Bottlenecks, also wo klemmt es?
Und das ist häufig in einer Situation der Organisation, weil unterschiedliche Größen, unterschiedlicher Schnitt ist immer sehr ähnlich, wo die Bottlenecks stehen.
Und das wirklich zu hinterfragen und aufzulösen ist, glaube ich, eine wiederkehrende Kunst.
Aber natürlich verändert sich global eine Organisation.
Also als wir angefangen haben, das war ganz...
Ich meine, damals war noch Client Server, da haben wir uns gerade von Hetzen in Richtung Cloud beschäftigt.
Also eine andere Welt.
Und da gab es, weiß ich noch, da gab es dann ein Backend-Team und da gab es ein Frontend-Team, da gab es ein Mobile-Team und da gab es ein Infra-Team.
Und dann haben wir das halt so aufgebaut.
Und irgendwann haben die halt alle aufeinander gewartet, weil ja keiner eine Ende-zu-Ende-Verantwortung hatte.
Und weil auch keiner in dem Setup irgendwie irgendein Produkt, ein Feature, irgendein Kundenthema vor Augen hatte.
Das ist ja Head of Backend.
Allein der Name, das interessiert ja niemanden.
So, und dann haben wir das erste Mal umgebaut und haben gesagt, okay, wie ist denn unsere Firma aufgebaut?
Welche Domänen hat denn unsere Firma?
Und haben dann so Domänen-Cluster gebaut.
Und das hat auch große Umbauten nach sich gezogen, weil natürlich, wenn jemand nur fürs Backend verantwortlich ist, dann sieht der Code, die Person baut, anders aus, als wenn er für ein ganzes Feature-Produkt verantwortlich ist.
Das heißt, da haben wir relativ viel umgebaut, was dann...
auch uns befähigt hat von einer monolithischen Struktur, die völlig in Ordnung ist, kommt auf den Use Case drauf an, aber in unserem Fall dann etwas verteilter uns aufzustellen, weil wir sonst nicht mehr in dem Maße hätten skalieren können.
Und dann hatten wir zwar diese Domänen, aber dann ist mir aufgefallen, so wie unser Gesamtgeschäft strukturiert war, war es schon gar nicht mehr optimal.
Das heißt, ich habe was in die Tech kopiert.
was schon suboptimal war.
Und dann ist mir aufgefallen, eigentlich ist meine Aufgabe mit meinen Business-Kollegen, mit meinen Mitgründern und Ziel-Level-Kollegen zusammen zu gucken, okay, was ist eigentlich unser Operating-Model?
Wie sieht denn das Gesamtmodell aus?
Weil sonst hängt die Tech ja immer suboptimal hinterher.
Und dann irgendwann haben wir tatsächlich, ich meine, für uns ist es relativ simpel, man kann sagen, es ist ein zweiseitiger Marktplatz.
Das heißt, ich habe jetzt einen Großbereich, im Demand-Kontext, also B2C, und dann ein Großbereich im Supply-Kontext, also B2B, die ganzen Partner und so weiter und so fort.
Und was über die Zeit jetzt viel wichtiger geworden ist, ist dieser Foundation-Bereich, der eigentlich, da ist natürlich auch DevOps drin und dieser ganze Klatterer-Datsch, aber auch ganz viel Enablement, was jetzt, wie gesagt, noch wichtiger wird, weil mit diesem AI-Hype werden ja auch immer mehr Menschen befähigt, irgendwie Dinge zu erzeugen, Code zu erstellen, die jetzt nicht perfekt über Architektur und Datenbankdesign nachdenken, sondern einfach mal was Vibe-Coden.
Und die musst du natürlich einhegen und gleichzeitig befähigen, dass da keine Scheiße bei rauskommt.
Wie erkennst du denn jetzt aktuell, dass das eine Teamstruktur gut ist oder schlecht ist?
Oder wie stellst du sicher, dass die Architekturentscheidungen am Ende des Tages nicht losgelöst vom Geschäftsmodell getroffen werden?
Also die Architekturentscheidungen, die treffen wir...
gemeinsam, da gibt es ein Architecture Board bei uns, da sitzen die ganzen Silberrücken und die geben so grundlegende Guidelines.
Das ist wichtig, weil du durch diese Abstimmung auch eine gewisse Flughöhe erzeugst, wo dann, ich will nicht sagen alle, aber ein Großteil der alltäglichen Voraussetzungen gemeinsam diskutiert werden, damit du keine Mikroentscheidungen triffst, die dann immer nur ein Suboptimum erzeugen.
Und ob Teams gut funktionieren, Das sehe ich witzigerweise auch mittlerweile.
Also ja, hast du die klassischen Metrigen, zum Beispiel Dora oder wie viele Bugs hauen die raus und wie lange brauchen sie um diese fixen etc.
pp.
Aber auch da ist mein Blick über die Zeit viel stärker in Richtung Business gewandert.
Wenn ein Team gut ist, dann erzeugt es echten Value.
Das heißt, mehr Umsatz, mehr Kundennutzen oder weniger Kosten.
Du merkst es, wenn da Leute intrinsisches Interesse dran haben.
Wenn selbst der Product Owner E, dass der die P&L kennt, wo auf der P&L zahlen denn seine Produkte ein?
Und auch Entwickler, die hinterfragen, was kostet es eigentlich und was bringt es, wie ist das Verhältnis zu dem?
Wenn da dieses kontextuelle Wissen vom A, Geschäft, aber B, wie sind die Zahlen?
Wenn das Eingang findet in dein Team, ein echtes Entwicklungs- und Tech-Team.
dann weiß ich, ah, das geht in die richtige Richtung.
Lässt sich das bei einem Tech-Team, das für eine Plattform zuständig ist, immer so eindeutig beantworten, was für einen Value sie liefern?
Also vielleicht ja, wenn sie ein neues Feature deployen, dann ja, aber wenn sie zum Beispiel jetzt Abkürzungen nehmen, um bestimmte Sachen schneller zu liefern, die Zahlung dafür, dass der Umsatz vielleicht später weniger schnell wächst oder langsam wächst oder sogar runter geht, der kommt ja vielleicht erst in einem halben Jahr oder einem Jahr.
Ja, also wir haben, Zum einen ist es eine Frage, wie sie Kunden definieren.
Der Kunde kann auch ein anderes Team sein.
Und dann ist die Frage, mache ich das Team irgendwie schneller?
Durchlaufzeitverwässerung.
Ein klassisches Beispiel, das wir immer hatten und da fängt es mit Transparenz an.
Wir hatten ein Foundation-Team, das war, als wir noch auf PHP waren, das war für Symfony verantwortlich.
Und da waren wir auf irgendeiner Symfony-Version von anno dazu mal, nicht mehr supported, alles irgendwie wahrscheinlich heutzutage mit Mythos löchrig ohne Ende.
Und dann hieß es, wir müssen jetzt hoch.
Und natürlich teuer, Aufwand.
So.
Und es stand aber nirgendwo.
Es war auf keiner Roadmap, es war nirgendwo, weil es war so ein Tech-Thema, Tech-Foundation-Debt-Thema, whatever.
Und dann habe ich gesagt, nee, ich will, dass das transparent gemacht wird.
Ich will den Aufwand lernen und ich will wissen, was ihr denkt, was der Nutzen ist.
Und da kann der Nutzen sein...
Welche Frage?
hast du dann dem Team gestellt, bevor du eine große technische Entscheidung triffst?
Hast du dann immer direkt gefragt, was ist denn der Value davon?
Oder welche Frage hast du gestellt?
Warum machen wir das?
Und dann hast du natürlich Totschlag-Argumente, wie es wird nicht mehr supported, es ist irgendwie buggy, aber dann sage ich, okay, aber ist es denn auch schneller?
Kriege ich da irgendwas dafür?
Ist es irgendwie im Betrieb günstiger, weil es, weiß ich nicht, weniger Compute braucht?
Whatsoever.
Also du musst die Fragen dann schon so stellen, dass du das verbindest, den technischen Nutzen mit, weil du musst den Leuten ja deine Gedanken mitgeben.
Das heißt, ich hatte vorhin, also die Definition von, das weiß doch jeder und so Common Sense immer so, das ist nur dann Common Sense, wenn du vorher erklärt hast, was Common Sense ist.
Das hat nicht jeder denselben Common Sense.
Und dann musst du da eben die Schnüre zusammenbinden und da lasse ich dann, Zu Beginn zumindest nicht einfach jedes Totschlagargument, Security ist immer so ein Totschlagargument geltend, sondern musst du dann halt drei, vier Fragen stellen.
Und dann merkst du schon, dass bei guten Teams quasi, wie meine Oma sagen würde, der Groschen fällt, dass sie dann anfangen, etwas Holistisches drüber nachzudenken.
Weil am Schluss auch die Diskussion zu TechDebt, das ist ja, wir müssen alle Steuern zahlen, das ist so.
Aber man muss sich dessen halt bewusst sein und kann es nicht einfach nur so nonchalant hinnehmen.
Das ist mir zu kurz gesprungen.
Ja, jetzt ist Flix nach außen betrachtet und du hast es auch gesagt, ein Mobilitätsunternehmen.
Intern aber eigentlich eine massive Travel-Tech-Plattform.
Was ist denn der technische Kern von dem, was ihr baut oder was ihr bereitstellt, der für viele von außen gar nicht sichtbar ist oder der massiv unterschätzt wird?
Also der technische Kern hat meiner Meinung nach mindestens drei Teile.
Man kann wahrscheinlich noch einen vierten dazu nehmen.
Der offensichtliche Teil ist mehr oder weniger klassisches E-Commerce.
Wir verkaufen Tickets.
Der zweite Teil, der eigentlich ein Nukleus ist, ist unser Inventar.
Das ist wie bei einem Onlineshop.
Wenn du möglichst viel von dem Zeug, was du haben möchtest, bei einem Onlineshop findest, dann ist der normalerweise relativ weit oben in der Auswahl, wenn du überlegst, was kaufe ich, wo du hinzuerfst.
Das heißt, für uns ist es die Ansammlung und die Kombination von allen Zielen, die wir anbieten, die dann in einem Fahrplan resultieren.
Wie macht man das möglichst clever, dass du eine hohe Taktung hast, dass du es kosteneffizient machst?
Wie baust du schlussendlich unser Inventar, unseren Fahrplan bestmöglich?
Und das ist an sich schon sehr kompliziert, auch in der Optimierung.
Aber es macht es natürlich nochmal komplizierter, wenn deine Partnerunternehmen lokal präsent sind.
Ich kann die ja nicht beliebig rumschieben, weil die haben ja sozusagen eine gewisse lokale Gravitation.
Das Zweite ist, wir sind immer im Wettbewerb.
Mit der Bahn, mit dem Auto, manchmal mit dem Flieger.
Das heißt, du musst immer einen optimalen Preispunkt setzen.
Was sind Menschen gewillt zu bezahlen für Mobilität?
Und bei uns natürlich für den Flixbus oder für den Flixcrant.
Und das herauszufinden, die Daten zu erheben, zu verarbeiten und möglichst schnell so zu entscheiden, ganz klassisches Pricing, Revenue Management, das ist der dritte Teil der Elementals.
Das ist auch der Teil, wo wir schon weit vor dem aktuellen Transformer-Hype mit künstlicher Intelligenz im technischen Kontext, klassisches Machine Learning, angefangen haben zu arbeiten.
Und dann ist der Teil, den ich gerade so ein bisschen stiefmünderlich mit Unrecht behandle, Der Operational-Time, weil du darfst nicht vergessen, dass wir eine Flotte von mehreren tausend Fahrzeugen haben, die 24 Stunden über der ganzen Welt verstreut unterwegs sind.
Chile, Indien, hier.
Und ich will ja immer als erster wissen, falls mal was nicht optimal funktioniert.
Das heißt, diese betriebliche Überwachung, Flottenmanagement, Traffic Control und so weiter und so fort, das ist quasi der letzte Teil.
den ich jetzt, wie gesagt, mit Unrecht etwas stiefmütterlich behandle.
Was war denn so gerade in den frühen Flix-Jahren, so die technischen oder organisatorischen Betten, die sich im Nachhinein als die richtigen Milestones herausgestellt haben?
Als wir unseren ersten großen M&A gemacht haben, Flixbus und mein Fernbus zusammengeschraubt haben, habe ich mir beides Systeme angeguckt und mir erschien das mein Fernbus-System superior, also besser.
Und obwohl es offensichtlich nicht mein System war zu dem Zeitpunkt, habe ich mich dafür entschieden, das ehemalige Flix-System abzuschalten, der Mannschaft zu erklären, wir bauen jetzt an was anderem.
Wie viele Gegner hast du da bekommen intern?
Es war eine positive Überraschung, gepaart mit direkt einem neuen Auftrag sozusagen.
Das heißt gar nicht so viel, ehrlicherweise.
Mit der Entscheidung haben wir dann auch angefangen.
Das erste Mal neben PHP Java als große zweite Sprache einzuführen, die sich jetzt eigentlich auch breit gemacht hat.
Und das war ganz gut, dass wir damals schon so einen langen Nukleus hatten, weil es einfach irgendwann im Enterprise-Bereich, das gerät PHP so ein bisschen an seine Grenzen.
Und da war ich ganz froh, dass wir direkt Java genommen hatten und nicht irgendwie dann damals fast super schick auf Ruby zu gehen.
Aber puh, Gott bewahre, das hätte mich jetzt wahrscheinlich viele Nerven gekostet.
Wir haben in dem Zeitraum aber auch echt falsche Entscheidungen getroffen.
Wir sind damals auf Angular gegangen, weil wir es hipper fanden als React in the early days.
Wenn du dich erinnerst.
Den Fehler haben aber viele gemacht.
Ja, genau.
Das war alles mies.
Wo gehubbelt wird, fallen auch Späne.
Als ich vorhin gesagt habe, als wir die Organisation umgebaut haben und die Plattform unter Druck geraten ist.
Wir haben dann das Decoupling mit so Self-Contained Systems gemacht.
das ist immer nur so eine 80-Prozent-Lösung, weil du nicht eigentlich auf allen Schichten sofort trennst und so.
An der Datenbank hängt da noch Dinges zusammen und so.
Das war aber good enough vom Aufwand her.
Und dann hat sich witzigerweise, manchmal musst du auch Glück haben.
Wir hatten damals einen sehr seniorigen DevOps-Kollegen, geiler Typ, den Steffen, der hat mit Kubernetes angefangen rumzufuhrwerken.
Und dann waren wir da relativ früh dran und das war eine gute Entscheidung.
Also die Containerization und dann auch ein bisschen die Abstraktion zu den Hyperscaler.
Und dann hatten wir einen anderen Kollegen, der auch witzigerweise fast schon eher aus einer spielerischen Natur, wir hatten Rabbit eine ganze Zeit lang und dann hat er sich mit Kafka beschäftigt und wir hatten echt am Anfang auch sunk Kost, weil da war noch viel PHP und das hat alles echt...
knarzt, aber jetzt im Nachhinein war Kafka frühzeitig auch eine gute Entscheidung.
Und dass wir halt dann wirklich sehr früh in die Cloud, in unseren Block of AWX gewechselt sind, das war auch, glaube ich, eine gute Entscheidung, weil uns sonst der Hetzner, ja, geiles Unternehmen, Franke offensichtlich, aber das wäre uns um die Ohren geflogen.
Also wir haben da schon rückwirkend ein paar gute Entscheidungen getroffen und das ist so, glaube ich, ein grobes Sammelsurium von denen, die wichtig waren, wo ich lang gehadert habe und wir viel Lehrgeld auch noch bezahlen, war so ein bisschen die Frage Native oder Hybrid im Mobile-Kontext.
Wie habt ihr das beantwortet?
Ich weiß es ehrlich gesagt gar nicht.
Seid ihr Native unterwegs?
Ja, ich würde sagen, wir sind noch zu großen Teilen native unterwegs.
Das hat sich ein bisschen mit React jetzt geändert, aber wir haben bisher zum Beispiel noch nicht irgendwie groß auf Flutter gesetzt oder so.
Bei sowas, das ist eine interessante, da habe ich ein Gefühl, was mich stört.
Ich will nicht sagen, ich habe kein gutes Gefühl oder so, aber ich habe kein Gefühl, was mich stört.
Da bin ich zum Beispiel mittlerweile technisch so weit weg, dass ich dann immer glaube, was zu wissen oder ich lese irgendwas und so, aber gleichzeitig darfst du natürlich den Leuten auch nicht auf den Sack gehen mit qualifizierten oder gefährlichem Halbwissen.
Also Mobile, glaube ich, müsste bei uns schon noch mehr gehen, aber Glauben heißt bekanntlicherweise nicht wissen.
Ja, was sind denn bei euch?
Ihr habt viel mit Internationalisierung gearbeitet, ihr habt Akquisitionen gemacht und damit gearbeitet.
Was ist denn?
so im Thema Kulturintegration nach so einem M&A besonders schwierig, vielleicht gerade auch in eurem Umfeld?
Das kommt darauf an.
Also jetzt auf meinen Fernbus von damals Bezug zu nehmen, ich habe entschieden, dass ich seit dem Zeitpunkt wirklich regelmäßig eigentlich wochenseitig, mittlerweile alle zwei Wochen in Berlin bin.
Das war wichtig, um die Kulturen von Flix und meinen Fernbus.
zusammenzubinden, best of both worlds und aber auch beide gemeinsame Legacy zu bewahren.
Das Kulturelle ist immer relevant, jetzt in dem Fall von Greyhound, deswegen, weil das natürlich 100 Jahre sind und im Texas eine andere Arbeitskultur herrscht, da muss man auch persönlich ran und da geht es dann gar nicht um Tech oder nicht Tech, sondern da geht es einfach darum, Dinge zu finden, die einen verbinden.
Und vor allem nicht irgendwie hochnäsig oder überheblich ranzugehen.
Technisch ist es aber so, dass wir seit der Mein-Fernbus-Geschichte eigentlich sagen, wir integrieren nichts, sondern wir schalten ab und kopieren die Reservierungen und die Kundendaten.
Und wenn wir sehen, dass irgendwo jetzt bei Greyhound Features Anlagen, die wichtig sind, dann programmieren wir die nach in unserem Ökosystem.
Aber wir schrauben keine Sachen zusammen.
Das funktioniert nicht, meiner Erfahrung nach.
Aber man muss eben auch immer bereit sein zu lernen.
Also während Covid haben wir Kamelkoz in der Türkei übernommen und waren da nicht genug on the ground.
Einfach damals, wir erinnern uns alle.
Und da sind wir live gegangen und ich hatte ein gutes Gefühl, aber wir hatten nicht verstanden, wie unterschiedlich gerade das Partnermodell der Türken ist.
Und da gab es schon ordentlich Feedback und wir mussten über Weihnachten nacharbeiten.
Und jetzt auch in Indien.
Da erhöhen wir gerade unseren lokalen Tech-Footprint auch.
Warum?
Weil ich glaube, dass wir mehr Local for Local machen müssen, weil die Inneren und Inder als unsere Kundinnen und Kunden einfach auch anderes gewöhnt sind.
Also wie da Tech funktioniert, wie sozusagen wie Transportation da unten funktioniert.
Und da muss man dann schon auch einfach zugestehen, dass entweder man sich sehr viel mehr mit dem indischen Markt beschäftigt und dann zeitweise Zeit in Indien verbringt oder dass man sagt, okay, ich habe eh immer ein Kapazitätsthema und brauche mehr Ressourcen und dann habe ich jetzt halt ein paar indische Ressourcen, weil die eben auch dann den Markt da besser verstehen.
Wenn du jetzt an Flick-Tags heute denkst, was davon...
Also siehst du da noch wirklich Startup-DNA im Unternehmen?
Oder bist du, ich meine, das ist ja was, was viele Founder, gerade wenn ihr Unternehmen größer wird, dann immer mit einem weinenden Auge hinterher trauern.
So die eigentliche Startup-DNA, der Drive, das Agile.
Und je größer das Unternehmen wird, umso professioneller wird es dann vielleicht auch, aber auch behäbiger.
Wie viel Startup-DNA ist denn in Flix aus deiner Sicht heute noch drin?
Also das mit der Größe und dem, wenn man nichts tut, behäbiger werden, das ist so.
Punkt.
Die Tränen lasse ich nicht gelten, weil gerade die Gründerinnen und Gründer, die dann auch noch in Zielevel kompetent sind, wer soll es denn ändern?
Vom Weinen hat sich noch nichts geändert, da kannst du viel Tränen verdrücken.
Das heißt, man muss schon so offen sein und muss das anerkennen, dass das ein Fakt ist und muss es dann aktiv angehen.
Und ich versuche schon noch, diese Startup-DMA im Sinne von Menschen sind bereit, Risiken einzugehen.
Entscheidungen treffen und nicht immer tausend Menschen in den CC nehmen und alles nach oben delegieren, vor allem Entscheidungen, sondern sie nehmen die Accountability, das ist schon was, was uns einfach sehr wichtig ist und deswegen versuchen wir dadurch die DNA zu erhalten.
Und wir hatten gerade vor, naja, ist jetzt auch schon wieder ein Jahr her, aber da gab es so Dinge, da sind Entscheidungen passiert und die sind mir aufgestoßen und dann klickst du da drauf und dann kommt irgendwann so, ja, das hat das C-Level so entschieden.
Nicht nur, dass ich mir gedacht habe, oh, das wüsstest du aber, weil du bist Teil des C-Levels, sondern auch, was bitte ist dann das C-Level oder der Vorstand?
Wie abstrakt ist das denn?
Also irgendjemand muss schlussendlich für eine Entscheidung die Accountability ertragen.
Und wenn es eine gemeinsame Entscheidung ist, dann erwarte ich, dass jeder die Accountability trägt.
Dann kannst du auch einen Namen hinschreiben.
Wenn es Disagree und Commit war, dann ist es schlussendlich der CEO, also André, der die Accountability trägt.
Das ist auch okay.
Aber irgendwie ein abstraktes Etwas, die Bundesregierung hat gesagt, welches Ressort hat es denn entschieden?
Also irgendjemand muss ja dafür die Verantwortlichkeit nehmen.
Und das mag jetzt vielleicht in der Politik etwas schwieriger sein in so einer Koalition.
In einem Unternehmen, insbesondere in einem gründergeführten Unternehmen, ist es sehr einfach.
Es muss man einfach wollen.
Ja, auf jeden Fall.
Was war denn für euch jetzt am wichtigsten für den Erfolg rückblickend betrachtet?
War es sowas wie das frühe M&A, den ihr gemacht habt?
War es Technologie?
Wart ihr einfach zur richtigen Zeit am richtigen Ort?
Ist es das Geschäftsmodell gewesen oder lässt sich das gar nicht so wirklich trennen?
Ich glaube schon.
Ich glaube, dass die Serendipity, also Timing, richtige Zeit, richtige Ort, natürlich auch ausschlaggebend waren.
Aber dann die Execution, der unbedingte Wille zu gewinnen.
Die Liebe des Wettbewerbs, also wirklich die Herausforderung anzunehmen, ist natürlich key.
Die Tatsache, dass ich als Techie Teil des Gründerteams war und auch am Anfang, wenn es dann zäh war, wie oft Jochen und ich diskutiert haben, weil, weißt du wie es ist, Tech dauert immer ein bisschen länger, wird immer ein bisschen teurer und einen externen CTO, den kannst du im Zweifel, wenn er nicht passt, auch auf die Straße sitzen.
Das war, also wir mussten uns damit beschäftigen, weil I just was around.
dann glaube ich die Tatsache, dass ich vielleicht nicht in einzelnen Bereichen, wir hatten eingangs über das Programmieren gesprochen, der Beste bin, sondern dadurch immer offen bleiben musste für bestmögliches Feedback.
Und das führt, glaube ich, zu besseren technischen Entscheidungen.
Und deswegen, und da bin ich besonders stolz drauf, dass wir jetzt in diesen ganzen 15 Jahren, und da kannst du auch nochmal Claude fragen oder das LLM deiner Wahl, wir hatten bisher keine signifikante Downtime.
Nie.
Tatsächlich, okay.
Das finde ich einigermaßen verwunderlich, aber sehr gut.
Prove it.
Ich habe es bisher noch nie geschafft.
In keinem der Unternehmen, in dem ich war, gab es irgendwie ohne signifikante Downtime.
Lag hoffentlich nicht an mir.
Aber egal.
Du hast im Vorgespräch eine klare These formuliert.
Du hast gesagt, der größere AI-Impact liegt nicht nur bei der Entwicklerproduktivität, sondern in Business-Funktion.
Was hast du damit gemeint?
Naja.
Also natürlich ist es so, dass Entwickler gerade was so repetitive Tätigkeiten angeht, sehr viel Support, unfassbar viel schneller werden und natürlich kannst du da, glaube ich, ordentlich Produktivität heben.
Aber wenn du dir anguckst, dass die Komplexität in Unternehmen über die Prozesse wächst, weil du ganz viel Matrix hast, weil du halt Querfunktionen hast, dann habe ich schon den Eindruck, dass AI auch sehr viel hilft, den ganzen Business-Funktionen.
Und dadurch, dass es jetzt mit Sprache funktioniert und nicht mehr wie RPA und UML als Notation und alles sehr formal, kann quasi jeder Normalsterbliche mittlerweile alles, was er irgendwie im Kopf hat, zu Papier bringen.
mit Hilfe von LLMs.
Das ist schon ein großer Benefit und da ist der Hebel meiner Meinung nach im Business größer.
Und die Art zu arbeiten, aber dann auch das Bewusstsein, wie Technologie funktioniert, bis hin zu den Kostentokens, das ist was, was auch nochmal mehr, habe ich den Eindruck, bei den Business-Kolleginnen und Kollegen ins Bewusstsein rückt und auch rücken muss, als bei den Techies.
Bei den Techies habe ich bisweilen dann eher die Berührungsangst.
Weil diese Besonderheit, diese Schöpferische, was du als Entwicklerin oder Entwickler hattest, das scheint so ein bisschen denken, einige verwässert zu werden durch LLMs, was ich gar nicht glaube.
Ich sage ja immer, wir haben ja Makitas im Keller ohne Ende.
Und technisch wäre ich in der Lage, ein Haus zu bauen.
Ich wäre der letzte Mensch, der in mein von mir gebautes Haus einziehen würde.
Rufe ich einen Handwerker an, der mit diesem Makita-Krempel was anfangen kann, außer ein Bild aufhängen.
hört es auch auf, obwohl ich eigentlich alles beim Obi kaufen könnte oder beim Baumarkt deiner Wahl.
Also verstehst du, was ich meine?
Das heißt, ich verstehe die Unsicherheit, aber ich glaube, die Top-Leute, die werden da bestehen und noch besser werden.
Aber ich glaube, das interessante Learning ist vielmehr jetzt bei den aus Tech-Sicht Otto-Normal-Kollegen und Kolleginnen.
Wie ist eure Erdoption gerade, gerade im Engineering?
Engineering deutlich über 90 Prozent.
Wir nutzen da hauptsächlich Cloud Code.
Wir haben jetzt vor ein paar Wochen Cloud Cowork an die komplette Firma ausgerollt.
Also das steigt jetzt richtig.
Am Anfang haben die alle da mit Cloud dem Chatbot oder Co-Pilot oder auch intern Fixed GPT rumgearbeitet.
Aber das ist nochmal was anderes, wenn du wenn du die Toolchain hast und da hat Entropic mit Cowork schon auch für die Business-Kolleginnen und Kollegen einen echt guten Job gemacht.
Siehst du dann eine höhere Adoption in Tech bei euch als jetzt zum Beispiel im restlichen Unternehmen, im Headquarter?
Das ist noch schwer zu vergleichen, weil die Techies hatten früher alle Werkzeuge an der Hand und wenn ich nicht allen die richtigen Werkzeuge gebe und es nur spielerisch ist, dann kann man die Adoption manchmal nicht vergleichen.
Es gibt schon auch einige Business-Kollegen, die ordentlich Tokens spenden, aber wie gesagt, ich halte es für keine sinnvolle Metrik.
Am Anfang ja beim Experimentieren, weil selbst das ist ja, also Adoption einfach im Sinne von, du haust ganz viele Prompts raus, die ganz viele Tokens verballern, das ist ja dumm.
Also man muss schon selbst da anfangen, irgendwie smart drüber nachzudenken.
Deswegen müsste ich die Frage wahrscheinlich nochmal vier Wochen nach hinten schieben und dann kann ich sie dir beantworten.
Macht ihr euch schon Gedanken über die Kosten, die durch AI entstehen?
Oder macht ihr euch erst dann Gedanken darum, wenn wirklich aus den Subscriptions ganz viel Token Spend rausgenommen wird und man muss den halt wirklich nochmal separat bezahlen?
Wir machen uns da von Anfang an.
Es gibt ein klares Dashboard.
Das heißt, ich sehe alles.
Es ist in unsere Organisationsstruktur reingebaut.
Das heißt, du siehst sehr genau in deinem Bereich, in deinem Team.
was Sache ist, so ähnlich wie du auch gucken kannst, wie viel Urlaub dein Team schon irgendwie genommen hat.
Also da machen wir uns schon auf jeden Fall Gedanken.
Bist du für AI verantwortlich für die Strategie oder ist das jemand anderes im Unternehmen?
Ich würde sagen, die Strategie, also wo die Reise hingeht, da bin ich schon, man würde in unserer Größe vom Executive Sponsor reden, also ich bin schon die permanente Leier, die da anliegt bei uns, die Platte, die hängt.
Da steht mein Name drauf.
Es gibt jetzt in der Umsetzung, gibt es da ein Team, das sehr operativ und auch enabling ist.
Das leitet ein Tech-VP und es gibt einen sozusagen Tech-VP-Vortänzer, der sowas wie der AI-VP jetzt ist.
Die beiden, die operationalisieren.
Ja, das ist eine Frage, die ich in letzter Zeit häufiger CTOs stelle und zwar ist dann, wie ihr Return on Invest von AI messt.
Natürlich kannst du die Kosten relativ leicht messen und dann ist die Frage, wie misst du denn den eigentlichen Impact?
Im Engineering gibt es vielleicht die eine oder andere Lösung, ich weiß nicht, wie ihr damit vorgeht oder versucht ihr aktuell erstmal zu adopten und dann später guckt ihr, was der Impact ist?
Wir messen und erzeugen Transparenz und adopten und was Impact angeht.
ist das quasi nur Cost-to-Revenue-Ratials, also Operational Leverage.
Welche Tech-Kosten habe ich, um diesen Revenue zu machen?
Und wenn ich AI einsetze, kommen Kosten dazu, aber insgesamt müssen die Kosten im Verhältnis zum Revenue senken, weil sonst ist es ja nicht besser als zuvor, sondern eher schlechter.
Und dann sorge ich nur dafür, dass von den Tech-Bros die Superjagden wachsen, aber da habe ich keinen Bock drauf.
Das heißt, die Kosten im Verhältnis zu Revenue ist da für uns ausschlaggebend und das halt auch pro Segment, pro Bereich, pro Team im Zweifel.
Aber ihr habt trotzdem sichergestellt, dass bei aller AI-Initiative, die ihr macht, immer noch Human in the Loop ist?
Oder gibt es auch Bereiche, in denen ihr wirklich explizit Human out of the Loop für sinnvoll gefunden habt und da den Ansatz schon fahrt und Richtung voll autonomen Systemen geht?
In den meisten Bereichen Human in the Loop, wo Autonomist-Theme rum experimentieren, das ist ein sehr, sehr engen Guardrails.
Also da würde man sich schon fragen, macht das da Sinn?
In dem experimentellen Kontext ja.
Aber eigentlich müsstest du den Scope erweitern.
Da sind wir aber tatsächlich noch sehr vorsichtig.
Wir sind da grundsätzlich auch ein Stück weit konservativ, weil da geht es ja auch im Schluss um PII-Data.
Wir hatten jetzt erst letzte Woche die Diskussion, ob im User-Kontext der Kollege Claude beispielsweise im Browser herumhantieren darf oder nicht.
Das war nämlich bisher ein Nicht.
Die Antwort.
Aber offensichtlich limitiert es dann relativ stark.
Also wurde die Antwort jetzt geändert?
Ich habe gerade eine Message in meinem Teams, dass da ein Proposal anliegt.
Die Woche weiß ich es nicht, aber nächste Woche entscheiden und ich plädiere dafür, es jetzt zu ändern, aber mal gucken.
Es ist eine so weitreichende Entscheidung, dass ich es nicht komplett alleine treffen werde.
Du hast jetzt eben auch nochmal gesagt, dass ja durchaus der ein oder andere Entwickler zögerlich reagiert, wenn es um das Thema AI geht.
Wie gehst du denn genau mit diesen Mitarbeitern um, die Angst haben, dass entweder AI ihre Arbeit entwertet oder vielleicht sind das ja sogar Identitätsängste, die da entstehen, wenn man sich sehr stark durch die Kunst des Codens definiert hat.
Was ist eure Vorgehensweise?
Im Prinzip, weil du Identitätsangst beschrieben gesagt hast, das beschreibt es ganz gut.
Im Prinzip ist es nicht so viel anders wie bei den Post-Merger-Integrations nach einem M&A und sehr viel Zeit und Gespräche.
Ich versuche es zuallererst zu verstehen und dann mich darüber zu unterhalten und die Leute mitzunehmen und dabei lerne ich auch eine Menge, weil manche Sachen, die kann ich auch nicht verstehen qua meiner Rolle, aber die sind halt wichtig, weil am Schluss brauche ich den Buy-in von allen.
Oder vielleicht gibt es aber auch den einen oder anderen im Laufe der Zeit.
Es wird es geben.
der sich so weit verweigert, dass man sich auch von ihm trennen muss, weil es einfach nicht weitergeht.
Aber das gab es ja immer, unabhängig von AI.
Das ist ja kein AI-Thema.
Was siehst du denn, wie sich die Rolle des Engineers jetzt aktuell verändert?
Und was bedeutet das für euch, für eure Organisation und für das, was ihr an Engineers überhaupt sucht?
Verändern sich jetzt ganz massiv die Job-Descriptions oder die Anzahl der Engineers, die ihr jetzt überhaupt plant einzustellen in dieses und nächstes Jahr?
Was ist der Impact?
Was prognostizierst du da?
Wir haben ein Budget, das heißt, die Anzahl ist da jetzt eher nicht, entlang des Budgets ist jetzt da nicht betroffen, erst mal.
Aber die Beschreibung, was wir suchen, schon.
Und Kontext wird immer wichtiger.
Also nicht nur das Singuläre, ich bin der oder die beste Programmiererin, sondern Kontext wird immer wichtiger.
Was für ein Geschäft ist es?
Wie funktioniert die P&L und so weiter und so fort.
Das kritische Denken wird immer wichtiger.
Zu hinterfragen, macht das Sinn?
Hat auch das LLM einen guten Punkt oder nicht?
Und dieses neugierige Schöpferische, diese Curiosity, die ist elementar, weil das ist genau das, wo die AI eben noch nicht ist.
Weil auch die LLMs, du hattest vorhin das Beispiel genannt, ob ich schon mal CTO war oder nicht, das ist alles basierend auf bestehendem Wissen.
Das heißt, das Schöpferische wird da nochmal relevanter.
Ich kriege immer mehr Feedback aus der Industrie und gerade auch, wenn ich mit Executive Recruitern spreche, dass die Erwartungen an an den CTOs sich gerade massiv ändern und CTOs von größeren Unternehmen, die noch vor fünf Jahren sich sehr stark eben durch das Thema Organisational Scaling und Design und so was und viel Business-Kontext ausgemacht haben, wird jetzt im Endeffekt der Coding-CTO wieder sehr viel stärker gesucht, auch in den größeren Unternehmen, weil Engineering gerade ganz viel Richtung braucht und ganz viel Richtung noch nicht da ist.
Wie ist das bei dir?
Wie viel Zeit verbringst du aktuell mit Agentic AI?
Im Ausprobieren, im Coden, kleine Dinge bauen, Piloten machen oder wie sehr musst du dich dann auch auf deine besten Mitarbeiter verlassen, die hier für dich das maßgeblich vorantreiben?
Wieder deutlich mehr als in den letzten fünf, sechs, sieben Jahren.
Aber nicht mit dem Anspruch, dass ich da jetzt wieder zurückgehe in eine Hardcore-Tech-Rolle, sondern mit dem Anspruch, diese Technologie zu verstehen und irgendwie einschätzen zu können, um da ein Stück weit Guidance zu geben oder, wo es notwendig ist, auch ein bisschen zu natschen und zu drücken.
Genau, da reicht aber ein sehr gutes Maß an technischem Verständnis.
Im Gegenteil, es ist sogar gar nicht so schlecht, wenn du nicht der beste Coder bist, weil dann streite ich nicht, ob ich recht habe oder die Maschine, sondern Ich freue mich darüber, dass ich jetzt endlich Dinge tun kann, wo ich vorher in der Kaskade von If-Schleifen verhungert bin.
Ich glaube, der beste Coder muss man nicht sein, aber man muss sich, glaube ich, noch mal tiefer mit der Materie befassen, als man das mit einem Kubernetes hat machen müssen oder mit einem Kafka oder was auch immer.
Welche Fehler siehst du denn gerade bei anderen Unternehmen, bei Konzernen beispielsweise oder auch bei Scale-Ups?
AI-Frameworks, andere Orchestrierungsprodukte, Modellanbieter zu schnell versuchen, übereinander zu stapeln, zu integrieren?
Oder siehst du das aktuell noch gar nicht, dass das passiert?
Doch, doch, doch.
Also A, Token-Maxing, Bullshit.
Diese Leaderboards, Bullshit.
Die Tatsache, dass jetzt wieder alle anfangen, drei Milliarden Frameworks, wie du sagst, aufeinander zu stapeln, Bullshit.
Jedes Framework hat seine Kosten.
Das war wie früher.
Klar ist Spring geil und dann kannst du nochmal 30 Sachen drauf schneiden.
Aber wenn du Java Enterprise machst, weißt du, was du hast.
So, und das Letzte ist, glaube ich, so eine Frage von Abhängigkeit.
Egal von was.
Wir hatten über Kubernetes gesprochen und wir hatten über Kafka gesprochen.
So eine gewisse Grundautonomie braucht man und die muss man auch definieren.
Wir zum Beispiel lassen alle unsere Modelle über AWS Bedrock laufen und dann kannst du ein bisschen orchestrieren.
Jetzt kann einer sagen, ja, du bist, was ist denn, wenn AWS down ist?
Ja, klar, wenn irgendwann der Strom ausfällt, brauche ich meine eigenen...
weiß ich nicht, nukleare Reaktoren irgendwo, das ist ja, also, it comes to an end, aber man braucht ein gesundes Maß und sollte sich darüber Gedanken machen und jetzt nicht einfach, was viele Konzerne machen, all in OpenAI, all in Microsoft Copilot, all in Antropic und dann, na, hatten wir jetzt ja erst, gerade im europäischen Kontext, dann sagt irgendein amerikanischer Präsident, ja, nee, nicht und dann hast du kritische Business-Themen da drauflaufen, dann ist es Schicht im Schacht.
Heißt, der trifft auch Entscheidungen in dem Kontext möglichst agnostisch, was jetzt die Modelle angeht?
Ja, immer.
Ich weiß noch, dass ich gerade vor ein paar Monaten bei uns im Vorstands-C-Level-Meeting mich rechtfertigen musste, warum wir nicht einfach wie alle anderen auch den großen Entraffic-Vertrag unterschreiben, sondern da rumbasteln, Zitat, auf Bedrock.
Es ist nicht langsamer und es dauert alles ewig.
Dann habe ich gesagt, ja, es gibt bestimmt ein, zwei Feature-Gaps.
Die gibt es auch.
Beispielsweise kannst du über Bedrock meiner Meinung nach noch kein Cloud Design machen.
Aber ich muss ja ein bisschen langfristiger denken.
Ich kann ja jetzt nicht nur den hippen Scheiß machen.
Du hast jetzt interessanterweise eben gesagt, Token Spend und so, da drauf zu gucken die ganze Zeit ist Quatsch.
Ja, stimme ich zu.
Interessanterweise habe ich gerade heute Morgen...
Also drauf gucken ist wichtig.
Also ich habe immer Transparenz.
Aber...
Ich sage nicht, wir sind super in Adoption oder dieses Team ist besser, weil es mehr Tokens spendet.
Das ist ein Quatsch.
Ja, genau, genau.
Richtig, genau.
Da stimme ich mit dir über ein.
Ich habe auch gerade heute Morgen irgendwie eine Infografik, ist mir bei LinkedIn durchgeflutscht und da habe ich auch gesehen, was angeblich Meter pro Monat an Tokens verbraucht und das ist wohl ein Spend, der umgerechnet bei über 200 Millionen US-Dollar im Monat liegt, die sie ausgeben, was eine immense Zahl ist und wo man natürlich auch dann wieder fragen muss, welche Metriken sollen denn CTOs nutzen, um AI-Adoption und Business Impact dann letzten Endes zu messen?
Weil irgendwann ist die Zahl groß genug, dass der CFO draufschaut und dann sagt, naja, was bringt uns das denn außer mehr Kosten?
Und dann kannst du natürlich sagen, ja, ich gucke nur auf den Revenue, aber für mich als CTO wäre es unbefriedigend.
Schaffst du es?
ein gewisses Team hat folgende Velocity und aktuell auch noch irgendeine Schätzgüte.
Schaffst du es endlich mal sozusagen besser zu sein als das, was vorher geschätzt worden ist?
Schaffst du es sozusagen, die Frequenz deiner Releases zu erhöhen?
Schaffst du es, weil du an der QA gearbeitet hast und an dem internen Prozesskletterer-Datsch, dass du sozusagen deine Bug-Ratio runterbringst?
Es gibt schon ein paar Aufgaben, die es so alltäglich gibt.
Vielleicht ist es wirklich sehr simpel zu sagen, okay, ich schaffe es so und so oft, was zu releasen.
Da kann man schon drauf gucken, weil man spricht ja immer von Productivity im Engineering-Kontext und wenn du doppelt so häufig irgendwie Features raushaust, also jetzt kein Bullshit, sondern irgendwas, was natürlich Nutzen hat, dann ist es ein klares Indiz, dass es in die richtige Richtung geht.
Richtig.
Also du hast gerade was genannt, da bin ich auch sehr dafür, dass man nochmal stärker auf die Velocity schauen sollte, weil theoretisch muss man in der Lage sein, ja mehr Storypoints pro Sprint zu liefern als vorher.
Wenn nicht, hätte man glaube ich als CTO wirklich einen Erklärungsbedarf, warum das denn nicht so ist.
Ich gehe sogar noch einen Schritt weiter.
Ich glaube, mit AI ist man in der Lage, viel besser zu schätzen auf einmal.
Weil wer kennt das nicht?
Also ich kenne es noch mit Engineering Teams, die Diskussion darüber, was ist Komplexität und was nicht.
Das stimmt.
Prozess, der Adoption oder des Wandels, der Transition ist ja witzig, weil normalerweise, also wenn wir uns verschätzt haben, haben wir uns eigentlich immer in eine Richtung verschätzt.
War immer zu optimistisch, ne?
Ja, genau.
So, und jetzt bin ich ja, schaue ich schon drauf, ob mal Menschen einfach sozusagen zu pessimistisch waren, weil sie eben die Magic von AI vielleicht, weißt du, dann weiß ich ja sofort, wenn irgendwas zu pessimistisch ist, dann denke ich mir, ah, okay, dann scheint es bei euch schon irgendwie schon so langsam es funktionieren anzufangen.
Ja genau, du hast auch im Vorgespräch eine spannende These angedeutet und du hast ja auch gesagt, mit AI könnten größere Monolithen wieder kontrollierbarer werden.
Ich weiß, was du damit gemeint hast, aber vielleicht der ein oder andere der Zuhörer nicht.
Vielleicht kannst du mal kurz sagen, was du damit genau gemeint hast.
Naja, als wir jetzt für Skalierung sorgen mussten, haben wir alles in kleine Teile geschnitten.
Das heißt, die einzelnen Teams, End-to-End-Verantwortung, auch Code.
Und dann ist es schon so, dass über die Schnittstellen du immer noch Abhängigkeiten hast, auch dann im Kontext, in der Logik und dann wartet das eine Team auf das andere.
Und dann ist ja auch ein Not Invented Tier, das heißt, das andere Team könnte technisch natürlich den Code von dem Team, Team A und Team B, aber das machen die natürlich nicht, dann warten die, aber Team A hat ja auch immer einen eigenen Backlog.
Und wenn alle eine gemeinsame Codebase haben, was bei uns am Anfang natürlich irgendwann zu Spaghetti geführt hat, dann bist du natürlich etwas freier.
Das heißt, ich glaube, wenn du es logisch immer noch trennst, kannst du es jetzt auf Code-Ebene technisch wieder zusammenführen, weil du quasi einen guten Co-Piloten hast, und damit meine ich jetzt nicht das LLM, sondern im eigentlichen Sinne, der dafür sorgt, dass es gegroomt ist sozusagen, dass es trotzdem irgendwie eine Ordnung hat, ohne dass du es so hart schneiden musst.
Weil mit diesem Schneiden und dem Decoupling kommt natürlich Overhead.
Ist ja logisch.
Und ich weiß noch, als wir decoupled haben, ich dachte, das ist das Beste nach geschnittenem Brot und dann kam Covid.
Das heißt, die Betriebskosten von unserem Verteilungssystem waren so viel höher und André hat dann immer gesagt, hast du nicht gesagt, das ist das Beste nach geschnittenem Brot?
Sag ich, ja, aber ich bin davon ausgegangen, wir verdoppeln uns jedes Jahr und nicht, dass wir quasi einfach gar keinen Umsatz mehr machen, zeitweilig, und dann mit dem Decoupling und dem Verteilungssystem natürlich die Betriebskosten in die Höhe geschnallt sind.
Ja, das ist ein guter Punkt, auch mit großen Organisationen, mit großen Teams oder mit vielen kleinen Teams.
Das kann natürlich jetzt die Adoption von Microservices wieder vorantreiben.
Das ist ja auch so ein stetiges Auf und Ab.
Vor über zehn Jahren wollten alle weg von ihren Monolithen, das war super schlecht.
Dann hatten alle Microservices gebaut.
Bis es keinen Morgen mehr gibt.
Und das war dann zu viel und die Komplexität wurde immer größer.
Und dann sagen sie, nee, Monolith ist doch wieder besser.
Aber natürlich, wenn du eine große Organisation hast, wenn du irgendwie 10, 20 Teams hast, natürlich müssen die dann ihren eigenen Services bauen, oder?
Ja, genau.
Und das ist immer so ein bisschen, das Pendel hat sehr stark ausgeschlagen.
Hype, aber auch Größe der Organisation.
Und ich glaube, dass du in der Lage bist, einen guten Mittelweg zu finden, wenn du jetzt mehr Wing, Man und Women hast im artifiziellen Kontext, die den Kontext verstehen und auch die Rechencapabilities haben, zu sagen, nee, schau mal her.
Da musst du nicht gleich hart Microservices machen oder musst du mit den Unzulänglichkeiten von einem großen, einer monolithischen Cookbase, sondern es werden sich vielleicht Wege auftun, die da etwas smarter sind mit der Hilfe von AI und die dann schlussendlich dazu führen, darum geht es, schneller mehr Customer-Badie zu schicken.
Gib uns mal einen zu deinen persönlichen Ausblick.
Was sehen wir denn in zwei Jahren in Engineering?
Sehen wir da ganz viel Level 5, also voll autonome Softwareentwicklungs-Lifecycles oder werden wir soweit noch gar nicht sein und dann eher uns über Orchestrierung weiter Gedanken machen?
Hast du da eine These dazu oder eine Meinung?
Also meine These ist in erster Linie, dass wir werden gemischte Teams sehen, wo du autonome Agenten hast, die gewisse Tätigkeiten machen und Menschen.
Und ich glaube, dass die Menschen sich eben sehr stark auf den Kontext konzentrieren werden, sozusagen auf das, was das Unternehmen, über das wir noch immer sprechen werden, eben an Wert erzeugt und sich dann wirklich auch aufs Schöpferische, wo wollen wir hin als Unternehmen, was ist die passende Architektur, konzentrieren werden.
Und gleichzeitig denke ich, dass viel von dem, was Entwicklerinnen und Entwickler genervt hat, das wird einfach weg sein.
wird einfach die Maschine voll autonom machen, quasi für dich mitdenken, die Kleinigkeiten.
Und dann bleibt eigentlich nur die Frage übrig, was machen die Top-Entwicklerinnen und Entwickler mit dieser freien Capacity?
Und ich hoffe ja, dass sie sich dann stärker damit beschäftigen, wo die echten Werte liegen.
Also zu dem, was ich als erstes gesagt habe, sich vielleicht von selbst mal an die Business-Kolleginnen und Kolleginnen ranwanzen oder Oder so weit öffnen, dass sie sagen, ja, lass mich mal mein System verstehen.
Was wollen die Kunden eigentlich?
Also ich glaube, da wird sich der Scope deutlich verbreitern.
Und die Kunst wird sein, dass du ja dabei zwar den Tiefgang im Alltag nicht mehr so sehr brauchen wirst, aber du kannst trotzdem nicht das Verständnis komplett loslassen, weil du ja deine Agenten irgendwie, überwachen musst.
Das heißt, es wird schon durchaus eine Herausforderung.
Was ich glaube, was man im Zuge dessen auch sehen wird, dass sich die Karrieren ändern.
Und zwar insofern als das, du fängst es an als Junior, dann bist du irgendwie besonders gut mit dem einen, dem anderen, dann wirst du mit Senior und so weiter und so fort.
Ich glaube, im Mittelbauch wird die größte mentale Flexibilität in Zukunft von den Kolleginnen und Kollegen, den Hardcore-Techies erwartet werden, weil da glaube ich, dass du Karrieren siehst, dass die mal was anderes machen, dass die mal raus aus der Tech gehen und irgendwo quer einen Schritt machen und dann wieder zurückkommen, weil ich glaube, gerade im Mittelbau, wo du früher mit reiner Exzellenz reinen Marriottes geglänzt hast, das wird halt schwer gegen die Maschine.
Ist das auch das, was du einem Senior-Entwickler raten würdest, der vielleicht CTO werden will, aber der vielleicht immer auch noch glaubt, der beste Entwickler im Unternehmen sein zu müssen?
Weißt du, Anekdote, ich habe in den USA bei einem Automobilzulieferer gearbeitet und das war technisch und das, also als Expert, da haben wir eine Softwareentwicklung aufgebaut in Detroit und die ganze Infrastruktur dahinter und so, weil es da Aufträge von Chrysler damals gab und so.
Und dann irgendwann kam die Automobilkrise und dann hat das als Expert keinen Sinn mehr gemacht und dann bin ich zurück und dann war irgendwann die Frage, was macht das Unternehmen mit mir?
Und dann hat mir der damalige der damalige Geschäftsführer gesagt, weißt du was, schon mal drüber nachgedacht, dass du ein Werk leiten kannst.
Also Produktion.
Und das kam dann nicht dazu, weil es gab noch ein großes SAP-Projekt, aber der Gedanke war für mich essentiell, weil ich mir gedacht habe, was will der von mir?
Ich bin doch ein Techie, ich brauche doch irgendwas zum entwickeln oder zum konfigurieren oder irgendwie ein SAP-Projekt oder whatever.
Ich habe nie daran gedacht, eine Werksleitung, what the fuck.
Aber im Nachhinein habe ich mir gedacht, ja stimmt.
Und eigentlich, die Frage ist ja, wie Dinge zusammenlaufen, Komplexitäten, Prozesse, Abläufe, Menschen, das hat mich sehr interessiert.
Und ich wollte ja Führungskraft werden.
Wenn du keine Führungskraft werden willst, mag das eine andere Bemegung sein.
Und einer meiner VP-Engineering ist aktuell, der war auch zwischenzeitlich mein Chief of Stuff, den habe ich mal aus der Tech-Weck gelobt, dass er bei uns Shops und Stations leitet.
Also so richtig nah am Kunden.
Also die Verkaufsstellen und da, wo dann auch die Passagiere und Kundinnen und Kunden ein- und aussteigen und so.
Und warum?
Weil ich glaube, das hilft, dass du auch weißt, wofür wir so eine Tech-Plattform bauen.
Wie gesagt, in den allermeisten Fällen.
Ja, gehe ich mit.
Ist ja auch interessanterweise ein Vorgehen, was bei vielen CEO-Aspiranten der Fall ist, die ja auch verschiedene Unternehmensfunktionen erstmal gesehen haben müssen, bis sie sich dann eines Tages auch für so eine Rolle qualifizieren.
Und du sagst, Für die CTO-Rolle wäre es auch hilfreich, wenn man mehr gesehen hat als nur Tech, um vielleicht auch aus dem Denken rauszukommen, dass es immer nur um die beste technische Lösung geht.
Das höre ich da auch zwischen den Zeilen raus.
Witzigerweise, diese Veränderung hat da schon stattgefunden, weil die Technisierung, Software eats the world und so weiter und so fort.
Und häufig ist es gar nicht so der Aufsichtsrat oder der CEO.
Häufig waren die CTO-Kolleginnen und Kollegen oder CTO-Kolleginnen und Kollegen, der...
eigene limitierende Faktoren, die haben sich selbst quasi klein gehalten, weil sie gesagt haben, mich interessiert aber jetzt nur das SAP-System oder nur dies und dann ich mir auch, ja, aber warum denn?
Ich meine, das macht ja auch keinen Sinn, weil dein SAP-System selber hilft dir ja überhaupt nicht, irgendwie geile Autos zu bauen.
Also schon prozessual, aber at the end, kein Kunde sagt, oh, das Auto fahre ich jetzt, weil das ist so eine schöne SAP-Konfiguration.
Die sind als erste auf S4 gegangen und deswegen ist das geilste Auto sehr katsch.
Wie siehst du denn die CTO-Rolle in fünf Jahren?
Glaubst du, sie wird wichtiger und mächtiger als vorher durch AI oder wird sie obsolet werden, weil AI Teil von allem wird?
Also ich glaube, es kommt darauf an, was das für ein Unternehmen ist.
Du hast bei CTO-Rollen im Hardcore-Entwicklungstechnischen Bereich, wir bleiben bei Automotive, die entwickeln ja Fahrzeuge, ist nochmal was anderes als im Softwarebereich.
Im Softwarebereich, wo es nur SaaS, Plattform, AI-Geschäft geht, glaube ich, dass diese Diskussion Product und Tech, CTO, CTPO noch virulenter wird, weil das muss man zusammendenken.
Das ist einfach irgendwie, das ist, glaube ich, dann nicht mehr zeitgemäß final.
Und ich glaube, das wird eben auch aufgewertet mit dieser Business-Denke.
Wo kommen die Euros rein?
Wie funktioniert die P&L?
Und dann, Und dann ist diese Rolle, wir nennen sie weiterhin CTO, ein elementarer Bestandteil von meiner Meinung nach jedem Management Board, weil wenn du dir dann als CEO denkst, das bräuchte ich alles nicht mehr, weil dann rufe ich meinen Kumpel den Claude an, das wird nicht lange gut gehen.
Da kann ich jetzt, da kann ich drauf, also da bin ich mir 100% sicher.
Gehe ich auch 100% mit mit dir.
Daniel, wir sind auch fast am Ende der heutigen Aufnahme angekommen und wie es so schön Tradition ist bei uns, gibt es am Schluss noch eine Fünf Rapid-Fire-Fragen mit hoffentlich Rapid-Fire-Antworten.
Hast du noch ein paar Minuten Zeit, damit wir die auch noch durchkriegen?
Ja, ja, vorher frei.
Ich bin jetzt gerade, ich bin umgezogen, wie du gemerkt hast, weil mein Akku leer war.
Die Probleme bleiben noch nicht gleich.
Sehr schön.
Bester CTO-Mythos, den wir endlich begraben sollten.
Dass du der oder die beste Techie in der Company sein musst.
Sehr gut, gefällt mir.
Eine Fähigkeit, die Entwickler für die AI-Ära unterschätzen.
Kontext.
und Critical Thinking.
Sehr gut.
Monolith oder Microservices, wenn du nur ein Wort wählen müsstest?
Streich das Micro, dann bin ich immer noch Pro-Services.
Sehr gut.
Ja, also ich dachte auch, am Anfang willst du eigentlich Monolith first bauen und später willst du Services, aber ob die Micros sind oder B, ist ja erstmal egal.
Ein Tool, ein Prinzip oder eine Gewohnheit, die deine Arbeit als Tech- und People-Leader verbessert hat?
Slack oder Teams oder wie auch immer du es nennst, the way the...
to work in Messengers war als life-changing.
Klingt jetzt profan, aber war wirklich so.
Okay.
Dein Rat an jemanden, der in fünf Jahren CTO werden will?
Überlegt euch neben der Technik, auf was ihr noch Bock habt, Werte zu schaffen.
Und dann sucht euch entsprechend ein Unternehmen, das damit erleint ist.
Schöne Antwort, gefällt mir sehr gut.
Daniel, vielen lieben Dank.
Wir haben hier...
Jederzeit, Philipp.
Danke dir.
Sehr gute Aufnahme hingelegt.
Ich habe eine Menge gelernt über dich, über Flix und über deine Perspektive auf AI, auf die Organisation.
Vielen lieben Dank.
Merci.
Jederzeit.
Sehr gut.
Mach's gut.
Ciao, ciao.
Ciao.