Wer das Business nicht versteht, ist nicht investment-ready | mit Chris Philipps

Software galt lange als natürlicher Burggraben digitaler Unternehmen. Chris Philipps hält dagegen: Im AI-Zeitalter lässt sich Software immer schneller nachbauen. Wirkliche Verteidigbarkeit entsteht eher durch proprietäre Daten, tiefes Domainwissen und die Fähigkeit einer Organisation, schneller zu lernen als der Wettbewerb.

In dieser Episode von Becoming CTO Secrets spricht Philipp Deutscher mit Chris Philipps, Gründer und Managing Partner von PHILIPPS & BYRNE. Sein Unternehmen begleitet Investoren, Start-ups und Scale-ups bei Tech Due Diligences, Product-and-Tech-Assessments und M&A-Transaktionen und bringt Erfahrung aus mehr als 700 Tech Assessments mit.

Chris erklärt, wie sich die CTO-Rolle seit seinen eigenen Anfängen fundamental verändert hat. Es geht darum, warum starke Entwickler unter Druck häufig wieder ins operative Arbeiten zurückfallen, weshalb ein CTO das Geschäftsmodell in der Tiefe verstehen muss und warum Leadership vor allem Arbeit an der eigenen Persönlichkeit ist.

Außerdem sprechen Philipp und Chris über die Realität der AI-Adoption: von ChatGPT und Autocompletion über Agentic Engineering bis zur Dark Factory. Sie diskutieren explodierende Token-Kosten, den möglichen Aufstieg des 100-fach produktiveren Engineers, neue Aufgaben für CTOs und die überraschende Renaissance der kombinierten CTPO-Rolle.

Zum Abschluss geht es um die Unterschiede zwischen Investment Readiness und Verkaufsreife, um technische Burggräben, Technical Debt und die Frage, wann schlechte Technologie tatsächlich zum Dealbreaker wird.

Eine Folge über die neue CTO-Rolle zwischen Business, Product, Engineering, AI-Transformation und den Erwartungen von Investoren.

Transcript

SPEAKER_00 0:00

Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs, für CTOs und diejenigen, die es noch werden wollen. Ich bin Philipp Deutscher, externer CTO, CTO Coach und Gründer der Becoming CTO Community. Heute spreche ich mit Chris Philips. Er ist der Gründer von Philips Byrne und einer der erfahrensten Stimmen für Tech Due Diligence, CTO Advisory und Tech Health Checks im europäischen Startup und Investment-Ökosystem. Chris bringt eine seltene Kombination mit aus eigener CTO-Erfahrung, Interim-CTO-Mandaten und hunderten Blicken in Product and Engineering Organisationen. Wir sprechen darüber, wie sich die CTO-Rolle gerade verändert, was AI-Adoption in seiner Realität wirklich bedeutet und wie Unternehmen aus Tech-Sicht Investment und verkaufsreif werden. Das klingt ja gut. Philips, herzlich willkommen. Na super, das geht ja gut los.

SPEAKER_01 0:53

Vielen Dank, Philipp. Vielen Dank. Schön, dass ich hier sein darf.

SPEAKER_00 0:57

Ja, siehst du mal, wenn dein Nachname mein Vorname ist, dann passiert so etwas.

SPEAKER_01 1:00

Du glaubst gar nicht, wie oft das passiert.

SPEAKER_00 1:02

Ja, okay, na okay. Mir ist es trotzdem jetzt ein bisschen unangenehm. Ich hoffe, du verzeihst mich. Wenn du auf deine Reise vom CTO, wir fangen direkt mit dem Thema an, dann gehen wir ja so nonchalant darüber hinweg. Wenn du auf deine Reise vom CTO über Interim-CTO-Mandate hin zum Gründer von Philips und Björn Schaus, welche Stationen hat denn dann dein Verständnis der CTO-Rolle am stärksten geprägt?

SPEAKER_01 1:25

Also ich glaube, ich habe überall was mitgenommen. Ich glaube, ich würde gerne zwei Sachen kurz erwähnen. Das erste ist tatsächlich meine erste CTO-Rolle gewesen bei Daily Deal. Da war der Perspektivwechsel von einer Head-of-Rolle bei Studio VZ vorher am krassesten. Auf einmal war ich für einen viel breiteren Themen-Scope verantwortlich. Und klingt ein bisschen blöd, aber psychologischer Aspekt. Auf einmal war niemand mehr da, hinter dessen Rücken. Ich mich mal hätte kurz ducken können oder verstecken können, sondern ich war verantwortlich gegenüber dem CEO, gegenüber Investoren. Und das ist, glaube ich, auch der größte Perspektivwechsel, den ich bei jungen CTOs sehr, sehr häufig sehe. Ein zweiter großer Shift hat sich bei mir ereignet, als ich gar nicht mehr in der CTO-Rolle war, sondern sozusagen von außen auf die CTO-Rollen drauf geguckt habe, wirklich aus Investorensicht eben für Investoren tätig war in Tech-DDs. Das hat auch nochmal, sagen wir mal, nicht unbedingt das Verständnis der Rolle geändert, aber die Kalibrierung, also die Kalibrierung war eine andere.

SPEAKER_00 2:37

Und du beobachtest die CTO-Rolle und CTOs im Allgemeinen seit ungefähr 2010, wenn ich das richtig bei dir gesehen habe. Und siehst sie heute natürlich auch nochmal von außen in diesen ganzen Tech-DDs und so weiter. Was nimmst du denn aktuell wahr? Was hat sich denn in den letzten Jahren fundamental verändert? Hat sich etwas fundamental verändert und was genau ist es?

SPEAKER_01 3:02

Ich würde jetzt insbesondere so auf Startups und Scale-Ups schauen, wenn ich über die CTO-Rolle spreche. Was sich in Deutschland ganz stark verändert hat, ist, dass es viel weniger Individual Contributors gibt, die dann irgendwann so zum CTO-befördert worden sind, ohne dass sie eigentlich ihr Verhalten geändert haben. Das gab es in den 2010er Jahren noch ganz, ganz viel. Das gibt es sicherlich immer noch, aber das hat sich erheblich verändert. Also wir sehen heute viel mehr CTOs, die schon eine Business-Perspektive, eine Business-Dänke mit reinbringen, die auch eine Product-Dänke reinbringen, die sich anders präsentieren und vor allem, die auch bessere Netzwerker sind. Also ich glaube, das ist wahrscheinlich der größte Unterschied. Ich erinnere mich auch, als ich 2010 meine erste CTO-Rolle hatte. Ich hatte überhaupt kein richtig strukturiert aufgebautes Netzwerk. Geschweige denn war ich gewöhnt, wirklich Outreach zu diesem Netzwerk zu machen, um mir Hilfe zu holen. Und heute mit AlphaList, CTO Craft, CTO-Stammtisch oder eben auch Becoming CTO Secrets oder Becoming CTO heißt, glaube ich, dann eine Community, ne? Genau. Also das sind alles ja Ansätze, wo Leute genau diese Netzwerke helfen zu bauen und Netzwerke ermöglichen. Ich glaube, das ist ein Riesenunterschied. Aber ich sehe auf der anderen Seite auch immer noch, gerade wenn man das jetzt so mit US oder UK-CTOs vergleicht, einige Defizite, so gerade auf strategischer Ebene, auf being the visionary, aber auch was so Umgang mit People angeht. Also ich glaube, da sind viele CTOs, UK-CTOs und US-CTOs, den deutschen CTOs doch noch einiges voraus.

SPEAKER_00 4:44

Ja, du hast gerade die Veränderung gesehen, dass der früher immer noch mehr ICs in der Rolle waren und sich auch wie ICs, also wie Individual Contributor auch verhalten waren oder Verhalten haben. Hast du den Eindruck, das ist eine natürliche Evolution in der Rolle, die da stattfindet und eine Professionalisierung in diesem Bereich oder ist das auch etwas, was viel stärker von Investoren eingefordert wird und dementsprechend die Anforderungen an so eine Rolle dann automatisch angehoben werden?

SPEAKER_01 5:12

