Vom CTO zum Chief Organizational Plumber: Daniel Krauss über 15 Jahre FlixBus

Philip, schön, dass ich das sein darf. Freut mich. Grüß dich.

Weißt du, ich bin bei uns dreien schon immer der Tecky 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 dazu bekommen, der eben nicht Teil des Gründerteams war und der musste zu dem Zeitpunkt schon sein Seal Level abgeben, weil eben nur Gründer damals das C getragen hatten und war aber ein geiler Typ. Ja, 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 war fand ich irgendwie eine Kackmessage und habe ich, weißt du was, dann dann gibt's diesen CTO Titel bei uns gar nicht mehr und dann habe ich mir die Teeflügelchen gestutzt sozusagen und war von dem Zeitpunkt CIO. Weil wie gesagt, ich hätte es als unangemessen empfunden, jetzt zu sagen, weißt du, gibt zwei CTOs und nur weil ich zufällig das Privileg des Mitgründers hatte, bist du jetzt VP Engineering und ich bin Capo. Dann haben wir das glaube ich salomonisch und 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 in den ganzen Letzten Tag. So, die Antwort ist, Programmieren war es schon lange nicht mehr, was aus Sicht von Flix bestimmt etwas Gutes ist. Und habe ich mir halt 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, ne? Und vor allem bin ich sehr stolz auf die Flix Tech, weil mit der Hand oder mit der Flasche groß gezogen und da muss ich natürlich dafür sorgen, dass die so schnell wie möglich laufen können. Und dann 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 Mario und das Resultat war, dass ich quasi der Chief Organizational Plumber bin und Andre findet es ein bisschen albern, aber ich finde es beschreibt am besten was ich tagtäglich tue.

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's mittlerweile einige VP Engineerings und inoffiziell ist es schon noch so, dass die großen Themen, ne, 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 Mehrwert bieten kann.

Das ja, das ist ja eine Frage, wie die nachgucken, ne? Und es gibt ja so Menschen, die dann die einzelnen Schritte und Veränderungen beispielsweise in LinkedIn kund tun. Das habe ich ja nie, ne? Ich habe einfach das bei mir steht ja quasi ein Volkszeitraum 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 LMs funktionieren, kann ich zumindest die Antwort nachvollziehen.

Die Eskalationsinstanz ist schon was in der Art des Jobs liegt, weil das C kommt ja als mit dem Chief und mein 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 inne hast, 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 da 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 Zwergenstart 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 ja auch mit man kann es als Information 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 bei Jochen Andreum mir im Kopf ist. Das entsteht da. Damit habe ich aber im Tagesgeschäft Informationsvorteil 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's ja das Conway's Law, dass die beiden Dinge zusammenbindet.

Richtig.

Ganz am Anfang habe ich das, aber vor allem Infrastrukturnah, ne? Das war das und da kommt vielleicht schließt da der Bogen zu ganz früher, wo wir an Rechnern rumgeschraubt haben, wo ich irgendwie selbst mit dem Lötkolben und Grafikkarten unterwegs war, was bisweilen erfolgreich war. Der also der das 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 kommen da muss ich schmunzeln, da kommen Gedanken hoch. Wir hatten mal so eine 1 € Aktion und da mussten wir, weil wir natürlich Traffic erwartet hatten und damals war das alles noch irgendwie beim Hetzner. Und dann musste ich da in der Patchi Konfiguration was ändern und na ja schlussendlich hat mich meine Frau abgeholt und wir haben den Freitag Nachmittag nicht irgendwie am Tegernsee verbracht, sondern im Büro, weil die Config nicht so von Erfolg gegrüht 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, 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 es, du lernst es alles, aber ich würde jetzt kein Poet werden. Und deswegen hat mich das relativ schnell gelangweilt, weil ich halt mich, weißt du, wenn du so das ist jetzt geil mit Cloud Code und den LMs, weil dann fällt einem das viel einfacher, aber früher war ich so selbst limitiert und das stresst dann und dann hast du dich halt auf andere Dinge konzentriert und weißt du, wenn du alles nur mit if Schleifen löst, da 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 Menschenorganisation bereizt, 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 zusammen zu binden und bin quasi mit ausreichend wenig hartem Programmieren durch.

