#43 „Jeder Trottel kann heute coden" – warum CTOs jetzt komplett neu denken müssen

Viele CTOs definieren sich noch immer über Technologie.

Über Architektur.
Über Frameworks.
Über Engineering Excellence.

Doch genau das steht gerade zur Disposition.

In dieser Folge spreche ich mit Konstantin Diener, CTO der cosee GmbH, über einen radikalen Wandel im Tech-Umfeld:
Wenn „jeder coden kann“ – was bleibt dann eigentlich noch vom CTO?

Wir diskutieren, warum KI und Tools wie Copilot klassische IT-Dienstleistungen zunehmend zur Commodity machen – und warum genau darin eine der größten Chancen für moderne CTOs liegt.

Konstantin teilt dabei seine Perspektive aus über 20 Jahren Erfahrung im IT-Services-Markt und zeigt, warum sich der Fokus verschiebt:

Weg von der Umsetzung von Wunschlisten.
Hin zu echter Produktverantwortung.
Hin zu messbarem Business Impact.

Ein zentrales Thema: Return on Investment.

Warum viele Tech-Organisationen noch immer nicht in der Lage sind, ihren echten Wertbeitrag zu erklären – und wie genau das zum Problem wird, wenn CFOs anfangen, Technologie kritisch zu hinterfragen.

Außerdem sprechen wir darüber:

• Warum IT-Dienstleister gerade massiv unter Druck geraten
• Wieso technologische Exzellenz allein kein Wettbewerbsvorteil mehr ist
• Wie sich die Rolle des CTO vom „Innenminister“ zum „Außenminister“ entwickelt
• Warum Product Thinking zur Pflichtkompetenz wird
• Weshalb viele CTOs aktuell an genau dieser Stelle scheitern

Und wir gehen der Frage nach:
Stehen wir gerade vor dem Ende des klassischen technischen CTO?

Oder erleben wir vielmehr die Entstehung einer neuen Rolle – irgendwo zwischen CTO, CPO und Unternehmer?

Eine Folge für alle, die verstehen wollen, wie sich Tech Leadership gerade fundamental verändert – und was das konkret für die eigene Rolle bedeutet.

Transcript

SPEAKER_00 0:00

Hallo und herzlich willkommen zu Becoming CTO Secrets, eurem Lieblings-Podcast rund um die CTO-Rolle. Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO Community. Und heute zu Gast ist Konstantin Diener. Konstantin ist CTO der COSI GmbH in Darmstadt, einem Unternehmen, das sich bewusst nicht als klassischer IT-Dienstleister versteht, sondern als produktfokussierter Sparing-Partner für Unternehmen, die mit Technologie echt ein ROI erzielen wollen. Return on Invest. Wer schreibt denn so komplizierte Sätze? Das war wahrscheinlich ich in der Vorbereitung. Wie bleibt man als Tech-Organisation relevant, wenn Co-Pilot und Co. vermeintlich alles billiger und schneller machen? Das ist beispielsweise eine der Fragen, die sich Konstantin stellt. Und deswegen sprechen wir auch über den Wandel im IT-Services Markt, über den Shift vom reinen Umsetzer und vom reinen Umsetzen von Wunschlisten hin zu echter Produktstrategie und über eine CTO-Rolle, die immer stärker zum Außenminister wird. Also geht es um Thema Vernetzung, Sichtbarkeit, wie macht man das Ganze strategisch. Ich freue mich, Konstantin, auf eine ehrliche, differenzierte Perspektive von dir. Auf Produkt, auf Return on Invest, auf KI und die Zukunft der CTO-Rolle. Haben wir einiges im Gepäck. Herzlich willkommen. Dankeschön. Ja, das wird ein wilder Ritt, ja. Dauen wir mal, wie wir zeitlich hinkommen. Wir haben ja schon angekündigt, wenn es nicht reicht, dann hauen wir noch eine zweite Aufnahme hinten dran. Konstantin, du bist seit vielen Jahren bei COSI. Wie hat sich denn dein eigenes Verständnis der CTO-Rolle über diese Zeit hinweg verändert? Oder ist es immer noch die gleiche wie am Anfang?

SPEAKER_01 1:36

Nein, es hat sich maßgeblich verändert. Als wir damals gegründet haben, da war die Firma quasi noch mein Hobby an Wochenende und an Abenden. Und ich hatte noch einen Hauptberuf. Da hat mir die Firma schon gegründet und ich war das CTO und ich dachte, ich bin der, der die coolen technischen Entscheidungen trifft und die Prototype implementiert und die Proof-of-Concept-Implementierung macht und den Rest macht dann das Team. Da kann sich jeder hier, jede und jeder im Publikum schon vorstellen, wie geil das die Softwareentwickler bei uns gefunden haben, dass die richtig coolen Sachen der CTO macht, der kaum greifbar ist, dann irgendein halbgar ein Prototyp über den Zaun wirft und die Entwickler dann Fehlerhandling und den ganzen Groundwork machen dürfen. Also das hat schon mal zu Verstimmungen geführt. Und das Zweite, was zu Verstimmung geführt hat, war, dass ich in meinem Hauptberuf zu der Zeit IT-Berater in Banken und Kapitalverwaltungsgesellschaften war. Das heißt, ich mit ganz anderen Tech-Stacks, ganz anderen Anforderungen gearbeitet habe als in so einem Startup. Und meist und völlig zu Recht rückblickend betrachtet, meine Technologieentwürfe von den Kollegen belächelt wurden als, ja, das passt vielleicht in der Bank, aber für so ein Startup ist das vielleicht ein bisschen überkandidat. Ich habe mich dann weiter wegentwickelt, davon wirklich selber in die Tasten zu greifen, wirklich selber irgendwelche Pull-Requests freizugeben oder irgendwas dergleichen, was ich bei vielen CTOs da draußen sehe, dass sie immer mehr zum Bottleneck werden, weil sie immer noch alles unter Kontrolle behalten wollen als oberster Entwickler. Und habe sukzessive die Technologieentscheidungen in das Team gegeben, habe mich in der CTO-Rolle erstmal, so klassisch CTO, immer mehr in so ein, ich will jetzt nicht Governance sagen, weil das so nach Bank wieder klingt, aber so ein, ich schaffe die Rahmenbedingungen, dass die Teams sinnvoll wertstiftend Software bauen können. Und ich gucke auch regelmäßig darauf, ob sie sich an diese Rahmenbedingungen halten. Also wir haben ein Technologieentscheidungsverfahren vor Jahren gegeben und ich bin nicht derjenige gewesen dann, der Technologieentscheidungen getroffen hat, sondern ich habe immer regelmäßig geguckt, ob die Teams sich dann wirklich an das halten, was wir uns davor genommen haben, oder doch wieder ihre Lieblingstechnologie verwenden, anstatt diesen Leitfaden zu verwenden.

SPEAKER_00 4:03

Du bist also quasi der Bademeister, kann man das so sagen?

SPEAKER_01 4:06

Ja, ja, ich bin der Bademeister, ja. Ich muss noch niemanden, hoffentlich niemanden retten. Aber tatsächlich war es dann auch so, dass wir vor ein, zwei Jahren festgestellt haben, dass es noch Defizite in diesem Technologieentscheidungsleitfaden gibt, dass es da noch zu viele Graubereiche gibt. Und dann bin ich auch nicht hingegangen und habe gesagt, ja, das müssen wir jetzt aber anders machen, ihr seid zu doof, sondern habe mich mit den ganzen Softwareentwicklern bei uns zusammengesetzt und haben dann überlegt, was wir denn regeln müssen, wo der Technologie Leitfaden Konkretisierung braucht und wo die Teams weiterhin autonom entscheiden sollen. Denn das ist das Wichtigste, es soll nicht alles über einen Schreibtisch laufen. Und die letzte Phase ist, dass ich in dieser Entwicklung tatsächlich noch mehr zu einem CPTO geworden bin, weil ich in meiner Berufslaufbahn irgendwann festgestellt habe, das ist alles schön und gut. Wenn man eine geile Engineering-Organisation hat, die ein Produkt richtig baut, wenn man das falsche Produkt verlut.