Ja, ich glaube von beidem etwas. Ich glaube, auf der einen Seite dadurch, dass sich das Ökosystem verbessert hat, also eben Netzwerke, aber auch einfach mehr Quellen, mehr CTOs, Ex-CTOs, CTO-Coaches, die tatsächlich die Rolle mal innehatten. Davon gab es vor 15 Jahren oder auch vor 10 Jahren noch wesentlich weniger. Und das hat viel gemacht mit den CTOs. Auf der anderen Seite Investoren, ich bin jetzt mal ein bisschen böse, vor 15 Jahren hat kaum ein Investor überhaupt mit dem CTO gesprochen, bei einer Farming-Runde zum Beispiel. Das war eher eine Ausnahme. Heute ist das anders. Und dementsprechend fällt natürlich auch einfach stärker auf, wenn die Person noch komplett irgendwo im Rabbit Hole ist und überhaupt nicht gar keine Vogelperspektive aufs Business, aufs Produkt, auf die Technologie als Enabler fürs Business zum Produkt hat.

SPEAKER_00 6:05

Ja, wir kommen ja auf das Thema Rabbit Hole, wie nah muss man irgendwo dran sein an der Technik, wie weit muss man weg sein? Da hat sich ja auch einiges getan dazu, da kommen wir auch später nochmal darauf. Was nimmst du denn wahr? Was unterschätzen denn ambitionierte Entwickler, also diese sehr guten Individual Contributor, was unterschätzen die am häufigsten, wenn sie Richtung CTO-Rolle wachsen wollen? Ist es auch dieses, eigentlich denken sie, sie müssten immer noch der beste Techie im Raum sein und werden dann irgendwann mit der Realität konfrontiert oder ist es noch was anderes?

SPEAKER_01 6:34

Ich glaube, auf der einen Seite ist es der zu starke Fokus auf Tech. Und die vergessen immer noch teilweise den Business-Kontext und vergessen auch, dass sie das eigentlich übersetzen müssen in den Business-Kontext und wieder zurück übersetzen. Also da ist mehreres drin. Da ist auf der einen Seite so, was ist eigentlich meine Aufgabe und mein Scope? Und auf der anderen Seite ist es, mit wem spreche ich. Also die typischen ICs sind es gewöhnt, mit Product-Leuten zu sprechen, mit Tech-Peers zu sprechen. Die sind es aber nicht unbedingt gewöhnt, mit einem VP-Sales zu sprechen. Und ein VP-Sales zum Beispiel braucht, der braucht eine andere Übersetzung für das, was du da erzählst. Also du kannst dann nicht damit ankommen, dass du jetzt folgendes Modul refactorst, weil die API auf der vorigen Version und so weiter, das versteht ihr überhaupt nicht. Der schaltet der ab und das müsste auch nicht sein Problem. Das heißt, du musst es in das übersetzen, was er versteht, was er da draußen verkaufen kann oder was sonst wie relevant fürs Business ist. Das ist sicherlich eine große Umstellung, womit ICs sich schwer tun und die andere ist eher so im Innenverhältnis zum Tech-Team. Und das ist das, was du gerade sagtest. Also dieser Automatismus, immer noch alle Sachen selber machen zu wollen, statt die zu delegieren. Und da ist mir selber in der Beschäftigung damit mal aufgefallen, Menschen fallen unter Druck immer auf bewährte Überlebens-Patterns zurück, mit denen sie bereits in der Vergangenheit erfolgreich waren. Und beim IC ist es halt, Code schreiben oder Sachen zu fixen und nicht zu delegieren. Und das ist ein Mechanismus, dessen man sich wirklich bewusst sein muss und werden muss und das Minenmuskel trainieren muss, dass man sagt, nein, ich springe da jetzt nicht zurück, weil das angeblich schneller oder einfacher ist oder ich der Beste darin bin, sondern ich muss mein Verhalten wirklich systematisch ändern und das ans Team delegieren. Nur so erlange ich überhaupt eine Freiheit, um dann managen zu können und nicht die ganze Zeit in irgendwelchen Troubleshootings gefangen zu sein.

SPEAKER_00 8:37

Ist dir das selbst auch ganz oft vor die Füße gefallen, das Thema?

SPEAKER_01 8:40

Ja, heute noch. Also ich musste das interessanterweise als CEO auch wieder komplett neu lernen. Das fand ich auch krass. Ich dachte, okay, CTO habe ich in viel größeren Organisationen gemacht. Auf einmal bin ich CEO in meiner eigenen Org und habe genau die gleichen Patterns wieder. Ich möchte am liebsten auch heute noch jede DD selber machen und musste immer wieder sagen, nein, das mache ich jetzt nicht. Ich habe Leute, die da mittlerweile viel besser drin sind. Aber das passiert sehr, sehr leicht. Ich glaube, das muss man einfach durch Verhaltensänderungen und ganz viel Kopfarbeit wirklich trainieren.

SPEAKER_00 9:11

Ja, du hast ja eben auch gesagt, was der Individual Contributor unterschätzt oder der ambitionierte Entwickler ist, wie wenig Tech dann eigentlich dann noch in der CTO-Rolle ist im Vergleich zu all den anderen Sachen drumherum. Dann stellt sich aber auch die Frage, braucht man dann unbedingt ein Techie in der CTO-Rolle? Oder reicht da nicht auch einer, der ein einigermaßen okayes Technologieverständnis hat und der kann das am Ende des Tages doch wuppen? Was würdest du sagen oder was, vielleicht du hast ja bestimmt auch in den Organisationen mal die einen oder anderen CTOs erlebt, die keinen Engineering-Background hatten. Wie haben die sich geschlagen und glaubst du, dass das eine Möglichkeit ist, diese Rolle auszufüllen?

SPEAKER_01 9:48

Ich habe da ein paar gute Ausnahmen gesehen von Leuten, die keinerlei Tech-Background hatten und trotzdem einen sehr, sehr guten Job gemacht haben. Das waren Leute, die extrem gute People-Skills und Management-Skills hatten und die schlau genug waren, dann so in der zweiten Führungsreihe in Tech extrem gute Te-Leute zu haben. Ich habe aber oft auch einfach gesehen, dass das fällt oder dass es zumindest knarzt. Weil die Leute meistens, demen fehlt so die Perspektive auf das, was wichtig ist. Wenn das Team mal irgendwie zu tief drin ist und die Prios nicht mehr klarkriegt und du guckst zum Beispiel auf eine Architektur drauf, ja, und du siehst dann, hey, was wir da gerade machen, das dreht sich eigentlich im Kreis. Wir müssen in die andere Richtung, wenn wir die Business-Ziele zum Beispiel erreichen wollen. Da hast du manchmal als CTO mit einem technischen Background die Chance, eine Intervention zu machen, die du nicht unbedingt machen kannst oder das zumindest nicht challengen kannst, wenn du gar keinen technischen Background hast. So. Und gleichzeitig muss man natürlich jetzt sagen, mit Agenc Engineering wird sich einfach auch extrem viel verändern, nochmal im CTO-Profil. Und ich glaube, da wird tatsächlich nochmal wesentlich mehr Business-Kontext und auch Product Context nochmal eine Rolle spielen. Also ich war zum Beispiel jahrelang gegen so CTPO-Rollen. Ich habe die immer sehr, sehr kritisch gesehen aus ganz vielen Gründen. Die Position habe ich mittlerweile aufgegeben, weil ich sage, naja, für so einen Agentic Engineering First Approach macht es durchaus Sinn, dass du nicht mehr so zwei Spitzen hast, sondern das eigentlich in einer Person vereint, dieses Profil.

SPEAKER_00 11:36

Aber das ist eine spannende Haltung, weil ich hatte durchaus auch den ein oder anderen CTO hier drin, der sehr stark auch schon vor Agentic AI für die CPTO-Rolle gewotet hat. Ich tatsächlich auch. Natürlich gibt es auch Kontexte, wo es nicht Sinn macht. Was ist denn dein Plädoyer gegen die CPTO-Rolle, also jetzt vor Agentic AI? Was waren denn die Gründe, um dass du sagtest, ja, das funktioniert nicht so gut oder dazu rätst du nicht?

SPEAKER_01 12:04