Nee, du musst schon und meine Antwort ist jetzt vor der Zeit der LMs, wo dir quasi fast alles abzüglich der Halluzinationen rausziehen kannst. Das ist schon wichtig aus zweierlei Gründen. A, um Entscheidungen hinterfragen zu können, sinnvoll und nicht immer nur mit Warum? Warum? Ja, wie meine vierjährige Tochter und B, um auch so eine bisschen eine Credibility zu haben, weil ich habe ja gesagt, ne, 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 es sinnig klingt und nicht nur, weil es der Capo ist oder aus Prinzip oder sowas, ne? Und dann brauchst schon bisschen auch Street Credit. Und gerade wenn du im Alltagsgeschäft oder gegenüber irgendwie dem Board, dem Aufsichtsrat manchmal abkürzt, dann ist ganz witzig bei uns, weil da wurde ich gleich zu Ressort gerufen, da ich habe neulich was über API kund getan, weil ich eigentlich nur beschreiben wollte, wie unsere zukünftige sehr offene Architektur aussieht und dann gab's gleich Feedback, weil sie ist ja das aber nicht richtig. Weil wir haben vor einigen Jahren auf eine Event-basierte Architektur umgestellt, ne, mit Kafka und dann hast du also technisch gesehen sind es ja Events und keine sag ich ja, okay, ich weiß so und dann ist es ganz gut, dass du a in dem Fall Feedback bekommst und B aber auch zu Riss 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 inhaltlich falsch getan 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 Alter sagt, wir machen es 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 die Grundlagen angeht und insbesondere und das gleiche, was du gerade gesagt hast, wird es auch jetzt wichtiger im Umgang mit den LMs, 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 Jubeljahre bei uns im Git unterwegs bin, ist es viel. Aber dennoch muss man sich ja natürlich damit beschäftigen, wie sich Technologien weiterentwickeln, ne? 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.

Genau. Also du, was heißt nicht geliefert, ne? Sehr 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. Auch naiv zu denken, dann kann Externer liefern. Ich meine, how there ja, du hast da mehr Capacity, aber du musst die auch briefen. Du musst auch ein sauberes MVP definieren, weil es ist ja immer quasi immer ein Dreieck und dann hast du noch die Abhängigkeit dazu und die anderen bauen das noch auf, dass 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, ne? Jetzt wo ich mir war, da hast du dich aber vorher auch einfach selber in 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 diesen Hang zum Perfektionismus, was Techis 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's 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 hier gesehen hat. Interessiert nämlich keinen.

Ja, also die a 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's und das ist häufig in einer Situation der Organisation, weil unterschiedliche Größen, unterschiedliche Schnitt ist immer sehr ähnlich, wo die Bottlenecks stehen und das dann wirklich zu hinterfragen und aufzulösen ist, glaube ich, eine wiederkehrende Kunst. Aber natürlich verändert sich global an die Organisation. Also als wir angefangen haben, das war ganz ich me damals war noch kleiner Server, da haben wir uns gerade von Hetzner Richtung Cloud beschäftigt, also eine andere Welt und da gab's, weiß ich noch, da gab's dann ein Backend Team und dann gab's ein Frontend Team und dann gab's ein Mobile Team und dann gab's ein Infrateam und dann haben wir das halt so aufgebaut, ne? 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, Feature, irgendeinen Kundentha vor Augen hatte, weil was das ja Head of Backend, ich meine 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änencluster 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 den Person baut anders aus, als wenn er für ein ganzes Feature, ein Produkt verantwortlich ist. Das heißt, da haben wir relativ viel umgebaut, was dann auch uns befähigt hat von einer monolitischen 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 CEO 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, ne, im Demand Kontext, also B2C und dann ein Großbereich im Supply Context, 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 diesen ganze dieser ganze Klettererad, aber auch ganz viel Enablement, was jetzt wie gesagt noch wichtiger wird, weil mit diesem AI Hype, wenn er 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 coden und die muss natürlich einhegen und gleichzeitig befähigen, dass da keine Scheiße bei rauskommt.