SPEAKER_00 5:07

Jetzt hast du natürlich gesagt, das ist am Anfang, hattest du die Vorstellung, du machst das jetzt irgendwie alles selber, die ganzen coolen Sachen. Jetzt bist du aber schon 17 Jahre CTO, zumindest mal, wenn man deinem LinkedIn-Profil schlauben schenken darf. Das wird ja wahrscheinlich, dann bist du zu dieser Erkenntnis, die du jetzt gelangt hast, bist du ja nicht erst jetzt nach 16 und ein halb Jahren gelangt, vielleicht aber auch nicht erst schon seit einem halben, also nach einem halben Jahr. Wann ist denn dieser Zeitpunkt gekommen, dass du gemerkt hast, du musst deine Interpretation der Rolle überdenken? Oder war das ein schleichender Prozess von Anfang an, der vielleicht sogar immer noch anhält?

SPEAKER_01 5:41

Naja, also natürlich ist das ein kontinuierlicher Prozess, der aber in Eruptionen verläuft. Da gibt es ab und zu so Vulkanausbrüche, zum Teil zwischendrin mal. Ansonsten fließt dieser Prozess. Dieses, du musst die Finger von aktuellen Implementierungen lassen und die Technologieauswahl dem Team überlassen, also erstmal, du musst die Finger von den konkreten Implementierungen lassen, das müssen die selber machen. Das ist so nach ein, zwei Jahren passiert. Daraus folgte dann irgendwann ein, aber wenn die das selber implementieren sollen und nicht du derjenige bist, der sozusagen mal den Rahmen bastelt und sie dürfen den Rest ausfüllen, dann folgt daraus relativ zügig, dass sie auch darüber entscheiden müssen, wie sie das umsetzen und du ihnen das nicht mehr. Also das waren so in den ersten zwei Jahren war dieses, du musst die Flossen von Softwareentwicklungsarbeit lassen. Mir kam zugute, dass ich wenig Zeit hatte. Viele CTOs da draußen haben diesen Luxus nicht, insofern, dass sie noch einen Hauptberuf haben, sondern die reißen sich den Arsch auf und verbrennen sich damit, das Bottleneck zu sein und überall in jedem Service der zu sein, der das genau weiß, wie der implementiert ist, welche Message Q one befeuert wird. Und ja, noch weitere zwei Jahre später würde ich sagen, war die Technologieauswahl vollständig bei den Teams und dann ist es sukzessive weggegangen von Rahmenbedingungen zu schaffen. Was bedeutet auch so in dieser DevOps-Philosophie, was bedeutet das, dass wir Software entwickeln, die sich betreiben lässt, worauf müssen wir achten, and überhaupt weiter weg von dem täglichen Code-Streiben zu kommen. Was aber wichtig ist, auch für die Verankerung in der Mannschaft ist, aktuelle Trends zu verstehen, auf Conferenzen, auf Community-Formaten immer wieder zu verstehen. Auf einer anderen Flughöhe, als die Leute, die das täglich anwenden, aber Potenziale zu verstehen, Gefahren zu verstehen, Auswirkungen zu verstehen. Was passiert da gerade? In der Kommunikation mit Kunden, aber auch in der Kommunikation nach innen. Ich möchte nicht derjenige, natürlich werde ich ab und zu belächelt, dann heißt es ja, Konstantin, als du das noch implementiert hast, hat man noch Software für BlackBerries gemacht und so. Die Sprüche muss ich mir auch mal anhören. Aber wir hatten in der Beratung so jemanden, der hat alles immer mit irgendwelchen Cyb-Base-Beispielen erklärt. Und das ist so mein abschreckendes Beispiel, weil der den Kontakt zur Mannschaft verloren hatte. Der verstand nicht mehr, wie das heutzutage funktioniert. Also das ist das, was ich mal als mein CTO-Party-Latein bezeichne, der sich zu einer gewissen Flughöhe mit den Leuten einsteigen kann und dann aber auch grundsätzlich weiß, was man wofür verwendet und so weiter und so fort und dumme Fragen stellen kann, aber nicht mehr mich hinsetze und dann irgendwelche Helmcharts implementiere oder irgendwie was in Terraform, um irgendwelche Cloud-Ressourcen zu provisionieren?

SPEAKER_00 8:49

Welchen Moment hast du denn irgendwie festgestellt, naja, ich muss jetzt, auch gerade weil es Agenturbereich ist, oder als Dienstleister man auftritt, ich muss jetzt viel mehr nach außen wirken als vielleicht der klassische CTO eines SaaS-Unternehmens. Kam dieser Moment relativ früh oder bist du da auch im Laufe der Zeit reingewachsen? Weil du bist gerade sehr aktiv, natürlich, was so die Außendarstellung angeht und die Repräsentation des Unternehmens nach außen. Wann ist dieser Zeitpunkt gekommen? War das auch so eine erruptive Erkenntnis?

SPEAKER_01 9:21

Ey, also meinen ersten Konferenzvortrag auf einer großen Konferenz habe ich noch als Berater gehalten, 2010. Und dann war aber relativ klar, auch wir hatten ja als IT-Dienstleister über lange Zeit eher die Herausforderung, gute Leute zu finden, als Kunden zu finden. Und insbesondere wenn man eine kleinere Unternehmung im Rhein-Main-Gebiet ist, wo man sehr große Arbeitgebermarken außenrum hat, die auch horrende Gehälter zahlen, ist das was, wo du dich zügig positionieren musst und zeigen, hey, was tun wir hier? Wir verstehen unser Handwerk. Also wahrscheinlich ist es am Anfang eher daraus entstanden, zu zeigen, dass hier modern Software entwickelt wird und Digitalprodukte gebaut werden, um potenzielle Kolleginnen und Kollegen aufmerksam zu machen. Und dann hat sich der Fokus irgendwann verschoben, dass es auch wichtig ist, Menschen, die das einkaufen wollen, dafür zu begeistern.

SPEAKER_00 10:25

Gab es dann auch einen Punkt dafür, an dem du gemerkt hast, naja, die reine technische Expertise und dass die technische Leitung ist es nicht nur, sondern du musst jetzt auch einen, ja, ich nenne es mal, unternehmerisch mitgestalten und musst mehr Richtung Richtung Business arbeiten?

SPEAKER_01 10:40

Naja, also ich habe das Unternehmen ja mitgegründet. Das heißt, so richtig fremd war mir das noch nie, wobei das ja niemand von uns gelernt hatte. Auch keiner von den handelnden Personen hatte jemals Betriebswirtschaftslehre studiert. Ich habe in meinem Informatikstudium im Master eine Vertiefungsrichtung Wirtschaftsinformatik gehabt. Da war eine ganze Veranstaltung, die man Sorten rein der Wirtschaftsinformatik hatte zuschreiben können. Und das war so ein Gemischtwarenladen zwischen doppelte Buchführung, Informationssysteme, Data Warehousing und was weiß ich noch allem. Also die unternehmerische Verantwortung ist ja als Gründer ja sowieso, die kannst du nie völlig ausblenden. Oder ich finde Menschen beeindruckend, die das können, ihre Verantwortung, unternehmerische Verantwortung auszublenden, aber in dem Kontakt mit Kunden zu dieser ganzen Produktdenke und Wirtschaftlichkeitsdenke, unternehmerischen Denke, sind wir eigentlich durch Schmerzen gekommen. Es war so, und das wird der ein oder andere, der im Dienstleistungsgeschäft unterwegs ist, auch kennen. Wir haben immer wieder Kunden gehabt, und da sind wir bei technischer Exzellenz, die sagten, hey, eure Softwareengineers sind voll geil und die denken mit und das macht echt Spaß und bla bla bla, aber ihr seid zu langsam und zu teuer. Bitte? Ihr seid zu langsam, ihr seid zu teuer, das muss alles schneller gehen, das muss alles billiger gehen, sagt wer? Ja, das muss schneller gehen, gemessen an was. Und irgendwann, da gibt es bestimmt genügend Leute, die sagen, ja, ist halt ein doofer Kunde, wir suchen uns den nächsten Kunden, bis der doof wird. Und wir haben halt, insbesondere ich, habe sehr intensiv darüber nachgedacht, womit hat das denn zu tun? Warum haben wir jetzt schon, und dafür reicht eine kleine Menge, das mussten nicht zig Kunden sein, wo wir solche Interaktionen hatten, sondern rauszuhören, irgendwie entsteht da eine Unzufriedenheit. Es gibt da einen ganzen Konferenzvortrag auch von mir zu dem Thema, dass wir dann angefangen haben, mit agilen Methoden zu arbeiten. Vorher war das eher so Programmieren auf Zuruf. Mit agilen Methoden zu arbeiten, haben festgestellt, dass wir deutlich schneller werden und deutlich weniger Missverständnisse mit den Kunden haben. Aber diese Grundunzufriedenheit, das müsste schneller gehen und das müsste billiger sein, die ist nie weggegangen.