Es gibt vor allem zwei Hauptgründe. Das eine ist, ich habe selten Leute gesehen, die es geschafft haben, in beiden Rollen extrem gut zu sein. Und ich habe oft gesehen, dass CTOs zu früh nach dieser Doppelrolle gegriffen haben, wenn ich eigentlich der Meinung war, Mensch, da ist erstmal auf der technischen Seite, auf der CTO-Rolle so viel Luft noch, sich nach oben zu entwickeln, dass ich es schwierig finde, den Scope so weit aufzumachen, weil natürlich struggles du, wenn du dann in die Breite gehst und gehst nicht mehr unbedingt dann noch weiter in die Tiefe. Das ist ein Grund und ich habe eigentlich lieber zwei extrem gute CTOs und CPOs als einen mittelmäßigen CTPO. Der zweite Grund ist, dass ich ein riesen Fan von dieser Reibung bin, die du zwischen CTO und CPO hast. Wenn das Verhältnis zwischen den beiden Leuten nicht gut ist und die keine gemeinsamen Werte und Sprache haben, dann ist das toxisch oder wird zumindest schnell toxisch. Aber wenn das Verhältnis gut ist, dann ist das wie so eine gute Ehe. Die reiben sich aneinander, die streiten sich, die ringen um eine Lösung. Aber genau in diesem Ringen entstehen meistens sehr, sehr gute Produkte, wenn man das wirklich ernst meint. Und diese Reibung, dieses Starring mit einer anderen Person, die vielleicht auch mal ganz andere Interessen hat, die fehlt mir bei so einer CTPO-Rolle oft.

SPEAKER_00 13:27

Ja, und trotzdem sagst du natürlich jetzt, jetzt wo Agentic AI kommt, ist die Konsolidierung der beiden Rollen vielleicht die logische Konsequenz. Dann stellt sich ja wiederum die Frage, CPTO kommt er dann eher, ist das eher der CTO, der dann CPTO wird, oder der CPO, der dann CPTO wird? Hast du dazu eine Haltung?

SPEAKER_01 13:44

Ich habe da noch keine abschließende Meinung. Ich sehe gerade jetzt beide Modelle. Ich finde die spannend. Ich meine, in dem Moment, wo du von dieser Doppelrolle sprichst, brauchst du eigentlich eine zweite Führungsriege, die wiederum, glaube ich, in ihren Bereichen extrem stark ist. Also, und ich glaube, wie gesagt, du holst ja Business und auch Produkt durch Agentic-Coding ein ganzes Stück näher, einfach nochmal an die Technik ran. Und das ist auch extrem gut. Aber trotzdem sind so Themen wie gerade Architektur und DevOps ja nicht weg. Ja, und auch so Governance-Themen, die du im Tech hast, die sind ja nicht auf einmal weg. Und die werden einfach, gerade Architektur- und DevOps-Themen werden einfach momentan von AI noch nicht gut gelöst. Und deswegen brauchst du auf jeden Fall eine starke technische Führung immer noch drin.

SPEAKER_00 14:35

Gibt es denn dann eine Lektion aus deiner eigenen CTO-Laufbahn, die du dann anderen, wenn du andere Leute triffst, die die CTOs werden wollen oder vielleicht gerade CTOs geworden sind, die du denen mitgibst oder mitgeben würdest?

SPEAKER_01 14:48

Ja, das eine ist, dass Leadership-Rollen grundsätzlich Arbeit an deiner eigenen Persönlichkeitsentwicklung sind. Das ist ganz, ganz wichtig, weil du musst unglaublich viel einstecken in diesen Rollen, du musst viel Verantwortung tragen, du musst aber auch einfach deine Soft Skills aktivieren können, authentisch sein, offen sein für Feedback, aber auch lernen, welches gut zu geben. Und das sind letztendlich die meisten davon sind Persönlichkeitsthemen und nicht Techniken. Die Leute müssen ja auch vertrauen, die Leute müssen irgendwie eine safe Umgebung haben. Und das ist nicht einfach so. Und das ist, ich habe das selber auch gemerkt, in Phasen, in denen ich unter Stress war, vielleicht wegen privater Themen, habe ich einfach einen schlechten Job gemacht als Führungskraft. Und das ist, das kostet wahnsinnig viel Energie und Aufmerksamkeit, das entweder zu trennen oder also trotzdem da sauber zu bleiben und zu filtern und einen guten Job weiterhin zu machen. Und das sind Persönlichkeitsthemen.

SPEAKER_00 15:58

Woran erkennst du denn, wenn du auf so eine Tech-Organisation drauf schaust, sei es jetzt im Rahmen einer Tech-DD, ob der CTO strategisch wirkt oder eher noch agiert wie ein typischer Head of Engineering?

SPEAKER_01 16:10

Ich frage CTOs zum Beispiel einfach gerne nochmal danach, was eigentlich ihr Businessmodell ist, also das Business-Modell der Company, für die sie arbeiten und was das eigentlich für Tech bedeutet. Und allein da wird es bei vielen schon schwierig, das zu beantworten. Oder umgekehrt, was das Refactoring, das sie gerade machen, was das denn fürs Business bedeutet. Weil leider ist Tech doch hier und da noch Selbstzweck oder vielleicht auch gar nicht böse gemeint, sondern man hat einfach die Scheuklappen auf und man sieht nur, dass es irgendwo wehtut. Man guckt sich zum Beispiel nicht an, ob diese Te-Dead, ob die einfach nur hässlich ist, aber jetzt auch noch bequem zwei Jahre da bleiben kann. Oder ob das wirklich jetzt der eine Treiber ist, der das Business nach vorne bringt.

SPEAKER_00 16:53

Ja, das Schöne an uns beiden ist ja, wir gucken ja sehr oft von außen auf Organisationen drauf und in Organisationen rein und sehen halt CTOs aller verschiedenster Ausprägungsstufen. Was nimmst du denn wahr? Wie unterscheiden sich denn diese CTO-Rollen? Gerade wenn du mal guckst, früh Startup, Scale-Up, später vielleicht größerer Mittelstand oder vielleicht auch Enterprise-Kontext. Wie verändert sich die Rolle?

SPEAKER_01 17:18

Naja, also wie gesagt, traditionell haben wir noch viel und ich glaube, das ist auch immer noch der Fall, auch wenn sich das Profil und das Verhalten geändert hat. Aber ich glaube, traditionell kommen in Startups die Leute wirklich noch aus dem IC-Bereich und haben irgendwann Lust gehabt, mehr Verantwortung zu übernehmen und sind dann so in den Ranks einfach nach oben. Aber die haben noch sehr oft wirklich eine absolute Te-DNA. Die haben nicht unbedingt in einer Sales-Rolle gearbeitet oder in einer Beraterrolle oder in etwas Tech-Fernerem.

SPEAKER_00 17:53

Ist das denn so sein, deiner Meinung nach?

SPEAKER_01 17:55

Nein, ja doch, in Startups würde ich schon sagen, in Startups in Frühphasen ist das, glaube ich, sehr gesund zumindest. Also ich habe auch schon gute Quereinsteiger gesehen, die aus dem Customer Support kamen und irgendwann merkten, sie wollen am liebsten programmieren und sind dann da voll rein. Oder Leute, die natürlich aus dem Data-Bereich kamen, also schon recht verwandt. Aber meistens sind es dann doch noch eher die Techis. Und ich glaube, in frühen Startup-Phasen, wo man wirklich brutal hands-on sein muss, ist es gar nicht so schlecht, drücken wir es mal so aus. Weil man einfach noch so nah dran ist. Je größer das Ding wird, also wenn ich jetzt von frühphasigen Startups rede, rede ich vielleicht von einem Tech-Team von fünf Leuten oder von zehn Leuten. Und da ist es, glaube ich, schon wichtig, dass man noch sehr viel Tuchfühlung hat. Wenn du irgendwann mal eine Organisation von 25, 30, 50 in Product Engineering hast, dann ist es nicht mehr ganz so wichtig, dass du wirklich noch Details verstehst. Was ich eben dann in den Phasen auch sehe, wenn es so um Scale-Ups geht, ist, dass genau diese ICs halt oft auch so an ihre Grenzen kommen, weil man natürlich auch sagen muss, dass oft in Startups überhaupt kein Leadership-Training oder irgendwas oder Coaching oder ähnliches erfolgt. Das heißt, das ist alles irgendwie so Learning by Doing und Blogs lesen und vielleicht noch ein bisschen auf eigene Faust sich ein Coaching holen. Und wenn man nicht einen guten Chef hatte oder ein gutes Training, muss man einfach viele Umwege machen. Und das sehen wir dann in den Scale-Ups. Und da ist es auch sehr oft so, dass CTOs, die relativ frühphasig reingekommen sind oder vielleicht von Anfang an mit dabei waren, irgendwann abgeben wollen, weil sie merken, das wird jetzt ein bisschen dünn für mich. Oder aber auch abgeben müssen. Weil die Company in eine andere Phase geht und da eigentlich was ganz anderes gebraucht wird an Profil. Viel mehr Managerial, ja, viele Teams managen, vielleicht auch nochmal Offshoring oder Outsourcing machen, aber auch so Geschichten wie Investoren wirklich versorgen, managen, mit in Fundingrunden reinkommen oder mehr so diese Governance-Themen machen, auf die meistens so die frühphasigen Leute auch nicht unbedingt Bock haben. Fair enough. Aber in der Phase sehen wir dann eigentlich so einen Generationswechsel, nenne ich das mal.

