Dein CEO baut mit KI. Und du erklärst, warum das nicht geht.

0:01 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. Mein heutiger Gast ist Paul Lunow. Er ist der CTO of Digital Solutions bei Vention und der Co-Host und damit auch ein Podcaster hier von Product ⁇ Cake.

0:25 Er hat selbst gegründet, war bei EBay und der XU-Gruppe und arbeitet heute als Field CTO an der Schnittstelle zwischen Kunden, Technologie und Strategie. Wir sprechen darüber, wie er dorthin gekommen ist natürlich und was CTOs verändern müssen, wenn aus der Umsetzung fester Anforderungen das Erkunden neuer Möglichkeiten wird.

0:43 Da haben wir viel vor heute, Paul. Herzlich willkommen. Vielen Dank für die Einladung. Freut mich sehr hier zu sein. Ja, sehr gerne. Und du bist ja auch ein alter Podcast-Hase, haben wir ja festgestellt. Ich darf auch, glaube ich, bei euch bald nochmal im Podcast auftauchen, da freue ich mich auch sehr.

0:58 Aber heute wollen wir natürlich. Achso, du meinst, wenn du schlechter wegkommst, dann werden wir uns große Mühe geben, dich ins rechte Licht zu rücken. Paul, du hast schon als Schüler programmiert, habe ich mir sagen lassen, hast du mir gesagt und später eine Agentur gegründet mit rund 30 Leuten. Wann hast du denn gemerkt, dass das reine Programmieren, das gute Programmieren allein für deine neue Verantwortung nicht mehr ausreicht?

1:24 Ja, genau, lange ist es her. Ich bin über die Tech-Schiene reingestolpert und vor 20 Jahren noch in dem Umfeld angekommen, wo gesagt wurde, ach, Internet und Webseiten brauchen wir nicht so unbedingt. Und dann habe ich mit ein paar Freunden die Agentur gegründet, die eigentlich den coolen neuen Tech-Kram gemacht hat.

1:45 Und das hat großen Spaß gemacht und Programmieren hat dafür auch sehr lange gereicht und wir sind auch immer über unser Netzwerk sehr gut gewachsen. So richtig gemerkt, dass Programmieren alleine nicht alles ist, habe ich eigentlich, als ich bei Ebay angefangen habe. Als ich meine Schritte in einen Großkonzern gemacht habe und gemerkt habe, okay, du kannst dir die beste Arbeit leisten, aber ein ganz wichtiger Teil davon ist das Politik-Game.

2:18 Wie stellst du es dar? Wie sind deine Netzwerke? Mit wem redest du wann? Und ich habe auch gemerkt, dass ich darin nicht super versiert bin. Immer noch nicht? Man lernt mit seinen Aufgaben, man ist natürlich interessiert, man sucht sich Coaches und Leute, die sich gut auskennen, um zu verstehen, was vor sich geht.

2:37 Aber es ist immer noch nicht meine größte Freude. Weil ich glaube, wenn man eine Organisation baut und Teams hat, die mit Vertrauen ausgestattet sind und man Leute findet, die Bock haben, Sachen umzusetzen, dann macht das einfach am meisten Spaß. Und ja, Politik zu spielen, macht mir nicht so viel Spaß.

2:56 Ja, ist das auch die Erfahrung aus deiner Agenturzeit oder vielleicht auch so Product Startup und so weiter, die dann die Zeit, die, nee, du hast ja gerade gesagt, das war eher bei Ebay, als du dann diese Erkenntnis hattest, die dann deine Vorstellung aber auch von einem guten CTO verändert hat?

3:12 Ja, sehr, sehr einschneidend und das war nun sehr früh in der Agenturzeit, was ich gelernt habe, dass nicht alle Leute gleich gestrickt sind. Nur weil mir Politik keinen Spaß macht und ich halt in Aufgaben reinspringe und dann Bock habe, irgendwie eine Lösung zu finden, heißt es nicht, dass alle genauso denken.

3:27 Das war eine Erfahrung, die wir sehr früh im Agenturbusiness gemacht haben, so mit dem dritten, vierten Mitarbeiter, wo wir gesagt haben als Gründer, wir haben die Zeit unseres Lebens, wir können machen, was wir wollen. Da sind die Kunden, da sind die Probleme, mach einfach irgendwas, was dir Bock macht.

3:46 Und es tatsächlich Leute gibt, die sagen, ich finde es cool, hier zu arbeiten, ich finde es spannend, aber sag mir bitte konkret, was ich machen soll und dann kann ich das auch tun. Und wir waren als Gründer, junge, idealistische Gründer so, hä, was? Wir sollen dir sagen, was du tun sollst? Wir haben auch keine Ahnung, was du tun könntest.

4:02 Und das war eine wichtige Erkenntnis wohl bei der Erkenntnis davon und auch das dann runterzu oder beziehungsweise umzusetzen in konkrete Handlung, im Sinne von ich als CTO muss einen Rahmen geben und muss erkennen, wie sind die Leute gestrickt, was wollen sie gerne machen, welche Freiheiten kann ich ihnen geben, welche kann ich nicht geben, wie gestalte ich die Leitplanken und wie kriege ich das hin, dass alle in meinem Team dann da drin spielen, sich ausprobieren, neue Dinge lernen können, neue Dinge machen.

4:36 Das ist schon eine Kunst für sich und es hat ein bisschen gedauert, bis ich das so als System erkannt habe, was man auch aktiv gestalten kann.

4:44 Ja, da geht es ja um die Themen Autonomie und Alignment auch. Und das sind beides Themen. Da hat man, glaube ich, zu Anfang seiner Karriere noch eine recht naive Vorstellung davon, wie das funktioniert. Denkt man, aber ich sage jetzt allen, wir sind selbst organisiert oder ihr seid alle empowered und dann läuft es und dann stellt man aber fest, okay, dazu fehlt dann doch noch einiges.

5:03 Und wie hast du das denn wahrgenommen und wie hast du gelernt, dann dieses Game zu spielen?

5:08 Ja, dazu fehlt einiges und vor allem passiert es nicht, weil man es einmal gesagt hat, ein autonomes Team aufzubauen, ist schon eine sehr, sehr große Kunst und braucht Erfahrung und das richtige Umfeld. Weil du kannst nicht als CTO oder als Engineering Manager oder in welcher Position man in der Führungsebene auch immer ist, wenn man selber komplett eingeengt ist und super strikt geführt wird, kann man nicht unter sich auf einmal super autonome Teams haben, die völlig durchdrehen.

5:42 Und so zieht sich das einmal durch die gesamte Organisation durch. Und ich glaube, oder das hat für mich lange gedauert zu erkennen, dass das von der Geschäftsführung über die mittleren Führungsebenen bis zu den Teams muss es eine stringente Geschichte sein, einer stringenten Vision folgen, um dann den vollen Impact auch zu erzeugen.

6:04 Hast du oder nimmst du wahr, dass sich das in den letzten Jahren auch verändert hat, wie Unternehmen hier agieren? Sind sie wieder autoritärer und bestimmter und direktiver geworden in der Art, wie sie arbeiten? Oder sind sie immer noch sehr darauf fokussiert, ein hohes Level an Autonomie zu wahren, zur Verfügung zu stellen, zu ermöglichen?

6:24 Also in meiner Rolle habe ich ja jetzt die große Freude, in sehr viele verschiedene Unternehmen reingucken zu dürfen und mit sehr vielen verschiedenen Unternehmen arbeiten zu können. Und so viele Unternehmen, wie es gibt, so groß ist die Bandbreite auch. Ich sehe ganz viele kleine Teams, Founder-Teams, die alles nochmal umkrempeln können.

6:45 Da sind völlig neue Wege möglich und auch ein viel höherer Autonomiegrad. Aber es gibt immer noch so viele Teams, wo so strikt geführt wird. Und jetzt die KI auf einmal als Heilsbringer daherkommt und sagt, super, wir können jetzt alle deine Performance-Probleme lösen und es sich wie damals bei OKRs rausstellt, als allererstes machen die OKRs, genauso wie die KI, deine ganzen Schwierigkeiten super sichtbar.