SPEAKER_00 12:49

Hat das nicht jedes Unternehmen, jeder Dienstleister, auch gerade im deutschsprachigen Raum, der jetzt nicht auf Nearshoring oder Offshoring mit Ressourcen zugreift?

SPEAKER_01 12:58

Tendenziell ja, wobei man dazu sagen muss, wir haben immer schon viel mit dem Mittelstand gearbeitet. Das heißt, das sind im Zweifel Leute, die ihr eigenes Geld ausgeben, sehr salopp gesprochen. Und da ist das schon gebräuchlicher, wenn du in so einem Konzern irgendwie vier Leute stellst und die Tagessätze aufrufen, die marktüblich sind. Und die Leute, die mit denen beim Kunden zusammenarbeiten, grundsätzlich mit den Arbeiten zufrieden sind, dann fragt niemand nach dem Wertbeitrag. Das kostet das halt. Die vier Leute, die kosten halt im Jahr eine halbe Million oder was auch immer. Das ist halt so. Und das stellen wir eben auch bei Konzernen immer wieder fest, dass dann ein Projekt gemacht wird, eine sechsstellige Summe oder sogar eine siebenstellige Summe investiert und ob sich das Ding dann amortisiert, naja, schauen wir mal, sagt der Bayer. So, und hier ist es aber so, wenn wir mit dem Mittelstand arbeiten, da ist es dann oft so gewesen, dass die Leute unzufrieden waren, weil sie am Ende ihr eigenes Geld ausgeben und ein sehr klares Gefühl dafür haben, sind wir wieder beim Unternehmerischdenken, sind wir wieder bei Wertschöpfung. Ist es das hier eigentlich wert, was ich hier tue? Und sobald sie das Gefühl haben, nein, das ist nicht so, beginnen diese Diskussionen. Und das war der, so sind wir sozusagen durch Zwang oder im Selbstschutz zu Produktmanagement-Techniken gekommen. Weil insbesondere ich da intensiv drüber nachgedacht habe, wo kommt diese Unzufriedenheit her. Es ist ja erstmal per se nichts zu teuer oder zu langsam, sondern das wird immer mit irgendwas ins Verhältnis gesetzt. Und bei allen diesen mittelständischen Kunden gibt es in deren Kopf zumindest einen groben Business Case. Die überlegen sich, ich will so und so viel Geld einsparen oder ich will so und so viel Geld mehr verdienen. Und daraus leitet sich irgendwie eine Art Willingness to Payup, weil sie sagen, ja, ich werde im Jahr 400.000 Euro sparen. Es wäre okay, wenn das, was ich jetzt tue, sich erst nach drei Jahren amortisiert. Also ich wäre bereit, 1,2 Millionen Euro dafür auszugeben. So, und wenn wir jetzt aber bei 1,5 Millionen Euro Kosten angekommen sind und es zeichnet sich immer noch nicht ab, dass dieser Case aufgeht, dann fangen die Leute spätestens an. Mittelständler schon früher, die fangen schon ab einer Million dann an, unruhig zu werden. Weil sie ihr eigenes Geld, genau, weil sie ihr eigenes Geld ausgeben und weil sie jetzt auch nicht die Beinfreiheit haben, wie so ein Konzern, hey, wir machen 82 Milliarden Euro Umsatz im Jahr, es ist scheißegal, ob das Projekt von einer Million jetzt erfolgreich ist oder nicht. So, und dann sind wir sehr stark zu diesem Produktmanagement, Product Discovery-Ding hingekommen, weil wir gesagt haben, meist scheitert es daran, also es scheitert ja entweder daran, dass die Ideen nicht gut sind oder nicht wertversprechend sind, die die Kunden mitbringen, oder es scheitert daran, dass die Execution, die wir an den Tag legen, nicht gut ist. So, wenn wir mal davon ausgehen, da haben wir schon einiges getan, dass wir aus der Execution das meiste rausgeholt haben und da jetzt keine großartigen Sprünge mehr möglich sind, kann es nur noch daran liegen, dass vielleicht die Ideen gar nicht so werthaltig sind, wie die Kunden meinen, dass sie sind und haben deswegen sehr stark in dieses, wie sieht denn eigentlich Erfolg aus, wirtschaftlicher Erfolg für das, was ihr vorhabt? Was habt ihr da eigentlich vor? Ist es zweckmäßig, eine hochwertige iOS-App für Zahnmediziner per Banner Werbung zu monetarisieren? Und solche Scherze, wird dieses Spiel wohl aufgehen? Also mehr da rein zu investieren, zu gucken, ist denn die Erfolgsgleichung, die sich der Kunde überlegt hat, ist die denn überhaupt zielführend?

SPEAKER_00 16:53

Hast du das Gefühl, das ist eine Tendenz oder hat sich der Markt dahingehend geändert, vor allen Dingen seit 2022 oder war diese, hast du das Verhalten bei Kunden tatsächlich schon viel früher festgestellt?

SPEAKER_01 17:08

Also wir machen ja schon, wir wenden ja Produktmanagement-Techniken. Auch da ist das ein fließender Prozess gewesen. Wir haben sehr heimsärmlich damit angefangen, aber den Canvas, den wir dafür verwenden, beispielsweise für Erstgespräche, Product, Vision und Strategy Canvas, den verwenden wir jetzt bestimmt seit mindestens acht Jahren. Wir hatten schon immer diese Diskussion. Und natürlich, und da kommen wir auch zu dem, was du sagst, gerade im Mittelstand oder bei Startups ist dann die Überlegung schnell, ja, aber ich habe diese geniale Idee und jetzt brauche ich jemanden, der diese Wunschliste möglichst kostengünstig implementiert. Das lasse ich irgendwo in Indien oder in Osteuropa machen, das ist viel billiger. Also die Diskussion oder diese Überlegung gibt es bei uns schon sehr, sehr lang, weil wir natürlich Trigema-artig ausschließlich in Deutschland produzieren, wir zahlen deutsche Gehälter, wir rufen deutsche Tagessätze auf und dafür müssen wir irgendwas haben, was den Leuten Erfolgversprechender erscheint. Also nicht nur erscheint, wir wollen ihn nicht verscheißern, aber was ihnen klar auch ersichtlich wird, Erfolgsversprechender, als irgendwo billig eine Wunschliste bauen zu lassen. Also ja, das ist schon deutlich länger, diese Tendenz bei uns.

SPEAKER_00 18:22

Jetzt wollen wir das Problem ja auch nochmal verstärken. Jetzt kommt nämlich das Thema, das hast du auch schon beschrieben, jetzt kommen ja einige CFOs oder Unternehmen, kommen auf die Idee, ja Moment mal, wir brauchen jetzt ja gar keine Dienstleister mehr, das macht jetzt Copilot und Co. Damit wird die Problematik, die du jetzt hast, gerade wenn du sagst, ihr wollt rein im deutschsprachigen Raum entwickeln, implementieren, umsetzen, wie real ist dann diese Gefahr wirklich, dass es noch, ja, diese Spirale auch noch weitergeht und wie könnt ihr dem Ganzen Herr werden?

SPEAKER_01 18:51