SPEAKER_00 20:27

Ich nehme das von außen auch so wahr und es ist schön, dass du das ansprichst, weil ich glaube, dass das oftmals auch ein Trade-off ist, den sich Founder auch gut überlegen müssen. Also nicht jeder CTO in einem Startup ist ja einer der Founders, sondern manchmal ist es auch einer, der in die Rolle reinkommt. Ganz oft wird auch diese Rolle vergeben, weil es die Unternehmen nichts kostet. Und weil sie, weil vielleicht ein sehr guter ein sehr guter Lead-Engineer bereit ist, sich dem Startup beizutreten, weil er diese CTO-Rolle kriegt, weil das vielleicht sein Eintrittsticket ist und er ist bereit, halt für ein geringeres Gehalt oder geringere Compensation anzufangen. So, das funktioniert. Das klingt natürlich auf den ersten Blick für beide Seiten nach einer smart Version und kann sich auch voll auszahlen. Aber es kann ja genauso gut sein, dass du zwei Jahre später an dem Punkt kommst, dass du feststellst, der ist ja gar nicht geeignet für das, was die eigentliche CTO-Rolle, die dann erst beginnt, der überhaupt in der Lage ist, die auszufüllen und auch nicht gewillt ist, sie auszufüllen. So, und dann kommen die Zinsen oder die eigentlichen Kosten für deinen Trade-off, weil dann musst du dir überlegen, findest du nochmal eine andere Rolle für ihn in der Organisation? Ist er bereit dazu, so eine Demotion oder so einen Schritt zur Seite zu machen? Oder geht er dann und kannst du dir das dann überhaupt leisten? Und das ist tatsächlich, ich meine, das lässt sich wahrscheinlich schwer antizipieren als Startup, ob was jetzt da die richtige Entscheidung ist. Aber das sind die möglichen Kosten von, ja, ich gebe jemand den Titel, weil ich ihn gerade unbedingt haben will, aber das ist das Billigste, was ich ihm geben kann.

SPEAKER_01 21:48

Ja, aber das ist nicht billig. Das ist oft eine sehr teure Entscheidung, wenn du Opportunitätskosten mitzurechnest. Also allein wenn ich an meiner eigenen Fehler als junger CTO äh. Dann weiß ich, was das gekostet hat. Ich finde das gerade in Startups trotzdem fällen nach, weil irgendwo müssen die Leute ja herkommen. Es gibt ja jetzt nun mal nicht das Ausbildungsprogramm CTO und dann purzeln da irgendwie Profis auf den Markt. Ich finde trotzdem wichtig, Expectation Management zu betreiben. Und also aus Founder, aus Investorensicht einfach zu sagen, hey, du bist jetzt der CTO, aber es mag der Zeitpunkt kommen, wo wir einfach ein anderes Profil brauchen. Und umgekehrt jungen CTOs würde ich immer raten, das eben nicht als Demotion zu sehen oder als Gesichtsverlust, sondern wenn dieser Punkt kommt, sogar proaktiv in dieses Gespräch zu gehen und zu sagen, ich möchte gerne hier bleiben, aber ich möchte auch vom zukünftigen CTO eben noch mehr lernen, weil ein guter Chef ist Gold wert. Wenn du dir ansiehst, wie ein Senior-CTO arbeitet, ist es unglaublich viel wert. Du lernst eine Menge. Und das ist eine Chance, die junge CTOs viel stärker mitnehmen würden oder sollten, statt ein bisschen beleidigt oder traurig zu sein und sich zum nächsten Unternehmen aufzumachen.

SPEAKER_00 23:09

Ja, genau. Und jetzt kommt natürlich das Thema AI noch mit dazu. Und das erhöht die Erwartung, dass ein CTO quasi alles macht. Gleichzeitig ist er der Produktstratege oder Produktmanager, er ist der Visionär, der Effizienztreiber, der Risikomanager, entwickelt auch noch selber mit und so. Wie siehst du das aktuell von deiner Perspektive aus? Wie verändert das die Rolle konkret oder ist das noch gar nicht so richtig abschätzbar, wohin sich das entwickelt?

SPEAKER_01 23:34

Da ist noch ganz viel Moving-Target drin. Also momentan, glaube ich, muss oder sollte ein CTO ganz stark ein Treiber sein für AI-Transformationen in Unternehmen. Aber Treiber bedeutet eben nicht, dass das alles innerhalb von Engineering passiert. Sondern was wir im Gegenteil, was wir gerade sehen, wir sehen halt hauptsächlich zwei Bilder. Das eine ist, dass Organisationen einfach noch sehr konservativ sind und die Leute Angst haben vor diesem relativ abstrakten Vehicle AI und sich dann nicht unbedingt drauf stürzen, sondern denken, es kostet sie ihren Job, wenn sie damit anfangen. Und das andere ist das Gegenteil, das ist das Szenario, wo auch gerade User, die bisher immer von Engineering abhängig waren, jetzt auf einmal Dinge wie Cloud Code entdecken oder auch sowas wie Lovable entdecken und auf Teufel komm raus und gib ihm Dinge bauen und sagen, geil, ich brauch eigentlich Engineering gar nicht mehr. Nicht wissen, was sie nicht wissen. So, und beide Situationen müsste so ein CTO eigentlich managen und müsste eigentlich ein Ambassador dafür sein, auf der einen Seite zu sagen, hey, guckt euch folgende Dinge mal an. Zum Beispiel macht man eine Session mit Customer Support machen, die mal auf, also bei den Skeptikern zum Beispiel, die mal auf Cloud Code setzen und sich einzelne Use Cases aus deren Alltag, die denen wehtun, rauspicken und denen einfach mal zeigen, die erfahren lassen, was es bedeutet, mit solchen Tools zu arbeiten. Und das ist, egal wen du fragst, jeder der this gemacht hat in seiner Organisation, kriegt, da kriegen die Leute solche Augen und sind völlige Fans davon. Und umgekehrt bei der anderen Gruppe, die dir sowieso davon rasen, ist es halt schon wichtig, ohne die irgendwie total zu demotivieren und auszubremsen, denen so ein paar Guardrails zu verpassen. Gerade wenn es jetzt vielleicht hochregulierter Bereich ist oder so, weil, wenn wir mal ganz ehrlich sind, fast alle Teams von diesen Enthusiasten machen gerade irgendwas mit ChatGPT und Claude und notfalls mit dem eigenen privaten Account. Und aus einer Governance-Perspektive ist das natürlich die Vollkatastrophe.

SPEAKER_00 25:58

Ja, so entsteht Shadow IT 2026.

SPEAKER_01 26:02

Absolut, bin ich absolut bei dir. Nur auf der anderen Seite, ich finde, die Leute zu blocken, kann halt auch nicht die Lösung sein, sondern das ist genau die Anforderung an so ein zukünftiges CTO-Profil, was an der Stelle eigentlich interessanterweise schon fast wieder so eine CIO-Breite kriegt, wie du die in großen Organisationen hast, also sich auch um interne Prozesse und Tooling-Themen zu kümmern.

SPEAKER_00 26:24

Also sagst du, das sind diese Fähigkeit oder Denkweise, die jetzt eine CTO jetzt braucht, um auch in den nächsten Jahren noch relevant zu sein? Das ist in erster Linie diese Ambassador-Rolle oder was ist es noch? Was sollte er sonst noch entwickeln, um hier im Fahrwasser ganz vorne mit dabei zu sein?

SPEAKER_01 26:41