7:15 Und dann brauchst du die richtige Organisationsstruktur, die das aushält und dazu die passende Lösung entwickeln kann.

7:21 Sehr, sehr richtig. Du hast dich, also ich habe dich hier angekündigt, auch als Field CTO. Jetzt bist du der erste Field CTO, den wir hier im Podcast haben. Vielleicht beschreibst du mal kurz, was ein Field CTO genau macht gegenüber einem normalen, ordinären, schnöden CTO.

7:40 Ich möchte jetzt hier keine Wertung reinbringen. Jeder CTO ist wichtig in seiner Rolle. Für mich der allergrößte Unterschied, nachdem ich die letzten 15 Jahre mehr oder weniger als Product-CTO gearbeitet habe, CTO-CPO, so in der Schnittstelle, wo es darum geht, ein Team auf eine Vision zu bringen, ein Produkt zu bauen und das kontinuierlich zu erweitern, ist diese Field-CTO-Rolle in dem Service-Sektor, in dem ich jetzt bin, sehr, sehr unterschiedlich.

8:13 Vention hat 3000 fest angestellte Entwicklerinnen und Entwickler. Die sind verteilt über unsere Entwicklungszentren in Osteuropa und Zentralasien. Und wir haben drei Field-CTOs, die regional aufgeteilt sind. Mein einer Kollege in UK, die andere in den USA und ich für den Continental Europe-Bereich. Und wir sind praktisch auf der einen Seite die strategische Entscheidungsinstanz als Team, wie müssen wir unser Unternehmen strategisch-technisch aufstellen, um den Marktanforderungen bestmöglich gerecht zu werden.

8:53 Das ist die strategische Seite. Und die praktische Seite ist, unsere Kunden darin zu unterstützen, wie sie das Beste aus unseren Services rausholen können und auch klassischerweise im Presales-Bereich zu verstehen, was wollen die Kunden überhaupt, wo sind die Erwartungen, welche technischen Lösungen können die erfüllen und wie matcht es auf unsere Angebote.

9:14 Jetzt kann man ja auch ketzerisch sagen, und es gibt ja auch Leute, die sagen das da draußen, dass ein Field-CTO wirklich nichts anderes macht als Pre-Sales, also eigentlich eine Sales-Rolle im Unternehmen hat. Wie gehst du damit um mit dem Label?

9:27 Ja, es gibt auch viele andere Bezeichnungen für die Rolle. Ich schätze mal, Forward Deployed Engineer oder AI Solution Architect, Field CTO. Alle spielen irgendwie so ein bisschen in eine ähnliche Richtung. Als ich den Vertrag unterschrieben habe, habe ich gesagt, SQL wird für mich immer Structured Query Language bedeuten und nicht wie bei all meinen Kollegen Sales Qualified Lead.

9:53 Also ich bin anders inzentiviert als allererstes. Ich bin jetzt nicht Sales Abschluss getrieben und ich habe die Connections in unsere Delivery-Einheiten und kann da tatsächlich auch technisch arbeiten. Das war meine Bedingung, weil ich will, ich bin einfach ein super schlechter Sales-Typ. Deswegen wollte ich kein Sales-Mensch werden.

10:14 Und ich schätze sehr wert, was wir für großartige Kollegen haben, aber man spürt schon, dass du anders tickst mit diesem technischen Background. Also von daher habe ich im Unternehmen selbst eine sehr klare Trennung davon und genieße die Rolle gerade sehr, weil es gibt wenig Positionen, wo man in hunderten Projekten weltweit gleichzeitig reingucken kann, wie KI eingesetzt wird.

10:39 Von daher bin ich eigentlich gerade ganz froh in der aktuellen Zeit, dass ich jetzt nicht ein Schnöder-CTO bin, der in ein Produktteam gehaftet ist, der ständig das Gefühl hat, verdammt, mein Team ist das Langsamste, während alle anderen total acceleraten gerade. Sondern ich kann in alle gleichzeitig reingucken.

10:57 Und kleiner Spoiler, alle haben gerade Probleme. Und die Lösung zu finden, macht Spaß.

11:03 Und es ist auch ein unfairer Vorteil, muss man sagen. Also ich bin ja in einer ähnlichen Rolle. Also ich bin kein viel CTO, aber dadurch durch meine Rolle und mein Tun bin ich auch permanent dabei, mit anderen Unternehmen zu sprechen, mit ihnen zusammenzuarbeiten, in sie reingucken zu dürfen. Und sehen natürlich auch dann ganz viele Muster.

11:18 Ich sehe, was alle, welche Probleme alle haben, womit sie sich auseinandersetzen. Und das gibt natürlich auch Möglichkeiten, sich anders aufzustellen, wenn man hier Trends besser erkennt und Muster besser erkennt? Also natürlich bei mir jetzt auf einem wesentlich kleineren Level als bei dir und Menschen, aber ich kann das auf jeden Fall nachvollziehen, dass diese Perspektive auch für die technische Urteilsfähigkeit natürlich nochmal ein enormer Boost ist, hier so viele Unternehmen quasi gleichzeitig kennenlernen zu dürfen und regelmäßig kennenlernen zu dürfen.

11:47 Gab es denn einen Moment in deiner Rolle, in dem du wirklich jetzt hier im Zwiespalt warst, zwischen technischem Urteil und attraktiver Auftrag?

11:57 Ja, sowas kommt schon hin und wieder vor, dass wir Kunden haben, die sagen, hey, wir brauchen ein Produkt für Problem XY. Wir hatten zum Beispiel einen großen Hersteller von technischen Geräten, die Weiterbildungsplattformen anbieten wollten für ihre Field Engineers. Die sollten einfach nachgucken können, die sollten Anleitungen abrufen und die sollten einen kleinen AI-Chat haben, wo alle Sales-Kollegen gesagt haben, ja, super, das können wir bauen from scratch.

12:27 Das ist ein schönes Zwölf-Monats-Projekt für all unsere AI-Enabled Engineers. Und ich aber gesagt habe, es macht keinen Sinn, die Anforderungen zu mappen eins zu eins zu 100 Lösungen, die es out of the box am Markt gibt. Und wenn wir das verkaufen als Custom-Build, dann haben wir vielleicht ein bisschen Umsatz gemacht, aber der Kunde hat am Ende viel zu viel gezahlt und ist unglücklich mit der Lösung, weil er noch viel mehr zahlen muss für die nächsten Iterationen darauf.

12:55 Also versuche ich möglichst frühzeitig zu erklären, lasst uns der langfristige Partner von diesem Kunden werden. Nehmen wir das Produkt, was es am Markt gibt, das die Anforderungen erfüllt und gucken wir dann, wie wir das einbetten in die technische Organisation. Weil auch mit KI haben wir mehr als genügend technische Herausforderungen und Benson versteht sich immer als der langfristige Partner für Unternehmen.

13:18 Und deshalb hatte ich da zum Glück auch leicht das Spiel meines Hellskollegen zu überzeugen, dass sie es gerne anbieten können, aber es hat wenig Aussicht auf Erfolg.

13:29 Du hast mir jetzt auch die perfekte Brücke gebaut, indem du KI gesagt hast. Natürlich, also ihr habt ja mit vielen Unternehmen zu tun, die kommen jetzt zu euch und sagen euch, na, wir wollen mit KI was machen. Wir wissen auch, dass wir mit KI Dinge verändern wollen, müssen, aber wir wissen nicht so ganz, wo wir anfangen sollen.

13:46 Wie gehst du denn damit um, gerade so in der Anfangszeit, wie holst du den Kunden ab? Oder potenziellen das Unternehmen, ja?

13:52 Ja, also wissen, wo wir anfangen sollen, sehe ich eigentlich immer seltener. Inzwischen benutzen alle irgendwie KI und sei es, dass sich alle ein privates Abo irgendwo geholt haben und auf ihrem privaten Rechner oder über den Firmenrechner halt anfangen, Copy-Paste Gewitter, KI irgendwie auch zu benutzen.