Das Interessante ist ja, dass es Dienstleistungsgeschäft, und ich mache das jetzt seit über 20 Jahren, IT-Dienstleistungsgeschäft, das hinterliegt ja immer so Schweinezyklen. Ich weiß nicht, wo wir jetzt in dem Schweinezyklus anfangen wollen, aber die goldenste Zeit für IT-Dienstleister war immer, wenn die Kunden festgestellt haben, hey, wir haben hier mehr Arbeit, als wir selber schultern können. Und zwar Arbeit, die in auch Geschäftserfolg münden wird. Hostwahrscheinlich, wir sind uns aber noch nicht so sicher anhand der konjunkturellen Situation oder sowas, dass wir dafür eigenes Personal einstellen wollen. Wir möchten mit jemandem arbeiten, mit dem wir schnell wieder loswerden. So, und dann ging das eine Zeit lang, das waren die goldensten Zeiten in diesem Schweinezyklus immer für IT-Dienstleister. Und irgendwann stellten die Kunden fest, warum soll ich eigentlich, wenn ich jeden Tag, fünf Tage in die Woche, mit dem Auto zur Arbeit fahre, immer einen Mietwagen nehmen? Das ist doch irrsinnig teuer. Und im Zweifel, also immer IT-Dienstleister dafür zu beschäftigen. Und das Know-how ist auch in Köpfen außerhalb meiner Payroll. Dann haben die angefangen, interne Mitarbeiter einzustellen. So, und dann ist das Pendelmeist zurückgeschlagen. Dann haben sie irgendwann nämlich festgestellt, dass die Sause nicht ewig so weitergeht wie die letzten paar Jahre. Und sie haben jetzt aber die Leute auf der Payroll stehen und haben wieder angefangen, die Teams abzubauen, und dann kam wieder, dann hat der Zyklus wieder von vorne. Und eigentlich als IT-Dienstleister konntest du dich immer darauf verlassen, dass irgendwann wieder diese Zeit kommt, wo die Leute sagen, das Geschäft zieht an, wir wollen uns aber nicht committen und Menschen einstellen. Der Unterschied dieses Mal im Schweinezyklus ist, dass die sagen, wir wollen uns nicht committen und Menschen einstellen. Wir wollen jetzt, aber wir sehen, dass es vielleicht das Geschäft wieder anzieht. Und ich habe jetzt gerade in der Zeitung den Begriff von Jobless Growth gelesen, was in Amerika ein großes Problem zu werden scheint, dass die Wirtschaft anzieht, aber keine neuen Jobs entstehen. Und das ist was, was wir in der IT-Dienstleistung natürlich auch sehr intensiv dann sehen, dass die Kunden im Moment in meiner Wahrnehmung sehr stark versuchen, the future is already here, but it's not evenly distributed, nicht alle Kunden überall und immer, aber in der Tendenz, vor allem modern tickende Technologieunternehmen in Deutschland oder Technologieabteilungen in Deutschland, zu sagen, warum denn eigentlich externe? Lass es uns doch mit KI probieren. Und das ist auch, höre ich aus verschiedenen Ecken existenzbedrohlich für diese ganzen Offshoring-Modelle. Denn wenn ich sowieso genau aufschreiben muss, was gemacht werden muss, dann fürs Offshoring kann es auch ein KI-Modell geben.

SPEAKER_00 21:40

Das heißt, es wäre ja auch eine Möglichkeit, sich nochmal wesentlich prominenter in dem aktuellen Markt. Also es ist eine Gefahr, das höre ich daraus, aber es ist auch die Gelegenheit, sich nochmal viel prominenter zu positionieren. Gerade weil man nicht auf billige Offshoring-Mitarbeiter zurückgreift, sondern weil man von vornherein Das Thema Qualität und das Thema Mitdenken und das Thema wir, wir lösen nicht nur dein vermeintliches Problem, dass du irgendwas umgesetzt haben willst, sondern wir denken auch die Lösung für dich mit von Anfang bis Ende. Das ist dann wahrscheinlich die große Opportunity für euch.

SPEAKER_01 22:16

Genau, also wir helfen dir, dein Return on Invest zu maximieren, weil immer im Kern steht, was ist eigentlich das, was wirtschaftlich bei rauskommen soll. Und wir haben das über Jahre schon gemacht, wie wird eigentlich das Produkt bei deinen Kunden erfolgreich? Und seit 2022 ist noch viel entscheidender auch, wie wird das Produkt für dich erfolgreich, Business Value generieren, was wir diese Facette noch mehr gestärkt haben. Und das Interessante im Dienstleistungsmarkt ist, dass Dinge, die jahrzehntelang funktioniert haben, jetzt von einem Tag auf ein ander nicht mehr funktionieren. Beispiel, es gibt IT-Dienstleistungsunternehmen in Deutschland, die absolute Technologieführerschaft haben. Immer wenn wir gegen die bei einem Kunden angeboten haben, der Kunde gesagt hat, ja, aber wir entwickeln, es ist ein zufällig gewähltes Beispiel, wir entwickeln hier ein Kotlin, weil wir uns irgendwann dafür entschieden haben, ja, ihr habt Leute, die beherrschen ein bisschen Kotlin, aber wir haben da drüben jetzt einen IT-Dienstleister, der kann die fünfführenden Köpfe der Kotlin-Entwicklung in Deutschland zu seinen Mitarbeitern zählen und die haben die uns angeboten. Und egal wo du auftauchtest, wenn du gegen die ins Rennen eingestiegen bist, hast du immer verloren, wenn der Kunde die absoluten Profis in diesen Technologien. Kafka, Kotlin, Rust, bla bla bla. Weil die immer, davon konntest du ausgehen und zu Recht, das war nicht gelogen, das gebe ich neidlos zu. Die hatten immer die besten Leute in diesen Technologien.

SPEAKER_00 23:52

Sie konnten das als Engpassressource, konnten sie das verkaufen, aber das wird ja mittlerweile immer weniger zur Engpassressource. Ja, und das ist ja auch nicht so gut. Nehmen an, du mit darauf, oder?

SPEAKER_01 24:00

Ist das irrelevant? Jeder Trottel kann heute Kotlin mit seinem AI-Exoskelett programmieren. Ich beschreibe dieses AI-Augmented Coding, wenn die Leute AI-Unterstützung in ihrer Entwicklungsumgebung haben, beschreibe ich gern wie so ein Exoskelett in der Softwareentwicklung. Und du kannst auf einmal Dinge heben, die du sonst niemals heben könntest, weil du dafür einfach, weil dein Körper da dann für nicht gemacht ist. Aber mit dem Exoskelett kannst du das hundertmal am Tag machen. So, und das Interessante ist, dass ein strategischer Vorteil der Vergangenheit sich jetzt in einen strategischen Nachteil über Nacht verwandelt hat. Warum? Weil in diesen Organisationen man eine Kultur gepflegt hat, wir sind die geilsten Technologen. Egal welche Technologie es hier auf diesem Planeten gibt, wir haben immer die geilsten Köpfe bei uns. Und wir sind Techniker. Aber selbst wenn die Unternehmensleitung jetzt die Zeichen der Zeit ähnlich liest wie ich und sagt, wir müssen da rein, uns als Wertstifter zu positionieren, haben sie jahrelang eine Organisation aufgebaut, die genau auf das nicht ausgerichtet ist.

SPEAKER_00 25:09

Ich stimme dir auch zu, aber ich würde trotzdem mal die Gegenfrage stellen: ist denn diese Erkenntnis auch schon bei den Kunden angekommen, dass du eigentlich ja gar nicht mehr gucken musst, wer hat denn die geilsten Kafka- und Kotlin-Leute? Oder ist dieses Denken trotzdem noch beim Kunden, der dann aber auch erwartet, naja, wenn jetzt aber die besten Kotlin und Kafka-Leute, wenn die jetzt die Agents bedienen, dann kommt ja noch bessere Sachen daraus in dem Bereich, was wir ja auch als Teil unserer Wertschöpfung nutzen. Die sind noch gar nicht so weit zu sehen, dass der Engpass überhaupt nicht mehr vorhanden ist.

