# AI-Driven CTO Strategy and Team Restructuring

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

## Transcript

Was passiert, wenn wir Software plötzlich schneller bauen können, als wir entscheiden, was überhaupt gebaut werden soll?
Mein heutiger Gast glaubt, dass sich dadurch nicht nur das Engineering verändert, sondern womöglich auch die Größe und Führung unserer Teams.
Aber funktioniert diese Vision auch in einer größeren Organisation?
Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es noch werden wollen.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer.
der Becoming CTO Community.
Heute spreche ich mit Benjamin Eckert, der bei mobile.de vom Backend Engineer zum Director of Engineering wurde, bei Babel CTO Verantwortung übernommen hat und später als Interim CTO bei Benefix gearbeitet hat.
Heute baut er mit Clarice AI ein Unternehmen für KI-gestützte Produktforschung und bringt eine klare These mit, nämlich AI verändert nicht nur, wie wir Software entwickeln, sondern auch, wie wir mit Teams wie wir Teams und die CTO-Rolle organisieren.
Benjamin, herzlich willkommen.
Vielen Dank.
Danke, dass ich hier sein kann.
Und gleich haben wir noch einen schönen Cliffhanger, weil wir hatten nämlich vor zwei Folgen, oder tatsächlich der aktuellen Folge, die jetzt aktuell noch draußen ist, hatten wir den ehemaligen CTO, den David Gebhardt von mobile.de zu Gast, den du mit Sicherheit auch kennst.
Ja, auf jeden Fall.
War immer mein Chef.
Sehr gut.
Und du bist selber auch zum CTO geworden.
Das ist super.
Du bist bei mobile.de vom Backend Engineer zum Director of Engineering gewachsen.
Ich habe es angekündigt in der Intro.
Welche Entscheidung hat damals gezeigt, dass du nicht mehr primär als Ingenieur arbeiten möchtest, sondern eher auch als Richtung Führungskraft denkst und handeln musstest, wolltest, wie auch immer du das ausdrücken willst?
Ich habe bei Mobile Mobility als Backend-Entwickler angefangen und für mich, ich wollte halt da auch mein Potenzial oder meinen Wirkungsgrad erweitern, was möglich ist und was nicht.
Und ich hatte damals die Möglichkeit, das Trot-Fighting und Trust-and-Safety-Team mit zu übernehmen, was ein sehr spannendes Thema ist, weil Betrug auf Marktplätzen ist leider nach wie vor ein Thema.
Und das hat mich so gereizt, dass ich mich dann dieser Herausforderung angenommen habe.
Auch wenn der Start vielleicht, ich sage mal, etwas holpriger war, als ich es mir vielleicht gewünscht habe.
Wie sah das denn aus?
Was war holprig?
Naja, das sah so aus, das Team war noch relativ klein.
Es war noch ein Interner und ein paar Externe.
Und der Interner meinte dann zu mir so, also, wer bist du denn?
Du sollst jetzt hier teamet werden?
Aber dir spreche ich doch gar nicht erst.
Und wenn man jetzt quasi das erste Mal in so eine Rollerei kommt, dann ist das schon eine Herausforderung, die sich nicht als sehr leicht achtet.
Darüber hinaus hatte mich ja dann mein damaliger Chef dafür, wollte mich da hin platziert auf diese Position.
Der ist dann aber zwischenzeitlich gegangen und so war ich auch so ein bisschen am Schwimmen, weil ich da auch dann, weil er halt entsprechend nicht mehr da war.
was keine einfache Situation für mich war.
War für dich CTO-Werden immer ein Ziel, was du so auf dem Schirm hattest?
Oder war das dann auch irgendwann einfach nur die logische Konsequenz aus deiner Entwicklung und dem Mehr an Verantwortung, was du dann nach und nach angefangen hast zu übernehmen?
Es war schon für mich ein Ziel.
Die Frage war immer, wo, in welchem Unternehmen und in welchem Kontext?
Weil CTO ist ja nicht gleich CTO.
Du kannst CTO von einem kleinen Startup sein und bist quasi nur...
Eine One-Person-Show, du kannst CTO von einem 300 oder 3000 oder 30.000, ich sag mal Microsoft oder ähnliches Unternehmen sein.
Von daher, es kommt immer auf die Rahmenbedingungen da an und wo man da hin will.
Und dementsprechend verändert sich ja auch die Aufgabenstellung sehr stark von der Rolle.
Und das heißt bei Bubble, sagt man eigentlich Babble oder Bubble oder wie spricht man es eigentlich richtig aus?
Wir haben es Bubble genannt, also Bubble, nicht Babble, sondern Bubble.
Okay, okay, dann shame on me.
Also bei Bubble warst du ja Acting CTO.
Wie hat sich das denn, was hat denn daran den Acting CTO-Teil ausgemacht?
Oder wie hast du das denn definiert, dass du jetzt eigentlich ja der handelnde CTO bist, auch wenn er noch nicht auf dem Titel stand?
Ja, also Bubble hatte sich damals dafür entschieden, dass sie keine funktionalen Rollen mehr haben, sondern nur noch, ich sag mal, Business-Rollen.
Und was ich bei Bubble dann gemacht habe ist, oder was die Aufgaben, die mir übertragen wurden, sind einmal direkt die Plattformorganisation zu leiten, aber darüber hinaus auch Engineering lateral über die ganze Organisation.
Das heißt, sowas wie Tech-Strategy sich anzuschauen, sowas wie AI-Strategy und das entsprechend zu formen und für die gesamte Organisation dazu.
Das war eine ganz neue Erfahrung, weil es ja dann darum ging, eine laterale Führung ist halt auch nochmal was anderes als direkte Führung, wenn man sich dann mit solchen gewissen Themen halt auch durchsetzen muss, weil man hat ja immer Trade-off-Entscheidung.
Möchte man jetzt eher technisch, möchte man Tech-Tept abbauen, möchte man...
gewisse Quality-Prozesse einführen oder sagt man, hey, ja, eigentlich, wir haben ja diese fünf Business-Themen, die klingen doch eigentlich viel spannender und haben Revenue-Impact und so, dass man halt noch viel, sehr stärker am Stakeholder-Management arbeiten muss und das war ja die Kern-Herausforderung dann dieser Aufgabe.
Ja, das ist interessant, also woran können denn angehende CTOs, also Personen, die auch an der Stelle waren, wie du damals bei Bubble, woran können die denn erkennen, ob sie bereits auf einer CTO-Flughöhe oder auf einer ähnlichen Flughöhe unterwegs zu arbeiten.
Also das ist ja auch eine Frage, die tatsächlich potenzielle Kunden mir stellen, die sich dann sagen, eigentlich möchte ich CTO werden.
Vielleicht bin ich es ja auch schon, aber so richtig weiß ich das ja noch gar nicht.
Was macht das denn überhaupt?
Was fehlt mir denn vielleicht auch noch?
Woran können das angehende CTOs merken?
Was hast du da bei dir festgestellt?
Da hat man die technisch, also wer hat die Verantwortung für die technologische Strategie der Auffirma, der Ausrichtung?
Wer hat die Verantwortung auch für das entsprechende Budget natürlich, auch wenn das bei lateraler Führung nur bedingt gegeben ist?
Wer hat die Entscheidung und wer sitzt denn mit dem Board oder mit den anderen Personen auf C-Level zusammen und entscheidet, dann wollen wir jetzt den Weg A gehen, wollen wir jetzt den Weg B gehen?
Macht er die Entscheidungsvorlagen?
Normalerweise, wenn jemand angehen ist, dann sind diese Rollen ja durchaus in irgendeiner Weise besetzt.
Also, dann gibt es vielleicht einen CTO oder es gibt einen CPO und dann berichtet die technische Person dahinter.
Sowas könnte ich mir dann an der Stelle vorstellen, dass du sagst, okay, ich habe eher für jemanden, der ist im Produktleadership und darunter habe ich vielleicht eine VP of Engineering und die berichtet dann an diese Person.
Und wenn es dann um strategische Themen geht, wie welche Technologiestrategie wollen wir denn einschlagen, welche Richtung wollen wir denn einschlagen, dann übernimmt diese dann der VP of Engineering an der Stelle oder Head of Engineering, je nach Firmengröße.
Ja, es ist ja tatsächlich nicht selten, dass ein...
VP Engineering von einem größeren Unternehmen durchaus schon auf einer Flughöhe angekommen ist, die ihn sehr gut prädestinieren, CTO in einem kleineren Unternehmen auch zu sein.
Also den Schritt nach vorne zu machen, aber was die Rolle angeht.
Am Ende ist es über die Frage, hat er dann wirklich noch das gleiche Level an Verantwortung oder ist das nicht auch manchmal eine Mogelpackung, dass du dann zwar CTO auf einmal in einem Startup geworden bist und dann aber feststellst, dass du vorher im größeren Unternehmen eine größere Mannschaft hattest, einen größeren Verantwortungsbereich hattest, vielleicht sogar mehr Budget verantworten konntest und musstest.
Ja toll, jetzt hast du die CTO-Rolle und dann musst du dich mit jungen Foundern rumschlagen.
Die sind alle nicht so mature wie wahrscheinlich die anderen VPs oder Directors oder der C-Level in einem größeren Unternehmen.
Du warst ja auch an so Stellen.
Würdest du den Weg nochmal so gehen?
Es ist ja nicht so, dass man sagt, du würdest den Weg so gehen.
Der Weg zu dem CTO ist nicht so linear, wie man sich das so vielleicht vorstellt.
Und da gibt es ja die ganz unterschiedlichen Einstiegspunkte.
Also manche haben vielleicht was gegründet und sind ja selber zum CTO geworden.
Andere haben das in größeren Unternehmen gemacht.
Ich glaube, ein Rat ist da an der Stelle, der Weg ist in der Regel nicht linear.
Also in den seltensten Fällen ist er linear.
Das heißt, es gibt auch mal Rückschläge, dass man sagt, okay, ja, ich hatte jetzt die Position, ich gehe jetzt nochmal einen Schritt zurück, nehme vielleicht auch mal so eine andere VP oder Head-off-Stelle nochmal an, um dann in der nächsten Möglichkeit, die sich mir ergibt, da dann qualifiziert zu sein.
Also, die Linearität, die man so sagt, ja, ich nehme mir das jetzt zum Ziel und jetzt meine nächste Position muss das so sein, die ist für mich nicht gegeben, sondern immer erst die Frage, was ist denn der nächste Schritt, weil der Der Weg zum Erfolg ist, auch wenn es eine Plotitüde ist, ist geflastert von Misserfolgen.
Und die Frage ist, komme ich damit einen Schritt näher meinem Ziel?
Also, nehmen wir mal an, ich bin jetzt, keine Ahnung, Head of Engineering, ich wechsle zu einer Firma, bin da zu einer kleineren Firma, übernehme da die Herausforderung.
Oder kann aber auch in einem größeren Unternehmen sein, wenn ich auch schon eine entsprechende Rolle habe.
Und gerade jetzt im Genic-Zeitalter zählt auch vielleicht nicht mehr so viel, wie viele Leute haben an mich.
haben an mich berichtet oder berichten in dem Zusammenhang an mich, sondern auch, was ist mein Wirkungsgrad, was kann ich da erreichen?
Also es könnte auch durchaus sein, dass man sagt, ich nehme jetzt mal ein spannendes Projekt, hat eine viel kleinere Auktion, hat eine viel kleine Organisation, hat einen viel kleineren Scope, aber dafür lerne ich etwas.
Und was kann mir auch wiederum helfen auf dem Weg dahin?
Also so zusammengefasst, ich glaube, es ist wichtig nicht zu sagen, hey, ich muss jetzt CTO werden und was ist jetzt mein nächster Schritt dahin?
Und jeder Schritt wird da hinführen.
Alle Schritte werden da irgendwie hinführen, aber es sieht nicht immer unbedingt danach aus.
Und man kann es zum Teil erst später erkennen, dass es eigentlich der richtige nächste Schritt war.
Ja, das stimmt schon.
Hast du andere noch auf deinem Weg begleitet, die vielleicht auch mit ähnlichen Ambitionen gestartet sind und die es dann vielleicht noch nicht geschafft haben?
CTO zu werden, während du das schon bist oder die vielleicht noch am Suchen sind, was ist der richtige Weg für sie oder vielleicht den Weg auch sogar schon komplett abgebrochen haben?
Also abgebrochen, abgebrochen vielleicht nicht, aber ich habe definitiv andere, auch die dann an mich berichtet haben oder die ich auch coache, die diesen Weg dann gehen wollten.
Hey, was kann denn mein nächster Schritt an der Stelle sein und wie komme ich da hin?
Und mein Rat dazu ist dann meistens so.
Du musst ja gar nicht so verbissen darauf kommen, ich will jetzt CTO werden, sondern was braucht das Business oder was braucht die Firma und was kannst du für die Firma tun, um sie erfolgreicher zu machen.
Und wenn du mit diesem Mantra da rangehst, dann kommt der Rest wie Beförderung oder es geht weiter in der Regel von ganz alleine.
Also frage immer nicht, ich möchte jetzt befördert werden, das ist ja auch der Klassiker von vielen Leuten her.
Was muss ich denn jetzt tun, um hier befördert zu werden?
A, die Frage gar nicht stellen und B, zu fragen, okay, wie kann ich mich hier einbringen, wie kann ich hier Wert stiften?
Und meine Erfahrung ist, wenn man das gut macht und auch darüber dann natürlich redet, was man geschafft hat, dann kommt der Rest von ganz alleine.
Das heißt, du würdest raten, die Ambition gar nicht zu formulieren?
Die Ambition sollte man schon formulieren, aber dann nicht sagen, die Frage stellen, was muss ich hier tun, um befördert zu werden, halte ich für falsch, sondern die Ambition sollte ich schon formulieren.
Wenn ich jetzt in dieser Firma bleiben will, hey, das ist das, was ich für euch hin will, kannst du mich auch vielleicht zum Interim machen, kannst du mir mehr Aufgaben geben, also wenn jemand direkt an den CTO berichtet, das definitiv schon, aber ich würde dann eher gucken, wie kann ich Wert schiften, Die letzte Stufe wäre davon, niemand berichtet schon an den CTO.
Ja, das ist interessanterweise auch so, je öfter man fragt, desto wahrscheinlicher ist die Antwort nein.
Das lernt man ja schon, bringt man seinen Kindern bei oder so, wenn sie dann irgendwann zum 100.
Mal fragen, ob es jetzt die Süßigkeiten gibt oder ob sie nochmal Fernsehen gucken dürfen.
Wahrscheinlich ist es bei der CTO oder bei anderen Sachen genauso.
Ja, richtig.
Und es nervt ja auch nur.
wenn dann kommt, hey, ich möchte aber eigentlich dahin.
Und was ich meinen Directs, also die Leute, die an mich berichtet haben, immer mitgegeben habe, hey, ich kann dir nichts versprechen, ich kann dich dabei unterstützen.
So große Wunder dauern länger, kleinere kommen schneller, aber definitiv hast du da meine Unterstützung und ich werde dir beim Wachstum helfen.
Du hast jetzt auch...
eine interessante Entwicklung gemacht.
Also du bist ja vom Acting-CTO, du bist danach Interim-CTO geworden, du hast auch Fractional-CTO-Rollen gehabt und bist jetzt CTO in deinem eigenen Unternehmen.
Inwiefern unterscheiden sich denn diese verschiedenen Ausprägungen der CTO-Rolle?
Wo siehst du die Gemeinsamkeiten und wo siehst du die maßgeblichen Unterschiede?
Ja, also die Unterschiede sind extrem, sage ich mal.
Also während es bei Bubble halt darum ging, eine sehr erfolgreiche Berliner Firma weiter zu skalieren, also die Botschaft sich anzugucken, wie kann man die weiter skalieren, wie kann man die Firma insgesamt reifer machen, ging es bei Benefix, ging es um eine...
Die hatten ja eine ähnlich große Firma Benefy gekauft mit einer komplett anderen Kultur.
Da kommt die englische Kultur auf die schwedische Kultur, weil die Firma Benefy sitzt in Schweden.
Und da ging es darum, diese beiden Firmen miteinander zu integrieren, auf technischer und als auch auf kultureller Natur, was eine sehr spannende Herausforderung ist.
Und jetzt bei meinem Startup ist es jetzt wieder so...
auch selber wieder hands-on zu sein und selber Sachen zu entwickeln.
Und es geht gar nicht so stark darum, Menschen zu führen.
Das ist ja auch wesentlich kleiner als die Organisation mit mehreren hundert Engineers, die ich vorher geführt habe.
Es heißt alles CTO, aber die Rollen sind eigentlich völlig unterschiedlich.
Was gleich am Ende des Tages ist, Als CTO bist du die Person, die die Hauptverantwortung für alle technischen Entscheidungen und für die technische Ausrichtung trägt.
Du hast es ja gerade sehr gut beschrieben, wie sehr sich diese Rollen dann auch unterscheiden.
Hast du eine Entscheidung mal parat, so als Beispiel, aber exemplarisch, die in dem einen Unternehmen richtig gewesen wäre und im nächsten komplett falsch?
Oder vielleicht kannst du es an einem...
Beispiel ausmachen, wie man diese Unterscheidung der verschiedenen Perspektiven oder auch der verschiedenen Ausprägungen der Rolle, die das ja auch manchmal mit sich bringt, wie sich das greifbar machen lässt.
Ja, also ich kann jetzt nicht ganz konkret sagen, das war so, ich muss ein bisschen gucken, was ich erzählen darf und was nicht, aber jedes Unternehmen hat halt so seine Herausforderungen.
Es gibt die Wachstumsunternehmen und dann gibt es eher die, ich muss jetzt auf eher darauf optimieren, auf meine Kostenbasis und dementsprechend passt das nicht immer alles, was auf das eine geht, passt auch auf das andere.
Also es kommt immer auf den Kontext des Unternehmens an und wo sie halt gerade an der Stelle hinwollen.
Also one size fits all gibt es da.
Ich strauche hier sogar so ein bisschen, weil ich nicht weiß, was ich öffentlich erzählen darf.
Hier darfst du alles erzählen, natürlich.
Du hast eben auch was sehr Richtiges gesagt.
Deine CTO-Rolle jetzt gerade im eigenen Unternehmen, die ist natürlich nochmal viel mehr Hands-on.
Das ist aber auch tatsächlich ein Muster, was mir von Executive Recruitern auch sehr viel stärker noch reflektiert wurde, dass das eine Veränderung ist, die ganz allgemein die CTO-Rolle jetzt in 2026, durchgemacht hat, dass ein sehr viel größerer Anteil an Hands-on-Arbeit wieder erwartet wird, gerade natürlich im ER-Bereich, weil es Leute braucht, die Aktivrichtung mit vorgeben müssen.
Und das können sie hauptsächlich, wenn sie sich selber auch aktiv damit auseinandersetzen.
Also deswegen, ich glaube, es ist nachvollziehbar, dass du in deinem eigenen Unternehmen nochmal sehr viel mehr näher an der Technik bist.
Aber wahrscheinlich wäre es auch in anderen Unternehmen, in größeren, würde das auch von dir verlangt werden würden.
Oder siehst du das anders?
Nee, das ist definitiv so, dass sich durch diese, durch KI, durch generative KI die Rolle auch nochmal drastisch verändert und auch, dass die PEs und Investoren also oder die VCs auf ganz andere Profile gucken.
Jetzt wollen sie Personen haben, die die Organisation transformieren.
Im PE-Bereich geht es ja sehr stark um Kosten-Sink.
Und sie wollen Leute, die auch selber wieder mit Hand anlegen und die Materie verstehen.
Vor einem Jahr ging es so richtig los mit Cloud Code.
Und da habe ich selber auch wieder angefangen, nach langer Zeit wieder Hands-on zu arbeiten, was ich bestimmt fünf, sechs Jahre vorher nicht gemacht habe.
Ich habe selber Anwendungen geschrieben und habe den Leuten gezeigt, hey, es geht doch jetzt viel schneller.
Ihr könnt es doch selber machen.
Und so hart es klingt, man muss als CTO denn anfangen, vorher hat man nur Leute geführt.
Jetzt muss man auch in der Lage sein, Agenten zu orchestrieren.
Und man braucht nicht mehr so Riesenteams von mehreren hundert Personen.
Man kann mit sehr viel weniger Leuten sehr viel mehr auf die Beine stellen.
Und das ist eine Transformation, die viele noch nicht so richtig wahrhaben wollen und wo viele noch, ich sag mal, sehr weit zurück sind.
Also für mich, jede Führungskraft im Engineering.
die nicht angefangen haben, selbst wieder Hands-on zu werden im KI-Zeitalter, finde ich schwierig.
Und natürlich frage ich die Frage, was ist denn, was heißt denn hier Hands-on, dann müssen die selber wieder programmieren.
Nein, aber sie müssen selber in der Lage sein, Agenten zu steuern, die dann am Ende des Tages die Arbeit machen, also zu programmieren, die Spezifikation zu verstehen, zu testen.
Und wenn ich mich nicht selber damit beschäftigt habe, glaube ich, kann ich diese Transformation in einem Unternehmen, und die wird jetzt von allen Seiten gefordert, auch nicht anführen.
Ja, sehr richtig.
Und wie viele Unternehmen, also du warst 2021, warst du, glaube ich, noch bei eBay.
Das war so, glaube ich, das letzte Jahr, in dem das Thema Skalierung noch irgendwie oder Unternehmen skalieren dadurch, dass man sehr viel mehr neue Mitarbeiter einstellt.
Das war damals das Allheilmittel für alles.
Damit hat man Wachstum finanziert und man hat ganz viele Engineers eingestellt.
Und wenn man die an dem einen Ort nicht mehr gefunden hatte, wo man war.
Dann hat man einen neuen Standort aufgemacht, vielleicht in einem anderen Land und hat dort Leute eingestellt.
Seit diesem Zeitraum hast du auch eine ganze Menge anderer Organisationen schon gesehen.
Wie viele dieser Organisationen haben sich mit dem Thema Scale auf People-Basis seitdem noch auseinandergesetzt, die du jetzt kennst?
War da eins dabei?
Ja, durchaus.
Ich würde sagen, es ging noch weiter.
Es ging noch bis 2022.
Weil warum denn die Skalierung hat ja dann aufgehört, wegen eher, weil sich der Investorenmarkt, weil die Zinsen gestiegen sind, weil wir Kriege in Europa hatten, deswegen war die Jobaussicht nicht mehr so rosig und deswegen haben Firmen aufgrund der Konjunktur, weil sie einfach gerade nicht mehr skalieren konnten, aufgehört zu skalieren.
Dass sie anders skalieren können, Das ist ja eigentlich erst, was seit einem Jahr so der Fall ist.
Also auch bei Bubble haben wir durchaus nach wie vor, also das war ab 2022, weiter Leute gesucht, weiter Leute reingestellt, weil technisch war man auch noch gar nicht, dass man jetzt viel mehr über KI machen kann und ganz andere organisatorische Setups wählen kann.
Also das ging da an sich schon weiter.
Aber der Bedarf war gerade aufgrund der geänderten Wirtschaftslage ab 2022 nicht mehr da.
Und jetzt so richtig geht es mit der KI erst los.
Ich finde, vor ungefähr einem Jahr ging es los mit immer mehr Firmen, die jetzt da mit auf den Zug springen.
Wie viele Leute brauchst du denn in deinem Unternehmen bei Clarice AI, um eine vernünftige Produktentwicklung inklusive Produkt- und Engineering auf die Beine zu stellen?
Gerade vor dem Hintergrund, was jetzt mit AI notwendig ist.
Wie viele Engineers hast du und wie viele glaubst du, wirst du mittelfristig brauchen mit dem Produkt?
Und wie viel kannst du tatsächlich orchestrieren?
Ich bin da sehr radikal, was das eigene Unternehmen angeht.
Ich habe bis zu zehn Agenten, die das Ganze machen, aber ich habe keinen einzigen Engineer eingestellt.
Und das ist jetzt sehr hart formuliert.
Und ich habe auch nicht vor, auf mittelbare Zeit einen Engineer einzustellen, sondern ich steuere aktuell absolut nur Agenten aus, die die ganze Produktarbeit und Produktentwicklung machen.
Im Startup funktioniert das.
Das funktioniert vielleicht nicht überall in dieser Radikalität, sondern nur im Ansatz in größeren Unternehmen.
Aber das ist, glaube ich, die Zukunft.
Für mich ist es immer so wie Anfang des 20.
Jahrhunderts die Automobilindustrie, wo mehrere hundert Leute am Fließband standen und irgendwelche Schrauben reingedreht haben oder halt programmiert haben.
Und dann kam die industrielle Revolution im Sinne von vielleicht sogar die zweite.
dass mehr Roboter, mehr Maschinen eingeführt werden.
Und auch heute laufen auch in so einer Assembly Line auch noch Leute rum, aber die steuern halt die Roboter aus.
Und genau so läuft unser Startup auch.
Wir haben keine Engineers eingestellt aktuell und wir werden auch derzeit noch keine einstellen.
Aber was wir brauchen, wo wir Bedarf haben, ist dann bloß um die zwischenmännische Kommunikation geht, zu verstehen, was wollen denn die Kunden oder auch im Vertrieb.
Da sehe ich als nächstes den größeren Bedarf an der Stelle.
Dass was genau passiert, dass der Bedarf aus Vertrieb und aus Customer Success besser übersetzt wird in Produktentwicklung und in neue Spezifikationen oder warum genau?
Am Ende des Tages, gerade im B2B-Bereich, treffen Menschen die Entscheidung, was sie kaufen.
Und dementsprechend brauchst du auch Menschen, die mit ihnen sprechen und überzeugen, was brauchst du denn und was brauchst du nicht und da dann auch die Sachen rauskitzeln.
Also was Produktentwicklung angeht, das ist ja, ich meine, was wir mit Clarisse ja de facto machen, ist, dass wir auch Kundenverhalten synthetisieren und dir ungefähr vorhersagen können, was könnte dein Kunde gebrauchen und was nicht.
Im Vertrieb, solange die Vertriebsentscheidungen, die Kaufentscheidungen von Menschen getroffen werden, brauchst du auch, glaube ich, Menschen, die mit deinen Kunden kommunizieren und sie auch hier und da von den besten Lösungen überzeugen und auch dazu beraten können.
Du hast jetzt eben gesagt, dass du deine Agents, also dass du zehn Agenten hast und dass du die orchestrierst.
Wie orchestrierst du sie denn?
Ich habe einen Spritzen-Flow dazu entwickelt.
Also ich hasse diesen Term Vibe-Coding, weil was sie machen, ist kein Vibe-Coding, sondern die arbeiten sehr stark nach einem Specification-Driven-Development-Prozess.
Das heißt...
Die müssen alle ihre Änderungen spezifizieren.
Dann gucke ich über diese Spezifikation auch nochmal rüber.
Das ist das, wo dann natürlich irgendwann, wo das Bottleneck dann kommt.
Weil ich lasse kein nichts auf die Plattform, wo ich mir nicht die Produktspezifikation angeguckt habe.
Dann müssen die einen Entwicklungsplan schreiben, müssen diesen Entwicklungsplan in Aufgaben runterbrechen, müssen die Implementierung vornehmen, müssen Reviewen, müssen Security Reviews machen, müssen Statisch testen, müssen Live testen.
Und dann müssen sie es irgendwann auf ein Staging-System bringen.
Und das machen die mittlerweile voll automatisiert.
Und wie oft bist du versucht, so ein Looks-good-to-me und dann durchzuwinken?
Klar, man guckt dann alles wieder an und irgendwann, nachdem du dir 20 Mal was angeschaut hast, was irgendwie ganz gut aussah, irgendwann denkst du so, ja, sieht doch ganz gut aus.
Nächste Station, da winke ich mal durch.
Also Hand aufs Herz, wie oft passiert dir das?
Oder bist du wirklich so diszipliniert, dass du dann sagst, nee, ich gucke mir wirklich alles genau an und nicht durchdenke es vorher und ansonsten gebe ich keine Spezifikationen frei?
Die Spezifikation gucke ich mir schon an, aber was danach kommt, was ich mir nicht mehr angucke, und das ist ja auch die Diskussion in der Community, ist die Zeilen Code.
Ich glaube, du musst stattdessen einen Harness, eine Umgebung schaffen, wo du die Ergebnisse verifizierst und validierst.
die produziert werden.
Also schaust, dass das, was rauskommen muss, auch rauskommt.
Das ist so ein bisschen für mich wie auch im Deep Learning Bereich selber.
Wenn ich da ein Modell aufbaue, ein Modell trainiere, als Mensch guckst du auch nicht, kannst du auch gar nicht mehr sogar bei Deep Learning.
Wie sind jetzt die Verschachtungen der einzelnen virtuellen Neuronen in dem Netz?
Aber du kannst das Ergebnis prüfen.
Richtig.
Und genau so musst du es auch beim Agenting Engineering machen.
Also es kommt nicht mehr darauf an, dass du jede Zeit ein Coder liest oder dich dann beschwerst.
Also auch Firmen, die ich da beraten habe, sagst, hey, aber der Coder, der gefällt mir nicht, den der Agent da geschrieben hat.
Also zwei Punkte dazu.
Also entweder leitet den Agenten halt besser an, wenn dir der nicht gefällt.
Aber zweitens, warum muss der denn überhaupt so aussehen?
Weil im Zweifelsfall nehme ich halt die nächsten Agenten, wenn mir da irgendwas nicht passt und lasse das App ändern oder wenn es gar nicht mehr geht, lasse ich es auch neu schreiben.
Ja, man könnte ja auch sagen, dass es unwirtschaftlich ist, überhaupt diese Form, also überhaupt dafür Tokens zu verschwenden, seinen Agent anzuweisen.
Ich übertreibe es, weil ich sage, das Clean-Code-Manifest zu berücksichtigen und allen Code nach Clean-Code-Manifest zu schreiben, könnte ja auch eine Verschwendung von Tokens sein.
Und damit ist es auch wirtschaftlich nicht sinnvoll, das zu tun.
Wenn man nicht den Anspruch hat, jede Zeile Code nochmal selber oder theoretisch jede Zeile Code von Menschen nochmal begutachten zu lassen.
Aber du hast gerade was sehr Wichtiges gesagt.
Du hast gesagt, man muss halt schon messen, ob AI tatsächlich zu dem guten Ergebnis führt.
Woran misst du denn, ob das auch passiert, ob sie tatsächlich schneller zu einem guten Ergebnis führt und nicht nur schneller sehr viel mehr Code produziert?
Naja, einmal wie gesagt, die Spezifikation, die zwar auch von Agenten erstellt wurde, aber die wird natürlich auch nochmal in Vorgaben und da sind halt funktionale Anforderungen drin und aber auch nicht funktionale Anforderungen.
Und dann, was halt produziert wird, wird gegen diese funktionalen und nicht funktionalen Anforderungen getestet.
Darüber hinaus gibt es aber gerade im B2B-Bereich, was sehr wichtig ist, ist Sicherheit natürlich.
Das heißt, Ich lasse alle Softwareänderungen auch nochmal auf Sicherheit testen und nicht nur nach Sicherheitslücken, sondern es gibt ja den OVAS Application Security Verification Standard mit den drei Leveln.
Dann lasse ich alle, das ist ein Kriterienkatalog von 300 verschiedenen Punkten.
Das muss auch getestet werden.
Dann lasse ich sie auch Test-Driven Development machen.
Nicht, weil die dadurch keine Bugs mehr machen, sondern weil dadurch Regression halt schwerer wird.
Weil dann...
Wenn denn der nächste Agent irgendwas ändert und irgendwas auseinanderfliegt, sieht man es.
Und so, dass es halt ein umfangreicher Testkatalog ist aus funktionalen und nicht funktionalen Anforderungen, Sicherheit, natürlich auch ein Code-Review und letztendlich den statischen Tests, aber auch den Live-Tests.
Du bist ja eine Ein-Personen-Organisation, die jetzt zehn Agents orchestriert.
Eine solche Veränderung werden wir auch in anderen Organisationen sehen, dass ein bis zwei Personenteams existieren werden, die eine Armada von Agenten kontrolliert.
In einem Startup hat das vielleicht noch relativ geringe Auswirkungen, weil sie sowieso sehr klein sind.
Aber was macht das denn potenziell mit den größeren Organisationen, wenn wir jetzt auf einmal nicht mehr Teams mit einer Größe von vier bis acht Leuten haben, sondern wirklich nur noch Teamgrößen von ein, zwei, maximal drei menschlichen Mitarbeitern, die aber eine sehr große Anzahl an Agenten verantwortet.
Kannst du dir ausmalen, was für einen Impact das auf Organisationen und ihre Teams haben wird?
Ja, durchaus.
Also für mich auch die Firma, die ich gesprochen oder die ich beraten habe, ist der größte entscheidende Punkt, es ist nicht die Technologie, die ist da.
Der kulturelle Wandel, der ist die große Herausforderung.
Also wie kriege ich Teams, die dahin von fünf bis acht Leuten anders zu arbeiten, also erst da kleiner zu schneiden?
Weil durch Agentic Engineering gibt es halt zwei große Hebel.
Natürlich, die Agent kann schneller programmieren.
Aber wir wissen auch, programmieren ist gar nicht unbedingt das, was am längsten dauert.
Wenn ich aber in einem Team nur noch ein bis zwei Leute habe, dann gefallen auch sehr viel Abstimmungen zwischen diesen einzelnen Teammitgliedern.
Und das ist der zweite große Hebel, der dann für sehr viel mehr Geschwindigkeit lockt.
Nichtsdestotrotz, gerade unter den großen Unternehmen ist es halt eher schwieriger, weil da geht es natürlich auch um Menschen und um deren Ängste.
Und das, hey, wenn ich das jetzt mache, fällt dann mein Job weg.
Es gibt durchaus Unternehmen, die das tun.
Es gibt auch Unternehmen, die sagen, nee, das ist gar nicht das Ziel.
Wir wollen einfach mehr leisten können.
Wir haben doch so viele Ideen.
Wir wollen einfach mehr machen können.
Und also ich denke, es geht auch im Enterprise-Kontext, wenn man halt...
Die, also die Wide and Conquer, das kennen wir alle als Ingenieure, wenn man die Einheiten klein genug schneidet und wenn man dann da auch entsprechend Freiheiten lässt und die Teams auch kleiner macht und auch an die Prozesse rangeht.
Weil was ich oft sehe, ist, auch größere Firmen sagen, ja, nee, KI machen wir alles.
Und wenn man näher hinterguckt, haben den Entwickler ein Agenting Engineering Budget von 200 Euro und geben davon die Hälfte aus.
Und dann muss er sich, ja, aber irgendwas schneller sind sie ja natürlich auch nicht geworden.
Nein.
Weil die einzige echte KPI ist nicht, und da habe ich auch schon tausende Diskussionen, selbst in der Vergangenheit schon in meinen Fractional- oder Interim-Mandaten, hey, welches KPI nutzen wir denn, um, wie viel Code produziert wird.
Sind es irgendwelche SDSC-Metriken?
Für mich gibt es nur eine einzige Metrik.
Wie viele Leute brauchst du in einem Team, um dasselbe zu shippen wie vorher?
Und da sind gerade so die mittleren und größeren, die tun sich da an der Stelle noch ein bisschen schwer.
Und das heißt nicht, dass ich die anderen da rausschmeißen soll.
Nein, nein.
Das heißt nur, dass ich meine Organisationsform ändern muss, um dann schneller agieren zu können, weil ich damit den Kommunikationsaufwand senke.
Und weil ich damit auch wirklich schneller Sachen auf die Straße bringen kann.
Ich bin mir zum Beispiel aktuell gar nicht sicher, was wir denn jetzt tun sollen mit der neuen Kapazität.
Also du hast ja gesagt, wir wollen ja nicht zwangsläufig Leute rauswerfen.
Ja, auf der anderen Seite, gibt es denn so viel mehr Ideen, die man jetzt noch an sein bestehendes Produkt dranflanschen muss, damit es noch besser wird?
Oder sind wir jetzt alle dazu verleitet, im Endeffekt Feature?
zu betreiben und ganz viel mehr Dinge zu bauen, die wir eigentlich effektiv gar nicht bräuchten, wir aber bauen, weil wir jetzt gerade die Kapazität dafür haben.
Wäre es da nicht wirtschaftlich sinnvoller, und das ist jetzt wirklich explizit nur eine hypothetische Frage, aber wäre es nicht sinnvoller für Unternehmen zuerst mal zu sagen, wir gucken, was wir...
mit der Kapazität jetzt hinbekommen.
Also wenn wir mit AI dreimal schneller geworden sind, dann gucken wir, brauchen wir vielleicht gar nicht mehr so viele Leute.
Lass uns erstmal konsolidieren und mal gucken, wie wir dann wieder, wenn wir uns gesettelt haben, wenn alles funktioniert, dass wir dann wieder skalieren.
Das hätte natürlich einen großen Einfluss auf den Arbeitsmarkt für Engineers, again.
Aber ich bin mir gar nicht so sicher, ob so.
Lass uns alle Leute zusammenhalten.
Irgendwie wird es schon gehen und dann gucken wir mal, was daraus wird.
bin ich so überzeugt, ob uns das immer zum schnellsten Ergebnis führt.
Nee, das ist fair.
Auf der anderen Seite, wenn ich so rangehe mit diesem Mindset, werde ich, also wenn du jetzt Entwickler in einem Team wirst, würdest du dann die AI-Transformation da rantreiben?
Fair point, ja.
Dann würdest du nämlich an deinem eigenen Stuhl sehen.
Also kann man natürlich auch machen.
Es gibt auch Unternehmen, die das tun.
Die schauen, welche sind jetzt, wo sind die Leute, die da mitgehen wollen?
Für die haben hier noch einen Platz und die anderen haben keinen Platz mehr.
Und die erkennt man ja auch relativ schnell.
Wer ist vorne dabei?
Wer treibt diese Themen voran?
Wenn ich das aber so mache, dann wird es wesentlich schwieriger sein, diese Transformations-Egentic-Engineering-Sight-Ader hinzukriegen, weil warum sollte ich als Entwickler an meinem eigenen Stuhl sägen?
wenn ich dann befürchtet habe, okay, ich mache das jetzt.
Because there is no other choice.
Also wenn sich überall, das ist ja keine Änderung, die nur in einem Unternehmen passiert, sondern sie passiert ja parallel überall.
Also die Antwort darauf könnte ja auch sein, der Engineer hat keine andere Wahl.
Wenn er relevant bleiben will, muss er an dieser Transformation mitarbeiten, in der Hoffnung, dass er gut genug ist, um jetzt diese Welle, die vielleicht jetzt kommt, zu überleben.
um dann später, also keine Ahnung, das ist ja jetzt rein hypothetisch, aber du schüttelst mit dem Kopf?
Naja, das ist halt, ich schüttel so viel mit dem Kopf, weil ich diese Diskussion bestimmt mit unzähligen Ingenieurs-Tagen geführt habe.
Es gibt zwei Lager, die sich da zu spalten.
Es gibt die, die Welle reiten und die sagen, hey, ja, ich will das tun.
Und dann gibt es die Leute, die sagen, nee, also weißt du, Benjamin, ich mag das eigentlich und ich habe Angst, wenn ich das jetzt hier nicht mehr mache, dann verlerne ich das nachher.
Und ich denke, du musst die Welle da an der Stelle reiten, um nach wie vor überhaupt im Markt zu bleiben.
Aber es wird genug Unternehmen noch geben, die das nicht machen.
Entweder, weil sie es nicht müssen, weil es ihnen wirtschaftlich sehr gut geht oder weil sie bei Unternehmen vielleicht arbeiten, was da auch sehr langsam vorangeht.
Also noch wird es sie geben.
Wird es ja auch noch in fünf Jahren geben?
Oder Zeitlos?
Es wird auf jeden Fall schwieriger.
Von daher muss das die Transformation sein.
Nichtsdestotrotz, wenn ich da reingehe und sage, hey, so Leute, wir machen jetzt mal Agentic Engineering und danach schmeißen wir irgendwie 50% oder 80% der Leute raus, halte ich das, glaube ich, für den falschen Ansatz.
Und ich kann mir nicht vorstellen, dass das von großem Erfolg gekrönt sein wird.
Das werden wir sehen, weil tatsächlich gibt es Unternehmen, die genau diesen Ansatz fahren und die Frage ist, was ist jetzt richtig?
Ich glaube, das lässt sich auch nicht pauschal beantworten, sondern muss dann immer für Case-by-Case betrachtet werden.
Aber klar, beide Seiten können Recht haben, beide Seiten können daneben liegen.
Ja, weißt du, was ich mir auch frage?
Wir hatten vorhin das Thema Engineering Teams und organisatorische Änderungen und sowas gesprochen.
Was macht das denn mit den Status Quo Frameworks, die es dann aktuell gibt?
Also gerade die Frameworks, die die Organisation von Menschen im Enterprise-Umfeld betrachten, Scrum, Kanban, was auch immer.
Was macht das mit diesen Arbeitsmodellen?
Lass mich mal so formulieren.
Ich glaube, die brauchst du in dieser Form.
Also bei Scrum ist ja sehr prozessual, welche Meetings du hast und so weiter.
Ich denke, das brauchst du in dieser Form an der Stelle nicht mehr.
Ich denke, es wird eher in Richtung, welche agentischen Prozesse geht, wie zum Beispiel Specification for Development und andere.
Diese werden eher relevanter sein.
Und warum ich auch denke, so diese klassischen Kanban und Scrum.
Es kommt ja jetzt dadurch, dass man jetzt wesentlich schneller ist im Bauen und das hast du ja auch schon angeführt mit dem, hey, wir bringen jetzt was, immer mehr Features da zu bauen und die Kunden brauchen wir gar nicht.
Es ist jetzt viel relevanter geworden.
Was baue ich eigentlich?
Das ist ja auch das, warum wir dieses Startup gegründet haben, weil wir auch schon vor einem Jahr gesehen haben, okay, also Engineering kann ja sehr schnell sein.
Der Flaschenhals wird jetzt aber mehr und mehr.
Was soll ich bauen?
Und deswegen glaube ich auch, dass diese traditionellen, du hast einen Produktmajor, dann hast du fünf bis acht Leute, dass das so nicht mehr Bestand haben kann und wird.
Ich denke, das Verhältnis zwischen Leuten, die entscheiden, was gebaut wird, früher Produktmajor, und Leuten, die sagen, wie es gebaut wird, früher Engineers, wird sich drastisch verändern und da gibt es ja Hypothesen auch aus dem Valley, also aktuell ist 1 zu 1 möglich, in der Zukunft ist es vielleicht sogar 1 zu 0,5 oder diese Rollen von Produkt und Engineering konverieren komplett und du sprichst am Ende des Tages von Produkt Engineers, die ein Produkt von End-to-End bauen, die ein Engineering-Intergrund haben, die Business-Verständnis haben und die dann ein Produkt bauen.
Jetzt kann man sich überlegen, also zwei mögliche Zukunftsszenarien, die ich da sehe.
Und ich möchte das mit einer Frage an dich mal anfangen.
Glaubst du, wir haben Peak Engineering bereits gesehen?
Also die Menge an menschlichen Mitarbeitern, die im Software Engineering Bereich arbeiten.
War dieser Zeitpunkt schon oder steht er uns noch bevor?
Ich denke, der steht uns noch bevor, aber mit einer ganz anderen Rolle.
Also ich denke, es geht eher in Richtung Product Engineers und dadurch, dass es günstiger wird, Software zu bauen, so Softwarelösungen zu bauen, wird auch der Bedarf und du kannst auf einmal Lösungen für Systemproblematiken bauen, die du vorher, ja, das ist vorher viel zu teuer gewesen wäre.
Von daher, ich glaube, es wird mehr Leute geben, die Software bauen und die das möglich machen.
Ist das jetzt reines Engineering?
Nein, wie gesagt, es wird für mich eine Mischform sein zwischen Produkt und Engineering.
Aber ich denke, es wird davon mehr Leute geben.
Es wird aber auch Verlierer geben.
Und das sind die Leute, die sagen, hey, da mache ich nicht mit.
Also ein CTO, der heute nicht selber schon Agenten orchestriert, ich glaube, Das wird sehr, sehr, sehr schwierig werden, auch in Zukunft.
Und dementsprechend ist es auch wichtig, sich damit zu beschäftigen.
Und da spielt es keine Rolle, ob man 300 Leute führt oder 30 oder nur drei.
Oder auch jeder Engineering Leader in der Organisation.
Wenn Engineering Leader in der Organisation nichts schafft, Agenten zu führen oder zu orchestrieren, dann wird es, glaube ich, schwierig in dieser Rolle.
Ja, jetzt stelle ich mir die Frage, wir haben jetzt noch vor zehn Jahren oder wahrscheinlich vor fünf Jahren noch, haben wir immer wieder gesagt, wir wollen, dass unsere Kinder alle müssen eigentlich irgendwelche Programmiersprachen lernen.
Ganz, ganz wichtig.
Ja, gucken, hat sich nicht so lange gehalten.
Und ich muss dazu sagen, also vor 15 Jahren war ich auch einer, der gesagt hat, ja, alle Kinder irgendwie programmieren, das ist das Wichtigste, was sie überhaupt machen können.
Ich glaube, das hat sich relativ schnell, ist das obsolet geworden.
Also natürlich brauchen wir immer noch sehr gute, sehr gebildete und sehr starke Engineers und welche, die Informatik und Computer Sciences verstehen.
Aber wir brauchen sie wahrscheinlich nicht mehr in dieser breiten Masse mit diesem Skillset.
Und das ist so die Krux bei der Geschichte, die ich sehe.
Ja, und es geht, ja, das denke ich auch.
Also ich habe selber zwei Töchter.
Ich kann ihn gerade nicht, vor allem gewissens 39 Jahre.
Würde ich ihm jetzt empfehlen, Informatik zu studieren?
Weiß ich nicht.
Ich glaube, es ist da, die Jobs in Zukunft werden Relevanz haben, wo es um zwischenmenschliche Interaktion geht und die ist beim reinen Engineering nicht so richtig gegeben.
Wenn ich verstehen will, was machen Kunden denn überhaupt, was wollen Kunden und wie biete ich denn die beste Lösung an, dann wird wieder ein bisschen was anderes draus.
Aber nicht das trotz, ja, empfehle ich beiden auch nicht mehr.
Informatikstudium, muss ich ganz ehrlich sagen.
Noch eine Frage habe ich noch zum Thema Clarice und Clarice AI.
Du beschäftigst dich dort mit synthetischen Kundenpersonas.
Wo hilft diese Methode denn bei einer richtigen Produktentscheidung?
Und wie stellt ihr denn sicher, dass die Antworten, die da simuliert werden, nicht zu falschen Entscheidungen führen?
Ja, also sie hilft quasi im gesamten Produktlebenszyklus und oftmals ist es ja so, dass überhaupt kein Research, auch kein User Research gemacht wird.
Da werden dann irgendwelche Entscheidungen getroffen, weil der Stakeholder XY sagt, hey, finden wir gut.
Und was mit Claris möglich ist, ich kann diese Entscheidung halt innerhalb von Minuten, kriege ich eine Synthese hin, was jetzt echte Kunden davon möglicherweise wollen, simuliert und was nicht.
Nicht, dass du trotz...
funktioniert es synthetischer Customer-Güste, ersetzt es nicht, ergänzt diesen Komplementär, wenn ich halt hier eine schnelle Entscheidung brauche oder es kommt auch auf die Fragestellung an.
Gerade im B2C-Bereich funktioniert es sehr gut, weil wir da auch simulierte Personas haben.
Im B2B-Bereich wird es noch relativ viel schwerer.
Was wir machen, ist, dass wir bei jeder Fragestellung ganz offen dem Kunden auch sagen, hey, hier, da kannst du Klairs nutzen.
Also keinen synthetischen Research machen wir für dich, in Form von User-Tests, Interviews oder Surveys.
Aber hier in dem Fall wird das nicht, wir schätzen da ein, wie valide ist das Ganze, ist es eher, nimm es als directional oder nimm es lieber hier gar nicht oder hier sind wir uns sehr sicher.
Und so, dass wir dir immer die Möglichkeit geben, echten Research oder synthetischen Research zu machen, weil synthetischer Research kann echten Research auch nicht...
komplett ersetzen, aber er hat den großen Vorteil, dass er so viel schneller ist und auf einmal, was wir über die Engineering sprechen und billiger natürlich auch, wäre viel billiger, aber wir im Engineering haben über Loop Engineering gerade gesprochen, wie ich in Loops, was wir mit Clevis dann möglich machen, ist quasi Loop Product Management, dass wir sagen, wir iterieren so lange über eine Seite, lassen wieder unsere von den virtuellen Personas diese Seite testen, sodass man quasi wie auf Stairways das Produkt verbessern kann.
Diese Use Cases wären mit echten Research überhaupt nicht an der Stelle möglich.
Nichtsdestotrotz ersetzt es keinen echten Research komplett, sondern es ist komplementär und man muss auf die gewisse Fragestellung gucken, ob jetzt echter Research oder synthetischer Research funktioniert.
Aber im Unternehmen hast du halt ganz oft, wie gesagt, dass gar kein Research überhaupt nicht gemacht wird.
Und bevor du gar keinen machst, dann mach lieber synthetischen.
Sehr gut.
Benjamin, bevor wir gleich zu der Runde an Rapid-Fire-Fragen kommen, habe ich noch eine Frage an dich.
Und zwar, wenn das hier geht, geht es jetzt auch um den Rat, den du vielleicht zukünftigen CTOs geben möchtest.
Nenn mal angenommen, ein guter Senior Engineer, der möchte dann in den nächsten zwei, drei Jahren möchte er CTO werden.
Welche Erfahrung sollte diese Person denn sammeln aus deiner Sicht?
Und gibt es dann auf der anderen Seite auch eine verbreitete Vorstellung?
von der CTO-Rolle, die du ihr ausreden würdest, weil sie vielleicht schon überholt ist?
Also wer glaubt, dass CTO eine rein technische Rolle ist und denkt, hey, ich bin ja Engineer, jetzt will ich irgendwann CTO werden, weil das ist ja die höchste technische Rolle.
Er oder sie ist da leider auf dem falschen Pfad.
CTO ist keine rein technische Rolle.
CTO ist eine sehr starke Businessrolle.
Und dementsprechend ist das auch meine Empfehlung.
Wenn ich CTO werden will, bringe ich meistens schon eine relativ gute technische Grundlage mit.
Aber zwei Sachen, also gerade wenn ich erst nur auf dem Senior Backend-Wegler bin, fehlen mir.
Einmal Business Acumen, also zu schauen, was braucht die Firma und wie kann ich das in Technik übersetzen.
Und das wird jetzt auch immer wichtiger werden, selbst wieder für diese Product Engineering-Rolle, weil es ist nicht mehr nur relevant, was ich technisch machen kann.
sondern was die Firma braucht, um das zu verstehen.
Also ganz viel in Business Acumen zu investieren.
Und die zweite ist natürlich Führung von Leuten.
Das ist was ganz anderes, als wenn ich jetzt für mich nur selber zuständig bin oder wenn ich für das verantwortlich bin, was ein ganzes Team macht.
Das heißt, wie wirke ich durch andere und will ich das überhaupt?
Will ich durch andere wirken oder will ich selber?
aktiv sein.
Weil wenn ich durch andere wirke, dann führt das auch dazu, dass ich auch für Entscheidungen, die die getroffen haben, bin ich natürlich verantwortlich.
Wenn ich CTO bin und mein Engineer baut da irgendwie Mist oder baut, dann ist das in meiner Organisation passiert.
Ich bin für Misserfolg und Erfolg verantwortlich.
Und das ist das, was man lernen muss, wie man dann Teams dazu enabelt, also das Beste aus sich.
rauszurollen und sie auch wachsen zu lassen, weil das ist, glaube ich, die, und das ist nicht nur im Tafel als CTO, das ist mit jeder Führungskraft so, deine Aufgabe ist dann nicht mehr, den besten Code zu schreiben, sondern die Leute dahin zu entwickeln, dass sie das Beste ihres, dass sie ihr Potenzial komplett erreichen können.
Und das sind die beiden Punkte, Business Acumen und wie ich Menschen führe.
Schön ausgeführt und das Bringt uns auch direkt schon zu den Rapid-Fire-Fragen.
Genauer gesagt, fünf Stück habe ich mitgebracht, fünf kurze Fragen.
Wir freuen sich auf fünf kurze Antworten.
Wenja, welche technische oder organisatorische Entscheidung würdest du nie vollständig an einen Agenten delegieren?
Welche technische, ganz definitiv, welche Anwendung geht wirklich in Produktion live, ohne dass ich sie mir in der Apro angeguckt habe?
Würde ich nicht komplett an einen Agenten?
Bei mir geht nichts in Produktion, was ich mir nicht angeschaut habe.
Organisatorische Entscheidung?
welche Person ich einstelle und welche ich geben lasse.
Sehr gut.
Das hätte ich tatsächlich auch so geantwortet, aber das sehe ich schon.
Die zweite Frage, da sind wir eben schon ein bisschen drauf eingegangen.
Ich stelle sie trotzdem und füge noch was hinzu.
Also ein Zwei-Personen-Pod oder ein Zwei-Personen-Team oder ein klassisches Acht-Personen-Team.
Was wählst du heute für ein neues Produkt?
Das ist die Frage und ich würde sie noch ergänzen, um...
Glaubst du, es wird Konstellationen geben, in denen du doch wieder acht Personenteams brauchst im Engineering?
Ich denke, die wird es nicht mehr geben.
Ich denke, es ist eher eine Person.
Es wird natürlich irgendeine Art von Organisationsform geben.
Es kann durchaus dann wahrscheinlich so sein, dass es trotzdem acht Leute gibt, die an einen Engineering Leader berichten oder einen Product Engineering Leader berichten.
Das schon, aber ich wähle immer eigentlich einen Personen-Pod an der Stelle.
Okay, klares Statement.
Ich glaube auch, dass es dahin geht.
Ich bin aber gespannt.
Ich kann mir vielleicht trotzdem vorstellen, dass es noch Konstellationen geben wird, wobei ich auch nicht weiß, welche das sein sollen, fairerweise, in denen es dann doch wieder anders funktionieren muss.
Aber auch hier, die Zeit wird zeigen, wo wir da wirklich landen.
Welche Fähigkeit wird für CTOs 2027 unterschätzt?
Business Impact verstehen und Spezifikationen schreiben und lesen können und Agenten orchestrieren können und wie man das Ganze in die Organisation auch reinbringt und sich nicht einfach davon sagt, hey, ja, wir machen ja schon alles identisch, sondern man muss auch Wege finden, das in die Organisation zu bekommen und es wirklich identisch zu machen.
Das ist ja das Gleiche wie 2026, oder?
Oder was davon wäre jetzt explizit, wo du sagst, das ist jetzt für nächstes Jahr, das steht an, das haben wir noch nicht jetzt schon.
Ich denke, die Product Engineering Leadership Rolle zu formen, ist was, was erst 2027 kommt.
Also wie kann ich Produkt und Engineering wirklich zusammenführen und Leute finden, die beides abdecken können und auch hochqualitative Software schreiben können.
Weil derzeit sehe ich viel Webcoding und ich sehe viel klassisches AI-assisted Engineering.
Was ich noch nicht so viel sehe, ist wirklich Agentic Engineering End-to-End.
vom Produkt bis zur Lösung durchgeführt von einer Person.
Ja, sehr wahre Worte.
Ja, doch, 100% gehe ich 100%ig mit dir.
Was war denn dein teuerstes Learning als Tech Leader?
Wann man sich von Leuten trennt und wann hält man an Personen fest?
Da habe ich auch schon sehr bittere Entscheidungen gemacht.
Manchmal ist es so, dass ich zu lange an Personen festgehalten habe, wo ich sage so, hey, Hier hätte man sich wahrscheinlich früher trennen müssen, nicht weil die Person schlecht ist, sondern einfach, weil es einen Mismatch gibt zu, was möchte die Person auch für sich erreichen und was wird von der Rolle erwartet.
Ja, finde ich auch gut.
Dann letzte Frage für heute.
Welchen Rat hättest du deinem früheren Ich als Senior Engineer gegeben?
Lerne, Menschen zu verstehen und Menschen zu fühlen.
Guck dir Simon Sinek an auf YouTube, einer Lieblings, ich sage mal Influencer, auch wenn er dich wahrscheinlich nicht als Influencer beschreibt.
Und lerne die Business-Seite zu verstehen.
Hätte dein früheres Senior Engineering ich auf dich gehört?
Ich hoffe es.
Am Ende des Tages kann ich es nicht sagen.
Aber ich denke schon.
Weil sonst, glaube ich, hätte ich nicht den Weg eingeschlagen, den ich eingeschlagen hätte.
Okay, auch gut.
Sehr schön, Benjamin.
Vielen lieben Dank.
Ich glaube, wir haben heute nochmal hier und da mal unterschiedliche Punkte eingenommen in einer Debatte, die wir beide wahrscheinlich schon an diversen Stellen geführt haben.
Und auch hier haben wir festgestellt, wahrscheinlich werden wir erst in den nächsten ein, zwei Jahren rausfinden, wohin uns der Weg wirklich führt.
Ich glaube, auch an der Speerspitze zu sein, dessen, was da gerade passiert, ist der beste Weg, relevant zu sein.
Nicht nur als CTO, auch als Engineer.
Aber natürlich ist die Frage, wo führt uns das alles hin?
Was macht das mit der gesamten Berufsgruppe?
Aber ich glaube auch, der Product Engineer ist eine Version der Zukunft, die ich auch sehr stark sehe.
Und du hast das Thema Loop Engineering angesprochen.
Das hatten wir hier im Podcast tatsächlich noch sehr, sehr selten.
Wahrscheinlich werden wir das auch spätestens in 2027 noch viel öfter hören.
Das ist, glaube ich, auch kein Hype-Thema, sondern das ist etwas, was noch viel zu wenig tatsächlich in Verwendung ist.
Benjamin, vielen Dank.
Genau, dann kommen wir bei Gelegenheit nochmal darauf zurück und schauen, wer von uns denn jetzt mehr Recht hatte als der andere.
Gerne.
Und wenn es nochmal ums Loop Product Management dann auch irgendwann geht, lass uns gerne nochmal sprechen.
Ja, auf jeden Fall.
Das ist ein interessantes Thema.
Das sollten wir gerne tun.
Sehr schön.
Benjamin, dann erstmal dir noch einen schönen Montag.
Alles gut, bis dann.
Vielen Dank.
Tschüss.
Ciao, ciao.