14:13 Die Shadow-IT hörst du wahrscheinlich auch sehr oft, dass wir die Nutzung sehen, aber es ist noch nicht in der Organisation integriert. Wie fangen wir da an? Es gibt immer zwei mögliche Wege, die wir sehen. Einmal KI-Integration ins Produkt, was Stakeholder wollen, was vielleicht Kunden wollen. Also wie stellt man es den Menschen zur Verfügung, die eigentlich das Produkt der Firma benutzen, und dann die KI-Integration in die Organisation selbst.

14:39 Wie kann man die Menschen, die im Unternehmen arbeiten, effektiver machen? Wir haben für Engineering-Teams sehr viele Services, die wir anbieten, im Rahmen von dem AI-First SDLC. Also, jetzt wird es schwer, das alles auf Deutsch nahtlos rauszubringen. Den KI zuerst Softwareentwicklungsprozess. Das hättest du auch auf Englisch sagen dürfen.

15:07 Okay. Okay, okay. Dann bleiben wir bei der schönen Dänglischsprache, die wir alle lieben. Also im AI-First SDLC haben wir ein Framework entwickelt, wo wir messen können, auf welcher Stufe das Team gerade steht und welche die nächsten sinnvollen Stufen sind. Da geht es in erster Linie um Spec-Driven Development, also wie kann man Anforderungen mit möglichst wenig manuellem Aufwand in Code gießen, damit die dann als Teil des Produktes evaluiert und getestet werden können und dann so die gesamte Produktentwicklung beschleunigt werden kann.

15:40 Das sind die, da sind wir inzwischen relativ standardisiert, wir haben sehr gut ausgebildete Leute, die haben das inzwischen schon sehr oft gemacht und das ist relativ einfach. Spannender ist es bei der Integration von KI in die gesamte Organisation und in Operations. Weil es ist ja jetzt nicht mehr so, dass nur noch wir als Tech-Nerds in irgendwie der Entwicklungsabteilung KI benutzen, sondern alle im ganzen Unternehmen machen sich darüber Gedanken.

16:05 Und die spannende technische Frage ist ja jetzt, wie kann ich als technische Führungsperson mein Unternehmen enablen, dass auf einmal alle Einheiten da drin untereinander kommunizieren, auf eine sinnvolle und sichere Art und Weise, die Mehrwertschaft und nicht auf eine Shadow IT und CEO-Prototypen, die jetzt zu Production deployed werden sollen, augenblicklich.

16:31 Hol uns mal kurz mit da, weil wie entsteht denn dann genau die Shadow IT?

16:35 Die Shadow IT würde ich sagen, in erster Linie entsteht durch LinkedIn und durch die Verheißungen der Medienapparate der Frontier Labs, die uns überdeutlich zeigen, dass wir in unserer Organisation viel, viel weiter sein sollten. Und dem vermeintlichen superschnellen Ergebnis, dass wenn man einmal eintippt, ich brauche jetzt eine neue Software, um meine Kontakte zu verwalten und man sie innerhalb von wenigen Augenblicken generiert hat und sich denkt, oh mein Gott, ich bin der neue Steve Jobs, guck, was ich gebaut habe.

17:09 Und dann zeigt man es irgendjemandem und der sagt, guck, ich habe genau das gleiche gebaut. Das ist die eine Seite. Und die andere, das dann mit Unternehmensdaten laufen zu lassen und auf einen Scale zu bringen, hat viele technische Fragen, die noch nicht einwandfrei so definiert sind, dass wir sie einfach abrufen können.

17:32 Es ist eine hochtechnisch komplexe, anspruchsvolle Aufgabe, was zu bauen, wo das sicher drin laufen kann.

17:38 Wie gehst du damit um, wenn das, wenn du Führungskräfte, also Tech-Führungskräfte erlebst in Unternehmen, die sich diese AI-Strategie nicht selbst zur Aufgabe machen? Und das vielleicht, also wir sind jetzt auf CTO-Level, es gibt ja auch andere Tech-Führungskräfte, die ja durchaus auch die Ambitionen haben können, an dem Thema zu arbeiten, ein CIO beispielsweise.

17:59 Was würdest du denn raten, was ist die beste Herangehensweise oder ist es wirklich von Unternehmen zu Unternehmen so unterschiedlich, wer das Thema ownen sollte? Oder hast du einen klaren Favoriten?

18:11 Ich tendiere sehr stark zur CPTO-Rolle. Ich glaube, Product und Tech irgendwo zusammenfließen zu lassen, ergibt sehr viel Sinn. Die Sicherheit, gerade bei uns in deutschen Unternehmen, muss auch nochmal von der juristischen Seite abgeklärt werden. Aber die erfolgreichsten Firmen sehe ich, wenn die beiden Rollen Hand in Hand arbeiten.

18:38 Der größte Schmerz entsteht, wenn der Head of IT oder der C AIO voll sehr hart von der Legal-Seite kommt und grundsätzlich eher sagt, wir können erstmal gar nichts machen, bis wir hier einzelne Freigaben erteilt haben für irgendwelche Softwareansätze, die jetzt schon veraltet sind. So das ist schwierig.

19:00 Wir müssen gerade in nicht so hart regulierten Unternehmen Wege finden, dass die beiden Rollen Hand in Hand arbeiten und vor allem den Rest des Unternehmens enablen und nicht zurückhalten. Weil dann haben wir die zweite Antwort auf deine Shadow-IT-Frage eigentlich, sobald die KI-Strategie des Unternehmens ist, wir sind super restriktiv und erlauben erstmal gar nichts, ist es der ultimative Treibstoff für die Shadow-IT, weil die Leute trotzdem Wege finden und es ausprobieren wollen.

19:29 Ich stelle mir das trotzdem unglaublich schwierig vor, gerade in großen Unternehmen, dass so hier die richtige Balance zu finden zwischen strukturiert ausrollen und überlegt ausrollen mit Strategie, aber nicht zu sehr jetzt nur mit der Legal- und Compliance-Schiene kommen. Aber ich trotzdem ist ja die Frage, welche Rollen sollen denn was genau damit machen?

19:47 Oder welche Modelle sind denn für welche Rollen und Aufgaben am besten geeignet? Was kosten die denn? Geben wir das jetzt alles raus? Also gerade je größer das Unternehmen, umso größer verselbstständigen sich dann auch die AI-Budgets und wachsen in die Höhe. Und auf der anderen Seite fangen dann wieder die Entlassungswellen an, zumindest mal in einigen Bereichen, die dann das halt quersubventionieren oder querfinanzieren, ihre AI-Tokenspend.

20:14 Wie kriegst du das mit oder was würdest du raten, wie man hier die richtige Balance findet zwischen schnell nach vorne gehen, aber gleichzeitig auch die Mannschaft mitnehmen?

20:24 Ja, große Herausforderung und definitiv gibt es dafür keine Lösung, die in zwei, drei, vier Wochen umgesetzt ist. Egal wer kommt und verspricht, wir können dieses eine Tool einführen, wir können diese eine Schulung machen und dann sind deine Probleme gelöst, das ist Quatsch. Es war noch nie leicht, eine Organisation aufzubauen, es war auch noch nie leicht, Engineering Culture in ein Team reinzubringen, was nachhaltig und zuverlässig funktioniert.

20:49 Und das Ganze wird jetzt durch KI noch viel, viel schwieriger. Es sind die drei klassischen Hebel, die man bedienen kann: Daten, Menschen und Prozesse. Dass man da gute Antworten kriegt, wie ziehen sich die durch das Unternehmen, wie managen wir das, wie viel Zeit haben die Leute, sich mit neuen Dingen zu auseinanderzusetzen?

21:13 Haben sie die Werkzeuge, haben sie die Prozesse, sind die Daten zur Verfügung? Wie messe ich das? Wo stehe ich gerade? Und wie komme ich auf die nächste Stufe? Was meine neue Lieblings-KPI in dem Zusammenhang ist, was ich jetzt immer öfters möchte, dass es eingebunden wird, ist zu tracken, wie oft Zugriff verweigert angezeigt wird.