SPEAKER_01 25:44

Auch hier wieder, the future is already here, but it's not evenly distributed. Es gibt noch genügend Organisationen, die sagen, wir brauchen hier für drei Monate einen Kafka-Experten. Fair. Das wird immer weniger, in meiner Wahrnehmung. Und das Interessante ist, du kriegst auf immer kleinere Gebinde abgesetzt. Früher war das so, dass es hieß: Ja, wir suchen ein Team von sechs Kotlin-Entwicklern, und es war klar, dass dieses Team mindestens für ein Jahr beauftragen wird. Geiles Ding für einen IT-Dienstleister. Planbarer Umsatz, sechs Leute in Umsatzjuhu, die Sekt knallen. Heute ist das dann so, wenn so eine Ausschreibung kommt oder so eine Anfrage, wie du sie beschreibst, ist es safe, wir brauchen einen Kotlin-Menschen, der uns in Teilkapazität für ein Quartal unterstützt und sozusagen mit unseren Leuten sein Know-how zusammen mit dem KI-Modell da zum Einsatz bringt und dann kommen wir alleine weiter. Das ist jetzt alles sehr überzogen gesprochen. Es gibt da draußen auch noch genügend, wir brauchen einen Java-Entwickler für drei Monate, für ein Jahr oder sowas. Aber das ist deutlich weniger geworden.

SPEAKER_00 26:51

Wie verhindert man denn? Also, ich meine, die Folge ist ja dann, du musst über das Thema LLM und Integration von LMM musst du natürlich dann noch auch, wie wahrscheinlich jeder Anbieter, sehr intensiv nachdenken. Aber wie verhinderst du, dass du nicht zu einem Unternehmen wirst, das jetzt nicht nur Dienstleister ist oder vielleicht sogar strategischer Partner, sondern zum reinen LLM-Bediener degradiert wird?

SPEAKER_01 27:15

Wir hatten letzte Woche einen tollen Vortrag bei uns im Büro, wo es darum ging, was heißt denn Softwareentwicklung und was heißt denn Produktmanagement in so einer KI-Ära überhaupt noch? Und das unterschreibe ich voll, was unsere Referentin Samina da gesagt hat. Dass wir heute noch machen können und wofür wir wieder Zeit bekommen, ist Entscheidungen zu treffen, was wird denn überhaupt gebaut, weil Bauen so unglaublich einfach geworden ist. Und LLM-Bediener, das ist das, was manche in der Branche die Expertenfalle nennen. Wenn du jetzt versuchst, immer noch geiler, noch mehr Kotlin wissen, damit du der beste LLM-Bediener bist zu werden bist, dann wirst du irgendwann, wird deine Nische immer kleiner und irgendwann ist sie weg. Das, was ich meine, ist, dass man, wenn man den Kunden dabei hilft, insbesondere Kunden, die jetzt Softwareentwicklung nicht gewöhnt sind, die richtigen Entscheidungen zu treffen, sodass das, was da rauskommt, wertstiftend für sie ist, ist meine persönliche Antwort daraus, dass ich nicht ein reiner LLM habe.

SPEAKER_00 28:25

Hat ja auch viel damit zu tun, du hast ja eben gesagt, ihr habt großen Produktfokus, ihr arbeitet nicht nur Wunschlisten ab. Ihr sagt ja auch bewusst, wir sind die Falschen, wenn jemand nur eine Wunschliste umgesetzt haben will. Siehst du, dass diese Haltung vor dem Hintergrund der immer stärker werdenden Integration von Copilots und LLM-getriebenen Entwicklungszyklen. Wie reagiert der Markt dann genau auf diese Haltung? Nimmt er das noch dankbarer an, weil er mittlerweile beginnt zu verstehen. Jetzt sagst du, ja, the future is not evenly distributed, ja klar. Aber wie reagiert der Markt darauf? Beginnen sie zu verstehen, dass das nochmal ein größerer Wert ist, den ein Dienstleister oder ein Unternehmen haben kann, wenn er genau das mit anbietet. Nämlich auch die Unterscheidung, wir bauen hier nicht nur irgendwas, was jetzt sich jemand ausgedacht hat, sondern wir denken mit aktiv und helfen auch mit Produktfokus umzusetzen.

SPEAKER_01 29:23

Das kommt ein bisschen darauf an, und ich nehme jetzt eine andere Plattitüde, it depends, ja. Das kommt ein bisschen darauf an, was du als den Markt betrachtest. Wenn wir, grundsätzlich ist in allen Märkten, über die wir sprechen, die Unsicherheit massiv gestiegen und gleichzeitig der Wunsch nach Sicherheit, nach Verlässlichkeit, nach echten Partnerschaften. Und wenn ich jetzt komme und sage, ich kann euch ein Bart bauen, was euren Ansprüchen genügt, was euch zufrieden macht, was euch erfolgreich macht. Und dafür haben wir auch die passenden Installateure, Fliesenleger, Elektriker, Rohbaumeister und was weiß ich alles in unseren Reihen, um das zu machen. Wenn der Markt Organisationen sind, die nicht selber Software entwickeln, ist das was, was unglaublich vertrauensstiftend wirkt. Denn selbst, also betrachten wir das mal als Privatperson, wenn ich ein neues Bad haben will, möchte ich eigentlich nicht als absoluter Laien einen Haufen von Handwerkern koordinieren, die mir alle nur erzählen, dass der andere es falsch gemacht hat. Da entsteht jetzt heute schon eine stärkere Sicherheit, so nach dem Motto, das sind nicht nur Leute, das konnten wir in der Vergangenheit auch schon, die mir alles aus einer Hand anbieten, sondern die richten sich auch noch danach aus, wie ich erfolgreich werde. Und nicht einfach, ich hätte gerne da eine Kloschüssel hin. Ja, super, dann kannst du unter der Dusche auf dem Klo sitzen. Das ist doch Schwachsinn. Sondern die mich auch noch beraten, dass ich da keinen Unfug mache, sondern dass es Wertstiften für mich will. In Technologieorganisationen habe ich das Gefühl, dass viele noch so unterwegs sind: geil! Wir brauchen jetzt keine Fliesenleger mehr, wir brauchen jetzt keine Installateure mehr, wir brauchen das alles nicht mehr. Denn mit Copilot können wir das jetzt alles setzen. Ob das dann immer funktionieren wird und die richtigen Entscheidungen treffen, werden, glaube ich, die nächsten Jahre zeigen, da ist die Bereitschaft noch nicht so groß. Das Problem ist auch, dass dort meist der strategische Unterbau fehlt. Dadurch, das Bauen jetzt so einfach geworden ist, baut man halt einfach alles. Und macht sich wenig Gedanken darüber, was denn Ziel führt, wer überhaupt zu bauen und was nicht. Also da nehme ich das noch nicht so wahr, dass einem die Leute die Türen einrennen. Und es gibt immer wieder Ausnahmen, da sind wir wieder bei den Not Evenly Distributed. Es gibt von beiden immer wieder Ausnahmen. Es gibt in der ersten Zielgruppe immer noch Leute, die sagen, ich will aber genau das haben und einen möglichst billigen Preis. Ja, das ist aber Schwachsinn, was du dir da ausgedacht hast. Such dir gerne jemanden, der dir das billig baut, denn damit wirst du auf die Nase fliegen. Und es gibt natürlich auch etablierte Tech-Organisationen, die schon sagen, wir brauchen zusätzlich zu den Leuten, die wir hier haben, externe Wertstifter, die uns auch regelmäßig den Spiegel vorhalten und sagen, allein durch eure Abteilungsstruktur seht ihr gerade etwas nicht, eine Möglichkeit, Kosten zu sparen oder zusätzlichen Umsatz zu machen, den wir sehen, weil wir auf mehrere Teile drauf gucken können und auch nicht in eure interne Politik eingebettet sind.

SPEAKER_00 32:38

