# CTO Strategy: AI, Product Engineering, and Vision

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

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, eurem Lieblingspodcast rund um die CTO-Rolle.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community.
Und als CTO-Coach begleite ich Tag Leader auf dem Weg zu mehr Verantwortung, Klarheit und Wirkung.
Und in der Becoming CTO-Community treffen sich jede Woche CTOs und auch angehende Führungskräfte zum Austausch auf Augenhöhe.
Ihr kennt das, wer tiefer einsteigen will, der Link dazu ist in den Shownotes.
Und mein heutiger Gast freue ich mich ganz besonders drauf.
Das ist nämlich Stefan Schmidt.
Er hat über 20 Jahre Erfahrung in der Tech-Branche, drei Startups gegründet, CTO gewesen, Stationen unter anderem gehabt bei eBay, bei EmoScout.
Und heute begleitet er ebenso wie ich als CTO-Coach wachstumsstarke Startups, das ist auch ein schwieriges Wort, zwischen 5 und 100 Engineers.
Und wir sprechen heute über die vielleicht schwierigste Rolle im Unternehmen.
Wir sprechen auch über Visionen und Strategien unserer sicheren Zeiten, über Alignment als unterschätzten Hebel und natürlich auch darüber, warum AI nicht einfach nur bessere Code-Generierung ist.
Stefan, schön, dass du heute da bist.
Ja, Philipp, freut mich, dass ich hier sein darf.
Sehr gut.
Wir wollen doch mal mit deiner langen CTO-Reise anfangen.
Ich glaube, da hast du einiges zu erzählen.
Wir haben da ja mal recherchiert.
Du hast 1981 auf einem VC20 angefangen zu programmieren, heißt das.
Was hat dich damals wirklich fasziniert?
Technik oder war das dann retrospektiv gesehen sogar schon eher was wie Gestaltungsmacht und Gestaltungswille?
wollte programmieren, damit ich die Videospiele in meinem Kopf als Kind spielen konnte.
Und so kam ich da rein mit Programmieren als Werkzeug und habe mich da 40 Jahre getäuscht über meine Rolle und habe das letzte Jahr mit AI festgestellt, dass ich eigentlich Sachen machen will.
Mehr, ich programmiere gern, aber ich mache Sachen mehr als Programmieren.
Was machst du jetzt damit?
Mit den Sachen, also ich mache sehr viele...
Also ich habe mir zum Beispiel eine eigene Plattform gebaut für Coaching.
Ich nenne das immer seit letztem Jahr auch Application Audience of One.
Also ich schreibe mir die Software genauso, wie ich sie haben will.
Und ich mache sehr, sehr viele Tools.
Ab und an habe auch probiert, wieder in die Spielebranche zu kommen, bisher ohne Erfolg.
Also das, was mich vor 20 Jahren da hingebracht hat, dachte ich, jetzt mit AI kriege ich es vielleicht ja auch hin.
Sehr schön.
Du hast drei Startups gegründet.
Du bist CTO gewesen, warst bei Ebay, du warst bei ImmoScout.
Und wenn du jetzt auf diese Station schaust, wo hast du am meisten Überführung gelernt?
In den Startups habe ich sehr viel über Führung gelernt durch Fehler machen.
Das, was alles nicht funktioniert, wo ich mir Sachen beibringen musste, was funktioniert, durchaus probieren.
Ich glaube, strukturiert gelernt über Führung habe ich einerseits mal bei ImmoScout.
Da kam ich zum ersten Mal in so einen strukturierten Entwicklungsprozess für Führungskräfte.
Hatten dann eine super, super Trainerin.
Da habe ich sehr viel gelernt.
Und das zweite Mal bei eBay.
Einerseits dadurch, dass meine Chefin sich sehr viel Zeit für mich auch genommen hat, mich zu entwickeln.
Und andererseits sprangen da auch ein paar sehr gute...
Role Models rum, die ich bis heute eigentlich, wo ich manchmal im Kopf immer noch denke, was würde der und der oder die und die machen in der Situation.
Wer ist das?
Waren das andere Führungskräfte im Unternehmen oder waren das Peers, mit denen du zusammengearbeitet hast?
Also meine Chefin war damals COO, als ich eine Zeit lang bei der eBay-Tochter, als ich eine Zeit lang sozusagen nicht an den CEO reportet habe, nach der Übernahme, was ich dann...
auch durch mein energisches Wünschen geändert hat.
Und das andere war der damalige Deutschlandchef von eBay, Stefan Zoll, den ich für den unglaublich guten und professionellen Manager halte.
Was haben die denn so besonders gemacht, dass du sie als Role Model auserkoren hast?
Da kann ich vielleicht so ein bisschen so einzelne, also zwei einzelne Incidenten, also sehr groß im Ganzen, aber ich mache es an zwei Sachen fest.
Als eine war, da hatten wir lange, lange diskutiert über ein Thema und dachten, jetzt muss der CEO das entscheiden und sind zum CEO gegangen, lauter andere C-Levels.
Und dann hat der CEO gesagt, entscheidet ihr doch.
Ihr habt euch jetzt damit beschäftigt, entscheidet ihr das.
Und ich habe mit sehr, sehr vielen CEOs zusammengearbeitet, gerade auch Startup-CEOs.
Und ich kann mir keinen anderen vorstellen, der das so gemacht hätte.
Also der solche Entscheidungen...
es waren jetzt nicht unternehmenskritische Entscheidungen, aber der solche Entscheidungen so delegiert hätte.
Und da habe ich auch viel mitgenommen im Sinne von auch mehr Vertrauen an Mitarbeiter zu haben und auch Entscheidungen, wo ich sage, vielleicht würde ich die gerne treffen, aber gegebenenfalls die auch zu delegieren.
Also das war so der eine Moment neben vielen.
Und der andere Moment war, als meine damalige Chefin vorgesetzte, sich sehr viel Zeit genommen hat, mich zu trainieren in bestimmten Sachen.
Da ging es darum, wie präsentiert man im Board, wie präsentiert man an eBay-Board oder an Boardmember.
Und da musste ich nochmal ein bisschen einen Sprung nach vorne machen.
Der eBay-Anspruch ist intern sehr, sehr hoch, wie wahrscheinlich bei allen Tech-Konzernen, wenn man da was präsentiert.
Und da hat sich sehr viel Zeit genommen.
mich zu trainieren mit Feedback und mit Arbeiten, um auf diesen Level zu kommen.
Und das hatte ich eigentlich in der Form auch noch vorher noch nicht gesehen, dass sich jemand eine vorgesetzte Zeit nimmt, mich irgendwo hinzuentwickeln, sondern mehr war immer so, hier, mach mal.
Ja, das ist ja auch nicht, das ist auch sehr ungewöhnlich, denn normalerweise holen sich Führungskräfte, die Führungskräfte führen, ja Führungskräfte, die schon fertig sind, in Anführungszeichen, dann können sie eine bestimmte Erwartungshaltung formulieren und dann wird erwartet, dass entsprechend performt wird.
Die Rolle des Coaches oder des Trainers, desjenigen, der dem anderen genau zeigt, wie er jetzt was zu machen hat, das passiert auf der Ebene doch relativ selten.
Aber du hast jetzt auch eben nochmal den CEO erwähnt.
Hat das dann auch dazu geführt, dass du selber den Wunsch verspürt hast, okay, ich möchte vielleicht auch mal CEO werden, um ihm nachzueifern?
Oder war es dann eher, okay, ich nehme mir Aspekte aus seinem Führungspotpourri und füge sie meinem Führen als CTO hinzu?
Es war eine Zeit lang auch die Diskussion oder die Diskussion auch bei Ebay, ob ich nicht CEO werde irgendwann mal oder generell erstmal General Manager und so.
Ich habe aber dann für mich beschlossen, dass ich Techie bleibe.
Ich wollte dann doch nicht CEO werden.
Und von daher, aber es war mal eine Zeit lang in der Diskussion, war für mich auch karrieretechnisch, dachte ich, eine tolle Sache.
Aber nach auch...
Ebay muss man sagen, hat sehr, sehr viel Zeit in mich investiert.
Einige Male in den USA gewesen, High Potential Leadership Trainings gemacht und so weiter.
Aber habe dann mich entschlossen, CTO zu bleiben und bin dann als CTO in das Startup meiner Frau gegangen.
Schließt sich das denn immer aus?
Kannst du kein CEO sein und gleichzeitig Techie bleiben?
Ich glaube, Das ist ein Kulturthema.
Ich glaube, in Deutschland ist es schwierig.
Ich glaube, in den USA ist es kein Thema.
In den USA ist es sogar eher erwünscht.
Also wenn mich immer jemand fragt, was ist der große Unterschied zwischen Deutschland und Amerika, dann sage ich Zuckerberg ist ein Techie, Brin ist ein Techie, Sergej ist ein Techie, Jeff Bezos war ein Techie, Steve Jobs ist ein Techie.
Das heißt, in Amerika ist es anders, da ist es eher so, dass es erwartet wird, dass ein Tech-Konzern von einem Techie-Konzern geführt wird.
In Deutschland ist es eher verbreitet, dass, sage ich mal, jemand aus dem Marketing, Finance, Operations Bereich kommt, der dann vielleicht als CEO das Unternehmen führt.
Ja, spannend.
Und so, wenn du das erzählst, ja, dieser Betrachtungsweise, dass es auch ein Kulturthema ist, der kann ich durchaus was abgewinnen, beziehungsweise auch folgen.
Gab es denn einen Moment, an dem du gemerkt hast, du willst auch nicht mehr nur operativ CTO sein, sondern...
andere CTOs auf ihrer Reise begleiten?
Ja, der Moment war, meine Frau ihr Startup verkauft hat und wir 700 Kilometer durch Norwegen gelaufen sind.
Jeden Tag 20, 30 Kilometer.
Und meistens schweigend, um rauszufinden, was man denn eigentlich will.
Und ich habe mich da entschlossen, nicht nochmal CTO zu machen in dem Unternehmen, sondern CTO-Coach zu machen.
Erstens, ich habe sowieso sehr viel Zeit in meine Mitarbeiter investiert.
Ich fand das immer sehr produktiv und auch sehr wertvoll, auch für mich.
Einerseits im Coaching und andererseits hatte ich sehr viele schwierige Situationen.
Jeder sieht die Uhr, glaube ich, sehr viele schwierige Situationen.
Ich auch.
Gründer, die einen anschreien, nachts um zwei im Schlaft-T-Shirt, Videokonferenz, weil der Server nicht mehr hochkommt.
Viele sehr schwierige Situationen.
Und dann bleibt immer irgendwie was übrig.
Also ich kann was mit meinem Chef diskutieren und mit meinen Mitarbeitern oder mit Peers.
Aber es bleibt dann doch immer irgendetwas übrig, was ich mit keinem diskutieren kann.
Und aus den zwei Situationen heraus dachte ich, Ein CTO-Coach wäre schön.
Du warst aber trotzdem CTO in einem Startup-Segment unterwegs.
Und da hast du primär mit wahrscheinlich selber mit wachstumsstarken Startups gearbeitet.
Was ist denn so der häufigste strategische Denkfehler von CTOs in genau dieser Phase?
Ich würde meinen, der größte Denkfehler ist, die CTOs sind zu reaktiv.
Das heißt, sie machen, da kommt von Produkt, von Marketing, vom CEO, von allen möglichen, von den Entwicklern, von allen Seiten möchte jemand etwas und der CTO versucht, dem allen gerecht zu werden.
Er hat aber in der Regel in den wachsenden Unternehmen wird es immer mehr.
Das heißt, es kommen dann auch immer mehr Leute dazu, wenn man insbesondere vielleicht Experienced Executives oder Führungskräfte einstellt.
Die kommen alle mit eigenen Ideen, Vorstellungen, Wünschen und Zielen ins Unternehmen.
Das heißt, das, was auf den CTO einprasselt, wird immer mehr.
Und ich sage da auch immer zu meinen Kunden oder zu den CTOs, Der CTO ist eben halt eine wichtige Stelle.
Der Head of Marketing will was, der Head of Sales will was, der COO möchte was.
Alle bauen in irgendeiner Art und Weise halt auf dem CTO auf, dass das Engineering oder Tech etwas delivered.
Intern, extern, Anbindung oder, oder, oder.
Und das ist in der Form, glaube ich, für keinen anderen C-Level, vielleicht für den CFO oder so, aber in der Form nicht der Fall.
Und da fallen die...
CTOs dann in die Falle, dass sie sehr, sehr reaktiv werden.
Da hat ein SVP von Ebay mal zu mir gesagt, wenn du deinen Kalender nicht selber managst, managst einen anderen den Kalender für dich.
Und in diese Falle tappen sehr, sehr viele rein.
Die kommen aus einer Entwicklung.
Ich programmiere 30 Stunden die Woche und dann nimmt es immer mehr und mehr zu.
Und am Ende sind sie nicht mehr Herr ihrer Zeit und sind nicht in der Lage, einen Plan zu machen, eine Strategie zu fassen, eine Vision zu machen.
selber das Ganze voranzubringen, sondern sind eben sehr, sehr reaktiv.
Und wo kippt dann genau diese Rolle vom Lead Engineer, von demjenigen, der eigentlich noch selber sehr stark hands-on in die Entwicklung integriert war und das selber mit vorangetrieben hat, wo kippt das dann zum echten Organisationsarchitekten?
Das geht so nach und nach, finde ich, und das geht bei einem CTO relativ schnell, weil bei einem CTO ist es auch so, bei allen meinen Kunden, glaube ich, Die haben alle die größte Abteilung im Unternehmen.
Das heißt, der CTO hat bereits fünf Entwickler, nichts gegen Marketing, aber der Head of Marketing hat einen Mitarbeiter und der CTO hat fünf Entwickler.
Der CTO kommt als erstes an die Schwelle, wo er Mittelmanagement braucht, wo er Prozesse braucht, wo er viel mehr rekrutet als alle anderen.
Und das heißt, er kommt schnell zum Teamlead, schneller als andere im Unternehmen und schnell Manager of Managers.
Und da geht es eigentlich so schnell, dass einem nicht klar ist, wie groß die Veränderung eigentlich ist.
Und schwupp, plötzlich sitzt man in der Falle.
Ja, absolut.
Du hast das ja eben schon angesprochen, die Engineering-Abteilung, R&D ist...
Sehr oft dann die Value Creation Engine des Unternehmens und du hast auch beobachtet, dass viele CTOs sehr reaktiv sind.
Wie schafft denn ein CTO dann nicht zur reinen Delivery Engine am Ende des Tages zu werden, der nur noch für die Umsetzung der Strategie ist, die wiederum andere entscheiden, das Produktmanagement, Marketing, Sales und so weiter und der CTO am Ende des Tages nur derjenige ist, der mit seinen Teams abliefern muss.
Weil das ist ja im Endeffekt genau diese, dann ist man nur noch reaktiv unterwegs.
Und wie schaffen CTOs jetzt hier aus diesem Teufelskreis rauszukommen?
Ist das ein struktureller Fehler, der schon zu einem ganz anderen Zeitpunkt gemacht wird?
Oder liegt das auch am Typus des CTOs und desjenigen, der da in der Rolle ist?
Ich denke, ich kenne auch viele gute Produktmanagers.
Immer wenn ich irgendwas sage, ich habe nichts gegen Produkte, ich habe nichts gegen Marketing.
Klingt manchmal so, ist aber nicht so.
Ich glaube, der Fork in the Road war einfach mit Agile, dass zum gleichen Zeitpunkt das Thema Produktmanagement aufkam und das Thema PO aufkam und dann auch auf natürliche Art und Weise, sonderbarerweise, aber irgendwie hat sich da keiner Gedanken gemacht, die PO-Rolle und die PM-Rolle zusammen.
gefallen ist, obwohl, glaube ich, nirgends bei Scrum oder sonst wo steht, dass das ein PM sein muss, der der Product Owner ist.
Kann jeder sein.
Der CTO könnte der Product Owner sein, aber ist er nicht und der Lead Engineer ist es auch nicht, sondern in der Regel ist der PM der Product Owner.
Und da gibt es so einen Fork in the Road, wo sich das so ein bisschen getrennt hat zwischen die einen denken sich was aus und die anderen bauen es.
Und das hat aber den Engineers und dem CTO, glaube ich, aus 20 Jahren sehr gut gefallen.
weil das Bauen halt das Tolle auch ist und dann brauchen Sie sich auch nicht mit dem Kunden beschäftigen oder keine bestimmten Gedanken machen und kann sich mit seinem Code beschäftigen und darüber nachdenken, welche Datenbank man verwendet und wie man bestimmte Sachen architektiert und so.
Und dieser Weg führte in perfekte Execution Engines und in einen Execution Mindset, aus dem es jetzt eben sehr schwierig rauszukommen.
Und mit AI, glaube ich, ist es ultra wichtig, aus dieser Ecke rauszukommen, in die man sich da 20 Jahre reingemalt hat.
Das ist interessant, weil am Ende des Tages bedeutet das ja auch, dass der Engineer ja selber schuld ist, dass er nicht mehr für Produkt verantwortlich ist, weil er es selber maßgeblich mit vorangetrieben hat.
Wenn du mal guckst, Agile und Scrum ist ja maßgeblich auch eine Bewegung, die von Engineers und Engineering-Teams mit vorangetrieben wurde.
die jetzt dazu führen, dass sie im Endeffekt eine reine Abarbeitungsmaschine geworden sind.
Das bestätigst du ja auch damit.
Ja, so würde ich sehen.
Und AI ändert das jetzt.
Und AI ändert das jetzt, sagst du.
Ja, also ich komme aus den 80er Jahren, ja, ich bin so alt.
Also Kind, ich komme aus den 70ern, aber aus den 80ern.
Und da waren, da ist halt so ein bisschen, da war schon der erste Fork in the Road natürlich.
Wenn man sich anguckt, Lotus 1, 2, 3, eine der ersten Tabellenkalkulationen, Word Prefect, Word Prefect ist jemand anderes, Word Perfect, wurde von einzelnen Leuten gemacht.
Das heißt, da war einer da, der hat dieses Produkt gebaut, von vorne bis hinten.
Und dann hat man gesagt, okay, jetzt brauche ich einen zweiten Engineer vielleicht, dann kommt Marketing dazu und so weiter.
Das heißt, eigentlich hatten wir in den 80er Jahren Das, was ich heute Product Engineer nenne, hatten wir in den 80er Jahren.
Und dann gab es da eben diverse Forks und mit dem letzten war dieser PM-Fork.
Und mit AI ist es eben so, dass, ich rede immer wieder mit Produktmanagern, die sich halt dann selber an die AI setzen und Dinge machen, weil dann die...
AI halt die Execution Engine ist und nicht mehr das Tech-Department.
Und deswegen sollten alle CTOs gucken, wie sie da aus dieser Ecke kommen, meiner Meinung nach.
Ja, das ist spannend.
Es können jetzt zwei Dinge passieren.
Es kann ja passieren, dass der ursprüngliche Techie, der vorher auch Product-Owner und Product-Manager in einem war, dass das wieder genau sich in diese Richtung entwickelt, durch AI-Tools, durch Vibe-Coding.
Es kann aber genauso gut sein, dass diese der Begriff des Citizen Engineers immer weitergetragen wird, dass jeder, der eigentlich gar keine Engineering-Erfahrung wird, auf einmal damit zum Engineer wird.
Was davon ist denn jetzt wahr?
Oder ist beides wahr?
Ich weiß nicht, ob Engineers zuhören.
Ich will ja nicht, die Engineers für alles zu verschrecken.
Ich will ja nicht, dass sie verschreckt sind alle.
Ich will ja niemandem Angst machen.
Ich will ja Leuten Hoffnung machen.
Aber ich glaube, das, was du sagst, sehe ich sehr ähnlich.
Und ich glaube, und ich sehe das auch bei meinen Kunden, eben den Move zu Product Engineer.
Das heißt, jemand, der sowohl teilweise Product Sachen macht, bestimmte Product Entscheidungen trifft, mit der AI arbeitet und engineerntechnisch dafür sorgt, dass die AI keinen Quatsch macht.
Durch welche Guardrails auch immer.
Und durch Special Prompting.
Und ich glaube, dass die nächsten Jahre, sagen wir mal die nächsten fünf Jahre, der Engineer im Vorteil ist.
Ich habe letztens ein Tool für mich programmiert.
Also AI hat es gemacht, aber ich sage mal, wenn ich programmiert zur Zeit, dann war es nicht ich, sondern die AI.
Aber ich habe ein Tool programmiert, das mit Markdown-Folien umgehen kann und da bestimmte Sachen machen kann.
Und da wollte ich ein anderes Format unterstützen und habe dann zur AI gesagt, zieh mal da einen Abstraction-Layer ein als erstes und dann bauen wir da weitere Backend-Engine rein.
Und das hat ziemlich gut funktioniert.
Aber das hatte, glaube ich, auch damit zu tun, weil ich halt ein Engineer bin.
Ich weiß, wie man da hinkommt, damit es hinterher auch funktioniert.
Deswegen glaube ich, aktuell sind Engineers im Vorteil, in der Bedienung von AIs, um Production-Ready-Code zu erzeugen.
Ich fürchte nur, dieses Window of Opportunity, ich nehme zu viel Englisch, ich bin eigentlich sehr froh, einen deutschen Podcast zu machen.
Du darfst gerne Englisch verwenden, ich meine, das ist halt so in unserer Branche.
Ich finde es sehr angenehm.
Production-Ready-Code zu machen, Produktionsfähigen Code zu machen.
Aber dieses Fenster, glaube ich, schließt sich immer mehr, je besser AIs werden.
Das heißt, jetzt hat der Engineer einen großen Vorteil, da nach vorne zu springen und sich zu positionieren.
Ich glaube, dass der Vorteil in fünf Jahren nicht mehr so groß ist.
Wie sieht diese Positionierung dann aus?
Was hast du da für eine Idee?
Oder sind wir da auch wieder an dem Punkt, wo wir sagen, alles unklar ist, können wir ja gerade alle nicht antizipieren.
Es ist unklar.
Es ist vielleicht sogar Singularity.
Bin ich mir auch nicht ganz sicher.
Fand ich bis Ende letzten Jahres ein spannendes Konzept.
Bin mir nicht mehr sicher, ob das nur ein Konzept ist.
Aber ich würde einfach mehr Ownership als Engineer, mehr Ownership übernehmen.
AI, also Nuarmen, annehmen, gucken, was es geht.
Es steckt auch sehr, sehr viel Craftmanship drin.
Das ist das, was ich auch mit meinen Kunden mache, wenn ich Workshops oder Trainings mache.
Es ist halt viel Craftmanship.
Wie prompte ich, wie mache ich Agents, wie kriege ich Agents dazu, zusammenzuarbeiten, wie mache ich Guardrails, wie mache ich Verification.
Alle diese Sachen sind Craftmanship, die man machen üben muss und die man machen muss, damit man besser wird.
Und das ist das, was ich alles machen würde und gucken, was kann ich an Produktthemen mit übernehmen, damit ich letztlich Ziel, jemand sagt mir, mach das und ich mache dann als One-Man-Show.
die relevanten Produktsachen und den Code und am Ende kommt produktionsfähiger Code raus.
So, jetzt können wir natürlich sagen, der klassische Technik-CTO in Startups, der war vielleicht schon seit längerer Zeit im Auslaufmodell, aber der ist dabei jetzt komplett auszusterben.
Ist es das, worauf es dann auch hinausläuft?
Ich glaube in der Breite ja.
Also wenn du jetzt, es gibt natürlich immer Ich sage jetzt mal, wenn du CTO bei SpaceX bist, ich weiß noch nicht mal, wer das jetzt ist, aber wenn du CTO bei SpaceX bist und wirklich Hardcore-Tech-Sachen machst, dann ist es wahrscheinlich alles nicht relevant aktuell in der Diskussion.
AI ist relevant, aber sicherlich nicht in der Diskussion.
Das würde ich aber mal auf eine Seite des Spektrums nehmen.
Wenn aber jemand CTO ist in einem Unternehmen, was praktisch ein Webfrontend für eine Datenbank ist, dann geht das, haben wir das ja in der Vergangenheit schon gesehen, dann glaube ich, wird es noch weiter transformativ sein im Sinne von Tech-CTO.
Viele CTOs, die leiden unter Business.
unter fehlender Business und auch fehlender Produktstrategie.
Und ich denke, die Vielzahl an AI-Tools und auch die Erwartungshaltung von, ja, macht mal irgendwas mit AI, die verstärkt das Ganze eher noch.
Wie soll denn...
Tech in Zukunft geplant werden, wie soll ein CTO Tech planen, wenn die Firma selbst keine Klarheit hat?
Wie gehst du damit um?
In deiner Rolle als CTO, aber auch mit deinen Kunden?
Weil diese Herausforderung, die erlebe ich sehr häufig, auch wenn ich mit meinen Kunden dann spreche, dass eine große Erwartungshaltung da ist und der eigentlich gar nicht gerecht gewährt werden kann und Leute auch in FOMO-Situationen dann sind.
Und auf einmal gar nicht mehr wissen, naja, es gibt jetzt halt das und jetzt morgen kann ich wieder das bauen und danach muss ich das ausprobieren und auf einmal sich in so einer Todeschleife da befinden und gar nicht mehr rauskommen.
Ja, also ich würde sagen, ich stimme dir voll zu, ich würde sagen, das Thema wird durch AI sicherlich schlimmer, aber sehe ich seit Jahren ein großer Punkt.
wo es überall hapert, ist aus meiner Sicht ein Mangel der Vision und ein Mangel der Strategie im Unternehmen, im Startup.
Das liegt oft daran, ich habe sehr, sehr viel darüber nachgedacht, über Vision und Strategie und mit vielen Leuten darüber gesprochen.
Aus meiner Sicht liegt es daran, dass die Leute Produktidee mit Vision verwechseln.
Das heißt, die Leute haben ein Startup und ihre Vision ist der Launch eines Produkts.
Und dann wird es gelauncht nach einem halben Jahr und dann ist die Vision erreicht.
Und dann ist die Vision Ende der Fahnenstange.
Und dann geht es nirgends mehr hin.
Dann ist der einzige Fortschritt wachsen.
Aber das Wachsen ist keine Vision.
Das heißt, der Kardinalsfehler ist zu glauben, meine Produktidee ist eine Vision.
Eine Idee kann eine Produktvision sein, aber keine Businessvision.
Eine Businessvision ist, wenn ein Produkt in der Businessvision vorkommt oder du als Firma in der Vision vorkommst, ist es schon nicht gut.
Und das war schon immer.
Bei vielen meiner Kunden schon.
Und jetzt bei AI wird es nochmal schwieriger.
Was würde ich machen als CTO?
Erstmal würde ich aktiver werden.
Also man kann Nein sagen zu komischen Features, an die man nicht glaubt.
In der Hinsicht nehmen auch aus meiner Sicht CTOs nicht genug ihre Executive-Rolle wahr.
Und zu sagen, da glaube ich nicht dran, das bauen wir nicht.
Das wäre das Erste.
Das Zweite ist, Sich wirklich zu überlegen, was ist denn meine Tech-Vision?
Wo geht es hin?
Und natürlich ist es schwierig, wenn es keine Business-Vision gibt.
Wenn es eine unklare Zukunft gibt, ist es schwierig, was zu machen.
Trotzdem würde ich eine formulieren, wo ich hin will und wie ich als CTO AI sehe.
Also das sind die zwei Sachen, die ich auf jeden Fall machen würde.
Also aktiver werden, sowohl wo ich glaube, dass es hingeht, weil es auch meine Mitarbeiternsicherheit gibt.
Noch ein kurzer Anhänger vielleicht dazu.
Aus meiner Sicht gibt es eine Engineering-Krise.
Das heißt, der Engineer befindet sich aktuell aus meiner Sicht in einer Krise.
Der eine mehr, der andere weniger.
Weil er nicht weiß, wo es hingeht.
Er weiß nicht, ob er in zwei Jahren noch 120.000 Euro verdient.
Es ist unklar.
Und in einer Krise ist es wichtig, aus meiner Sicht, den Leuten, seinen Mitarbeitern, eine Vision zu präsentieren, an die man glaubt, die glaubhaft ist und die einen Weg aus dieser Krise in eine goldene Zukunft zeigt.
Und daran würde ich als CTO arbeiten, etwas zu formulieren, in dem sich meine Mitarbeiter in der Zukunft sehen können.
Selbst wenn du es noch gar nicht selber weißt, ob diese Zukunft überhaupt eintreten wird.
Weiß niemand, sonst würden wir Lotto spielen.
Aber klar, diese, das...
die Rolle des Engineers gerade eine starke Identitätskrise durchleidet, ist glaube ich, da sind wir beide einer Meinung und dass unklar ist, wie sich Engineering in den nächsten Jahren entwickelt auch.
Wir können ja aber mal spekulieren, was das denn mit der Rolle des CTOs macht, weil ich habe ja auch verschiedene Lesarten davon schon gesehen.
Ich habe auch dazu eine Meinung, aber ich will erst mal deine hören.
Der eine sagt ja, der CTO wird damit obsolet.
Den brauchst du nicht mehr, du brauchst weniger Führung.
Die anderen sagen aber, Eigentlich bräuchte es ja noch viel mehr, viel bessere CTOs, die in der Lage sind, hier diese Brücke zu bauen zwischen Business und Technologie, auch wenn dieser Technologieansatz, diese Hürde nicht mehr so hoch ist wie vorher, um hier die richtigen Entscheidungen zu treffen.
Was davon heilst du denn für wahrscheinlicher?
Ich stelle mir die Frage, ob Führungsrollen von unten kommen oder von oben kommen.
Also sind erst die Mitarbeiter Henni oder Ei?
sind erst die Mitarbeiter da und dann suche ich eine Führungsrolle oder es ist erst die Führungsrolle da und dann suche ich die Mitarbeiter.
Heißt, heute lauben ja alle CPO, CTO, Produktmanager und so weiter, gibt es Erlewigkeiten, gab es aber in der Form vor 20 Jahren nicht.
Das heißt, es sind alles neue Rollen, die letztlich mit dem Internet in dieser Form, wie wir sie heute kennen oder wir glauben sie zu kennen, entstanden sind.
Und jetzt ist die Frage, kommt das von oben oder von unten?
Ich glaube, wenn es...
Wenn es eine Transformation der Entwickler zu Product Engineers gibt, dann werden wir, glaube ich, eher einen CPTO sehen und mehr CPTOs sehen, die diese am Ende executive-mäßig diese Product Engineers führen.
Ich kann mir aber vorstellen, weil ich sehe das so, dass sich das ein bisschen aussplittet.
Wie gesagt, ich möchte jetzt kein Geld drauf wetten auf die Zukunft.
trotzdem meiner Meinung nach wird sich das aussplitten in Product Engineers und AI-Ops oder ML-Ops.
Also DevOps plus Data plus Plumbing plus Modelle plus weiß ich nicht was.
Und da kann ich mir vorstellen, dass es vielleicht einen CTO gibt oder einen CEO, Chief AI Officer oder wie auch immer das dann heißt, wahrscheinlich heißt es ganz anders, der eben sich um diesen Infrastruktur-Plumbing-Teil kümmert, Data und so weiter und so fort.
Das ist sozusagen Hardcore.
Integration Data Teil jemand macht und den produktlastigeren Teil jemand anders als Exekutiv.
Ja, das ist eine spannende Perspektive.
Ich würde mal gerne meine noch damit reingeben, weil sie gar nicht im Widerspruch zu deiner steht, sondern nochmal eine andere Ebene reinzieht.
Und zwar der C-Level ist ja auch da, also im C-Level ist unwahrscheinlich viel Ambiguität.
Da gibt es sich widersprechende Anforderungen und Ziele.
Die sind teilweise gewollt, teilweise lassen die sich gar nicht wirklich logisch auflösen, sondern du musst halt Kompromisse machen.
Und in diesem Umfeld ist der Mensch gefordert, um hier...
zu verhandeln, um auch herauszufinden, was ist denn jetzt die beste richtige Idee für einen richtigen Zeitpunkt im Unternehmen.
Das ist ja das, was viele dann als Politik bezeichnen, was viele auch nicht toll finden.
Hat erstmal wenig mit Technik zu tun, aber hier braucht es ja weiterhin einen, der für die Technik in diesem Kreis eintritt.
Und das wäre für mich der Grund, warum ich sage, diese Rolle des CTO wird nicht verschwinden, sondern sie wird eigentlich eher noch wichtiger.
Weil diese Rolle in diesem Gremium weiterhin vertreten sein muss.
Und das muss dann, das kann natürlich jemand sein, der aus dem Engineering rauswächst und in diese Rolle reinwächst und hier die Brücke baut zwischen Technik und Business.
Es kann aber auch jemand sein, der aus dem Product-Bereich kommt und diese Rolle mit einnimmt und ein gutes Technologieverständnis hat.
Ich glaube, so komplett ohne Technologieverständnis wird es schwierig.
Aber das Technologieverständnis macht nicht 80, 90 Prozent dessen aus, was du im Tagesgeschäft tust.
Kannst du damit mitgehen oder siehst du da auch Ansatzpunkte, denen du widersprichst?
Nee, ich würde dem nicht widersprechen, ich würde es nur umframen.
Mach mal.
Ich würde sagen, das, was du dann bezeichnest oder was du sagst, als jemand, der Technik vertritt, wäre dann für mich eher derjenige, der die AI-Infrastruktur vertritt, wo auch immer dann genau die Grenze ist.
Aber potenziell hört, also ich habe zum Beispiel CTOs.
die bauen Setups für Produkt, also die bauen Bausteine, Service-Bausteine und APIs in einer Art und Weise, dass sie von AIs leicht begreifbar sind, um Produkt zu enablen, oberhalb dessen Produkte zu bauen.
Und ich könnte mir vorstellen, dass der untere Teil dieser...
Lego-Teil, der Lego-Bausteine baut, auf denen AI aufsetzt, plus alles, was da drunter an Data ist, das wäre für mich mehr dann nochmal Hardcore-Tech.
Und da kann ich mich auch vorstellen, derjenige wäre für mich auch im Board.
Oder im Top-Manager-Executive.
Während der Produktteil bis zur AI weiß ich nicht, wie viel Hardcore-Tech da drin steht.
Für die meisten meiner Kunden.
Also wie gesagt, SpaceX mal außen vor oder Leute, die wirklich innovative Hardcore-Tech-Sachen machen, auch außen vor.
Die werden sicherlich lange Zeit noch einen echten, in Anführungszeichen, ich war auch ein echter CTO, aber einen echten CTO brauchen.
Aber so würde ich es, also sehr ähnlich, bloß ein bisschen eine andere Blickrichtung.
Was hältst du denn vom Begriff des Product Engineers?
Du hast es ja schon so ein bisschen angedeutet in die Richtung, aber ist es das, worauf es hinausläuft?
Ich glaube schon, ja.
Die Frage ist immer für mich auch, also mein Modell ist, muss nicht richtig sein, aber so wie ich mir ein bisschen die Welt erkläre, ist, es gibt verschiedene Kräfte im Universum und die eine Kraft ist das Unternehmen, das möglichst alle Leute gleich haben möchte.
Ein Unternehmen hätte am liebsten nur eine Art von Mitarbeitern, eine Rolle.
Die kann ich dann austauschen, kann ich skalieren, sind einfach zu managen und so weiter und so fort.
Das geht aber nicht.
Also es geht natürlich, wenn ich jetzt ein Startup gründe, zu zweit, dann ist es ja genau das.
Da sind wir sehr identisch.
Machen wir Marketing und Finance und so weiter und so fort.
Und jetzt gibt es eine andere Kraft, die ist sozusagen Ich brauche, wenn sich Technik und Systeme weiterentwickeln, diversifizieren sich die Skills.
Und dann fächern sich die Skills auf.
Und immer wenn die Skills zu breit werden, dann breche ich eine Rolle in zwei auf.
Als ich 1995 meine ersten Webseiten gemacht habe, oder 1996 weiß ich nicht genau, aber irgendwann meine ersten Webseiten gemacht habe, da habe ich auch HTML, ganz normal, HTML und Datenbank und Perl-CGIs gemacht.
Und da war ich ein Full-Tech-Ingenieur.
Wir hatten ja nichts anderes.
Genau, da war ich ein Full-Stack-Engineer.
So, und dann wird aber das Frontend immer breiter und das Backend immer breiter und die Datenbanken breiter, sodass wir dann, dass es dann zu einer Diversifizierung dieser Rollen kam.
Die ist aber jetzt nicht irgendwie, die ist ja nicht Gott gegeben, sondern das Skillspektrum wurde einfach für eine einzelne Person immer breiter und immer größer.
Und deswegen gab es, gibt es eine Rollendiversifizierung.
Und das spielt für mich so hin und her.
Aber wenn die Möglichkeit besteht, Rollen zusammenzufassen, dann würde ein Unternehmen immer lieber Rollen zusammenfassen.
Und aus diesem Grund glaube ich, dass wir jetzt aus einer Diversifikationsphase, und wir haben das ja auch vorher in DevOps schon ein bisschen gesehen und so, eine Zusammenfassung von einzelnen Rollen.
Und das glaube ich, deswegen möchte ein Unternehmen auch Product Engineers haben.
weil es weniger Rollen sind, weil es einfacher ist und weil es effizienter ist und so weiter und so fort.
Das ist die logische Konsequenz.
Es ist ja auch die logische Konsequenz.
Du sagst ja auch, am Anfang gab es ja sowieso nur den Product Engineer, weil Product und Tech musstest du halt zusammen machen.
Dann hat es das immer weiter diversifiziert.
Es gab immer mehr breitere Rollen.
Und jetzt sind wir an einem Punkt, an dem...
dass Coden überhaupt keine Engpass-Ressource mehr ist, weder im Wissen noch sonst irgendwo.
Es ist halt einfach vorhanden und du kannst es auf Knopfdruck generieren.
Damit geht es halt wieder zusammen und damit kannst du eigentlich auch die Rollen wieder verschmelzen.
Also wenn du es mal so betrachtest, ist es ja eigentlich, ja nicht alternativlos, aber es ist im Endeffekt, wäre die logische Konsequenz, wenn es sich wieder so entwickelt.
Ja, weil ich brauche jetzt, ich kann halt, ich kann Webseiten machen, ich brauche keine CSS-Skills mehr.
Also Claude ist halt relativ gut für Sachen, die ich mache und dann sage ich, macht er CSS oder macht er zwei Spalten und dann macht er zwei Spalten oder ich sage, macht das mal responsive und so weiter, macht das responsive und dann sage ich zu ihm, dann gucke ich da rein und sage, das scheint mir so 2005 CSS zu sein, kannst du nicht moderne Features nehmen und dann sagt er, ach ja, stimmt und dann macht er Variablen und nestet Attributes oder Properties und so weiter und so fort.
Also ohne, dass ich das alles wissen müsste.
Und wenn man zum Beispiel, auch ganz, ganz spannend, wenn man mal Cloud Code mit GitHub Client arbeiten lässt, mit GH und einem Token Generator zum Beispiel arbeiten lässt, dann stellt man fest, wie viele Funktionen, Parameter und sonstige Sachen in diesen ganzen CLI Tools drin stecken, die ich mein Leben lang noch nie verwendet habe, aber die Cloud dann einfach optimal nutzt, um das Ziel zu erreichen.
Viel, viel besser als ich.
Der kennt dann alle Flags und alle Befehle und so weiter und so fort.
Das heißt, ich habe die Skills nicht, aber Claude hat die Skills und deswegen brauche ich auch weniger Skills und das ermöglicht sozusagen wieder diese Zusammenführung der Rolle.
Ja, das ist auch spannend.
Ich erinnere mich noch gerade an etwas, was du im Vorgespräch, glaube ich, mal erwähnt hattest.
Du hast nämlich da gesagt, AI ist nicht Software.
Und da wollte ich dich sowieso noch mal fragen, was meinst du genau damit?
Also ich glaube, ein Verständnis davon zu haben, was du meinst, aber ich glaube für...
Für die Zuhörer da draußen, ist das unter Umständen nochmal was, was ein bisschen Erklärung bedarf?
Ich dachte, ich hätte jetzt Engineers ausreichend erschreckt.
Darfst gerne weitermachen.
Dann machen wir Level 2, Level 2 Horror Show.
Was meine ich damit, wenn ich sage, AI ist nicht Software?
Software ist ein Werkzeug, mit dem wir Probleme lösen.
Das heißt, ich habe ein Problem, Businessproblem, irgendein Problem, To-Do-Listen-Verwaltung.
Und dann nehme ich Software dafür.
Vor 100 Jahren hätte ich einen Zettel genutzt und einen Kugelschreiber.
Löst aber genau das gleiche Problem.
Und so gibt es eben unterschiedliche Werkzeuge in den letzten 10.000 Jahren, die wir verwendet haben.
Kugelschreiber und Notizblock oder was Elektronisches, Elektrisches, eine CPU und so weiter.
Und Software ist der letzte Schritt vor AI, den wir die letzten 30, 40 Jahre benutzt haben, als Standardwerkzeug, um Probleme zu lösen.
Also wenn ich sage, Beispiel eben.
und To-Do verwalten, dann würden 5% der Leute daran denken, okay, ich bringe einen neuen Filofax auf, also einen neuen Filofax auf den Markt, kennt keiner, ein neues Notizbuch auf den Markt und 95% würden sagen, ja, lass uns eine App bauen.
Das meine ich sozusagen mit diesem Standard-Tool, während vor 100 Jahren hätten die Leute alle einen Filofax auf den Markt gebracht, weil es Software noch nicht gab.
AI ist eine neue Kategorie von Tool.
Diese Kategorie von Tool wird über kurz oder lang aus meiner Sicht Software als Tool ablösen.
Und wie unterscheidet sich das?
Software ist Quellcode, der aus Sequenzen besteht und aus Ifs besteht und der irgendwo existiert und ausgeführt wird.
Das heißt, wenn ich ein ERP-Programm habe, dann existiert irgendwo ein ERP-Code.
Ob den jetzt ein Mensch geschrieben hat oder in einer Transitionsphase die AI.
Und das meine ich mit Software.
Da gibt es irgendwo Ifs, ob das jetzt C ist oder Maschinencode oder was auch immer.
Es gibt etwas, was ERP, was dieses ERP-System domaintechnisch digital repräsentiert.
Und bei AI ist es so, wie ich mir das vorstelle, es gibt ein generelles AI-System.
Und zu diesem AI-System sage ich, guck mal alle meine Mails durch und sag mir, welche die Top-Kunden sind.
Rrp, Top-Kunden.
Bitte schick allen meinen Top-Kunden eine Upsell-Mail.
Zip, Upsell-Mail.
Da habe ich keinen ERP-Code oder keinen CRM-Code.
Bei ERP wäre, was sind meine Lieferanten oder sowas oder optimiert die Lieferanten.
Aber sagen wir mal CRM.
Dann schickt er die Mails raus, ohne dass dort irgendwelche domainspezifische CRM-Code steckt.
Das sind letztlich nur Gewichte mit Prompts verknüpft und mit ein bisschen Software außenrum als Interface, so wie heute quasi Elektronik das Interface zur Software ist.
Ja, ich habe einen Computer, da ist lauter Elektronik.
Außen ist es Elektronik.
Und innen drin sind ICs, also CPUs.
Und ganz in den CPUs läuft Software.
Also die CPUs sind von Elektronik umgeben und die Elektronik ist physikalischer Hardware.
Hier steht ein Laptop von physikalischer Hardware umgeben.
Das heißt, diese Tools sind alle in meinem Laptop vereint, quasi wie eine Zwiebel.
Und so wird das, denke ich, auch mit AI sein.
Ich habe außenrum Software für bestimmte Tätigkeiten oder für Services.
Aber im Kern gibt es nichts, was CRM-spezifisch ist oder sowas.
Wenn du den Gedanken weiterentwickelst oder auch nochmal bis zum Ende durchdeklinierst, könnte das ja auch bedeuten, dass wir das Ende von Software-as-a-Service sehen oder überhaupt von großen Softwareprodukten, weil irgendwo durch Agentik, AI, alles anderweitig lösbar ist und du die Software gar nicht mehr brauchst.
Ich meine, das ist natürlich das Endzeit-Szenario für das komplette SaaS-Business.
Wahrscheinlich wird es am Ende des Tages nicht so weit kommen, aber das ist mit ein Grund dafür, warum das gerade sehr schwer investierbar wird, dieses ganze Business.
Wie gehst du damit um?
Ich meine, du arbeitest ja auch mit Unternehmen in diesem Kontext zusammen.
Wie erlebst du die Branche in der Hinsicht gerade?
Schwierig.
Also Investments sind schwierig.
Investment in SaaS-Unternehmen ist schwierig.
ist leicht, weil die VCs nicht machen.
Also von VC-Seite ist leicht, weil sie es nicht machen.
Für die, die das Geld brauchen, ist schwierig, aus meiner Erfahrung zurzeit.
Und ich glaube auch nicht, dass es besser wird.
Was machen die dann?
Entweder profitabel werden oder zumachen.
Das heißt, die haben ja eigentlich nur die Wahl, sich selbst so weit gesund zu schrumpfen, bis sie profitabel sein würden und dann über ihr Ei wiederum zu versuchen.
die Effizienzgewinne umzusetzen, um dann wieder andere Sachen zu bauen, um weiterhin relevant zu bleiben.
Ja, ich habe aber so einen ganz kleinen AI-Newsletter, der ist nicht sonderlich groß, wo ich ab und an AI-Gedanken teile.
Der heißt Tabula Rasa und der heißt deswegen Tabula Rasa, weil ich glaube, dass wir eben vor einem blanken Tisch stehen und ich empfehle Foundern, Gründern von Startups zu überlegen, Ist Software, also wenn AI jetzt in der Geschwindigkeit drei Jahre weitergeht, wie würde ich eigentlich in drei Jahren mein Startup gründen?
Würde ich das so gründen wie vor zwei Jahren oder eben anders?
Und wenn ich mein Startup in drei Jahren anders gründen würde, dann würde ich jetzt darauf hinarbeiten, dass ich mein Startup oder meine Firma auf die Art und Weise reorganisiere.
wie ich es machen würde, wenn ich in drei Jahren ein Startup gründet hätte.
Ein Startup gründet hätte, sehr schön.
Die CTOs, mit denen du dann an der Stelle zusammenarbeitest von den Unternehmen, was brauchen die denn aktuell am meisten?
Ist das Unterstützung im Bereich der Technik, im Bereich AI?
Du hast es ja angedeutet, du bist da auch sehr versiert.
Ist es dann doch eher strategisch?
Ist es emotional?
Wo hapert es bei denen?
Ich würde sagen, bei den CTOs hapert es strategisch.
Also mit den CTOs, mit denen ich arbeite, reden wir viel über Strategie.
Wo geht es hin?
Wo möchten sie hin?
Wie führen sie AI ein?
Was wird ersetzt?
Was wird wie umgeformt?
Was ist eigentlich das Ziel des Ganzen?
Indirekt betrifft die CTOs aber, was ich mit ihnen bespreche, das Thema Emotionen.
Das heißt, dem Senior-Entwickler einen Weg aufzuzeigen in eine goldene Zukunft, in der er sich wiederfinden kann.
Das ist schon eine sehr emotionale Sache.
Und auch, ich komme manchmal in Firmen und mache Motivationsvorträge für Entwickler, weil es schon sehr viel Resistance gibt gegen AI.
Also das meiste ist, habe ich ausprobiert, der Code ist schlecht.
Mache ich nicht mehr.
Das ist so jetzt ganz, ganz platt, aber das ist so, wo viel Resistance herkommt, ja.
Also beides, was du angesprochen hast, Emotionen und Strategie.
Ich höre auch immer viel davon, dass es diese Resistance in Engineering Teams gibt.
Ich habe tatsächlich keinen Entwickler getroffen, der das tatsächlich so offen formuliert.
Wie viel sind das denn?
Also kannst du da so, da umschätzen, wie viel Prozent der Entwickler haben tatsächlich so große Ressentiments gegenüber der AI?
dass sie das Einsetzen dieser Tools eigentlich ablehnen, wenn man sie nicht dazu drängen würde?
Also die Ablehnung ist auf mehreren Leveln.
Also eine Ablehnung gegen Autocomplete in Cursor ist nicht da.
Eine Ablehnung gegen schreib mal eine Funktion X, die Y macht, ist auch nicht da.
Die Ablehnung beginnt am Punkt, wo hier guck mal das Ticket an, mach mal, implementier dieses Ticket.
Und dann muss ich mir den Code angucken und dann ist der nächste Resistance Level implementiertes Ticket und Packs of Production.
Also es gibt verschiedene, AI ist ja sehr vielgestaltig mit ganz simple Autocomplete zu, ich gucke mir den Code nicht an, verschiedenste Stufen da dazwischen und ich würde sagen, von ganz unten bis nach oben wächst die Resistance.
Und bei Senior mehr als bei Junior.
Bei Juniors sehe ich ganz überhaupt gar keine oder bei vielen Entwicklern und bei Juniors sehe ich gar keine Resistance.
Wenn eine kommt dann bei Senior-Entwicklern und die äußert sich dann manchmal so durch die Blume, also so direkt sagt es ja auch keiner, aber die Leute stellen mir dann, wenn ich so einen Vortrag halte, nenne ich das immer 30 Minuten, Stefan hält 30 Minuten Vortrag und dann erklären die Leute 30 Minuten, warum Stefan ein Idiot ist.
So teilt sich das immer auf, so ein bisschen.
Nett und so weiter durch die Blume, aber es kommt schon sehr viel wie, also sehr kritische Fragen.
Also es wird mehr fokussiert auf die kritischen Fragen.
Es wird ganz selten gefragt, was kann man denn jetzt Tolles machen, aus deiner Sicht oder so, sondern sehr viel, hältst du den Code wirklich wie gut, kann man das wirklich machen?
Also mehr in diese Richtung.
Das heißt, du versuchst Visionen zu geben, du versuchst eine Begeisterung auch für das Thema zu geben, weil du siehst, ihr werdet sowieso nicht drumherum kommen und dann musst du dich aber mit der immer noch vorherrschenden Resistance auseinandersetzen.
Ist das auch die Erwartungshaltung, die du dann hast aufgrund der Vorträge?
Also eigentlich möchtest du Aufbruchstimmung mit erzeugen?
Bei mir ist es so, letztes Jahr kam ich ein bisschen zu der Erkenntnis für mich, dass es Creator und Coder gibt.
Der Creator benutzt den Code, um etwas zu erzeugen und der Coder benutzt das Produkt, um zu coden.
Und der eine ist in das Ergebnis verliebt, der will was schaffen und der andere ist in den Code verliebt.
Und erst mal, und das war jetzt sozusagen 20 Jahre lang alles ganz okay.
Und mit AI wird...
verändert sich das dahingehend, dass derjenige, der Code liebt, und ich habe auch super viel Bücher, Scala-Code-Puzzles und solche Sachen gelesen, und mein Lieblingsbuch ist immer noch Z80 Sub-Assembly-Routines und so.
Also ich finde es faszinierend.
Ja, nur ich glaube, das geht halt weg.
Der Coder-Teil geht halt weg und der Creator-Teil bleibt.
Und wenn man sich als Creator begreift, der etwas schafft, und das war auch, was mich rangebracht hat an die Sache, ich habe mir an den Computer gesetzt, an den VC20, was eingetippert und dann kam da ein Text und die Farben haben sich geändert.
Man hat was in den Fernseher reingemacht und es kam was raus, während man vorher nur aus dem Fernseher was rauskam.
Und plötzlich konnte man den...
Fernseher dazu bringen, etwas zu tun.
Das ist für mich der Creator Spirit und ich möchte eigentlich, dass die, dass Engineers das wieder erkennen oder das vielleicht auch in sich finden und das Ganze ihnen einen Weg nach vorne zeigt.
Genau, Entschuldigung, weniger verliebt sein ins Handwerk und mehr wieder Liebe finden für die Ergebnisse, die man damit produzieren kann.
Ist es das am Ende?
Ja.
Also ich, ja, also ich programmiere auch ab und an noch auf einem Z80 Board irgendwelche Z80 Sachen und finde es faszinierend und so weiter.
Ja, das ist wie, ich würde mal sagen, das ist wie japanische Kalligrafie.
Es ist eine sehr schöne Sache.
Nur kann man ganz schlecht, glaube ich, mit japanischer Kalligrafie Geld verdienen.
Und so kann man sicherlich...
immer noch weiter programmieren.
Wie gesagt, ich programmiere seit 80 Sachen, wenn ich mal Spaß haben will, was ich vor 40 Jahren gemacht habe.
Es geht immer noch und so wird es auch gehen.
Wie japanische Kalligrafie, schön, aber es ist schwierig, damit Geld zu verdienen und so sehe ich in Zukunft das Programmieren.
Im Sinne von, ich schreibe Code.
Heißt, wir haben Peak Coding eigentlich ja schon erreicht.
Also das Peak Coding meine ich jetzt wirklich von Menschen, selbst geschriebener Code, dieser Moment ist vorbei.
Ja, also wir haben noch nicht Peak Software erreicht.
Software wird noch explodieren.
Also auch gerade dieses Thema One Person, Audience of One, Apps, App für eine Firma.
Und diese Leichtigkeit, um Sachen zu bauen, führt natürlich dann dazu, dass es, glaube ich, eine Explosion von Software gibt.
Nochmal.
Aber Peek Coding würde ich glauben, ist erreicht im Sinne von Leute schreiben Code und gucken den an.
Ja, und ja klar, Open Claw, wenn du das zum Beispiel als Software noch bezeichnen würdest, ist ja im Endeffekt ein Paradebeispiel jetzt gerade dafür.
Innerhalb von...
von, ich weiß nicht, wie lange er jetzt dafür gebraucht hat, ob das jetzt Wochen oder Monate nochmal waren und so und jetzt auf einmal dann bei OpenAI und bei Lex Friedman im Podcast und erzählt da drei Stunden darüber und wenn man sein Aktienpaket dann anguckt, dann wird es wahrscheinlich sehen, er ist jetzt eigentlich schon Milliardär.
Keine Ahnung, übertreibe ich es vielleicht ein bisschen.
Ich habe es nicht gesehen.
Nee, aber die Richtung.
Genau.
Ja, genau.
Und du denkst auch, es wird erstmal noch weiter in die Richtung gehen?
Ich glaube, es gibt erstmal noch sehr, sehr viel mehr Software.
Und dann kommen wir nochmal in den Bereich AI only.
AI als nächstes Tool, wie Open Cloud oder so.
Ich sehe das tatsächlich ähnlich.
Ich sehe aber auch nämlich gerade, also ich sehe viele Sachen von denen, die wir jetzt auch im Laufe des Podcasts heute angesprochen haben, nämlich Software as a Service ist gerade sehr schwer investierbar.
Wie sie es halten, Geld zurück wollen da gar nicht mehr investieren.
Und natürlich ist das ein Riesenproblem für die Branche.
Auf der anderen Seite sehe ich aber auch junge Startups, die gerade in dem AI-Bereich Software bauen, die durchaus disruptives Potenzial für bestimmte Branchen hat.
Die werden gerade vom Markt aufgekauft, noch bevor sie eigentlich richtig an den Start gegangen sind.
Und zwar auch nicht wenige.
Also Geld wird weiterhin in Software investiert, aber nicht in klassisches SaaS-Business, sondern...
Am Ende ist das auch SaaS, nur es ist halt nochmal AI-enabledes Software-as-a-Service und das sehe ich schon auf der anderen Seite.
Und dann ist aber auch genau der Fall, dass das wahrscheinlich irgendwann auch einen Endlichkeitsfaktor hat und irgendwann das wirklich nicht mehr relevant sein wird.
Ja, aber die sind wirklich nicht mehr relevant, sage ich jetzt mal zehn Jahre plus.
Also ich würde jetzt nicht behaupten, dass es morgen passiert oder so.
Aber ich sage auch zu den Leuten, Also wenn du 50 bist, brauchst du dich vielleicht nicht mehr groß umorientieren, dann kannst du vielleicht noch von Nische zu Nische bis in die Pension hüpfen.
Es gibt ja auch immer noch Vortran-Programmierer.
Wenn du 22 bist, würde ich nicht erwarten, dass du bis zur Pension programmierst oder bis zur Rente programmierst.
Was macht das denn, also ich habe gerade eben ja mal Peak Coding angesprochen, was macht das denn mit der Menge an Personen, die im Softwarebereich angestellt sind.
Glaubst du, wir haben auch diesen Peakbereich längst überschritten?
Also es gab ja mal einen Peak, der würde ich mal sagen, der war 2021, Anfang 2022 war der erreicht und dann gingen ja die ganzen ersten Layoffs los.
Ich glaube, wir sind nicht mehr an dem gleichen Punkt der Menge an Engineers, die mittlerweile im Softwareumfeld aktiv sind.
Glaubst du, wir leben trotzdem nochmal eine Steigerung?
von Menschen, die in dem Bereich dann mit Software arbeiten und sich Software-Engineer nennen können?
Oder haben wir auch diesen Peak erreicht und der kommt nicht mehr?
Schwer zu sagen, weiß ich nicht.
Zwei Indizien.
Ich mache ab und an Mentoring auf Mentoring Club und habe Gespräche mit Leuten, die seit Längerem einen Job suchen.
Das nimmt zu, Softwareentwickler, die länger einen Job suchen.
Nimmt zu, würde ich behaupten.
Also ich habe keine relevante Menge oder so.
Es ist reines Gut-Feeling von dem, was ich sehe.
Aber das würde ich sagen.
Umgekehrt natürlich, als ich 1990 oder sowas angefangen habe zu studieren, Informatik zu studieren, haben alle gesagt, wie kann man Informatik studieren?
Es ist ja schon alles programmiert.
Alles, was man sich vorstellen kann, ist schon programmiert.
Wer hat das gesagt?
Wirklich?
Ja, es gibt eine Tabellenkalkulation und es gibt Word und was willst du denn eigentlich machen als Informatiker?
Das war 1990.
Dann kam das Internet, dann kam Mobile, dann kam SAS, dann gab es eine Verhundertfachung oder eine Vertausendfachung der Entwickler.
Aber ja, also von daher zwei Data Points.
Einerseits Leute, die Schwierigkeiten haben, den Job zu finden.
Einerseits wurde das halt schon ein paar Mal totgesagt und dann hat es sich vertausendfacht.
Von daher...
Für mich schwierig einzuschätzen.
Ja, spannend.
Diese Aussage habe ich tatsächlich noch nie gehört, dass das zu so einem frühen Zeitpunkt so eine Aussage kam.
Ja, also wir haben alle abgeraten, davon Informatik zu studieren damals.
Okay, interessant.
Ja, es erinnert mich so ein bisschen an die Aussage eines Politikers.
Ich glaube, das war so um die Jahre zwischen 2003 bis 2005, der dann meinte...
Er wüsste nicht, warum ein Haushalt überhaupt eine Leitung mit mehr als ein Mbit überhaupt brauchen sollte, wenn nicht zum Softwarepiraterie betreiben oder Filmpiraterie.
Und ich glaube, das ist auch eine Einschätzung, die hat, glaube ich, gezeigt, dass sie nicht eine lange Halbwertszeit hat und ein ziemlicher Quatsch war.
Ähnlich wie das, was du gerade, die Anekdote, die du erzählt hast.
Ja.
Sehr schön.
Wir sind auch schon fast am Ende, lieber Stefan, der heutigen Aufnahme angelangt.
Aber ich habe, wie es so gute Tradition ist, eine kleine Runde Rapid-Fire-Fragen mitgebracht, wenn du Bock hast.
Ja, klar.
AI in drei Jahren.
Ist das Hype oder Fundament?
Fundament.
Tech-Debt unterschätzt oder überdramatisiert?
Ich sage immer Tech-Debt außerhalb von Tech nicht verwenden als Wort.
Schadet man sich nur selber.
Oder anders erklären in Impact und sowas.
Also sagst du, ist es überdramatisiert oder ist es weiterhin unterschätzt?
Als Konzept überdramatisiert.
Okay.
Remote first oder hybrid?
Ich liebe Office.
Ich mache aber 100% remote.
Ich würde lieber 100% remote machen als Hybrid.
Okay.
Komischerweise ist das bei mir auch so.
Ich mag Office, aber arbeite auch in den allermeisten Fällen remote.
Also irgendwie der lebende Widerspruch.
Vision zuerst oder Team zuerst?
Was sagst du?
Für Tech Vision.
Und der CTO, Übersetzer oder Entscheider?
Entscheider.
Beides, aber Entscheider.
Sehr gut.
Sehr schön.
Stefan, es hat mir sehr großen Spaß gemacht mit dir.
Mir auch.
Wo kann man dich denn finden, wenn man mit dir in Kontakt treten möchte?
Falls das jemand möchte, dann kann man entweder Amazing CTO googeln oder eine AI danach fragen.
oder mich auf LinkedIn suchen.
Stimmt, da bist du auch aktiv.
Bist du auch viel am Createn?
Bist du viel am Selberschreiben?
Ja, ich schreibe relativ viel selber auch.
Dann Stefan, hat mich sehr gefreut.
Und vielleicht kommst du uns ja nochmal hier im flauschigen kleinen Podcast besuchen.
Bis dahin weiterhin viel Erfolg auch bei der Motivation der Engineers, damit sie AI-Tools besser verstehen und sich mehr auf das Ergebnis konzentrieren und weniger auf das Coden.
Vielen lieben Dank und bis bald.
Bis bald, sehr gern.
Tschüss.
Macht's gut.
Ciao, ciao.