Ich glaube, insgesamt ist eine CTO-Aufgabe, ein bisschen die Zukunft lesen zu können. Und das ist natürlich wahnsinnig schwer im Moment. Aber als CTO musst du dich auch nicht nur mit der Technologie selber beschäftigen, sondern du musst dich mit dem Markt beschäftigen. Also was machen gerade die großen Frontier Labs, wo gehen deren Businessmodelle hin, auf was werden die sich stürzen und so weiter. Was sind so Sachen wie zum Beispiel jetzt Export Control bei Fable 5, ja? Dass du weißt, dass solche Dinge im Baum stehen können, weil nur dann kannst du eigentlich strategische Entscheidungen in Bezug auf technischen Einsatz treffen und hast wahrscheinlich immer noch in 50 Prozent der Fälle nicht recht. Aber trotzdem ist das, glaube ich, wichtig. Und auf der anderen Seite ist eben auch wichtig, zu verstehen, was braucht meine eigene Company, um vor allem Feedback Loops zu installieren. Ja, und mit Feedback Loops, ich meine, wir alle kennen Feedback Loops aus der Technik, zum Beispiel durch automatisierte Tests. Das ist sicherlich der kleinste Feedback Loop, den wir so im Alltag haben. Ein großer ist zum Beispiel Customer Feedback auf UX-Tests oder auf Surveys oder Product Analytics sind größere Feedback Loops. Die sind meistens mittlerweile momentan broken bei uns, indem ab irgendeinem Punkt dieser Loop kein Loop ist, sondern stoppt und dann müssen wieder Menschen irgendwas entscheiden und bewusst machen. Aber in Zukunft wird es ja immer mehr autonome Feedback Loops geben. Und die wird es in der Technik geben, im Produkt, die wird es aber eben auch in Customer Support geben und im Business geben. Und meiner Meinung nach ist eine Hauptaufgabe von CTOs in der Zukunft Treiber für diese Feedback Loops zu sein. Und dazu brauchst du eine vernünftige Dateninfrastruktur, dazu brauchst du gute Prozesse, dazu brauchst du auch hier und da ein bisschen Governance und du brauchst auch eine Org, die vielleicht anders aussieht als momentan, um das Bauen dieser Feedback Loops unterstützen zu können.

SPEAKER_00 28:36

100 Prozent. Und du machst natürlich auch solche AI-Benchmarks und AI-Readiness-Checks, also du und deine und dein Unternehmen. Wenn jetzt Unternehmen zu dir kommen und sagen, ja, wir machen AI, was siehst du denn dann in der Realität, wenn du mal aus deiner fachlichen Brille drauschst, wie viele AI machen sie denn da wirklich und was ist die harte Realität, mit der du sie konfrontieren musst?

SPEAKER_01 28:57

Ja, ich mittlerweile sagen alle, wir machen AI. Also vor einem Dreivierteljahr haben noch ganz viele gesagt, nein, wir machen das nicht, das ist Quatsch. Das hat sich jetzt im letzten Dreivierteljahr komplett geändert, mittlerweile machen sie alle AI. Und wenn wir dann reingucken, sehen wir literally alles von wir benutzen Chat-GPT als wirklich als puren Chat, bis über, wir haben ein bisschen Autocompletion in unserer IDE, bis hin zu wir arbeiten gerade auf Dark Factory hin, ist alles vertreten. Fairerweise muss man aber sagen, also wenn man jetzt mal von verschiedenen Bereichen ausgeht, zum Beispiel Product Engineering, fast niemand ist bei der Dark Factory, sondern viele sind gerade im Mittelfeld. Benutzen Cloud Code oder Codecs, die haben vielleicht so 30, 40, 50 Prozent, wenn sie gut sind, angenec generiertem Code. Die Zahlen werden auch mehr. Also wir gucken uns zum Beispiel in DDs oder in so AI-Benchmarks, gucken wir uns auch gerne einfach mal die Metriken dazu an, in den Tools, wie viele Commits sind da erfolgt, wie viele Contributors gibt es da, die wirklich die Tools regelmäßig nutzen. Und da siehst du ganz klar bei den Leuten überall, dass die Kurve nach oben geht. Aber du siehst bei vielen Companies auch, dass sie tatsächlich auch erst so Anfang des Jahres ungefähr damit angefangen haben. Also das war wirklich so, ich habe Kollegen, die haben vor drei oder vier Jahren mit Agentic Engineering angefangen, als es unfassbar mühsam war und man da eigentlich mehr Arbeit mit hatte, als dass es die Ergebnisse gebracht hat.

SPEAKER_00 30:33

Ja, so richtig geht das ja erst seit Anfang des Jahres dann los, als dann die ersten richtigen Breakthroughs waren, auch mit Cloud Code gerade. Aber ich nehme das ähnlich wahr. Es gibt halt so es gibt ja fünf verschiedene Level von manueller Softwareentwicklung hin zu, du nennst es jetzt Dark Factory oder man kann es vollautonome Softwarefabriken nennen, was auch immer. Die meisten sind auch meiner Erfahrung nach zwischen Layer 2 und also nicht Layer, Level 2 und Level 3, was so zwischen Autocompletion und Augmentation ist. Weil das eigentliche Orchestrieren von mehreren Agenten und dann hinzu, so da wollen sie vielleicht hin. Ich glaube, die allerwenigsten haben noch gar nicht die Fantasie dieser Dark Factory, die haben sie noch gar nicht gesehen, die tasten sich so langsam vor. Aber ich glaube, viele Organisationen, ja, wo stehen die denn gerade? Wie siehst du das? Dann auch so zwischen Level 2 und Level 3?

SPEAKER_01 31:24

Die meisten ja. Ich würde aber eine Unterscheidung machen. Etabliertere Companies stehen irgendwo zwischen Level 2 und Level 3 und kommen eben noch aus dieser Welt, in der wir, ich höre mich jetzt an, die Opa, der vom Prick erzählt, also diese alte Welt, ja, aus der wir auch kommen. Und was ich aber zu meiner Freude feststelle, bei sehr, sehr jungen Companies mit, auch die von sehr jungen GründerInnen geführt werden, da sieht die Welt ein bisschen anders aus. Also da merke ich, dass das Mindset einfach ein anderes ist, ja. Zum Beispiel, ich habe mal vor zwei, drei Monaten habe ich einen jungen Gründer gefragt, wie seid ihr denn aufgestellt? Und dann erzählte der mal über die Engineers und dann habe ich gesagt, wo ist denn bei euch Produkt? Und die hatten eine gute Produkt-Organisation, sowas nicht, also einen guten Product-Prozess und die hatten auch ein gutes Produkt. Aber trotzdem hat er mich angeguckt wie ein Auto und sagt, so, ja, wie Produkt, die denken in diesen Kategorien nicht mehr, weil die einfach auch, die beschreiben ihr Produkt in Specks, die sie mit Cloud-Code generieren, oder mit Cloud generieren die Specks, die darum sind, wirklich die absolute Grundlage im Repository eingecheckt, um darauf Code zu generieren und das Ding zu bauen. Also die denken überhaupt nicht mehr so in, ich habe hier irgendwo ein Jira und ich habe irgendwelche whatever extra PRDs oder so, also wie viele, sagen wir mal, eher so mittelständische Firmen und etablierte ältere Companies noch arbeiten, so denken die gar nicht mehr, sondern die denken viel mehr in gemörgten Rollen, in anderen Identitäten, in schnelleren, viel kürzeren Prozessen. Und das finde ich ist schön zu sehen. Da würde ich sagen, sind die schon weiter, aber die haben natürlich den Vorteil, dass sie auf der grünen Visa anfangen und eine super kleine Organisation haben.

SPEAKER_00 33:18

Ja, ich habe auch vor drei Monaten mit einem Startup gesprochen und der CTO hat mir auch begeistert erzählt, dass jetzt seine Engineers eigentlich jetzt alle zu Engineering Managern geworden sind, weil sie schon, also die waren jetzt schon damals schon auf Level 4 unterwegs und haben halt sehr viel schon orchestriert und waren schon über die eigentliche Augmentierung hinaus. Und er war sehr begeistert davon. Und ich habe jetzt nach drei Monaten wieder mit ihm gesprochen und er sagt jetzt, sie rollen jetzt gerade wieder zurück, weil die Kosten sind so explodiert und die sind jetzt halt, also es ist auch das Thema Kostenkontrolle und Token-Ökonomie ist tatsächlich ein Riesenthema. Ich habe jetzt erst vor ein paar Tagen gelesen, also die Company um Facebook, gibt pro Monat über 220 Millionen Dollar für Tokens aus. Das sind über zwei Milliarden Dollar im Jahr. Ja, und ich glaube, die allerwenigsten machen sich gerade Gedanken um die Kostenkontrolle. Und da ist ein guter Hebel.

SPEAKER_01 34:06