Du hast jetzt, oder ich habe auch in der Einleitung erzählt, wir reden auch über Return on Invest. Und du hast, glaube ich, auch im Vorgespräch erwähnt, dass du das natürlich auch in Kundengesprächen anbringst. Wie stark sprichst du denn über das Thema? Und wie konkretisierst du das denn, auch vielleicht als Teil von echter Produktverantwortung, die ihr übernehmt, hier den Kunden zu helfen, über Return on Invest nachzudenken? Und hat das auch dann in letzter Konsequenz die Folge, dass ihr dann, ich würde jetzt mal walk away-Power habt und sagt, nee, das macht keinen Sinn, was ihr da bauen wollt, geht da bitte woanders hin. Du hast es gerade eben ja schon mit angedeutet, aber kann sich ein Unternehmen, ein Dienstleister das heute überhaupt leisten, das so den Kunden dann wieder wegzuschicken? Das sind ja mehrere Fragen auf einmal. Danke, ja.

SPEAKER_01 33:24

Erste Frage, wie offensiv spreche ich das an? Das kommt darauf an, ob es gleich im ersten Gespräch zur Sprache kommt oder im zweiten, aber spätestens dann. Ich möchte immer spätestens im zweiten Gespräch mit dem Kunden verstehen, was für sie wirtschaftlicher Erfolg bedeutet. Warum machen die das überhaupt? Und ab und zu helfe ich ihnen dabei auch aufs Pferd, dass es dann heißt, ja, wir implementieren das jetzt, damit bei uns in der Auftragserfassung die Leute nicht so überlastet sind. Dann sage ich, ist okay, aber dann werden wahrscheinlich, sonst müsste man noch zwei weitere Leute einstellen. In der Region, in der sie unterwegs sind, kostet jemand, in den Job-Level Gehaltskosten pro Jahr, sagen wir mal, irgendwie all in 50.000 Euro. Das heißt, ab 100.000 Euro fängt sich an, dieser Case für Sie zu rechnen. Das ist so der Sweet Spot. Und ja, das könnte ungefähr die Daumengröße sein. Oder hey, wir haben im Monat Ausfälle von X. Ja, ich kenne Ihr Geschäft nicht detailliert. Ich nehme mal an, das bedeutet ungefähr einen entgangenen Umsatz in der Größenordnung von. Das bedeutet, und vermutlich soll sich das nach einem halben Jahr amortisieren, weil sie ja als mittelständisches Unternehmen nicht unerwartet viel Liquidität haben. Das heißt, wir reden über eine Investition im mittleren sechsstelligen Volumen. Das ist relativ, kommt das früh aufs Tapé. Natürlich am Ende begreife ich mich wie so ein Anwalt. Der versucht, dem Mandanten möglichst gut durch diesen Rechtsstreit zum Beispiel zu bringen. Aber wenn der Mandant sich entscheidet, obwohl der Anwalt gesagt hat, ich würde niemals vor Gericht gehen damit, das lohnt sich nicht. Das Gericht wird einen Sachverständigen bestellen und wir sowieso auf eine gütliche Einigung außergerichtlich hinweg, die wollen das gar nicht entscheiden und bla bla bla. Aber wenn der Mandant sagt, ich will die aber vor Gericht sehen, dann machen wir das. Ich hab dir vorher gesagt, das wird nichts. Und natürlich ist das auch wieder nicht null oder eins, sondern es gibt da Zwischenstufen dazwischen. Es gibt Kunden, die dann von sich aus sagen, nee, wir suchen, aber das wollen wir euch gar nicht erzählen. Da braucht ihr euer hübsches Köpfchen, euch gar nicht drüber zu zerbrechen. Das ist unser Thema. Wir wollen von euch nur den günstigsten Preis haben. Und da haben wir schon in der Vergangenheit immer gesagt, in jeder konjunkturellen Situation günstigsten Preis, aber da sind wir die Falschen. Das wird nicht funktionieren. Das gibt es woanders auf der Welt deutlich günstiger als hier. Also es ist selten so, dass ich Kunden aktiv wegschicken muss, aber auch das habe ich schon gemacht.

SPEAKER_00 36:13

Du hattest auch, ich erinnere mich auch im Vorgespräch das Beispiel gebracht, dass Unternehmen von 20 Cent Marge auf 8 Cent Marge gefallen sind. Und dass das Thema Automatisierung, auch die Integration von AI, helfen kann, diese Marge potenziell zurückzuholen. Ich glaube auch, dass die ja eine der großen KPIs der Jetztzeit und vielleicht auch der nächsten Jahre ist wahrscheinlich so der Umsatz pro Mitarbeiter oder Gewinn pro Mitarbeiter. Wie argumentierst du das auch strategisch gegenüber einem CEO, einem CFO, mit dem du mit dem du arbeitest, wenn es darum geht, Produktentscheidungen mit dem Kunden gemeinsam zu treffen? Wie hilft dir das dabei, auch Projekte zu gewinnen, wenn der Kunde merkt, er versteht oder er erkennt, dass du verstehst, was sein eigentliches Problem ist, über das er vielleicht eigentlich gar nicht gesprochen hat am Anfang.

SPEAKER_01 37:08

Was ist denn das große Problem, was CFOs, insbesondere on CEOs in der Vergangenheit mit den Technikern hatten, ja, und unser ganzen IT-Bubble. Da kamen Leute, die irgendwelches Zeug erzählt haben und sagten, hey, lass uns das bauen und das ist geil, und das machen wir agil und da machen wir Sprints und da machen wir Disses und da machen wir Backlog. Und der CFO hat gedacht, wir haben null verstanden, worum es hier geht. Natürlich ist das sofort ein ganz anderes Gespräch, wenn du dann nicht als Agenturbubi auftauchst, der irgendwie mit geilen Technologien spielt, sondern sagt, also aus meiner Wahrnehmung ist euer Geschäft gerade an der und der Stelle unter Druck und ich kann euch erfahrungsgemäß helfen, indem wir da und da den Druck rauslassen. Ich habe jetzt letztens mit einem Unternehmer gesprochen, produzierendes Gewerbe, da ist das gerade richtig krass. Der sagt, Konstantin, meine Rohstoffkosten im Einkauf sind um 70 Prozent gestiegen. An einige meiner Kunden, nicht alle, mit manchen habe ich langlaufende Lieferverträge. An einiger meiner Kunden kann ich Preiserhöhungen von bis zu 3 Prozent im Jahr weitergeben. So, und dann braucht sich keiner mehr zu wundern, wo die Marge ist und dass der Bewegungsspielraum immer kleiner wird. Und da brauchen wir über KI noch gar nicht zu reden. Es ist oft so, dass dann zum Beispiel Bestellungen handgeschriebene Zettel sind, von denen Fotos per Mail oder WhatsApp an das produzierende Unternehmen geschickt werden. Und dann sitzt da irgendjemand in der Auftragsbearbeitung, die Ritter, die auch in fünf Jahren dann in Ruhestand geht und versucht zu entziffern, was auf diesem Zettel draufsteht und macht daraus eine SAP-Buchung. Und da braucht man auch gar eine KI, sondern einfach einen sinnvoll strukturierten Prozess, der digital unterstützt ist und der auch sich an der Lebenswirklichkeit der Kunden orientiert und denen nicht irgendeinen Webshop hinstellt, den die eh nicht benutzen werden, in ihrer Werkshalle oder in ihrem Schnellgastronomiebetrieb oder sowas, sondern der zu deren täglichen Kontext passt. Also, wenn ich die Frage nochmal kurz beantworten soll, es verändert das Gespräch fundamental, ob du erstmal darüber redest, was hier die wirtschaftliche Herausforderung ist und wie du die lösen kannst oder ob du gleich mit irgendwelchen Frameworks und Programmiersprachen und bla bla bla ankommst.

SPEAKER_00 39:32

Ist es das auch, was vielen CTOs aus reinen Produktunternehmen am häufigsten fehlt? Ja.

SPEAKER_01 39:39