21:35 Weil wenn du im Unternehmenskontext irgendwas tust und auf einmal kriegst du ein Screen, kriegst vom Kolleginnen den Link geschickt, klickst drauf und kriegst Access Denied Screen. Oder du gibst was in ein Chatbot ein und der sagt, ich kann auf die Daten nicht zugreifen. Dann heißt es ja entweder, du versuchst auf Daten zuzugreifen, auf die du wirklich nicht zugreifen darfst.

21:54 Das heißt, du hast deine Rolle nicht verstanden, oder dein AI-Bot versucht, in die falschen Eimer zu greifen. Oder das Sicherheitssystem in deiner Firma ist zu rigoros und die Leute wissen nicht genau, wie sie es benutzen können. So oder so landest du an einer Frustrationsschwelle, die insgesamt den Menschen vermittelt, nichts funktioniert hier, alles ist langsam, nichts ist erlaubt, ich kann meine Arbeit einfach nicht machen.

22:17 Ich mache lieber erstmal langsam oder ich mache erstmal gar nichts. Und wenn wir das messen und die Zahl runterbringen, dann müssen wir automatisch die Datenstruktur, die Datensicherheitskonzepte und die Prozesse verbessern.

22:32 Das ist aber eher jetzt eine Kennzahl, die wahrscheinlich für die Einführung von AI allgemeinem Unternehmen gilt und jetzt weniger eine Kennzahl, die für Engineering einen besonderen Stellenwert hat.

22:44 Genau, im Engineering-Bereich sehe ich es eher seltener. Die Menschen, die programmieren, wissen in der Regel, wie sie Git benutzen und wie das Rechte-Management da funktioniert. Das ist eher für die allgemeine Einführung der KI im Unternehmen.

22:56 Und wie siehst du, was siehst du im Engineering-Bereich für Kennzahlen, die jetzt relevanter werden, auch um zu zeigen, was für einen Impact das hat?

23:03 Im Engineering-Bereich fangen wir auch immer mit einem ganzen Set an KPIs an. In unserem Framework von dem AI-First SDLC. Ich mag am allermeisten eigentlich die Zeit, die es braucht von Product Requirement bis zu Deploy. Also die Full Cycle Time von Lead Time von einem neuen Feature. Weil letztendlich umfasst es alles oder es berührt alles und ist ein guter allgemeiner Gradmesser.

23:36 Wenn man dann da reingeht und sich fragt, warum ist die so hoch, dann ist es von Unternehmen zu Unternehmen und von Industrie zu Industrie sehr unterschiedlich, was die Gründe sind und wo die stellschrauben.

23:48 Ja, das war auch so einer meiner ersten Ansätze, in so Lead Time und Cycle-Time zu messen und sagt, die müssen ja dann zwangsläufig hochgehen, wenn der Durchsatz höher wird. Aber dann stellt man auch fest, dass Teams, die gerade noch vielleicht eher in Scrum-basierten Ansätzen unterwegs sind, die auf einmal natürlich in der Lage sind, viel größere und komplexere Storys in einem Sprint zu machen.

24:09 Und damit wird auch die Lead Time und Cycle-Time eigentlich nicht schneller. Also erstens, weil du dich sowieso in einem Scrum-Talk-Kontext bewegst, also innerhalb von diesen zwei Wochen bringst du dann die Sachen nur raus. Und dann wird eine Story halt umso größer, aber der Durchlauf ist auf einmal nicht schneller.

24:21 Du kriegst nur etwas Größeres durch. Und das musst du dann nochmal, keine Ahnung, zum Beispiel mit gegenüber Storypoints nochmal gleichziehen, um zu gucken, was denn der wahre Impact ist. Aber dass es auch durchaus sein kann. Und wir haben das auch in Startups gesehen oder in E-Commerce-Unternehmen gesehen, die wirklich Schwierigkeiten hatten, das nachzuweisen, die nämlich genau diesen Effekt hatten.

24:41 Und der Investor wollte zuerst nicht glauben, dass sie wirklich jetzt besser geworden sind, weil die Zahlen das einfach nicht hergegeben haben.

24:48 Ich meine, würdest du denn sagen, dass Scrum noch das Mittel der Wahl sind, um jetzt in dieser beschleunigten Welt Engineering-Teams zu steuern?

24:59 Ich glaube nicht. Also ich habe keine finale Meinung dazu, aber ich tendiere aktuell dazu, dass es nicht mehr zeitgemäß ist und es aus einer Zeit kommt, in der Engineering sehr viel mehr Koordinationsaufwand zwischen verschiedenen menschlichen Rollen benötigt hat. Also da gab es den Frontend-Engineer, den Backend Engineer, den Data Engineer, was auch immer.

25:18 Also die Rollenvielfalt war wesentlich größer und aktuell beginnt sich das sehr stark zu konsolidieren. Und damit halt bist du auch in der Lage, kleinere, zwei, drei-Mann-Teams, die halt komplett Produkt bauen können alleine. Und brauchst du da wirklich so ein Framework, das so, also Scrum, ich glaube nicht, dass Scrum so heavy ist, aber das ist selbst für diesen Ansatz, ist es halt Overhead.

25:39 Und dann nehme ich dann lieber was Leichtgewichtigeres. Also ich, aktuell ist das meine These, dass Scrum ganz massiv an Bedeutung verliert und das sehe ich auch in Unternehmen. Aber du wahrscheinlich ja auch.

25:50 Ich sehe es genauso. Ich war auch ehrlich gesagt noch nie ein großer Freund von Scrum, so viel Zeit in Planning-Poker-Sessions verbracht. Ich hatte immer Spaß daran, aber gut, egal. Ich hatte auch immer Spaß, aber immer nur am Anfang und dann werden irgendwann Sachen gepokert, wo man nicht ganz so tief involviert ist und dann diskutiert man und diskutiert und hat stundenlange Termine und das finde ich sehr, sehr schwierig.

26:18 Und ich glaube, das umzustellen und dann auch im Sinne der Kommunikation zu Stakeholdern auf eine kurze Lead-Time zu setzen, durch ein Framework wie Kanban zum Beispiel und auch da auch im Training des Teams darauf zu achten, dass die einzelnen Features möglichst klein geschnitten sind. Klar, man kann jetzt auf einmal riesige Features bauen, aber ich meine, das war auch schon immer unsere Aufgabe zu sagen, bau die Features in ihren kleineren Einheiten, damit wir genau diese Acceleration sehen und damit wir den Stakeholdern auch zeigen können, yo, du hast gestern nach Microsoft Login gefragt, guck, heute ist es da.

26:56 Ohne zu sagen, wir haben jetzt das ganze Login-Framework umgebaut. Das passiert im Hintergrund immer noch auch viel schneller, aber die Features, die sichtbar sind, nach außen, um den Stakeholdern zu zeigen, yo, wir im Engineering-Team haben auch gemerkt, dass es KI gibt und wir sind auch viel, viel schneller geworden, ist, glaube ich, extrem wichtig.

27:17 Weil was ich sehe an vielen Stellen, ist die Friction, dass wenn der CEO übers Wochenende einfach mal nebenbei eine neue Version des eigenen Produktes vibecodet und dann sagt, es sind alle Scheiße, die hier arbeiten und ich weiß nicht, was die machen, die liefern mir Buggy-Software und es dauert alles ewig, es ist schwierig.

27:35 Und das zeigt, also das rückt unser Engineering, unsere Engineering Craft nicht ins beste Licht. Und das ist mit unserer Aufgabe als CTO, dafür zu sorgen, dass die Stakeholder verstehen, was wir tun. Wir können uns nicht noch weniger jetzt hinter Technik verstecken.

27:52 Ja, das Traurige ist ja, dass beide Seiten ja irgendwo recht haben. Also der CEO hat recht, der auf einmal sagt, ja, ich code hier was in Lovable und bin halt so viel schneller, die, ich kriege hier Kunden auf meine Plattform, da ist Interesse da, ich kann prototypen und so weiter. Das funktioniert sogar, es ist schnell gebaut.

28:07 Und dann kommt der Engineer und sagt mir, es ist scheiße, was ich hier mache. Und dann gucke ich die, was die machen. Das ist halt heavy, das dauert lange, bis das fertig ist, das ist buggy, der Kunden sind nicht zufrieden. Aber das sind die Experten angeblich. So, was soll ich denn jetzt glauben? Und der Engineer guckt genauso einfach auf den Code und legt die Maßstäbe an aus den letzten 20 Jahren und sagt halt auch, naja, das kann ja so, oder wie kann das denn funktionieren?