Also die Architekturentscheidungen, die treffen wir gemeinsam. Da gibt's ein Architecture Board bei uns, da sitzen die ganzen Silberrücken und die geben so grundlegende Guidelines. Es 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 Metriken z.B. Dora oder wie viel Bugs hauen die raus und wie lange brauchen sie dies fixen etc. pp, aber auch da ist mein Blick über die Zeit viel stärker in Richtung Business gewandert. Wenn Team gut ist, dann erzeugt es echten Value. Das heißt mehr Umsatz, mehr Kunden nutzen oder weniger Kosten. Und das du merkst es, wenn da Leute intrinsisches Interesse dran haben, wenn selbst also der Product Owner, dass der die P&L kennt, wo auf der P&L zahlen denn seine Produkte ein. Ja. Und auch Entwickler, die hinterfragen, was kostet es eigentlich und was bringt's, wie ist sozusagen 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 ein Team, ein echtes Entwicklungsag Team, dann weiß ich, ah, das geht in die richtige Richtung.

Ja, also wir haben zum einen ist eine Frage, wie sie Kunden definieren. Eine Kunde kann auch ein anderes Team sein und dann ist die Frage, mache ich das Team irgendwie schneller, ne? Durchlaufzeitverbesserung. Ein klassisches Beispiel, das wir immer hatten und da fängt's 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 Ano dazu mal, ne, nicht mehr supported. Alles irgendwie wahrscheinlich heutzutage mit Mythos löchrig ohne Ende. Ja, und dann hieß es, wir müssen jetzt hoch und natürlich teuer Aufwand. So und es stand aber nirgendwo. Es war auf keiner Road mehr, es war nirgendwo, weil es war so ein Tech Thema, Tech Foundation Thema whatever. 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.

Genau, warum machen wir das? Ja, und dann hast du natürlich Totschlagargumente, wie es wird nicht mehr supportet, es ist irgendwie buggy, aber dann sage ich okay, aber ist es denn auch schneller? Krieg ich da irgendwas dafür? Ist es irgendwie im Betrieb günstiger, weil es weiß ich nicht ja weniger Comput braucht, whatsoever. So, 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. Es 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 immer so ein Touch Moment gelten und dann 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 holistischer drüber nachzudenken. Weil am Schluss ne auch die Diskussion zu Tech Debt, das ist ja wir müssen alle Steuern zahlen, das ist so oder aber man muss sich das halt bewusst sein und kann es nicht einfach nur zu Nonchalant hinnehmen. Das ist mir zu kurz gesprungen.

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 eigentliche Nukleus ist, ist unser Inventar. Das wie bei einem Onlineshop, wenn du möglichst viel von dem Zeug, was du haben möchtest, bei dem Onlineshop findest, dann ist der normalerweise relativ weit oben in der Auswahl, wenn du überlegst, was kaufe ich, wo du hinsurfst und so. Das heißt, für uns ist es die Ansammlung und die Kombination von allen Zielen, die wir anbieten, die dann in dem 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? So und das ist an sich schon sehr kompliziert auch in der Optimierung, aber es macht's natürlich noch mal 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 ein optimalen Preispunkt setzen, was sind Menschen gewillt zu bezahlen für Mobilität und für bei uns natürlich für den Flixbus oder für den Flix Train und das herauszufinden, die Daten zu erheben, zu verarbeiten und möglichst schnell so zu entscheiden, ne? Klassisches Pricing Revenue Management. Das ist der dritte Teil, der elementar ist. Das ist auch der Teil, wo wir schon weit vor dem aktuellen Transformer Hype mit künstlichen Intelligenz im technischen Kontext, klassisches Machine Learning angefangen haben zu arbeiten. Und dann ist der Teil, den ich gerade so ein bisschen stiefmütterlich mit Unrecht behandle, der Operational Teil, weil du darfst nicht vergessen, dass wir eine Flotte von mehreren 1000 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.