Kurze Antwort ja, weil der CTO historisch gesehen da auch nicht unterwegs war. Das CTO, gute CTOs, so vor drei bis fünf Jahren noch was. Wenn du ein guter CTO warst, dann hattest du eine gut funktionierende, im Optimalfall sogar gut skalierende Engineering-Organisation gebaut, die verlässlich liefert, mit verlässlicher Qualität, mit verlässlichen, sagen wir jetzt mal ganz oldschool-Terminzusagen, also dass sich alle außen rum darauf verlassen können, wenn der Philipp und seine Organisation uns in Aussicht stellen, prognostizierter Liefertermin, dann und dann, dann ist das auch so. Und dann ist das nichts, was da auf dem Hof steht und zusammenbröckelt, sondern das hat hart und Fuß, das funktioniert, das ist stabil, das skaliert. In dem Rahmen, den wir hier so haben. Nicht unendlich, sondern mit dem Wachstum, was wir hier antizipiert haben. Und es ist jetzt aber immer mehr so, dass, und das wird durch KI ist das auch wieder ein Brandbeschleuniger, dass die Engineering Organisationen und gerade die Leiter dieser Engineering Organisationen, und das sind CTOs, VP Engineering oder wer auch immer, Head of Engineering sehr viel stärker zu Wertbringern werden müssen, zusammen mit dem Produktmanagement. And das sind CTOs in der Historie selten gewöhnt. Also es gibt, ich habe selten wirklich gute CPTOs kennengelernt, die im Product-Bereich und im Tech-Bereich gleich stark sind. Die sind entweder sehr productlastig, haben aber ihre Engineering-Organisation verloren, weil sie mit dem, wie Produkte richtig gebaut werden, nicht viel anfangen können und da auch keine Erfahrung haben. Was aber viel häufiger der Fall ist, dass die im Te-Bereich stark sind und mal ein Buch über Produktmanagement gelesen haben oder so, aber im Wesentlichen mit Product Discovery, Produktmanagement, das richtige Produkt finden, iterativ, experimentell nicht praktisch wirklich viel anfangen.

SPEAKER_00 41:51

Bedeutet es dann auch, dass der Rhein, du siehst dann, der rein technische CTO mit einem ganz großen T in der Mitte, der ist gerade dabei, auszusterben?

SPEAKER_01 42:02

Auch hier wieder gibt es natürlich Organisationen, die sehr technisch sind, wo es das noch gibt. Aber ich glaube, langfristig, und das ist auch durch alle Gespräche, die ich auf Tech Leads Breakfast oder sonst was geführt habe, spüren alle CTOs, dass sie produktlastiger werden müssen. Und nicht um irgendjemand die Butter von Brot zu nehmen, sondern weil sie ein einfaches, we organisieren, hier delivery, nicht mehr als Jobbeschreibung haben können in der Zukunft. Das wird man ihnen nicht mehr durchgehen lassen, sondern es wird immer die Frage gestellt werden. The CFO wird dann immer die Frage stellen, ist das wertvoll oder kann das weg? Wofür brauchen wir diese Teams überhaupt noch? Wofür brauchen wir ein CTO? Wenn eigentlich das CPO uns hier uns zeigt, wo der Wert drin steckt. Also natürlich wird auch da sicher noch Organisationen in der Zukunft geben, die sehr technisch sind und wo auch die CTOs weiterhin sehr technisch und im Delivery-Bereich unterwegs sind, aber das wird mehr verschmelzen. Wir hatten bei dem Vortrag letzte Woche auch diesen Begriff des Product Engineers, den ich sehr mag. Das wird auf der operativen Ebene auch so, dass die Rolle zwischen Softwareentwicklung und Produktmanagement Design mehr verschmilzt. Ich sage nicht, dass wir keine Designer mehr brauchen. Ich sage nicht, dass wir keine Produktmanager mehr brauchen. Ich sage nicht, dass wir keine guten Softwareentwickler mehr brauchen. Aber dieser heilige Gral des Scrum-Guides, dass wir T-Shape-Personalities haben, die jetzt zum Beispiel nicht mehr für jedes Design, einen Grafikdesigner brauchen, die nicht mehr für jede Produktentscheidung einen Produktmanager brauchen und nicht einfach nur noch das implementieren, was in der User Story und den Tasks darunter in Jira steht. Das ist Realität und das setzt sich auf der Leitungsebene genauso fort, dass auch die Rolle zwischen CTO und Chief Product Officer weiter verschmelzt.

SPEAKER_00 44:00

Also zum Zeitpunkt der Veröffentlichung der Folge ist die Folge auch schon live mit dem Stefan Schmidt, seines Zeichens auch CTO-Coach, gesprochen und auch über die Rolle des Product Engineers gesprochen. Uns ist dabei auch im Gespräch aufgefallen, dass wir eigentlich eine Rückentwicklung sehen, weil du hattest vor 20, 30 Jahren hattest du einen Engineer, der war für alles verantwortlich, der war für Frontend verantwortlich, für Back-End, vielleicht sogar auch noch für Produkte ein bisschen HTML und CSS hat er gleich auch noch mitgemacht. Das heißt, Designer hast du vielleicht auch nicht wirklich gebraucht. So, das war sehr stark auf eine Rolle fokussiert. Danach kam halt ganz schön viel. Das Ganze hat sich immer mehr professionalisiert. Es kamen Frameworks dazu, es kamen Spezialisierungen dazu. Und das ging unwahrscheinlich in die Breite. Du hast Rollen gefunden, und siehst du vielleicht jetzt immer noch, wie Sand am Meer. Und jetzt beginnt dieser Prozess sich zurückzuentwickeln, hin wieder in die Konsolidierung, in eine zentrale Rolle. Und das ist der Product Engineer, der für all diese Aspekte alleine verantwortlich sein kann. Weil er muss aber in keiner dieser Sparten der Experte sein. Dafür hat er nämlich seine LLMs. Würdest du mit diesem Beispiel dann mitgehen oder siehst du hier nochmal einen Aspekt, der, du sagst, das passt nicht, weil?

SPEAKER_01 45:17

Zwei Antworten. Also das erste, die Herleitung, oder schreibe ich sofort. Ich habe um die Jahrtausendwende bei Ballland gearbeitet und ich glaube, die Produktivität, die wir damals mit Ball Delphi und ähnlichen Tools haben, haben wir danach nie wieder erreicht. Eine Datenbankanwendung in Ballland Delphi zu entwickeln, war eine Sache von einer halben Stunde. Wir hatten das mal, als wir von irgendwie der C-Bit oder der Systems nach Hause kamen und einen Haufen Visitenkarten eingesammelt hatten und Kontaktbögen aus dem Marketing oder aus dem Vertrieb. Dann sollten wir die irgendwie so aufbereiten, dass der Vertrieb sie dann weiterverwenden kann. Und dann hat uns ein System-Engineer bei Borland in einer halben Stunde schnell in Delphi eine Anwendung dafür gebaut. In einer halben Stunde. Und diese Produktivität, zack, zack, zack, drei Controls reinziehen, verbinden, fertig aus, die haben wir nie wieder erreicht danach. Ich habe Diskussionen vor noch fünf, sechs Jahren mit meinen Kolleginnen und Kollegen geführt, dass ich sagte, wenn man das hier anklickt, dann möchte ich, dass darunter alles deaktiviert wird und wenn man ausgegraut wird und also, dass man da mit den ganzen Block an Controls, boah, da müssen wir einfach mal gucken, ob in der React-Bibliothek das so einfach ist. Und ich gesagt, seid ihr bescheuert? Das waren damals in Delphi 1998 zwei Klicks. Ja, das war nicht responsive. Ja, das war nicht im Browser, obwohl es Delphi dann auch im Browser gab. Alles gut, das waren internationalisieren konnte man das auch, aber das wollt ihr mir jetzt nicht erzählen, dass ich erstmal prüfen musste, ob das überhaupt geht und in Delphi waren es zwei Klicks. Also diesen Teil gehe ich vollkommen mit, dass wir hoffentlich durch diese ganze LLM und vielleicht auch in Kombination mit Wipecoding wieder in einen Produktivitätsmodus zurückkommen, den wir vor Jahrzehnten mal hatten, mit Tools wie Delphi, Visual Basic, Born in Cilder und wie sie alle heißen.

SPEAKER_00 47:10