28:31 Ich glaube, die Wahrheit liegt irgendwo dazwischen, aber wir müssen alle noch herausfinden, wie diese Wahrheit denn am besten funktioniert.

28:38 Und ich glaube, es ist unsere Aufgabe als Technik-Team, Lösungen zu finden, dass die vibe-gecodeten Produkte irgendwie den Weg in Production finden. Weil einfach nur zu sagen, nein, dein AI-Slot ist scheiße, nützt halt nichts, weil so scheiße ist es nicht. Und wir müssen rausfinden, wo die Stellschrauben sind oder die Sollbruchstellen, die kaputt gehen, wenn man es launcht.

29:06 Aber einfach nur zu sagen, nein, nein, du hast ja keine Ahnung, zieht nicht mehr. Richtig.

29:10 Und dass danach sagen, ja, dann baust du mal in Lovable und danach bauen wir es nochmal richtig, das führt ja auch zu nichts. Also du musst ja irgendwo den Prototypen nehmen und musst den dann in ein tragfähiges Produkt überführen können. Und ich sehe es auch so, ich glaube, wir sind nicht sehr weit davon entfernt, dass du diese Dinger wirklich sehr lange in Produktion fahren kannst.

29:28 Kannst du sie noch mit einer Million User in Produktion fahren? Wahrscheinlich nicht. Aber das wirst du mit der ersten Version deiner handgekrafteten Software wahrscheinlich auch nicht können. Also von daher, das muss man auch so ein bisschen in Relation ansetzen.

29:40 Und ich meine, vor allem auf die Frage, werden wir alle als Entwickler unsere Jobs verlieren, ist das ein wichtiger Teil der Antwort. Du baust jetzt vielleicht nicht mehr die User-Facing-Applikation, aber dafür zu sorgen, dass diese Applikation läuft und dass egal welches Model, welchen Code dir hingeneriert, du eine technische Infrastruktur hast, die das handelt, das ist mega kompliziert und technisch hoch, hoch anspruchsvoll.

30:05 Und das wird mehr und mehr unsere Aufgabe.

30:08 Ja, du hast doch im Vorgespräch, hast du mal beschrieben, dass ihr gerade, wo ihr gerade beim Thema Prototyping seid, dass ihr mehrere schnelle KI-Prototypen so gegeneinander testen könnt. So, wenn ihr das denn macht, wie entscheidet ihr dann im Anschluss daran, welcher Ansatz wirklich besser ist und was dann nur in der Demo gut funktioniert hat?

30:26 Genau, das kommt sehr stark auf die Kunden an. Manche Kunden können sich es leisten, mit A-B-Tests zu arbeiten, dass man die Hälfte der Leute auf den einen lässt, die andere Hälfte auf den anderen und dann kann man anhand der Usage Metrics bestimmen, welcher davon der bessere ist. Die meisten Kunden, muss man aber auch ehrlich sagen, haben nicht so viel Traffic, nicht so viel Zeit oder nicht so viel Geld, um das jetzt so super langsam und super product-driven auszurollen.

30:54 Also zu sagen, hey, wir bauen diese Prototypen, wir zeigen das ein paar internen und externen Stakeholdern und dann treffen wir die Entscheidung für einen, ist total fair. Man muss nicht das Playbook von Google und Meta verfolgen, wenn man noch nicht in der Größenordnung angekommen ist.

31:12 Dann aber mal noch ein bisschen konkreter, kannst du sagen, was muss denn so ein Produkt, so ein Prototype können oder welche Voraussetzungen muss er erfüllen, damit du ihn dem erlauben würdest, halt ja zuverlässig auch in Produktion zu laufen, gerade wenn dann mal die erste Phase vorbei ist und dann die nächste Welle 2 und 3 an Features noch dazugekommen ist.

31:32 Also vielleicht definieren wir dafür diesen Prototyp ein bisschen genauer, weil es gibt natürlich sehr, sehr viele unterschiedliche Arten von Prototypen. Viele Kunden kommen zu uns und sagen, wir brauchen jetzt eine Landingpage, wir brauchen das Minimum Viable Product für unsere Idee. Hier sind vielleicht auch schon ein paar lovable generierte Anwendungen, die man nehmen kann, und dann mit der Fachexpertise von UIUX-Designern, von Senior Engineers und Architects drauf zu gucken und zu entscheiden, was davon können wir so launchen und was braucht vielleicht noch ein technischer Unterbau, kommt dann sehr, sehr stark auf das konkrete Produkt an.

32:11 Wenn man sagt, es geht hier um ein Feature innerhalb von einer größeren Anwendung, dann ist es im Endeffekt immer die Entscheidung von dem Entwicklungsteam, zu sagen, wir können das so launchen oder nicht.

32:21 Ja, und wie gehst du dann, oder was macht das jetzt mit der Rolle des Entwicklers auf der anderen Seite? Wir haben jetzt gerade eben besprochen, wie jetzt Prototyping passiert, wie ihr das auch macht, dass man sowas auch relativ schnell in Produktion schieben kann, wenn die Rahmenbedingungen stimmen?

32:38 Was macht das denn mit dem Entwickler, der vorher einfach nur dafür da war, Anforderungen umzusetzen? Er war dafür da, den Code so zu schreiben, dass andere Menschen gut damit arbeiten konnten und den weiterentwickeln und warten konnten. So, und jetzt ändern sich diese Erwartungshaltungen, die ändern sich jetzt ganz maßgeblich.

32:57 Wohin denn aus deiner Sicht und was bedeutet das?

33:00 Die ändern sich, das ist völlig richtig. Ich denke, wir alle haben unsere Momente, wo wir das Gefühl haben, es ändert sich in eine Welt, wo die Computer einfach selbstständig den ganzen Kram machen. Die Änderung braucht aber Zeit. Und die Änderung braucht auch eine ganze Menge technische Steuerung. Also die romantische Vorstellung und auch viele, viele Stunden, die ich damit verbracht habe, im Flow zu sein und nur in meiner IDE und zu coden.

33:29 Und ich weiß, ich habe genau die Aufgabe, ich weiß jeden Teil dieser riesigen Anwendung, wie sie funktioniert. Alle Shortcuts sind perfekt gelegt. Ich bin einfach eine Eins mit dem Code. Ich fürchte, die Zeit ist vorbei. Und wer noch da drin steckt, muss Wege finden, rauszukommen, weil es wird nur noch sehr, sehr, sehr wenige Jobs geben, wo sowas gefordert ist.

33:55 Es entwickelt sich hin zu einem viel größeren Verständnis von den Anforderungen und von den Zusammenhängen. Wie ist die Anwendung aufgebaut? Womit macht die Firma Geld? Was habe ich jetzt konkret für einen Impact mit dieser Anwendung und wie kann ich dafür sorgen, dass andere Teile des Unternehmens möglichst effektiv und gut arbeiten können, sodass wir als Unternehmen gemeinsam mehr Wert schaffen, weil das bezahlt letztendlich unsere Jobs.

34:24 Vielleicht nochmal der Versuch, das Konkrete auf einen Engineer runterzubrechen, wäre zu sagen, wie orchestriere ich die Tools und wie stelle ich sicher, Antworten darauf zu haben, was gerade gut funktioniert und was nicht und was wir uns in unserem aktuellen Kontext leisten können. Weil wenn du KI-News siehst, kannst du jeden Tag neu deinen Stack aufbauen, ist aber vielleicht auch nicht super nachhaltig.

34:51 Ich glaube für Menschen oder auch gerade für Executives, die jetzt nicht den Tech-Hintergrund haben, ist es auch unwahrscheinlich schwierig zu unterscheiden, wo sind berechtigte technische Einwände und wo ist jemand, der eigentlich eher der Bedenkenträger ist, weil er an alten Gewohnheiten oder an seiner alten Identität festhalten will.