Ist ein super starker Punkt. Das hat sich natürlich auch einfach jetzt im letzten halben Jahr extrem verändert. Einfach natürlich dadurch, dass die Token-Kosten nicht mehr subventioniert worden sind. Ich glaube, das wird vor allem einen Impact zweierlei haben. Auf der einen Seite, also ich meine, Meta ist immer ein schwieriges Beispiel, weil bei Meta natürlich auch das eine Metrik ist, auf die Leute inzentiviert sind, Tokens zu verbrennen. Das halte ich per se für komplett wahnsinnig. Aber gut, die können sich leisten. Ich glaube trotzdem grundsätzlich, also auf der einen Seite wird es halt immer mehr so Infrastrukturthemen und ob es Support-Themen geben, um Token-Kosten zu minimieren. Auf der anderen Seite wird es wahrscheinlich eben eine stärkere Hinwendung zu lokalen Models geben. Da bin ich sehr gespannt drauf, was da wirklich jetzt passieren wird. Ich sehe das ganz viel so im Kollegenkreis in den Anfängen, aber wir sehen dann doch letztendlich, wenn wir DDs machen, relativ wenig lokale Models as large im Einsatz, sondern da sehen wir dann doch wieder die etablierten Anbieter. Das zweite ist aber, was ich sehe, und da bin ich sehr gespannt drauf, wenn du, ich sage jetzt mal irgendeinen fiktiven Wert, wenn du pro Engineer durchschnittlich 100.000 Euro Token-Costs rechnen musst, oder 200.000, 300.000, ist egal. So, dann rentiert sich das eben nur, wenn du Engineers hast, die so gut sind, dass sie 10.20, 30 oder 100-fache Produktivität eines normalen Engineers haben. In dem Moment, wo du dieses Szenario hast, weil wenn du diesen hundertfach Engineer hast, dann lohnt sich das auch wieder, also Cashflow vorausgesetzt. Aber wenn die Rechnung passt, dann lohnt sich das für dich, dann ist das ein gutes Investment. Das heißt aber wiederum auch, dass du alle anderen freisetzen musst, um dir das überhaupt leisten zu können, und weil die alle anderen eigentlich überhaupt keinen Unterschied mehr in der Produktivität machen. Und das wird wahrscheinlich diese Freisetzungsspirale nochmal beschleunigen.

SPEAKER_00 36:15

Wie siehst du das gerade mit den Investoren, mit denen du sprichst? Wie stark pushen die ihre Organisation, in die sie investiert sind, hin zu AI First oder halt Level 4, einer oder vielleicht sogar Level 5, also Dark Factory. Ist der Push sehr stark oder ist das noch moderat? Wie sehr wird der Druck ausgeübt?

SPEAKER_01 36:39

Momentan ist er noch relativ moderat. Es gibt natürlich Ausnahmen, aber ich würde sagen, so across all ist es eher moderat, weil es nicht zielgerichtet ist. Die wenigsten wissen, ja, was müssen die Leute eben wirklich machen. Also das heißt, wenn ein CTO jetzt erzählt, ja, wir machen schon AI und wir machen dies und das, das ist wahnsinnig schwer, das zu challengen. Also das ist ja der Grund unter anderem, warum wir für Investoren diese Portfolio-Benchmarks anbieten. Also einerseits um den Investoren mehr Transparenz zu geben, aber auch um eben die Gründer in eine Situation zu versetzen, wo sie zum Beispiel dann sagen können, hey, wir sind innerhalb des Portfolios da und da oder innerhalb aller Assessed Startups da und da. Und gegebenenfalls auch innerhalb der Portfolios mal zu vernetzen und zu sagen, hey, die Company, die ist schon richtig weit. Vielleicht mag der CTO ja einfach mal erzählen, wie sie das geschafft haben. Wo wir das eher sehen, ist so im Private Equity Bereich oder auch Growth Equity-Bereich, wenn es um Produktstrategie geht und Produkte selbst. Weil wir wissen alle, es gab irgendwie so vor Monaten startete die große SARS-Panik am Markt, ja, dass jetzt SARS komplett tot sei. Das hat sich zu. Ja, aber das ist ganz interessant, weil es gibt gerade diesen Stretch. Auf der einen Seite gibt es da immer noch diese Panik, auf der anderen Seite hat sie sich bei vielen auch wieder so ein bisschen relativiert. Und aber nichtsdestotrotz, also Produkte in drei Jahren werden trotzdem komplett anders aussehen, als sie jetzt aussehen und mit anderen Usern interagieren, Stichwort Agenten. Und da, glaube ich, tut sich schon was, da ist gerade eine große Diskussion auch bei den Investoren am Markt. Und wir werden in jeder DD, egal in welcher Phase, auch letztendlich gefragt, was ist mit Defensibility? Ist die Idee, ist die in einem halben Jahr abgeräumt von AI oder wo ist da eigentlich Mode?

SPEAKER_00 38:40

Ja. Und jetzt kommt nur noch hinzu, dass viele Tech Leader so typischen FOMO haben, weil überall, also LinkedIn, Podcasts, wo auch immer, wird überall suggeriert. Alle anderen sind so viel weiter und ja, überall wird Panik geschnitten. Es entsteht keine Panik, aber tatsächlich so dieses: Oh mein Gott, alle anderen sind schon mir drei Schritte voraus. Und das kann ja unterschiedliche Reaktionen hervorrufen. Was ist denn so deine nüchterne Beobachtung, wenn du das, wenn du das wahrnimmst?

SPEAKER_01 39:11

Ich bin da auch ein bisschen gefangen von. Deswegen fällt es mir da schwer, nüchtern zu sein. Ich hatte, also im ersten Quartal hatte ich auch die Mega-FOMO und den kompletten AI-Wahn. Und ich persönlich, also ich habe da irgendwann so einen Podcast mit Andrew Capaz, Andrew Capazi gehört. Und als selbst dieser Typ in diesem Podcast sagte, dass er jeden Tag mit FOMO an seinen Arbeitsplatz geht, weil er denkt, so es passiert gerade so viel und ich kann es überhaupt nicht und I'm falling behind. Habe ich gedacht, so, ja, wenn Capazi dieses Gefühl hat, dann ist kein Wunder, dass alle anderen das auch haben, weil der ist, glaube ich, schon ziemlich vorne mit dran. Das hat meine eigene FOMO so ein bisschen relativiert auf der einen Seite, was so eine persönliche Psychological Safety angeht. Auf der anderen Seite, glaube ich, haben wir auch allen Grund, FOMO zu haben. Es ist, ich, also es ist, glaube ich, wahnsinnig schwer, gerade an den Themen dran zu bleiben. Einerseits als CTO selbst, ich meine, du, das habe ich auch gemerkt. Also, ich habe auch zeitweise 50% meiner Zeit auf diese Hands-on-Themen gelegt. Also, das kannst du halt auch nicht dauerhaft machen, wenn du ein Business hast oder einen anderen Job. Aber du brauchst, glaube ich, schon eine relevante Menge an Zeit, um wieder diese Tuchfühlung zu bekommen. Zum Beispiel, ich habe zehn Jahre lang hands-off gearbeitet, ich habe keinen Code mehr selber angefasst und ich bin wieder dahin zurück, weil ich gesagt habe, wenn ich das nicht habe, verliere ich meine Intuition, weil sich die Paradigmen ändern. Und deswegen habe ich wieder angefangen, um diese Intuition und diesen Grip zu behalten. Ich glaube, das ist so ein Minimum, was CTOs machen müssen.

SPEAKER_00 41:05

Nicht nur das, wenn ich da mal noch einhaken darf. Es geht ja nicht nur um Intuition, es geht auch, jetzt sitzen da Organisationen verschiedenster Größenordnungen und die brauchen Richtung. Und die Richtung muss ja irgendwie vorgegeben werden. Kein Senior-Engineer denkt in aller Regel über das große Ganze nach. Wie sieht denn der gesamte Software Development Lifecycle aus? Und wie kann ich denn und wo kann sich das Ganze hin entwickeln? Sondern die meisten gucken halt auf einen kleinen Ausschnitt der Realität. Und eigentlich ist es dann die Aufgabe des obersten Technologie-Verantwortlichen, das ist normalerweise der CTO, hier Richtung vorzugeben. Und in einer Zeit, wo sich so viel ändert, ja, wo soll denn die Richtung herkommen? Also das geht ja eigentlich nur durch der aktiven Auseinandersetzung mit dem Thema und zwar permanent, bis man, wir steuern ja gerade alle in eine Richtung, von der wir noch gar nicht wissen, wo sie denn enden wird. Wir haben alle eine Idee und dauernd passiert irgendwas, was unsere Thesen und Hypothesen auf den Prüfstand stellt. Und deswegen ist es, glaube ich, unumgänglich, nicht nur für die eigene, für die, für die Intuition, sondern auch für den Auftrag, den man hat, hier Richtungen mit vorzugeben und zu gestalten, hier wirklich ganz vorne mit dabei zu sein.