Was bedeutet das denn für die Zukunft, auch für die Zukunft der CTO-Rolle? Ist das, was ist das Killer-Kriterium für einen guten CTO? Wenn das stimmt, was wir gerade gesagt haben und auch der Trend der ist, den wir gerade beschrieben haben?

SPEAKER_01 47:25

Ich glaube, ich, bevor ich die Frage beantworte, gehe ich nochmal eben auf den zweiten Teil deiner Frage ein. Ich glaube nicht, dass diese Rollen vollständig verschmelzen werden. Es werden die Entwickler wegfallen, die nur Code ins Terminal getippt haben und sich toll darin fühlten, jetzt den Tag über eine geile Delete-Methode implementiert zu haben und dabei alles auch immer, wie auch immer, bedacht zu haben. Es werden die Grafikdesigner wegfallen, das machen wir mit einem LLM oder sowas. Aber geile, cross-funktionale UX-UI-Designer, die so ein, wie muss die Interaktion für den Kunden aussehen, bis hin zu, wie kann eine Bild- und Formensprache dafür aussehen, da glaube ich auch nicht, dass die so schnell wegfallen. Und Produktleute, die gewöhnt sind, datenbasiert Entscheidungen zu treffen, die werden es auch nicht so schnell wegfallen. Aber diese Produktmanager, die im Endeffekt eigentlich nur Backlog-Administratoren waren und User Stories geschrieben haben. Oder wie Melissa Perry sagt: Waiter-PMs, die haben halt Bestellungen von ihren Stakeholdern aufgenommen, haben die in User Stories verwandelt, in einen Backlog gepackt, vielleicht nochmal Tasks geschrieben und ihre Softwareentwickler haben das implementiert. Das wird alles wegfallen. Ich glaube aber, dass es weiterhin Bedarf nach überlappenderen Rollen gibt. Der Techniker muss stärker verstehen, wie hier Wert entsteht und was die wichtigen Entscheidungen sind, kann aber zum Beispiel viel besser Edge Cases bewerten als ein Produktmensch. Ja, aber was ist denn, wenn hier der Kunde einen negativen Betrag eingibt? Was ist denn, wenn er gleichzeitig das löscht und hier was Neues anlegt? Was ist denn? Das ist nichts, was Produktleute gut können. Wie müssen wir das in der User-Experien? Also diese Rollen wird es weiterhin geben, die werden aber generalistischer werden und sich stärker überlappen. Und für den CTO der Zukunft bedeutet das, dass wir eigentlich moderne CTOs in der Regel CPTOs sein müssen, weil sie zumindest Produktmanagement-Techniken verstehen und anwenden können müssen, in der Praxis anwenden können müssen, weil sie immer stärker zu Wertstiftern werden müssen. Gleichzeitig aber wir auch in der Zukunft Engineering-Organisationen haben, in denen Menschen arbeiten, in denen Dinge passieren, in denen man gucken muss, wie man möglichst viele Sichtweisen übereinander bringt, in denen man all die Bestandteile gut zusammenarbeiten lässt, sodass man verlässlich liefert und auch verlässlich Qualität liefert und so weiter.

SPEAKER_00 50:05

Konstantin, jetzt ist genau das passiert, was du natürlich schon mit großer Erfahrung vorausgesehen hast. Wir sind fast nämlich am Ende der heutigen Aufnahme und haben noch gar nicht alle Themen. Ich glaube, wir müssen das Ganze an anderer Stelle auch nochmal mit fortsetzen. Trotzdem würde ich ganz gerne noch eine Runde Rapid-Fire-Fragen mit dir spielen, wenn du Lust hast. Und die anderen Themen oder die Fortsetzung der Diskussion, die heben wir uns dann für Teil 2 auf. Das ist ja auch ein toller Cliffhanger jetzt. So, Rolle des CTO in der Zukunft, Killer-Kriterium für einen guten CTO, haben wir jetzt, haben wir schon mal abgehakt. Genau. Dann würde ich mal mit den Rapid-Fire-Fragen anfangen. Ein KPI, auf die jeder CTO schauen sollte.

SPEAKER_01 50:42

Wie viel, das ist auch wieder eine Etipense Antwort. Ja, das zählt nicht. Nee, nee, was ist die wichtigste Kennzahl, die euer Geschäft beschreibt und wie könnt ihr darauf, also was ist eure, um rauszufinden, ob ihr darauf einzahlt? Also wenn es Anzahl Subscription ist, wie könnt ihr rausfinden? Wenn es Customer Lifetime Value ist, wie könnt ihr rausfinden, die KPI, dass ihr eine Engineering-Organisation darauf einzahlt, auf diese KPI, die euer Unternehmen hat. Ist es am Ende nicht immer Umsatz?

SPEAKER_00 51:17

Nicht immer. Dann Buch oder Konferenz, die dich zuletzt wirklich weitergebracht hat.

SPEAKER_01 51:22

Das ist eine schöne Anschlussfrage, denn Impact First Product Teams von Matt LeMay, weil er nämlich auch sagt, das Ziel deines Teams sollte nur eine mathematische Operation und ein Why entfernt sein von den Zielen deines Unternehmens. Das ist im Endeffekt das, was ich eben gesagt habe. Wenn das Unternehmen das und das als Ziel hat, wie ist unser Ziel und welche eine mathematische Operation bringt uns dahin und welches eine Why bringt uns sozusagen zum Unternehmensziel. Wir machen das und das und das, wir steigern bauen die und die Sachen, warum? Weil wir den Customer Lifetime Value stärken wollen. Wir investieren das und das und das. Warum? Weil wir es dann schaffen, den Customer Lifetime Value zu stärken in der und der Form. Und Konferenz vielleicht so in eigener Mission unterwegs. Wir veranstalten ja jetzt Mitte April zum dritten Mal die Crafting Products, eine deutschsprachige Konferenz zum Produktmanagement mit KI als Thema. Was macht KI im Produktmanagement anders? Und das ist, jetzt weiß ich nicht, ob Pflichtveranstaltung ist vielleicht ein großes Wort, aber gerade für CTOs, die jetzt rein wollen müssen, fühlen, dass das ihr neues Thema ist für das Ding Produktmanagement, da wird es eben echte Praxisdinge geben. Und natürlich sind sie davon haufenweise Produktleuten umringt, aber auch gerade für CTOs ist das ein sehr wichtiges Thema. Und kein Bullshit und Buchwissen, sondern Praxisinfos.

SPEAKER_00 53:03

Sehr gut. Und dann die letzte Frage: Eine Fähigkeit, die jeder angehendes CTO unterschätzt. Abgeben.

SPEAKER_01 53:12

Abgeben von Implementierungsdetails, Abgeben von Implementierungsjobs, abgeben von Quality Gates. Ich kenne so viele Scale-Ups, in denen jeder Pull-Request noch von dem CTO freigegeben werden muss. Und die da stapeln sich, jetzt in der VorKI-Ära stapelten sich dann da für ein halbes Jahr noch Pull Requests, weil der nicht dazu kam, die alle freizugeben, zu Reviewen und freizugeben. Also ich glaube, dieses irgendwann musst du erkennen auch, dass du jetzt schlussendlich ein Manager bist und kein Maker mehr, dass du dich um Leadership-Themen kümmern musst und deine Organisation besser machen und nicht deinen Code.

SPEAKER_00 53:53

Sehr gut, das ist auch ein wunderschönes Schlusswort für heute. Wir sind eine spannende Reise angetreten, haben sehr viel gelernt und sind sehr tief eingestiegen in das Thema nicht nur Text, sondern auch Product und wie das zusammenhängt, wie wir die Zukunft damit gestalten können, auch für die CTO-Rolle. Und ich glaube, Konstantin, wir müssen dir tatsächlich einen Teil 2 folgen lassen. Den werden wir im Anschluss auch planen. Und bis dahin bedanke ich mich schon mal recht herzlich bei dir für die heutige Teilnahme und für das sehr spannende Gespräch. Ich danke dir auch. Sehr schön. Mach's gut. Ciao, ciao. Ciao.