35:13 Fällt dir das relativ leicht, damit umzugehen, weil du den Tech Background hast oder merkst du auch, dass du da hin und wieder am Struggeln bist? Und wie gehst du damit um, wenn du mit anderen Executives sprichst, die keinen Teil Background haben?

35:24 Ich finde diese Beobachtung sehr schön zu sagen, dass alle glauben, dass alle anderen von KI ersetzt werden können. Nur die eigene Profession nicht, weil man da die ganzen Insights hat. Also der Product-Head, der sagt, ja, Engineers kann ich ersetzen, aber Product, ja, ist schon schwierig, wie es alles zusammenhängt.

35:43 Man muss schon wissen, wie die Frameworks funktionieren. Und der Engineer sagt, Product kann ich eigentlich komplett ersetzen. PRDs generiere ich hier einfach so on the fly. Aber Engineering, ja, ist kompliziert und Orchestration, bla bla bla. Das würde ich erstmal anerkennen. Und ich finde es auch sehr schön zu sehen, wie unterschiedliche Professionen die KI-Tools benutzen.

36:02 Wenn ich jetzt unseren Designern über die Schulter gucke, die generieren auch mit Claude neue Designs, aber die sehen ganz anders aus als der Kram, den ich mit meinem Tech-Background generiere. Der sieht so aus wie der ganze andere AI-Durchschnitt. Aber die machen neue coole Sachen, weil sie anders damit umgehen.

36:18 So, und ich glaube, als Executive musst du genau das verstehen, wertschätzen und Vertrauen aufbauen in dein Team, dass du Leute hast, die das sehen, die der Vision folgen und die verstehen, wo der eigene Einflussbereich ist. Leichter gesagt als getan, weil das Gefühl von alle AI sloppen nur so rum und ich bin der Einzige, der hier versucht, was nach vorne zu pushen, ist gerade bei Führungspersonen sehr weit verbreitet.

36:47 Aber Wege zu finden, wie man auf menschlicher Ebene connectet und wie man versteht, was eigentlich der Wert der Teams ist, das in den Gesamtkontext der Firma stellt und dann die Teams enablet, um wirklich Mehrwert zu schaffen, das ist die große Aufgabe.

37:00 Ja, ich frage mich auch, was sich da durchsetzen wird. Was ist denn der Wert der Teams dann noch, wenn heute du ein Team, was vorher mit sechs Leuten gestafft war, morgen mit drei Leuten laufen kann? So behältst du dann alle sechs und machst halt doppelten Output, aber wofür denn genau? Bist du auf einmal in der Lage, doppelt so viele Ideen umzusetzen?

37:24 Hast du doppelt so viele Ideen? Also Ideen haben wir viele, wir wissen seit AI, Ideen generieren ist super billig, Umsetzung und Execution ist immer noch teuer. Baust du dann noch mehr Kram? Oder ist dann vielleicht sogar, also ich bin jetzt mal ganz ketzerisch und sage, vielleicht ist der richtige Werk ja wirklich zu sagen, die Branche muss sich konsolidieren und das Konsolidieren heißt auch schrumpfen und vielleicht auf ein gesundes Maß zurückgehen, um dann nochmal zu gucken, wo wir wieder weiter wachsen können.

37:51 Aber das wollen, glaube ich, nur sehr wenige hören.

37:53 Ja, also ich finde diesen Spruch schön, die Deutschen sind die einzigen, die Angst haben, dass KI ihnen die Jobs wegnimmt und gleichzeitig Angst haben, dass sie keine Fachkräfte mehr finden. Also vielleicht levelt sich das ja auch aus in gewisser Weise. Erstmal den Anspruch als Führungsperson an sich selbst zu haben, dass man sagt, die Leute, die bei uns im Unternehmen arbeiten, die haben wir sehr sorgfältig gehiert, im Idealfall.

38:23 Die sind eingearbeitet und die können wir jetzt mit KI enablen, einfach viel mehr besseren Output zu generieren. Also können wir theoretisch erstmal mit den Leuten, die wir haben, viel, viel mehr erreichen, was ja der Wachstumslogik erstmal folgen würde. Ob sich das alles eins zu eins und in mehr Umsatz ummünzen lässt, da wage ich auch dran zu zweifeln.

38:50 Und da sehen wir auch schon viele Reports und viele Berichte, die sagen, jetzt haben wir so viel in KI investiert, aber der Revenue ist einfach gleich geblieben. Manche Teams sagen auch, unser Backlog ist einfach leer, wir haben alles gebaut, aber die Kunden wollen gar nicht alles, was wir gebaut haben.

39:07 Was ja im Prinzip das Bottleneck dieser ganzen Beschleunigungsgeschichte wieder verschiebt auf, was macht von Business-Seite-Sicht, was macht aus Business-Seite-Sicht, was ist aus Product-Seite der richtige nächste Schritt. Und was können wir von der Engineering-Seite so einbauen, dass es auch langfristig gut funktioniert.

39:28 Ich glaube, diese ganze Wachstumsgeschichte ist vielleicht eh mergwürdig, wenn man sich die planetaren Grenzen anguckt. Und ich kenne auch viele Firmen, die sagen, unser Ziel der Firma ist, dass wir alle, die hier arbeiten, kleines Team, 10, 20 Leute, dass wir einfach alle ein richtig gutes Einkommen haben und eine Runrate, die uns jetzt nicht Angst und Bang werden lässt, dass morgen alle die Lichter ausgehen.

39:54 Vielleicht ist das ein super schönes Bild für zukünftige Firmen, die einfach ein gutes Leben für die Leute, die da arbeiten, ermöglichen, ohne jetzt den Anspruch zu haben, das nächste Unicorn zu werden. Und mit dem Ansatz, glaube ich, haben wir mehr als genug Probleme, die gelöst werden müssen als Menschheit.

40:13 Ja, stimmt. Vielleicht kommen wir gerade so ein bisschen weg von dem Wunsch, dass jedes Unternehmen ein Unicorn auf einmal werden soll. Das war so der feuchte Traum, der noch bis, keine Ahnung, 2021, 2022 gegolten hat. Ich habe das Gefühl, da sind wir jetzt ein bisschen weg davon. Jetzt versuchen wir eher klein, schnell, agil und schnell rausfinden, wo uns das denn alles hinführt.

40:36 Aber wie ist es denn bei euch? Ich kann mir ja vorstellen, dass die Entwicklung oder auch die Veränderung auch für euch als Unternehmen nicht Halt macht, auch was Auftragslage vielleicht angeht, was Kundenwünsche angeht, was brauchen sie denn noch? Wie kannst du uns da ein paar Insights geben, wie da gerade die Situation ist?

40:53 Ja, definitiv. Also ich meine, die Veränderung im Markt sehen wir genauso. Wenn ich schon gibt es jetzt seit 20 Jahren, gegründet auch von einem Entwickler, der diesen ganzen Bedarf gesehen hat und der mit Sicherheit sehr goldene Zeiten in dieser Unicorn-Jagd hatte, wo es bei CTOs nur darum ging, wie groß ist dein Headcount.

41:17 Und Menschen Anrufe bekommen hat, wir brauchen morgen 100 Leute und wir gesagt haben, ja, hier bitteschön, da sind sie. Das war eine komplett andere Zeit, leider vor meiner Zeit. Jetzt sehen wir eine massive Änderung zu kleineren Teams, aber wir sehen auch die Masse an Anfragen extrem nach oben gehend.

41:36 Weil, wie vorhin schon gesagt, nicht mehr nur die Entwickler-Teams brauchen plötzlich Entwickler, sondern auch Marketing, Legal, Sales, Customer Support. Eigentlich alle Funktionen im Unternehmen brauchen jetzt Menschen, die sehr tiefes technisches Verständnis mitbringen, sowohl für die Business-Prozesse, was vor sich geht, als auch für die KI-Möglichkeiten und das beides zusammenbringt.