SPEAKER_01 42:14

Ja, absolut. Unterschreibe ich zu 100 Prozent. Ich glaube aber, das ist halt eine Aufgabe, die ein CTO nicht mehr alleine leisten kann, sondern tatsächlich brauchst du da Sparring in Form von dedizierten Rollen, die mit dir, also die dieses High-Level Thinking hinkriegen, die jetzt nicht komplett nur im Engineering-Rabbit-Hole sind, die aber trotzdem auch noch zusätzlich zu deiner Zeit wirklich viel, viel Zeit auf diesen Themen verbringen können.

SPEAKER_00 42:40

Ja. Und bevor wir nicht noch zu sehr in diesem Thema verharren, weil das super spannend ist, aber uns auch natürlich die Zeit davon läuft, wir wollten noch über das Thema sprechen, was auch dich als Unternehmer beschäftigt und du ganz oft siehst, nämlich wann ist etwas Investment ready, wann ist etwas verkaufsreif? So, was ist aus der CTO-Sicht der Unterschied dazwischen zwischen Investment ready und verkaufsreif? Also vielleicht fangen wir dann damit an. Und wieso beschäftigt sich das überhaupt aus dem beruflichen Kontext, diese Frage?

SPEAKER_01 43:09

Ja, Investment ready, also da würde ich jetzt so ganz groß mal den VC-Stempel drauf machen, weil sich damit, glaube ich, mehr Leute was drunter vorstellen können, was Investment Ready meint. Also wenn so ein klassischer, keine Ahnung, HV Capital oder Early Bird oder Capnamic in ein frühphasiges Startup, sagen wir mal in einer Series A oder sowas, investieren will oder vielleicht auch in der CTD. So, da wird viel noch in Vision und Potenzial investiert. Also gerade natürlich, wenn wir so über Pre-Seed-Seed reden, da geht es viel noch um Pläne und so erste Proofpoints, aber da geht es noch nicht wirklich um einen gefundenen Produkt Market Fit. Da gibt es auch ganz oft noch relativ junge Teams. Das heißt, da werden noch Anfängerfehler gemacht und ich würde sagen, die VC-Szene, die ist schon risikobereiter und da werden Anfängerfehler auch mal hier und da verziehen, wenn die nicht Business Critical sind. Und insgesamt, da ist einfach mehr Mut zur Lücke, wenn man es mal auf den Punkt bringt. Während, wenn du jetzt von Verkaufsready redest, dann redest du an Verkauf an einen strategischen Investor, was sehr oft irgendwie auch ein Corporate ist. Oder du redest an Verkauf an PE. Und da wird ganz klar auf sowas wie, was sind die Assets geguckt, ja, was ist der Track Record. So, da wird ein gewiss Reifegrad erwartet an Produkt, an Technik, an Leuten auch, an Leadership. Und diese Käufer sind in der Regel auch deutlich entweder risikoaverser im Kauf, in der Kaufentscheidungen, gerade bei Strategen, oder auch einfach deutlich aggressiver in puncto Personalentscheidungen, wenn es jetzt in einen bestimmten PE-Bereich geht. Die wollen da einfach ein Top-CTO in dem Moment drin haben.

SPEAKER_00 45:00

Wie verändert das die Fragen, die aktuell oder dann an den Tag gestellt werden, abhängig von der jeweiligen Konstellation? Oder sind die am Ende des Tages doch relativ ähnlich?

SPEAKER_01 45:10

Also die sind schon ähnlich, die haben schon Overlaps. Ich glaube, die Akzentuierung ist anders. Also im VC-Bereich ist es halt so, was müssen wir denn tun, damit es funktioniert? Also ein gewisser Teil wird schon erwartet, dass er funktioniert, aber es ist ganz viel auch so dieser Blick nach vorne. Was müssen wir tun, damit es funktioniert? Oder auch so der Blick auf die Skalierbarkeit, ja. Also Skalierbarkeit ist aus technischer Sicht ein ganz wichtiger Punkt. Kann das skalieren? Kann das vielleicht 50x, 100x oder was auch immer aushalten? Und wie kommt man da hin? Wenn wir jetzt irgendwie spätphasiger unterwegs sind, dann ist es eher so, funktioniert es schon, ja, und wo sind Potenziale, um es auch effizienter zu machen? Natürlich ist da auch irgendwie dann die Liste dabei mit Vorschlägen, die noch gefixt werden müssen und Sachen, die verbessert werden müssen oder die noch nicht funktionieren. Aber wie gesagt, der Akzent ist ein anderer. Und gerade bei so strategischen Käufern ist es häufig so, okay, funktioniert es und wie lange funktioniert es und können wir das jetzt noch risikofrei fünf Jahre neben unserer eigentlichen Plattform laufen lassen und passt es in unsere Gesamtlandschaft oder können wir es auf unsere Plattform migrieren? Das sind so typische Fragen, die eigentlich in einem strategischen Kontext kommen.

SPEAKER_00 46:23

Und die Mode-Frage, also die Frage nach dem Burggraben, die kommt heute fast immer, habe ich zumindest den Eindruck. Was ist denn ein glaubwürdiger technischer Mode oder Burggraben? Und was ist dann am Ende des Tages nur Storytelling? Wie unterscheidet man das?

SPEAKER_01 46:37

Ja, das ist schon ein Stück weit auch wirklich Einzelfallbetrachtung. Also weil was die Leute mal auf den ersten Blick annehmen, ist, dass in der Technologie der Mode sei oder in spezifischen Algorithmen der Mode sei. Und das ist eigentlich wirklich viel seltener der Fall, als die meisten denken. Ich meine, in Software ist sowieso kein Mode mehr. Also das Thema ist vorbei. Glaube ich nicht dran. Also du kannst fast alles irgendwie nachbauen und sehr, sehr schnell ja mittlerweile.

SPEAKER_00 47:09

Zumindest in SARS, es gibt ja immer noch Grenzen, also Cutting Edge, aber ja, okay.

SPEAKER_01 47:13

Ja, aber also die Software alleine, die macht es in der Regel nicht mehr. Daten ist ein anderes Thema, aber auch da musst du halt unterscheiden, sind das proprietäre Daten oder sind die allgemein zugänglich? Weil alles, was allgemein zugänglich ist, ist mittlerweile auch von LLMs aufgesogen worden und kommst du leicht dran, ist überhaupt kein Mode. Aber du hast manchmal Daten, die werden zum Beispiel wurden traditionell immer extrem teuer verkauft. Das heißt, die Leute haben die gehütet wie Chroniowählen und dadurch sind die einfach immer noch nicht öffentlich zugänglich. Oder nur Unternehmen hat 20, 30 Jahre lang eigene Daten gesammelt, ohne die in irgendeiner Weise zu scheren. Das ist ein wahnsinniger Datenschatz, eine Historie. Den kannst du auch nicht mal ebenso replizieren woanders. Eine andere Sache ist zum Beispiel die generelle Domain-Komplexität. Also wir hatten mal eine Company, die wir uns in einer DD angeguckt haben, die haben sowas mit Bodengesundheit gemacht. Und die haben auf der ganzen Welt Bodenproben entnommen und haben die dann analysiert und daraus jede Menge Daten produziert. So, aber letztendlich, deren Mode war ganz stark in diesem Akt, diese Bodenproben zu entnehmen und auch dem Wissen, welche Bodenproben sie wie, wo entnehmen müssen? Das ist jetzt überhaupt nicht Technik. Natürlich ist es in den Daten reflektiert und dadurch sind auch die Daten der Mode. Aber der eigentliche Mode liegt in der Beherrschung der Komplexität und dem Domainwissen darunter.

SPEAKER_00 48:50