Als wir unseren ersten großen M&A gemacht haben, Flixbus und MeinFernbus zusammengeschraubt haben, habe ich mir beide Systeme angeguckt und mir erschien das MeinFernbus 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 und manchmal wie viel Gegenwind hast du da bekommen intern? Ich habe es, 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 da mal schon so einen langen Nukleus hatten, weil es einfach irgendwann im Enterprise Bereich PHP so ein bisschen an seine Grenzen und da war ich ganz froh, dass wir direkt Java genommen hatten und nicht irgendwie dann damals war es super schick auf Ruby zu gehen, aber puh, Gott bewahre, das hätte mich jetzt wahrscheinlich viel Nerven gekostet. Wir haben in dem Zeitraum aber auch echt falsche Entscheidung getroffen. Wir sind damals auf Angular gegangen, weil wir es hipper fanden als React in the early days, wenn du dich erinnerst.

Ja, genau. Das war alles mies. Wo gehobelt 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 Contain Systems gemacht. Das ist immer nur so eine 80% Lösung, weil du nicht eigentlich auf allen Schichten sofort trennst und so. Das an der Datenbank hängt da noch Dinge zusammen und so. Also das war aber good enough vom Aufwand her und dann hat sich witzigerweise manchmal muss auch Glück haben, ne? Also, wir hatten damals sehr seniorige DevOps Kollegen, geiler Typ, den Steffen, der hat mit Kubernetes rum angefangen rumzufuhrwerken und dann waren wir da relativ früh dran und das war eine gute Entscheidung, ne? Also die Containerisation und dann auch ein bisschen die Abstraktion zu den Hyperscaler und 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 Kost, weil da war noch viel PHP und das hat alles echt geknarzt, 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 unserem Fall auf AWS gewechselt sind. Das war auch war auch glaube ich eine gute Entscheidung, weil uns sonst der Hetzner geiles Unternehmen, ja, Franke offensichtlich, aber das wäre uns um die Ohren geflogen. Also, wir haben da schon rückwirkend paar gute Entscheidung getroffen und das ist so, glaube ich, ein grobes Samurium denen, die wichtig waren. Wo ich lang gehadert habe und wir viel Leergeld auch noch bezahlen, war so ein bisschen die Frage native oder Hybrid im Mobile Kontext. Ja, aber im großen und ganzen hab das beantwortet.

Ja, ich würde sagen, wir sind noch zu großen Teil Native unterwegs. Das hat sich ein bisschen mit React jetzt geändert, aber wir haben bisher z.B. bin noch nicht irgendwie groß auf Flutter gesetzt oder so. War da, also ich 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 z.B. bin mittlerweile technisch so weit weg, dass ich dann immer glaube, was zu wissen oder ich lese irgendwas und so, aber gleichzeitig darfst natürlich den Leuten auch nicht auf den Sack gehen mit qualifiziertem oder gefährlichem Halbwissen. Also mobile, glaube ich, aber glaube ich müsste bei uns schon noch mehr gehen, aber glauben heißt bekanntlicherweise nicht wissen.

Das kommt darauf an, ne? Also jetzt auf MeinFernbus 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 MeinFernbus zusammenzubinden, ne? 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's dann gar nicht um Tech oder nicht Tech, sondern geht's einfach darum Dinge zu finden, die einen verbinden. Und vor allem nicht irgendwie hochnässig oder überheblich ranzugehen. Technisch ist es aber so, dass wir seit der Fernbusgeschichte 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, ne? Also während Covid haben wir Kamil Koç in der Türkei übernommen und waren da nicht genug on the ground einfach, ne, 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, ne, 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 Inderinnen und Inder als unsere Kundinnen und Kunden einfach auch anderes gewöhnt sind, ne? Also wie Datach funktioniert, wie sozusagen 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.