41:59 Das ist dann nicht mehr das 100-Personen-Team für einen Kunden, aber es sind halt 50 Kunden, die jeweils zwei Leute kriegen. Und da machen wir gerade intern auch eine super spannende Transformation durch, wo ich dankenswerterweise auch ein wichtiger Teil von sein kann. Weil wie bringst du jetzt Menschen bei, die jahrzehntelang darauf trainiert wurden, genau die Anforderungen zu befolgen, die einmal definiert wurden, weil die Entwicklung super teuer ist, hin zu Wir stehen hier und wir wollen irgendwie weg, aber wohin wissen wir auch nicht so genau.

42:30 Gib uns die Möglichkeiten aus deiner Erfahrung. Und da ist Menschen an einer sehr einmaligen Position, ich sage immer, wir geben dir eine Person, aber die kommt nicht mit der Erfahrung von einer, sondern von 3000. Weil die Schwierigkeiten sehen wir ja weltweit gleichzeitig. Und das versuchen wir zu kanalisieren und in die Menschen zu bringen.

42:50 Ja, ich finde es auch spannend. Also hast du eine, da du, dass das auch ein bisschen vor deiner Zeit war, hast du auch eine Haltung dazu oder eine Meinung zu der Zeit, als dann Unternehmen kamen und 100 Engineers geordert haben? Was das, wie blickst du darauf zurück?

43:08 Ich habe selber zu der Zeit eine Firma gegründet und Investorengeldern eingesammelt. 100 Entwickler waren es nicht ganz, aber wir hatten auch ein sehr schönes, großes Team und haben uns auch sehr mit uns selbst beschäftigt und gleichzeitig natürlich auch hervorragende Arbeit geleistet, das ist klar. Also von daher will ich die nicht verurteilen.

43:26 Ich glaube, es war eine Phase der Technologieentwicklung, die sich jetzt verändert. Und sehr viele Layoffs sind auch immer noch dadurch bedingt, würde ich sagen. Dass man einfach in Strukturen investiert hat, weil das Geld da war und man gesagt hat, ja, wir können uns das leisten, alles doppelt und dreifach zu machen.

43:50 Und wir wollen halt ganze Gebäude füllen mit unseren Leuten, weil das ist State of the Art. Die müssen halt abgebaut werden und das geht nicht von heute auf morgen.

43:59 Ich will das nicht mehr. Ich kann das auch nicht verurteilen, aber ich muss schon sagen, und ich habe auch sehr positive Erfahrungen gemacht, aber ich habe genauso gut erlebt, dass gerade diese ganz großen Unternehmen, die haben eine Zeit lang alles eingestellt, was nicht bei drei auf dem Baum war. Und wenn der, wenn der Hello World fehlerfrei schreiben konnte, dann war der auf einmal ein Engener.

44:16 Was dazu geführt hat, nicht selten, dass du, wenn du halt zwei, drei Teams gehiert hast, dann hast du irgendwie ein, zwei Leuchten da drin gehabt und der Rest war Füllmaterial, für den du mehr Geld bezahlt hast, wie wenn du sie selbst eingestellt hättest und da hast du noch Leute dabei, die hättest du es im eigenen Recruiting-Prozess nicht mal mit der Kneifzange angefasst.

44:34 Also es ist ja schon auch irgendwie ein Gesundschrumpfen von dieser Art von, wie wir jetzt etwas bauen wollen, weil das war natürlich an vielen Stellen nicht sonderlich substanziell gut. So, das ist jetzt natürlich ein bisschen ein Rant und natürlich ist das auch ein bisschen unfair und wahrscheinlich an vielen Stellen doch nicht die Realität, aber ich habe es nicht nur einmal gesehen, dass das der Fall war.

44:54 Und ich würde sagen, dieses Hello World, was die Leute geschrieben haben und was gerade so fehlerfrei gelaufen ist, haben sie ja alles zu GitHub hochgepusht. Und die ganzen KI-Modelle haben einmal GitHub runtergeladen und darauf trainiert. Also die Nachwehen von dieser ganzen Entwicklung, die stecken jetzt alle in deinem Clot-Code.

45:14 Ah, das kann gut sein. Aber willst du damit sagen, dass wir, dass wir nur auf Hello World-Niveau jetzt mittlerweile bauen können?

45:19 Nein, nein, überhaupt nicht. Die Ergebnisse sind absolut herausragend und die überschlagen sich jede Woche, keine Frage. Ich will nur sagen, dass der technische Sachverstand und das Interesse daran, was baue ich hier eigentlich, wie funktioniert meine Infrastruktur, was orchestriere ich hier zusammen, ist immer noch extrem wichtig.

45:40 Und als Unternehmen braucht man Leute, die darauf Bock haben. Und als Entwickler braucht man Kolleginnen und Kollegen, die darauf Bock haben, weil wir als Menschen sitzen zusammen, diskutieren darüber und finden krass coole Lösungen. Ich meine, in den Teams, die du gerade beschrieben hast, da gab es auch viele Menschen, die sind morgens gekommen und haben sich an die Kaffeemaschine gegangen und sind abends wieder gegangen, aber mit denen hast du halt auch nicht diskutiert, wie jetzt die nächste Architektur aussieht.

46:06 Richtig so. Bevor wir jetzt dann gleich zu den Rapid-Fire-Fragen kommen, habe ich noch eine Frage, die jetzt so auch bis in den Abschluss der Folge schön rund machen soll. Was soll denn ein CTO nach dieser Folge in den ersten oder in den nächsten 30 Tagen, was soll der denn ausprobieren? Und woran erkennt er, ob er danach weitermachen soll oder den Versuch beenden soll?

46:28 Das ist eine hervorragende Frage. Und um nicht damit zu antworten, kommt drauf an, was es für ein CTO ist, würde ich sagen, was man auf jeden Fall als CTO tun sollte, ist anzufangen zu meditieren. Zehn Minuten am Tag, sich einmal hinzusetzen und zu betrachten, was das Gehirn eigentlich gerade tut und wie es dem geht, and welche Gedanken the day hinterher ballern, ist schon extrem hilfreich, um mit dieser absolut durchgedrehten Welt zurechtzukommen.

47:09 Es ist nicht leicht, ich schaffe es nicht jeden Tag, ich würde es gerne, aber es klappt nicht immer, aber es hilft auf jeden Fall. Und es gibt den Raum, um seinem Team eine Sicherheit zu geben, dass wir irgendwie auch morgen noch einen Job haben. Und dass wir einen Weg finden, wie wir als Team weitermachen.

47:30 Oder im schlimmsten Fall, dass wir einen guten Weg finden, wenn wir uns jetzt kleiner schrumpfen müssen, wie wir das irgendwie menschenverträglich hinkriegen. Naja, und ich dachte mir, das 30 Tage mal zu versuchen und zu gucken, ob es irgendwas ändert, wäre auf jeden Fall ein sehr wertvolles Experiment.

47:48 Weißt du was? Ich habe nämlich eine ähnliche Empfehlung mal bekommen, das auch mal anzufangen und zu probieren. Ich würde das jetzt mal zum Anlass nehmen und das mal ausprobieren, weil mal gucken, was es in 30 Tagen macht.

48:02 Was mir geholfen hat, ich habe den Ura-Ring schon eine ganze Weile und du kannst so Unguided Meditation Sessions da drin machen. Dann machst du 10 Minuten und dann sollst du still sitzen und dann misst er die Körpertemperatur und den Herzschlag und die Atemfrequenz und so und kann davon nicht, also davon kannst du ableiten, ob du es schaffst, deinen Körper auch runterzufahren.

48:24 Und da ich immer Tech getrieben bin, hat es mir sehr geholfen, so ein bisschen technisches Feedback dazu zu kriegen. Bloß nicht um zu bewerten, ob dein Meditation-Session gut oder schlecht war. Das ist nicht die Idee. Aber um nochmal neutrale Insights zu kriegen.

48:40 Ja, ich verstehe trotzdem den Drang natürlich sehr gut. Ich habe auch diverse Variables, die ich da nutze. Kein URA, aber genau, ich würde wahrscheinlich das gleiche machen, da irgendwie zu gucken, welchen Impact hat das denn auf die Sachen, die man dann irgendwie misst. Also ich kann das sehr gut nachvollziehen.