Also wird Domainwissen also immer wichtiger und Software immer weniger wichtig. Das habe ich auch so wahrgenommen oder mitgenommen. Wie sollten denn die CTOs mit Technical Debt oder mit der fragilen Architektur in so einer Due Diligence denn umgehen, wenn du reinkommst, ohne also gerade wenn er weiß, naja, da gibt es halt irgendwie offene Baustellen, alles direkt ansprechen, alles offen ausbreiten oder macht es dann schon mal auch Sinn, das ein oder andere unter den Tisch zu kehren?

SPEAKER_01 49:19

Ich glaube grundsätzlich erstmal, also Technical Debt hat jeder. Also ich habe noch nie ein Unternehmen gesehen, das keinerlei Technical Debt hatte. Also dann stirbt man meistens auch in Schönheit. Und was ich gelernt habe, ist, dass du sehr oft, also wenn du jetzt wirklich auch von der, sagen wir mal, Verkäuferseite oder Startup-Seite schaust, hast du oft CTOs oder Techniker, die sehr skeptisch sind, die ihrem Produkt gegenüber sehr skeptisch eingestellt sind. Und das ist so das Erste, was ich CTOs raten würde, die jetzt under DD sind, das mal abzustellen und zu sagen, als erstes verändere ich meine eigene Perspektive, weil das Business funktioniert. Wenn das Business wächst, hat die Technik obviously einen Job gemacht, der dem Business dabei hilft, zu wachsen. Und da kann man sich erstmal schon mit einer gewissen breiten Brust auch dahin stellen und sich selber auch glauben, dass das grundsätzlich erstmal schon ganz okay ist, was man da gebaut hat. Und das ist so eine Haltung, das ist einfach eine mentale Haltung, mit der ich in eine Ddee reingehen würde, die dir erlaubt, sehr souverän zu sein. Und dann aber auch fairerweise zu sagen: Okay, das, was an technischen Schulden da ist, das stelle ich dar. Da bin ich, das versuche ich nicht zu verstecken, weil erfahrene Auditoren werden dann Grip dran kriegen. Die Leute, die vielleicht nicht so erfahren sind, kriegen vielleicht keinen Grip dran. Die spüren das aber trotzdem. Und was die dann machen, ist cover your ass und entscheiden sich sozusagen für die sehr defensive, eher negative Bewertung. Deswegen würde ich.

SPEAKER_00 50:55

Wann ist denn schlechte Technik ein Dealbreaker?

SPEAKER_01 50:57

Ein Dealbreaker ist schlechte Technik per se meistens nicht, sondern es kann zu einer Abwertung führen oder man sagt, es ist ein Risiko. Ein Dealbreaker ist es dann zum Beispiel, wenn die schlechte Technik dafür sorgt, dass man sehr langsam ist, dass ein Produkt sich vielleicht nicht schnell verändern kann, nicht schnell weiterentwickelt werden kann und man gleichzeitig in einem hochkompetitiven Environment ist. Das ist zum Beispiel ein potenzieller Dealbreaker, wenn einfach absehbar ist, die sind zu langsam für die Konkurrenz und die werden überholt werden, werden Marktanteile verlieren. Das wäre sowas. Und ansonsten, um nochmal den Bogen zurückzuschlagen, wenn du technische Schulden klar und transparent adressierst, du brauchst einen Plan nach vorne. Weil das ist immer die halbe Miete. Du kannst nicht sagen, ja, das ist alles scheiße und dann sagst du, ja, kümmern wir uns irgendwann mal drum, sondern du musst sagen, dieses Thema haben wir, wir haben das auf dem Radar und folgendes ist der Plan, machen wir eben Q4. Nur mal als Beispiel. Das ist ein ganz anderer Eindruck, als wenn du versuchst, deine technischen Schulden zu verstecken oder einfach nur relativ unstrukturiert offenlegst.

SPEAKER_00 52:05

Und wenn du, also bevor wir jetzt dann gleich zu den Rapid-Fire-Fragen kommen, dann vielleicht noch die große Abschlussfrage. Wenn du die vielen Organisationen vergleichst, in die du im Tagesgeschäft reinschaust, was machen denn die besten CTOs, was machen die anders als der Rest, als der Durchschnitt? In der DD, meinst du? Ja, allgemein in der DD, in der DD, ja, nicht in der DD, in ihrer Rolle als CTO in der Organisation. Ich meine, du hast einen Blick von außen in ganz viele, du guckst rein, du siehst eine Menge. Was machen denn die besten anders?

SPEAKER_01 52:36

Die besten CTOs sind extrem nah am Business und verstehen wirklich ihr Business in der Tiefe. Die sehen sich nicht als Gatekeeper, sondern die sehen sich als Konversationspartner ihrer Stakeholder und bieten denen Alternativen an. Die führen ihre EntwicklerInnen in einer Weise, dass sie wachstums- und leistungsorientiert sind. Und die messen sehr viele Dinge. Und mit diesen Daten gehen sie eigentlich in eine kontinuierliche Verbesserung rein. Ja, gut.

SPEAKER_00 53:14

Chris, wir sind dann auch eigentlich fast schon am Ende. Die Zeit, die Zeit, die Zeit, ne? Die geht so schnell vorbei. Gerade wenn man sich gut unterhält und über sehr interessante Themen spricht. Aber wir haben ja noch irgendwo fünf Rapid-Fire-Fragen, die ich auch gerne auch mit dir noch machen würde. Bist du bereit dafür? Leg los. Was ist denn die beste CTO-Eigenschaft, die in keiner Jobbestreibung steht? Resilienz. Ach, tatsächlich. Ja, stimmt. Guter Punkt. Was ist der größte Mythos über Tech Due Diligence?

SPEAKER_01 53:43

Auf Investorenseite sehr oft, dass man gar keine braucht.

SPEAKER_00 53:46

Ist das heute immer noch so?

SPEAKER_01 53:48

Ja, insbesondere bei so relativ einfachen Sachen wie SaaS Companies oder so. Da denken viele Leute so, ja, da braucht man keine, aber das ist in meinen Augen leider falsch.

SPEAKER_00 53:58

In meinen auch. Sehr gut. Aber danke, dass du mich da bestätigst. Was ist denn eine AI-Entwicklung, die du gerade ernst nimmst?

SPEAKER_01 54:05

Tatsächlich bin ich da eher so auf der politischen Seite unterwegs und gucke gerade so in Richtung Export Control und ähnlichen Sachen und was das gerade so auf Europa für Auswirkungen hat.

SPEAKER_00 54:18

Also dann eher, ob wo die Modelle sind und welche Modelle überhaupt genutzt werden, auch okay. Und wie groß unsere Abhängigkeit ist. Ja, absolut. Tatsächlich auch schon mit einigen Startups gearbeitet und die sehr großen Wert darauf legen, auf rein europäische Infrastruktur zu laufen. Und das bedeutet tatsächlich alles. Und hier einen sehr großen Fokus drauf legen. Ist vielleicht auch ein Trend, den wir in der nahen Zukunft noch öfter sehen werden. Ein Warnsignal, dass ein CTO nicht investment ready ist.

SPEAKER_01 54:50

Dass er oder sie den Zusammenhang zwischen der Technik und dem eigentlichen Business nicht versteht. Oder nicht gut genug versteht.

SPEAKER_00 55:00

Okay. Spiegelst du das dann auch dem Investor, wenn du das wahrnimmst?

unknown 55:04

Okay.

SPEAKER_00 55:04

Auf jeden Fall. Und letzte Frage für heute: einen Satz, den du angehenden CTOs mitgeben würdest.

SPEAKER_01 55:10

Gib den weiter, den mir ein Mentor mal gegeben hat. Und angeblich stammt der von Kent Beck, das habe ich aber nie verifiziert. Und der heißt: Wann willst du wissen, dass du ein Problem hast? So früh wie möglich.

SPEAKER_00 55:22

Ja, tatsächlich. Ein schöner Satz, ein weiser Satz zum Abschluss, Chris. Es hat mir sehr viel Spaß gemacht mit dir. Auch wenn wir das, das merkt der Zuschauer natürlich gar nicht, auch wenn wir zweimal noch zweimal starten mussten, weil einmal die Technik versagt hat. Wir haben das trotzdem in der Zeit gut gemeistert. Ich danke dir für deine ausführlichen Antworten und du warst ein super Gesprächspartner. Ich habe viel gelernt.

SPEAKER_01 55:43

Herzlichen Dank, Philipp. Herzlichen Dank.

SPEAKER_00 55:45

Mach's gut. Sehr gut. Mach's gut. Ciao, ciao.

SPEAKER_01 55:48

Ciao.