Also das mit der Größe und dem, wenn man nichts tut, behebiger werden, das ist so. Punkt. Die Tränen lass ich nicht gelten, weil gerade die Gründerinnen und Gründer, die dann auch noch in C-Level 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 DNA im Sinne von Menschen sind bereit Risiken einzugehen. Sie wollen Entscheidungen treffen und nicht immer 1000 Menschen in CC nehmen und alles nach oben delegieren, vor allem Entscheidungen, sondern sie nehmen die Accountability. Neudeutsch. Das ist schon was, was uns einfach sehr wichtig ist und deswegen versuchen wir dadurch die DNA zu erhalten. Und weißt du, wir hatten gerade vor, na ja, ist jetzt auch schon wieder ein Jahr her, aber da gab's so Dinge, da sind Entscheidungen passiert und die sind mir aufgestoßen und dann klickst du da drauf und dann kommt irgendwann so: 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 tragen 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 & Commit war, dann ist schlussendlich der CEO, also Andre, der die Accountability trägt. Ist auch okay, aber irgendwie ein abstraktes etwas.

Ja, auf jeden Fall.

Also ich glaube, dass die Serendipity, also Timing, richtige Zeit, richtiger 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 Teil des Gründerteams war und auch am Anfang, wenn es dann zwei, wie oft die auch und ich diskutiert haben, weil du weißt wie es ist, Tech dauert immer ein bisschen länger, wird immer ein bisschen teurer und ein externer CTO, den kannst du im Zweifel, wenn nicht passt, auch auf die Straße setzen. Das war also, wir mussten uns damit beschäftigen, weil ich just was around. Ja. Und dann glaube ich die Tatsache, dass ich vielleicht nicht in einzelnen Bereichen, wir hatten eingangs übers 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 noch mal Cloud fragen oder das LLM deiner Wahl, wir hatten bisher keine signifikante Downtime, nie tatsächlich.

Na ja, also natürlich ist es so, dass Entwickler gerade was so repetitive Tätigkeiten angeht, ne, 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 Prozessen in Unternehmen über die Prozesse wächst, ne, weil du ganz viel Matrix hast, weil du halt Querfunktionen hast, dann habe ich schon den Eindruck, dass auch sehr viel hilft den ganzen Businessfunktionen und dadurch, dass es jetzt mit Sprache funktioniert und nicht mehr wie RPA und UML als Notation und alles sehr formal, können da auch, kann quasi jeder Normalsterbliche kann mittlerweile alles, was er irgendwie im Kopf hat, zu Papier bringen mit Hilfe von LLMs. Das ist schon 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 Kosten Tokens, das ist was auch noch mal mehr, habe ich den Eindruck, bei den Business Kolleginnen und Kollegen sozusagen ins Bewusstsein rückt und auch rücken muss, als bei den Techis. Bei den Techis habe ich bislang eher die Berührungsangst, weil diese Besonderheit, dieses 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 sag ja immer, wir haben ja Makitas im Keller ohne Ende. Ja, 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 ein Handwerker an, der mit diesem Makita-Krempel was anfangen kann. Außer Bild aufhängen hört's auch auf. Ja, obwohl ich eigentlich alles von IKEA kaufen könnte oder beim Hornbach, 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, noch besser werden. Aber ich glaube, das interessante Learning ist viel mehr jetzt bei den aus Techsicht autonomen Kolleginnen und Kollegen.

Engineering deutlich über 90%. Wir nutzen da hauptsächlich Claude Code. Wir haben jetzt vor ein paar Wochen Claude Cowork an die komplette Firma ausgerollt. Also das steigt jetzt richtig. Am Anfang haben die alle da mit, ne, mit Claude dem Chatbot oder Copilot oder auch intern FlixGPT rumgearbeitet. Aber das ist noch mal was anderes, wenn du die Toolchain hast und da hat Anthropic mit Cowork schon auch für die Business Kolleginnen und Kollegen echt guten Job gemacht.

Ist noch schwer zu vergleichen, weil die Techis hatten früher alle Werkzeuge an der Hand und wenn ich nicht allen die richtigen Werkzeuge geb und es nur spielerisch ist, 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 muss man schon selbst da anfangen irgendwie smart drüber nachzudenken. Deswegen müsste ich die Frage wahrscheinlich noch mal vier Wochen nach hinten schieben und dann kann ich sie dir beantworten.