48:55 Kommen wir zu den Rapid-Fire-Fragen. Fünf Stück habe ich mitgebracht und es ist beliebte Tradition, hier im Podcast am Schluss die kurz rauszuhauen und schöne, kurze, knackige Antworten zu kriegen. Bist du bereit? Ich bin bereit. Perfekt. Welche Fähigkeit wird bei angehenden CTOs am meisten unterschätzt?

49:15 Ich denke, die Fähigkeit, Context-Switch zu managen. Alle Entwickler.

49:20 Der wird immer krasser gerade.

49:22 Ja, der wird immer krasser. Entwickler wollen es alle vermeiden, das war auch lange Zeit unser Thema. Aber als CTO bist du der Master of Context-Switches. Und die sind viel schlimmer als von einem Tech-Projekt zum anderen, sondern von Budget-Diskussion über Presentations, Stakeholder Management zu nitty-gritty-Tech-Detail-Questions.

49:41 Ja, darüber können wir eine eigene Folge machen über das Thema. Ja, genau, glaube ich. Da gehen uns die Themen nicht so schnell aus. Welche alte Engineering-Regel hast du zuletzt bewusst verworfen?

49:51 Schweren Herzens, Clean Code. Eine ganze Weile habe ich gedacht, ey, komm, guck, was die KI generiert hat. Prompte sie besser. Es ist wichtig für die langfristige Nachhaltigkeit des Projekts. Aber ehrlich gesagt, die KI baut es halt auch einfach nochmal. Oder in Rust oder in TypeScript. Es ist ihr relativ egal, keiner beschwert sich.

50:13 Du könntest ja auch noch einen Skill noch dazu schalten und könnt sagen, hier ist das Clean Code, die Clean Code-Bibel macht das danach.

50:20 Genau, aber damit, wenn ich meine Tokens outmaxen will, dann auf jeden Fall. Ansonsten investiere ich die Zeit lieber darin, wie kann ich sicherstellen, dass der Kram, der generiert wurde, schnell und performant läuft und die Funktionalität erfüllt, die ich haben wollte, ursprünglich.

50:36 Ja, guter Punkt. Und ich nehme an, bei euch ist Token Maxing kein Qualitätskriterium.

50:42 Nein, ganz im Gegenteil. Wir sind natürlich super nachhaltig damit, weil im Endeffekt müssen es die Kunden bezahlen. Richtig.

50:49 Guter Punkt. Sehr schön. Bei welcher Aufgabe lässt du KI heute noch nicht alleine entscheiden?

50:54 Uh, sehr schöne Frage. Strategie und Decks. Als der ganze Kram neu kam, war ich so froh, bau mir die Vorstandsstrategie, nice nur zehn Minuten, ich lese einmal drüber, gehe ins Meeting, mach die Präsentation an und merke, okay, es ist einfach nur generischer Kram, den ich selbst nicht verstehe und der nichts mit unserem Unternehmen zu tun hat, der aber als ich gestern Nacht müde davor gesessen hat, sich mega gut angehört hat.

51:18 Also es selber zu schreiben und dann zu sagen, Claude, geh hin, du bist der Vorstandsvorsitzende oder die Geschäftsführerin, gib mir Feedback, was fehlt, gib mir die zehn kritischen Fragen. Brillant, Gold wert, aber wir müssen die Fähigkeit behalten, selber sowas aufzuschreiben.

51:36 Welche Erfahrung als Romanautor hilft dir beim Führen? Sehr schöne Frage. Jetzt haben wir natürlich auch völlig ohne Kontext ja gar nicht erklärt, warum du Romanautor bist. Also vielleicht kannst du dazu auch noch was sagen.

51:49 Ja, dann mache ich nochmal ganz kurz die Einführung hier. Mein Traum als Kind war es immer, Schriftsteller zu werden. Und dann habe ich mich gefragt, wohin mit den ganzen damaligen, traurigen Liebesgedichten, die meine Kumpels und ich zu Pubertätszeiten geschrieben haben. Und dann habe ich angefangen, eine Webseite zu bauen.

52:09 Dann meinen wir so ein kleiner Online-Literaturclub und waren auch relativ viele Leute. Es waren irgendwann 100 Autoren und tausende Texte, wir haben Lesungen gemacht und so. Aber es wollte keiner Geld dafür bezahlen, aber sehr wohl Geld dafür bezahlen, eine Website programmiert zu kriegen. So habe ich dann kurz 20 Jahre Abstecher in die Tech-Industrie gemacht.

52:27 Und letztes Jahr ist mein Debüt-Roman erschienen, ein Cyber-Roman über eine Programmiererin, die den Job ihrer Träume kriegt und dann feststellt, dass ziemlich fiese Sachen vor sich gehen. Ich hatte fertig geschrieben und dann kam ChatGPT raus, was auf erstaunliche Art und Weise die Romanhandlung vorausgenommen hat.

52:49 Gibt es jetzt als Buch zum Lesen oder als Hörbuch zum Hören bei Audible und Amazon, erschienen bei Peri Planeta und das Hörbuch bei der Lauscha Lounge, dem Hörspielstudio von Oliver Rohrbeck, der Stimme von Justus Jonas. Also, genau da ist so eine kleine Leidenschaft. Und letztendlich, was mir das bringt als CTO, ist das Storytelling.

53:13 So, auch wenn wir Tech-Menschen das vielleicht nicht gerne hören wollen, im Endeffekt erzählen wir die ganze Zeit eine Geschichte. Wir erzählen die Geschichte, wo stehen wir als Team, warum sind wir hier? Wo wollen wir hin? Was ist der Cliffhanger als nächstes? Und was ist das Happy End, auf das wir alle zusteuern?

53:29 Und das nochmal in einem eigenen Romankontext zu haben, wo man selber einfach alles entscheiden kann, ist wirklich großartig.

53:38 Jetzt darfst du aber noch sagen, ich glaube, du hast bei der schönen Erzählung über deine Roman hast du gar nicht erzählt, wie er heißt. Der Name ist Ria Ruh. Den werden wir auch natürlich noch in den Shownotes verlinken. Sehr schön. Vielen lieben Dank schon mal dafür. Aber dann letzte Frage für heute, Paul.

53:54 Welchen Satz würdest du deinem ersten CTO-Ich mitgeben?

53:58 Meinem ersten CTO-I würde ich sagen, mach mehr von dem, was funktioniert. Ich erinnere mich sehr, sehr gut daran, wie wir damals in der Agentur eine WordPress-Seite gebaut haben, dachten, das war ja einfach, sieht mega geil aus, kundesfröhlich, nice. Okay, welche Blocksysteme gibt es noch? Ich würde so gern zurückreisen und zu sagen, warte mal, Paul, bau mal 100 WordPress-Seiten, mach diesen Prozess besser, versteh, was du tust und skaliere das, anstatt ständig auf neue, spannende Sachen zu springen.

54:32 Aber ich weiß nicht, ob ich auf mich hören würde.

54:36 Das habe ich letztens auch die Frage jemandem anderen gestellt, einem anderen CTO, und er meinte, auch egal, was er seinen früheren Ich gesagt hätte, er hätte es wahrscheinlich ignoriert. Ist dann vielleicht auch ein ehrliches Statement zum Ende. Sehr schön. Paul, vielen lieben Dank. Danke für die Einblicke.

54:52 Wer mit dir über Produkt und Technologie weiter nachdenken möchte, der findet dich bei Product ⁇ Cake und auf deiner Webseite. Beides verlinken wir in den Shownotes. Und wer die eigene Rolle als CTO weiterentwickeln möchte, findet unsere Becoming CTO-Community auch über den Link in der Beschreibung. Paul, vielen lieben Dank.

55:10 Und das war eine super Folge. Ich glaube, das müssen wir bei Gelegenheit wiederholen.

55:14 Das wiederholen wir auf jeden Fall. Und wer mehr über dich herausfinden will, sollte jetzt sofort Product ⁇ Cake abonnieren, weil dann erscheint ja bald der Gegenbesuch in der Folge. Ah, habe ich mich qualifiziert, das ist ja schön. Du bist qualifiziert. Ich freue mich schon. Vielen Dank für die Einladung hier.

55:29 Hat großen Spaß gemacht. Danke dir. Mach's gut. Ciao, ciao.