#47 Jeder kann coden – warum trotzdem so viel Unsinn gebaut wird. Mit Konstantin Diener

Viele CTOs stehen gerade vor einem Paradox:

Software zu bauen war noch nie so einfach.
Und trotzdem bauen viele Teams… die falschen Dinge.

In dieser zweiten Folge mit Konstantin Diener (CTO @ cosee) gehen wir genau in diesen Widerspruch rein.

Nachdem wir im ersten Teil darüber gesprochen haben, warum technologische Exzellenz zur Commodity wird, geht es diesmal um die entscheidende Frage:

👉 Warum entstehen trotz besserer Tools, AI und höherer Geschwindigkeit so viele Produkte ohne echten Impact?

Wir sprechen über ein zentrales Problem moderner Tech-Organisationen:

Features werden gebaut, weil sie jemand will –
 nicht, weil sie ein echtes Problem lösen.

Konstantin zeigt, warum viele Unternehmen noch immer kein echtes Product Mindset haben und wie gefährlich das in einer Welt wird, in der Umsetzung kein Engpass mehr ist.

Ein besonderer Fokus liegt auf:

• Warum Geschwindigkeit kein Wettbewerbsvorteil mehr ist 
• Wieso „mehr Features“ oft zu schlechteren Produkten führt 
• Wie man erkennt, dass man gerade das Falsche baut 
• Warum Feedback-Zyklen wichtiger sind als Delivery 
• Weshalb viele CTOs noch immer im alten Denken gefangen sind 

Außerdem sprechen wir darüber:

• Was mit Entwicklern passiert, die „einfach nur coden wollen“ 
• Warum Upskilling wichtiger wird als Hiring 
• Wie CTOs beginnen müssen, in Wert und nicht in Output zu denken 
• Und welche Rolle Product Thinking in Zukunft spielt 

Diese Folge ist ein Reality Check für alle, die glauben, dass bessere Tools automatisch zu besseren Produkten führen.

Transcript

SPEAKER_00 0:00

Hallo und herzlich willkommen zu Becoming CTO Secrets, deinem Podcast für die harte Realität der CTO-Rolle zwischen Tech, Team und Business. Ich bin Philipp Deutscher, Ex-Tender CTO und CTO-Coach und natürlich auch Gründer der Becoming CTO Community. Vor ein paar Wochen hatten wir Konstantin Diener zu Gast und haben dann gemerkt, wir sind mit den Themen auch nicht ganz durchgekommen. Und Konstantin ist weiterhin natürlich das CTO der Kursie GmbH in Darmstadt. Er begleitet weiterhin Unternehmen dabei, Technologien nicht nur umzusetzen, sondern echt einen Business Impact zu erfolgen, äh, erzeugen, erfolgen, erzeugen natürlich. In der letzten Folge haben wir bereits darüber gesprochen, warum klassische IT-Services zur Commodity werden und sich die Rolle des CTO fundamental verändert. Und heute gehen wir einen Schritt weiter und schauen uns an, was da konkret im Alltag in Teams und in Entscheidungen bedeutet. Konstantin, guten Morgen, herzlich willkommen. Moin Moin, ich freue mich drauf. Ja, ich merke schon, wir sind beide noch nicht so ganz auf Betriebstemperatur angelangt. Wir nehmen früh am Morgen auf, am Montagmorgen sogar. Und mal schauen, wie wir so rein starten. Wie ist gerade der Puls bei dir?

SPEAKER_01 1:07

Ich glaube, es wird trotzdem ein wilder Ritt. Ich bin hier extra ins Büro gedüst, damit ich auch ein ordentliches Setting habe, um den Podcast aufzunehmen. Von daher glaube ich, wir kommen schnell auf Betriebstemperatur.

SPEAKER_00 1:20

Sehr schön, dann lass uns direkt reinsteigen. Genau, in der letzten Folge haben wir ja gesagt, jeder kann heute coden, jeder Trottel kann heute coden war ein starkes Statement von dir, was auch auf diversen anderen Social-Media-Plattformen sowohl Zustimmung als auch Ablehnung gefunden hat, aber das war ja zu erwarten. Warum bauen dann trotzdem noch so viele Teams die falschen Dinge, wenn eigentlich heute jeder coden hat?

SPEAKER_01 1:43

Ich meine, das war ja in der Vergangenheit auch nicht die Herausforderung. Da hat man das im Zweifel durch große Mannschaften erschlagen. Das, was man heute dann irgendwie KI gestützt macht, AI-Augmented Coding oder wie auch immer, dafür hat man riesige Entwicklerherscharen gehabt. Aber das heißt ja erstmal nicht, dass man in die richtige Richtung rennt. Jetzt ist es noch einfacher, sich der Illusion hinzugeben, dass Geschwindigkeit alles ist. Und viele Organisationen haben aber immer noch kein Product Mindset, sondern irgendwie Stakeholder, Senior Management oder wer auch immer, denken sich Features aus und die werden dann gebaut oder die Kunden bestellen Features. Weil auch bei B2B-Produktunternehmen ein Riesenthema immer noch. In Deutschland ist ja gerade der B2B-Softwaremarkt historisch sehr stark. Und da ist immer wieder dieses Spannungsfeld von wegen, ja, aber unser Kunde X, der sonst so viel Prozent des Umsatzes ausmacht, der wünscht sich Feature Y und dann wird das einfach gebaut. Und dann gibt es ja irgendwie diesen Kreislauf von Melissa Perry: so von wegen, niemand benutzt dein Produkt. Du fragst deine User, was sie haben wollen, du baust es und dann geht der Kreislauf von vorne los. Und das erlebe ich in den Organisationen zum Teil halt auch. Vielleicht nicht ganz so krass, wie ich es jetzt eben beschrieben habe, aber es ist oft noch so ein, wir ermitteln gar nicht, was die Probleme der Nutzer sind, die wir lösen wollen, sondern wir haben schon gleich geile Ideen. Und das ist auch so ein Punkt, weshalb ich mit dem Begriff Anforderung zum Beispiel so mein Problem habe, weil ja da irgendjemand ganz sicher ist, dass es das jetzt braucht. Das ist richtig.

SPEAKER_00 3:20

Ja, ich frage mich aber trotzdem, wenn das Erzeugen von neuen Ideen, von Features gerade so billig ist und das den User fragen, ist ein sehr teurer Prozess. Also gerade im Vergleich dazu wird das ein sehr teurer Prozess. Lohnt es sich ja doch für viele Teams vielleicht zu sagen, naja, wir bauen jetzt einfach mal drauf los und irgendwas, wenn wir genug Scheiße an die Wand werfen, dann irgendwas bleibt schon kleben. Kann man ja auch so sehen.

SPEAKER_01 3:46

Naja, also erstmal ist es so, auch die User zu fragen, und das ist ja in diesem Kreislauf von Melissa Perry, es geht nicht darum, die User zu fragen, was sie gerne haben wollen, sondern zu verstehen, welche Probleme wir eigentlich für die Nutzer lösen. So, das ist das Erste. Das zweite ist, dass ich gerade vorletzte Woche kurz vor Ostern ein Gespräch mit dem Kunden hatte. Und allein die Überlegung, was man nicht baut, hat deutlich mehr Geld gespart, als ich es durch jeden KI-Einsatz hätte erreichen können. Weil uns aufgefallen ist, dass dafür eine full-blown Softwarelösung zu bauen, einfach unsinnig wäre. Es ist eine Übergangslösung. Wir haben uns dann dazu entschieden, dass wir sagen, wir exportieren ihnen was in ein Exportschema und sie bauen sich einfach mit ihrem Reporting-Tool einen kleinen Reporter drauf für die Übergangszeit. Das ist Lichtjahre günstiger und das hat unglaublich viel Arbeit gespart. Man hätte halt Unsinn gebaut. Zu dem, was du jetzt eben gesagt hast, ich befürchte, dass dann die Softwareprodukte noch mehr so werden, wie LinkedIn-Posts heute oft sind. Hauptsache Masse und die Leute können es einfach nicht mehr sehen. Sie wollen es nicht mehr lesen, weil es einfach so ein durchschnittlicher, weichgespülter Kram ist. Und in der Vergangenheit war es ja auch nicht so, dass Produkte nicht erfolgreich waren, weil sie zu wenig Features hatten. Melissa Perry hat diese erschreckende Statistik, dass irgendwie unter 10% der Features in einem durchschnittlichen B2B-Softwareprodukt überhaupt benutzt werden. Unter 10%. Und es gibt ja diese anderen Untersuchungen, die sagen, rund ein Drittel unserer Ideen hat positiven Einfluss auf das Nutzererlebnis. Ein Drittel rund, und zwar in guten Organisationen, in den besten. Rund ein Drittel hat gar keine Auswirkungen auf das Nutzererlebnis. Und rund ein Drittel hat eine negative Auswirkung auf das Nutzererlebnis. In der Zeit, als der ich angefangen habe, professionellen Software zu entwickeln, da gab es auch kein Test-Driven Development, also gab es die Konzepte gab es schon, aber das hat keiner flächendeckend eingesetzt, Test-Driven Development und so weiter. Und da haben wir gerne von Bananensoftware gesprochen, die beim Kunden reift. Und das machen wir jetzt im Zweifel, wenn wir jetzt einfach allen möglichen Scheiß, der uns einfällt, in so ein Produkt einbauen und dann die User rausfinden lassen, was die geil finden. Die werden da keinen Bock drauf haben. Denn, und das ist ja auch, wenn das jetzt auch ein bisschen pathetisch klingt, aus dem kleinen Prinzen, dieses Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzubauen kann, sondern Perfektion ist dann erreicht, wenn man nichts mehr weglassen kann. Und das ist die große Gefahr durch dieses so viel ist jetzt einfach baubar, dass die guten Produkte sich dadurch sich auszeichnen werden, die guten Softwaresysteme sich dadurch auszeichnen werden, dass sie das enthalten, was notwendig ist und nicht alles, was irgendjemandem eingefallen ist.

SPEAKER_00 6:42

Ja, auf einer intellektuellen Ebene stimme ich dem zu, aber ich halte es auch genauso für komplett unrealistisch, dass wir jetzt anfangen, mehr wegzulassen als vorher in einer Zeit, in der wir mehr dazu bauen können als vorher.

SPEAKER_01 6:55

Ja, das wird mit den Organisationen zu tun haben. Ich halte es, also im positiven Fall schaffen wir es, die Zyklen deutlich schneller zu kriegen, denn was ja auch in der Regel fehlt, ist, alles das, was wir als Features bauen, sind am Ende Hypothesen. Ich habe gerade gesagt, diese Drittel-Drittel-Drittelregel in den besten Organisationen, in den durchschnittlichen Organisationen oder in Startups ist es so, dass eine von zehn Ideen einen positiven Impact auf das Nutzererlebnis hat. So, im Optimalfall schaffen wir es dadurch, dass Delivery jetzt so einfach ist und dass wir auch in der Product Discovery im Rausfinden, was das richtige Produkt ist, durch KI uns dieses Exoskelett überziehen können und Product Manager zum Beispiel viel datengestützter arbeiten können, wofür sie in der Vergangenheit, Data Analysts, Softwareentwickler und was weiß ich noch alles gebraucht hätten. Im Optimalfall schaffen wir es, viel kürzere Feedback-Zyklen hinzukriegen. Oder in manchen Organisationen, ja, euch meine ich da draußen, überhaupt Feedback-Zyklen hinzukriegen. Denn in vielen Organisationen ist ja ein Feature zu bauen. Da ist den Leuten überhaupt nicht klar, dass da eine Hypothese dahinter steckt, sondern die hauen dieses Feature raus und damit war es das. Niemand misst überhaupt jemals, ob die Hypothese, die hinter diesem Feature steckt, überhaupt aufgeht. Ist das überhaupt ein Nutzerproblem? Nutzen die Leute es überhaupt? Also im Optimalfall schaffen wir mit diesem Exoskelet, was uns deutlich beschleunigt in Delivery and Discovery, dass wir deutlich schnellere Feedback-Zyklen hinbekommen, or überhaupt Feedback-Zyklen hinbekommen, and nicht einfach ungesteuert jeden Quatsch bauen, der uns in den Kopf bist.

SPEAKER_00 8:33

Yeah, dem stimme ich auch zu. Mir ist jetzt parallel dazu der Gedanke gekommen: es gibt ja durchaus auch Feature that sich gut verkaufen lassen. Dann baust du das Feature, the revenue geht hoch. Dann user nutzt es trotzdem nicht, aber er ist weiterhin der Meinung, er braucht das ja ganz dringend. Solche Features magst du ja auch geben. Würdest du die trotzdem ausbauen? Weil du wirklich eine Korrelation herstellen kannst zwischen, Kunde sagt, er braucht das Feature, Kunde kauft das Produkt, weil er das Feature braucht. Am Ende siehst du aber, Kunde nutzt das Feature gar nicht.

SPEAKER_01 9:00

Die Frage ist doch, also die Frage, die viel zu selten gestellt wird in dem Zusammenhang, ist, warum meint der Kunde, dass er dieses Feature braucht? Was wird dadurch anders? Was wird dadurch besser? Das ist die zentrale Frage, die viel zu selten gestellt wird, sondern es heißt einfach, und ich habe genügend B2B-Kunden und ich kenne das aus unseren Engagements genauso. Es ist ein steter Kampf, immer wieder die Frage zu stellen, was genau wird dadurch besser? Wann benutzt du das? Wofür benutzt du das? In welchen Situationen benutzt du das? So, und Kunden sind in der Regel keine Lösungsexperten. Wir sollten sie als Problemexperten betrachten, beziehungsweise mit ihnen das Problem beleuchten. Und dann finden wir im Zweifel raus, dass sie damit was ganz anderes eigentlich vorhaben und dass das, was sie sich vorgestellt haben, vielleicht in der Realität überhaupt nicht funktioniert. So, und wenn ich das Problem verstanden habe, was der Kunde damit lösen will, dann kann ich ihm auch was bauen, was zu seinem Problem passt. Und das ist dann was, was auch ein positives Nutzererlebnis auslöst. Ich habe Ende letzten Jahres mehrere Vorträge zum Thema Product Delight gehört. Und das ist dieses erstens Überraschung und zweitens das Übererfüllen von Erwartungen. Und das schaffe ich nicht, wenn ich einfach stur das baue, was der Kunde verlangt, sondern wenn der Kunde auf einmal sagt, wow, ich wusste gar nicht, dass das geht. Ach, ist das ja. Oh, das ist aber jetzt. Okay, ja, das ist ja viel einfacher, als ich mir das ausgedacht habe. Und das sind die Punkte, an denen, an die wir ran müssen, zu verstehen, was ist das Problem. Und dann können wir weiter Nutzer begeistern. Und das ist was völlig anderes, als einfach nur weil es geht, alles Mögliche da reinzuballern in so ein Produkt. Ich habe das letzte Mal gesagt, wir haben meiner Meinung nach bislang nie wieder die Produktivität erreicht, die wir mit Ball and Delphi mal hatten. Übrigens auch ein schönes Statement, was auf Social Media sehr gut funktioniert hat. Und ich bin immer noch davon überzeugt. Aber wenn man sich das anguckt, diese Produktivität hat zum Teil auch, und die schon ein bisschen länger dabei sind unter uns, die werden sich erinnern an die Nutzeroberflächen, die wir dann in der Vergangenheit zum Teil hatten, wo wir einen riesigen Screen, full with Buttons, with the ganzen, weil die so einfach to bow were with Delphi. Man hat einfach einen weiteren Button in this thing reinzogen. Ging das schnell? Yeah. War das einfach? Ja. Waren wir super produktiv? Ja. Hat das ein geiles Nutzererlebnis ausgelöst? Nein. So, and this is, we must die Produktivität halt dafür nutzen, großartige Nutzererlebnisse zu erzeugen. And ich meine, ich habe ja zehn Jahre meiner Zeit als Berater in der Bank verbracht. Und da war immer die Aussage, hey, Dina, UX, brauche ich nicht, das müssen die Leute eh benutzen. So, und das funktioniert aber heute nicht mehr. Diese Diskussion hatte ich mit einem Bekannten letztens, der sagte, ja, aber wenn du jetzt vor allem klassische Unternehmen anpackst und deren Prozesse optimierst, ist doch scheißegal, wie das aussieht, ist doch scheißegal, wie das sich anfühlt. Nein. Wir haben überall auch Consumerization, die Leute der Gen X, Gen Y, Gen Z sind da unterwegs und die akzeptieren es nicht mehr. Es gibt Leute, die kündigen ihren Job, weil sie mit beschissenen Tools arbeiten müssen. Auch in der aktuellen Zeit noch. Und das ist, die Leute akzeptieren immer weniger, dass sie geile Anwendungen auf dem iPhone haben und sobald sie eine B2B-Applikation aufmachen, ist einfach nur noch ein Krampf.

SPEAKER_00 12:26

Wenn du jetzt heute in Unternehmen kommst, du redest ja auch mit CTOs anderer Unternehmen, woran erkennst du sofort, dass die alle noch im alten Denken sind und was sind aus deiner Sicht so die größten Fehlannahmen, die diese CTOs aktuell noch haben.

SPEAKER_01 12:41

Also meine Grundhypothese, und das haben wir beim letzten Mal besprochen, ist, dass CTOs näher ans Produkt dranrücken müssen, weil wir in den Organisationen alle zeigen müssen, was wir an Wert bei. Und es reicht nicht, Delivery ordently zu organisieren, sondern wir müssen halt gucken, dass wir die richtigen Sachen bauen. Und dabei muss auch Engineering das CTO helfen. Und woran ich merke, dass ein CTO noch sehr stark in dieser so wie du es genannt alten Welt ist, es fängt erstmal mit so Silo an. Also es fängt erstmal damit an, dass einmal kann es Silos sein. So here we are engineering and da drüben is product and we have miteinander nicht so viel zu tun, sondern die schreiben PRDs and we implementieren die dann. Das ist das eine. Und das zweite ist so organization where Product unter dem CTO hängt, but im Endeffekt eigentlich eher Requirements Engineering is. Und nicht dieses, wir müssen rausfinden, was wirklich Nutzerprobleme löst. Also, das ist oft dieses, we have noch nicht verstanden, dass wir hier Wert bringen müssen und es nicht darum geht, möglichst gute Delivery zu machen und Wert zu finden, dafür sind andere zuständig.

SPEAKER_00 13:58

Würde ein gutes Requirements engineering nicht auch implizieren, dass du herausfindest, was du eigentlich lösen musst?

SPEAKER_01 14:04

Also, es gibt mal das war sehr lustig, weil ich als jemand, der ein Problem mit dem Begriff Anforderungen hat, einen Vortrag auf einer Requirements Engineering Conference gehalten habe, über modernes Requirements Engineering. Und da habe ich mit vielen Leuten sehr emotional darüber diskutiert, weil Requirements Engineering für mich, und das haben manche Leute, alter Hasen Requirements Engineering anders gesehen, halt sehr so ein, ich benehme möglichst gut die Bestellung auf ist. So ein ich frage alles Mögliche ab, was man an dieser Bestellung verstehen muss. Ich frage mich aber nicht, was der Kunde jetzt gerade, was der Gast jetzt gerade essen will oder in welcher Stimmung der Gast ist und was dafür für ein Menü passen würde. Und so weiter und so fort. Also ich gehe nur hin und schreibe auf den Zettel und da um möglichst Missverständnisse bei der Herstellung in der Küche auszuschließen, ob es wirklich die Bratkartoffeln sein sollen und dass an den Bratkartoffeln auch Speck dran ist, ob das in Ordnung ist und so weiter und so fort.

SPEAKER_00 15:06

Aber liegt es nicht an jedem Einzelnen, das Requirements Engineering jetzt hier anders mit Leben zu füllen? Also was du gerade beschreibst, dem stimme ich überein. Das ist, was wir da draußen sehr oft sehen, aber es hindert ja niemanden daran, das richtig zu machen und Requirements Engineering auch über, ich nehme nur Bestellung auf und überlege mir, wie ich die Bestellung perfekt bearbeiten kann, anstatt ich hinterfrage, was der Gast jetzt hier eigentlich möchte. Das ist ja alles nur eine Frage davon, wie ich das selber interpretiere.

SPEAKER_01 15:37

Ja, zwei Gedanken dazu. Erstens, die meisten Leute im Requirements Engineering, die ich kenne, verstehen sich so nicht, sondern sie verstehen sich so, dass sie sozusagen den Riss in der Matrix finden, wo irgendwas nicht zusammenpasst, damit danach ein exaktes Bild dessen entsteht, was nur noch implementiert werden muss. Ich habe das vor Jahren in der Beratung mal gehabt. Da hatte ich einen Kollegen, der wurde immer wahnsinnig mit meinen User Stories als Product Owner damals, weil er meinte, ich hätte das Requirement nicht exakt genug spezifiziert, der wollte nicht mehr mit mir sprechen, sondern es einfach runterimplementieren. Und dann habe ich mal User Stories so geschrieben, wie er die gerne hätte, und dann haben die anderen in dem Team gesagt, ob ich sie für grenzdebil halten würde. Das wäre doch alles gesunder Menschenverstand, was da drauf stünde. Das ist das eine. Und das Zweite ist, dass es viele Organisationen gibt, die ihre Product Manager, Product Owner, Requirements Engineers gar nicht in diese Rolle lassen. Diese Diskussion habe ich mit Kunden auch immer mal wieder. Das heißt, wir wollen es verstehen. Und was ihr damit eigentlich erreichen wollt, was euer Ziel ist, und dann kriegen wir regelmäßig, und da ist keine Branche eine Ausnahme, ja, das wäre alles viel zu komplex. Sie hätten sich das schon alles ausgedacht und das müsste genauso sein. Nein, muss es nicht. War es noch nie und keine Branche ist überdurchschnittlich komplex. Denn das geht mathematisch einfach nicht, dass alle Branchen überdurchschnittlich komplex sind.

SPEAKER_00 17:05

Jetzt mal ein kurzer Einschub da rein zum Thema Requirements Engineering, jetzt gerade auch, weil sich das Thema im Zuge von Agentic AI nochmal verändert. Jetzt sagst du richtigerweise, die Teams haben dann irgendwann gefragt, sag mal, bist du grenzdebil, das sind doch das, also mit gesundem Menschenverstand und so und dem impliziten Wissen, was wir alle haben, wissen wir doch genau, was hier gemeint ist, warum schreibst du das dann alles noch so genau hier rein? Wenn wir uns jetzt Richtung Agentic AI aufstellen wollen, muss ja doch genau das passieren, oder nicht? Also, es muss alle Informationen da rein, implizites Wissen muss da rein, damit die AI oder die Agentic AI auch später den Kontext hat, um auch genauso umsetzen zu können.

SPEAKER_01 17:44

Naja, da ist wieder meine Frage, wie will man das denn machen? Also aus meiner Sicht gibt es zwei unterschiedliche Ansätze, wie man KI im Software Engineering verwendet. Einmal dieses AI-Augmented Coding und dann tatsächlich Agentic Coding. Und das ist für mich: der Unterschied liegt darin, wer sitzt im Fahrersitz. Und tatsächlich ist bei diesem AI-Augmented Coding viel stärker noch der Software-Entwickler oder die Softwareentwicklerin. Und dann ist das wie dieses Exoskelett, was ich bezeichnet habe. Und die Verantwortung bleibt auch bei den Software Engineers, was da entsteht. Und sie machen sich regelmäßig Gedanken darüber, ist das überhaupt das Richtige, was ich da gerade baue. Natürlich gibt es das in vielen Organisationen auch heute so nicht. Da, wo Jira-Tickets geschrubbt werden, da sitzt irgendein Business-Analyst, schreibt ein Jira-Ticket und dann nimmt einen Softwareentwickler das vom Stapel und implementiert das. Und das Jira-Ticket ist möglichst so geschrieben, dass er mit niemandem reden muss und es genauso implementieren kann. Da wird man wahrscheinlich einen Geschwindigkeitsvorteil mit Agentic AI haben. Das ist ja auch der Anwendungsfall. Der einzige mir bekannte Anwendungsfall, wo in der Praxis so Offshoring-Modelle einigermaßen gut funktioniert haben. Aber die Frage dabei bleibt weiterhin, wer kümmert sich denn darum, dass wir hier überhaupt das Richtige bauen? Also, ich weiß nicht, ob es der erstrebenswerte Zielzustand ist, alles so genau aufzuschreiben, dass dann daraus Code entsteht, weil wir ja auch uns über diese ganzen das Eintippen von Code in der Vergangenheit eigentlich nicht unbedingt unser Engpass war, sondern dieses, ja, aber was bedeutet das denn, wenn ich gleichzeitig diesen Stammdatensatz ändere und jemand anders löscht ihn oder führt eine Berechnung darauf aus und so weiter. Und diese Gedanken müssen wir uns weiterhin machen.

SPEAKER_00 19:44

Was passiert denn mit den Entwicklern, die einfach nur coden wollen?

SPEAKER_01 19:51

Also, das wird eine Entwicklung sein, das wird nicht von heute auf morgen sich ändern. Aber ich gehe davon aus, dass die Entwickler, die einfach nur coden wollen, in den nächsten Jahren verschwinden. Weil wir wieder stärker dahin kommen müssen, Problemlöser zu sein, Problemversteher zu sein, Problemlöser zu sein und nicht einfach nur coden. Deswegen bin ich auch jedes Mal etwas unruhig, wenn ich auf LinkedIn bei jemandem lese Open to work und dann gleichzeitig ein, ich liebe es, sauberen Code zu schreiben. Ich weiß nicht, ob das in Zukunft wirklich das Kernkriterium sein wird. Nicht überall und sofort, aber dieses, ich will einfach nur Code schreiben, ich möchte mit Menschen nichts zu tun haben, glaube ich, wird ein Riesenthema, dass das nicht mehr funktioniert. Immer weniger funktioniert.

SPEAKER_00 20:43

Und im Team, also da gibt es sehr viele Entwickler, die gehen sofort mit dir mit, andere bleiben in dieser alten Welt auch gefangen. Wie gehst du mit dem Widerstand im Team um, wenn sich die Rolle jetzt gerade so verändert? Gerade wenn du aktiven Widerstand spürst oder Ressentiments noch feststellst?

SPEAKER_01 21:00

Naja, also erstmal ist es so, dass wir schon länger so einen Produktentwicklungs- und Wertschaffenfokus haben. Und wir haben schon immer darauf geachtet haben, and ich war in jedem Bewerbungsgespräch in diesem Unternehmen hier dabei, dass wir Menschen einstellen, die Probleme lösen wollen und Software bauen wollen, um Probleme zu lösen und nicht einfach nur Code ins Terminal tippen. Natürlich hat auch dieser Prozess hundertprozentig funktioniert. Ich hatte vor Jahren mal einen Kollegen hier, der sagte mir, Konstantin, ich habe festgestellt, dass wir hier machen, hat so viel mit Menschen zu tun. Ja, das ist so. Ja, da habe ich keinen Bock drauf. Ich hasse Menschen. Wenn ich das gewollt hätte, die Sozialpädagogik oder irgendwas dergleichen studiert, aber ich habe Informatik studiert, weil ich nichts mit Menschen zu tun haben will. Dann haben wir zusammen entschieden, dass er dann hier falsch ist. Das war auch schon vor acht Jahren so. Das heißt, diese Herausforderung habe ich weniger. Auf der anderen Seite habe ich natürlich schon. Gibt es bei uns Überlegungen, so hey, macht jetzt in Zweifel die Maschine die Sachen, an denen ich Spaß hatte? Das ist natürlich ein Transformationsprozess, über den wir sprechen müssen, wobei ich der Meinung bin, den Code einzutippen. War das das, was euch in der Vergangenheit Spaß gemacht hat? Oder diese Nüsse zu knacken, wie löse ich dieses Problem jetzt möglichst einfach, möglichst kompakt und möglichst so, dass beim Nutzer Wert entsteht und verkünstle mich nicht daran und baue nicht irgendwelche goldenen Wasserhähne. War das nicht das Interessante und Code ins Terminal zu tippen oder in die IDE zu tippen, vielleicht nicht unbedingt das, was uns mit Freude erfüllt hat.

SPEAKER_00 22:52

Braucht es dafür neue Profile an Mitarbeitern, die man dann im Unternehmen braucht? Und kann man die Leute, die man schon hat, da hin entwickeln?

SPEAKER_01 23:03

Also ich war ja immer ganz großer Fan der Fraktion hinentwickeln. Schon immer ein Kollege von mir in der Beratung hat immer gesagt: du musst mit den Bräuten tanzen, die auf dem Ball sind, andere wirst du nicht finden. Und das ist natürlich, in der Politik nennt man das das Dorfdisco-Prinzip. Also man muss mit den Leuten, man sollte mit den Leuten arbeiten, die man zur Verfügung hat, und nicht immer davon träumen, sich andere zu backen. Also, das ist mal der Anfang. Was man auch dazu sagen muss allerdings ist, dass wir noch keine so grundlegende Transformation durchgemacht haben, weil wir schon mit einem DevOps-Mindset gestartet sind. Also dieses, wir lösen Silos auf und so ein Kram. Das mussten wir nie tun. Es könnte sein, dass das die erste grundlegende Transformation in der Entwicklungsmannschaft ist, die wir vor uns haben. Aber ich war in der Vergangenheit immer eher ein Verfechter von, arbeite mit den Menschen, die du da hast, und führe die an die neuen Herausforderungen heran. Da wird nicht jeder Bock drauf haben und da wird auch nicht jeder mitmachen wollen. Aber das ist dann okay, wenn diese Menschen entscheiden, dass sie da keine Lust drauf haben und sich was anderes suchen. Aber fertig gebackene, das fand ich auch bei unseren Kunden immer komisch. Die haben dann, wenn die Stellenausschreibungen draußen hatten früher, dann waren das nur Senior XY and Dev, Senior Diddle, Engineer, Senior This, Senior This, Senior This. Die haben immer nur versucht, fertig gebackene Profis einzustellen. Und haben sich dann gewundert, dass die aber irgendwie nicht die Performance gezeigt haben, die sich vorgestellt haben. Und dann kamen die Leute von uns, die zum Teil als Werkstudenten hier angefangen hatten im dritten Semester oder sowas, Informatik, und dann sagt der Kunde uns: Kon, wo findet ihr diese großartigen Leute? Die finden wir nicht einfach, die bilden wir aus. Das ist ein langer, langer Prozess. Ihr seht jetzt ein Produkt von mehreren Jahren Ausbildung in Teams und nicht ein, wir denken, wir können die Tiefkühlpizza einfach aus dem Regal nehmen und dann in der Mikrowelle heiß machen, sondern wir haben tatsächlich einen Teig geknetet und Zutaten geschnippelt und so weiter. Und dann wird die Pizza natürlich ganz anders, als wenn man versucht, eine Tiefkühlpizza in der Mikrowelle aufzubacken. Und das ist hier jetzt auch wieder so, dass die Leute dann am besten nach Senior AI-Engineers suchen oder irgend sowas, aber das im Zweifel gar nicht auf ihren Kontext passt.

SPEAKER_00 25:44

Glaubst du, dass dieser Ansatz auch für größere Unternehmen funktioniert? Oder ist das ein Ansatz, jetzt auch auf Talente zu setzen, die auszubilden, sie in die eigene Kultur von vorne, also quasi auch schon zu formen, dass sie zur eigenen Spielidee passen? Und funktioniert das auch in größeren Unternehmen at Scale? Oder ist das was wirklich für Agenturen, für Boutique-Agencies, was auch immer?

SPEAKER_01 26:09

Also ich war der Meinung, dass das natürlich funktioniert das nicht in allen Unternehmen, immer, aber grundsätzlich hat die Unternehmensgröße da erstmal nichts mit zu tun. Man muss aber davon ausgehen, also das habe ich sehr krass auch in Startups erlebt, dass die nicht eine gemeinsame Verantwortung wahrnehmen, beispielsweise um neue Teammitglieder zu gewinnen, sondern sie stellen dann irgendeinen Tech-Recruiter ein, der einen geilen Track-Record hat. Und das ist jetzt dessen Aufgabe, der kriegt jetzt Recruiting-Ziele, daran ist sein variabler Gehaltsbestandteil gekoppelt, und das ist dann Dans Aufgabe. Denn Dan ist ein Profi. Wir haben das immer als Teamsport verstanden: zu sagen, jeder ist hier Markenbotschafter und es ist nicht Konstantins Aufgabe, alleinige oder Dans Aufgabe, geile Leute ranzuschaffen. Sondern wenn wir irgendwo jemanden sehen, der cool ist, dann sprechen wir die Leute an, wir strahlen das in die Welt raus, dass es cool ist, hier zu arbeiten. Und das war aber oft, nämlich in anderen Organisationen, sehr silo-artig und arbeitsteilig, war so nach dem Motto, wir stellen jetzt den ein, der kriegt einen Haufen Geld dafür und der soll das dann alles machen. Und mit so einer Denke, natürlich, bildet man sich nicht die Talente aus. Aber das ist, am Ende ist das kein Vortrag, kein Podcast ohne Fußballmetapher, am Ende ist das wie im Fußball. Es gibt Vereine, die eine sehr starke Nachwuchsförderung haben, sich die Leute ausbilden. Und es gibt halt Vereine, die kaufen sich einfach Talente zusammen. Es funktioniert beides, aber ich war immer Fan einer guten Nachwuchsarbeit.

SPEAKER_00 27:56

Ja, beides kann funktionieren. Gerade auch, also ich meine, andere Vereine, große Vereine wie ein Real Madrid, die setzen weniger auf Talentförderung, die haben das natürlich auch, aber die können sich auch leisten, Stars zu transferieren, dafür Geld auszugeben, die dann aber auch zu ihrer eigenen Spielfilosophie und zum Selbstverständnis des Clubs passen. Ich habe noch in Erinnerung, es gab mal in den 90ern eine Real Madrid-Mannschaft. Da waren halt so Größen dabei, wie David Beckham, Roberto Carlos, Luis Figo und so weiter. Das war ein Sammelsurium an Stars, man nannte sie damals, glaube ich, auch die Galaktischen. Sie hatten trotzdem riesige Probleme, weil sie einfach nur eine Zusammenstellung aus Einzelspielern waren, aber substanzielle Fähigkeiten oder Typen in diesem Team dann auch gefehlt haben. Und dann haben sie irgendwann mal einen Spieler verpflichtet, Thomas Gravisen heißt er. Hieß ja, das waren Däne, der war ein Raubein, der war ein defensiver Mittelfeldspieler, der hatte, jetzt gehen wir aber zu sehr ins Fußballerische rein, egal. Der war einfach, der hat dem Team etwas gegeben, was dieses Team nicht hatte. War der ein Spieler, der in dieser Mannschaft objektiv was verloren hatte, ganz und gar nicht. Aber er hat in dem Moment die Mannschaft besser gemacht als vorher. Und ich glaube, mittlerweile haben Unternehmen, also auch Fußballvereine wie Real Madrid das verstanden oder besser verstanden als damals noch und agieren genauso. Deswegen finde ich diesen Zusammenhang, den du hier herstellst, von Talente ausbilden, Talente finden und integrieren, ist ein guter Ansatz. Du kannst aber natürlich auch dir gute Leute zusammensuchen, auch die Seniors zusammensuchen. Musst aber dann immer noch mal genauer hinschauen, passt dir denn wirklich zu dem, was ich dann vorhabe zu tun, denn der ist gegebenenfalls schon mehr fertig in seiner Entwicklung als derjenige, den du dir selber ranziehst, der nach seiner, der mit einem Praktikum bei dir angefangen hat.

SPEAKER_01 29:55

Ich war jetzt letzte Woche in Barcelona, einer der Top-Vereine, und die haben eine ganz berühmte Fußballschule, durch die unter anderem Leonel Messi auch gegangen ist. Der hat mehr Zeit seines Lebens in Spanien verbracht als in Argentinien. Der ist als ganz junger Kerl nach Barcelona an diese Fußballschule gekommen. Und das ist, glaube ich, ein gutes Beispiel dafür. Die machen exzellente, hochkarätige Nachwuchsarbeit dort. Und viele Unternehmen haben in der Vergangenheit das eben nicht gemacht, sondern haben einfach versucht, sich Stars zusammen zu kaufen. Und dann war es so ein, und die Diskussion hatte ich mit Kunden auch, dass ich gesagt habe, hier ist ein Team von uns, da sind Software Engineers drin, da ist ein Scrum Master, da ist ein Product Manager drin. Nicht, ja, okay, wir sind ja ein Startup, wir haben nicht so viel Geld, können wir den Scrum Master weglassen? Das sind ja alles erfahrene Menschen. Nee. Der FC Bayern würde auch nie auf die Idee kommen, den Trainer wegzulassen, weil das ja alles erfahrene Fußballspieler sind. Und der Thomas Müller trainiert die anderen so. Damals spielte der Müller noch in München, so mit der linken Hand trainiert er die anderen noch mit, weil er der erfahrenste unter denen ist. Auf die Idee würde niemand kommen, aber in Unternehmen ist das regelmäßig so.

SPEAKER_00 31:07

Das ist richtig. Jetzt hast du ja auch ein paar Dinge angesprochen, die sich jetzt gerade in der Industrie verändern, wo sich Mitarbeiter verändern müssen. Der Engineer muss sich in seinem Selbstverständnis ändern. Was hast du denn ganz konkret in deinem Alltag verändert in den letzten Jahren?

SPEAKER_01 31:22

In meinem Alltag hat sich verändert, dass ich mich immer weniger mit Technik beschäftigt habe und immer mehr mit zum einen Produktmanagement und zum anderen mit Betriebswirtschaftslehre. Deckungsbeitragsrechnung, Margen, Deckungsbeitrag 1, Deckungsbeitrag 2, Ebitmarge, was weiß ich alles. Also diese ganzen Dinge, die darüber entscheiden, ob ein Unternehmen erfolgreich ist oder nicht. Und das im Zusammenhang. Was will ich eigentlich erreichen? Betriebswirtschaft, wie messe ich, ob ich es erreiche, Betriebswirtschaft auf Impact bezogen und ich erreiche nie Impact, also dass ich irgendwas, dass bei mir was vorangeht, wenn ich nicht Outcome bei meinen Kunden erzeuge. Das heißt, und damit sind wir bei Produktmanagement, wie schaffe ich es denn, so Produktmanagement zu machen, dass meine Kunden was davon haben, dass die zufrieden sind und dann bei mir Impact entsteht. Und das hat alles kaum was mit Technik zu tun. Ich hatte letztens wieder ein Erstgespräch mit dem Kunden, da sitzt ein CTO, nämlich ich, auf dieser Seite. Und dann hatten die extra noch einen Softwareentwickler mitgebracht für die ganzen Technikfragen. Ich habe denen keine einzige Frage gestellt, weil mich interessiert hat, welches Problem löst ihr da, wann seid ihr erfolgreich, warum macht ihr das jetzt gerade?

SPEAKER_00 32:41

Ändert sich das nicht gerade nochmal etwas? Also auch vielleicht dein Bezug zu Technik und wie du dich mit Technik auseinandersetzt, gerade weil jetzt nochmal so viel im Technologiebereich passiert? Stichwort natürlich wieder, AI, LLMs und so weiter.

SPEAKER_01 32:55

Ja, wir müssen eigentlich, das ist eine gute Frage. Die Frage ist nämlich, wir wissen ja noch nicht, auf was das alles hinausläuft. Ist Agentic Coding wirklich so großartig, wie das im Moment scheint? Oder bauen wir uns da gerade irgendwas auf, wo wir in ein paar Jahren sagen, um Gottes Willen, das klang so toll, aber warum haben wir nie über X nachgedacht? Und ich diese Woche ist, also am 16. April findet ja die Crafting Products statt. Ich arbeite an der Keynote, wo es eben um das Thema geht, was macht denn Produktmanagement in der KI-Ära überhaupt aus? Und es bleibt weiterhin dabei, dieses Herausfinden, was Wert stiftet und was es wert ist, gebaut zu werden, wird sich auch in der KI-Ära nicht verändern. Und wir haben jetzt auch im Produktmanagement KI-Unterstützung, die uns bei ganz vielen Fleißarbeiten hilft. Aber das Interessante ist, jedes Mal stelle ich wieder fest, dieses sich Gedanken darüber zu machen, welches Problem lösen wir ja eigentlich, welches davon ist wert, gelöst zu werden und wie lösen wir das? Da sind wir mit Menschen immer noch so viel besser als mit irgendwelchen KI.

SPEAKER_00 34:09

Woran erkennst du denn konkret, dass ihr gerade dabei seid, das Falsche zu bauen? Also, wie sieht denn so ein Entscheidungsprozess bei euch heute aus? Und wie bist du da auch mit involviert?

SPEAKER_01 34:18

Die Frage ist: das Falsche am Ende wirklich beurteilen, sind wir wieder beim Fußball, am Ende zählt nur, was auch Platz stattfindet. Natürlich gibt es Hypothesen darüber, was das Falsche und was das Richtige ist, aber am Ende sieht man es auf dem Platz, werden die Features überhaupt benutzt. And natürlich, wenn der Kunde darauf besteht, dass er dieses Feature unbedingt haben will, und wir aber zusammen eigentlich objektiv herausgefunden haben, dass es Unfug ist, er will es aber unbedingt haben. Und dann kann ich ihm danach in den Analytics immer noch zeigen, dass er dafür Geld zum Fenster rausgeschmissen hat. We versuchen durch Product Discovery Techniken rauszufinden, was ist denn eigentlich das Problem und was ist dafür die kleinste sinnvolle Lösung, damit wir nicht unbedingt beim Bauen rausfinden, dass es das Falsche ist, but wenn wir feststellen beim Bauen und Feedback einholen, dass das Feedback uns das Gefühl gibt, einfach völlig auf dem falschen Weg zu sein und die Leute das sehr umständlich benutzen und eigentlich scheinbar was anderes damit erreichen wollen.

SPEAKER_00 35:32

Du hast jetzt eben auch das Thema Deckungsbeitrag, du hast die BWL-Schiene auch noch mit reingebracht. Wie bringst du denn sowas wie Return on Invest wirklich in so eine Product-Diskussion mit rein, ohne dass es dann am Ende des Tages nur nach Vertrieb klingt?

SPEAKER_01 35:50

Ein bisschen weiter ausholend als Antwort auf die Frage, weil ich nächste Woche auf der D-Con auch wieder einen Vortrag da drüber halten werde in Köln, was denn was wir denn im Product-Bereich, im Agilitätsbereich in den letzten paar Jahren eigentlich falsch gemacht haben. Was haben wir gemacht? Wir waren sehr überzeugt von dem, was wir, dass Retrospektiven sinnvoll sind, dass Sprint-Reviews sinnvoll sind, und zwar mit dem gesamten Team, dass AGI sinnvoll ist, dass Product Discovery sinnvoll ist und bla bla bla. Und wir haben das immer wieder den wirtschaftlichen Entscheidungsträgern im Senior Management auf dieselbe Art und Weise erzählt, immer wieder das Gleiche wiederholen. So, und die haben das aber nicht verstanden, weil wir das in unser Sprache ihnen erzählt haben. Und dann vergleiche ich das gern mit, wenn man in einem fremden Land ist, die Sprache nicht so perfekt spricht und die Leute einem was sagen, wo man die Vukabel nicht versteht. Und dann fangen sie an, lauter und langsamer mit einem zu sprechen, was aber nichts daran ändert, dass man die Vukabel nicht versteht. Sondern man muss dann irgendwie Umschreibungen dafür finden, man muss in der Sprache des Gegenübers sprechen. Und das haben wir jahrelang, jahrzehntelang nicht gemacht. Sondern wir haben immer lauter geschrien, wie geil Agile ist und bla bla bla, und dass das so muss und die Leute werden so zufrieden und so. Niemals hat jemand wirtschaftlichen Entscheidungsträgern wie einem CFO oder einem CEO das in betriebswirtschaftlichen Zusammenhängen erklärt. Guck mal, das spart uns das und das oder es gibt uns den und den Umsatz oder Cost of Delay ist sonst und so viel kleiner oder sowas. Also das ist grundsätzlich ein Problem, was wir haben, und in dem Vortrag nehme ich das auseinander und zeige den Leuten, wie sie schon durch jeder in seiner Domäne, auch Softwareentwickler, so argumentieren können, dass CFOs und CEOs, Senior Management Führungskräfte das besser verstehen. So, deine eigentliche Frage war ja aber, wie kann ich das in ein Product-Mindset reinbringen, ohne dass es gleich nach Vertrieb klingt? Ich weiß nicht, warum das gleich nach Vertrieb klingen sollte. Der Punkt ist ja, am Ende wollen die Leute immer irgendwas erreichen. Und tatsächlich auch im Product-Bereich ist es mir heute immer noch zu wenig darauf fokussiert, was betriebswirtschaftlich dabei rauskommen soll. Ich habe jetzt in den letzten Monaten Produktstrategie-Assessments angeboten. Da haben die Leute mit ihrer Produktstrategie gekommen, wie so ein Repair-Café, ja, und wir haben uns die zusammen angeguckt. Und es ist erschreckend, wie selten betriebswirtschaftliche Kennzahlen in diesen Produktstrategien auftauchen. Sondern es ist meist so, hey, wir wollen das und das verbessern, das das cooler machen, das und das cooler machen, aber da steht nirgendwo, welchen Wert das fürs Unternehmen, also wie das mit den Unternehmenszielen zusammenhängt und welchen Wert das fürs Unternehmen stiftet. Und dann sind wir wieder ganz beim Anfang unseres Gesprächs. Das wird sehr schwierig in Zukunft, wenn man nicht zeigen kann, welchen Beitrag man zum Unternehmenserfolg leistet. Von daher ist es das ureigenste Interesse und bisher habe ich bei den meisten Gesprächen eher Erleichterung wahrgenommen, dass da jetzt nicht wieder irgendwie so ein Tech-Dully kommt, der sie nur mit allem möglichen Kram voll labert, den sie eh nur halb bis gar nicht verstehen, sondern der verstehen will, wann sie wirtschaftlich erfolgreich werden, warum sie das Ganze tun und woran sie das festmachen, was die maßgeblichen Kennzahlen sind, die sie erreichen wollen.

SPEAKER_00 39:14

Es ist natürlich nicht immer so einfach, diesen Zusammenhang herzustellen, aber wenn man es gar nicht erst probiert, wird man auch nie natürlich dort landen. Also natürlich muss man hier auch mit Hypothesen arbeiten und Annahmen, aber trotzdem wird es dir am Ende des Tages das Produkt, beziehungsweise auch die Konversation mit einem CEO und einem CFO vereinfachen, wenn du diese Brücke schlägst.

SPEAKER_01 39:34

Lustigerweise gibt es sogar in diesen Kreisen potenzielle Kunden, die sagen, ja, man muss ja auch nicht immer alles in Geld ausdrücken können. Dann sage ich Ihnen, naja, aber wir werden ja auch die Kosten in Geld ausdrücken. Also was ist besser? Ja, unsere Kunden sind dann zufrieden. Aber was hilft euch das? Denn am Ende ist niemand zufrieden, wenn wir da für einen Haufen Geld Software auf die Wiese stellen, ob es jetzt ganz viel mit Agentic AI ist oder weniger ohne Agentic AI. Aber es tut sich auf der Umsatzseite nichts.

SPEAKER_00 40:12

Du hast jetzt ein paar Mal schon erwähnt, oder hast von Konferenzen auch gesprochen, auf denen du in nächster Zeit unterwegs bist. Du bist allgemein, glaube ich, extrem viel außen unterwegs oder danach draußen gerichtet unterwegs. Also quasi CTO als Außenminister, so die Interpretation. Warum ist das für dich kein reines Nice-to-have, sondern essentieller Bestandteil deiner Interpretation, der CTO-Rolle?

SPEAKER_01 40:38

Also grundsätzlich hat das zwei Facetten. Und als ich damit angefangen habe, war das so ein, hey, ich gebe der Community was von den Dingen, die ich gelernt habe. Dann mit der Zeit habe ich gelernt, dass in einem Geschäft wie unserem, wo lange Jahre auch das Thema technische Exzellenz und entwickelt ihr überhaupt, versteht ihr euer Handwerk, ein wichtiger Faktor war, da ist es wichtig, dass du nicht nur dich hinstellst und sagst, natürlich können wir tolle Software entwickeln, sondern dass du auch einfach initiativ dein Wissen teilst und die Leute auch Videos von Konferenzen angucken können auf Konferenzen, was von dir hören. Und das einfach auch deine Glaubwürdigkeit steigert. Das soll jetzt nicht sein, dass man die Leute einlullt mit irgendwas, sondern, hey, der hat was Relevantes zu sagen, was uns weiterhilft und so weiter. Das steigert die Glaubwürdigkeit und das ist in einem Dienstleistungskontext natürlich ganz wichtig, Glaubwürdigkeit, denn immer noch das, was wir herstellen, kann niemand anfassen, Kostenhaufen Geld. Und Vertrauen und Glaubwürdigkeit ist eine ganz, ganz wichtige Währung. Der Typ, der mir da gegenüber sitzt, der da oben auf der Bühne steht, glaube ich dem, was er sagt, versteht er sein Handwerk oder redet der nur Stuss? Oder ist das auch jemand, der betriebswirtschaftlich was versteht oder kann er nur Technik? Das ist das eine. Und jetzt könnten natürlich die ganzen Product-CTOs aus Product Companies sagen, die keine Dienstleistungsunternehmen sind. Ja, das brauche ich alles nicht. Unsere Kunden sind Maschinenbauer, die laufen eh nicht auf Tech-Konferenzen. Konferenzen war für mich auch immer wieder ein Mechanismus, mein CTO-Partylatein zu füttern. Das heißt, auf einer gewissen Flughöhe einen Einblick in die ganzen Themen zu kriegen, die gerade da passieren, und zwar in einer praktischen Hinsicht. Es gibt auch beschissene Konferenzvorträge, die hätten auch einen LinkedIn-Post sein können, aber die, die wertvollen, da kriegt man so ein paar Praxisimpulse, wo die Leute wirklich die Motorhaube aufmachen und einen reingucken lassen. Und das füttert das CTO-Party-Latein. Man hat weiterhin, und das ist ganz wichtig für jeden CTO, egal in welcher Organisation, so eine Landkarte zu haben. Was tut sich denn überhaupt? Und das muss nicht der Gardinerquadrant sein oder sowas, sondern einen Eindruck davon zu haben, wie entwickelt sich denn eigentlich die Technologielandschaft, die Methodiklandschaft und so weiter. Ja, es gibt Leute, die haben das ausschließlich über Twitter und Blogs und Reddit und was weiß ich gemacht. Ich bin da aber eher so ein Typ, ich lerne lieber durch die Interaktion mit Menschen und wenn dann jemand da ist und den ich ansprechen kann und wo ich dann auch mal ein paar Fragen stellen kann, finde ich deutlich sinnvoller, da auf einem Stand zu bleiben. Man muss allerdings dazu sagen: gerade was Leadership-Themen im CTO oder im Tech-Bereich, im Engineering-Bereich angeht, gibt es wenig bis gar keine guten Veranstaltungen oder gab es in der Vergangenheit. Sondern es ist meist sehr technig, aber auch das ist wichtig, um diese Landkarte immer wieder zu füttern. Wie gesagt, diese CTO-Party-Latein. Und nicht nur im eigenen Saft zu schmoren.

SPEAKER_00 44:03

Aber vielleicht brauchst du genau so etwas noch, auch im deutschsprachigen Bereich. Weil ich gebe dir völlig recht, es gibt eine Menge Engineering-Konferenzen, die haben aber dann doch einen sehr, sehr starken Engineering-Bezug und sind natürlich für die CTO-Rolle, die dann sich eher Richtung Richtung Business, Tech, Product und hier die Brücken schlägt, da gibt es relativ wenig, was sich auf der Flughöhe, ja, was hier auf der Flughöhe Austausch anbietet, wäre ja natürlich auch was, was wir ja irgendwo auch auf die Beine stellen können. Weil ich stelle auch tatsächlich fest, dass die meisten CTOs, die ich kenne, und ich denke, das deckt sich mit dem, was du kennst, die meisten CTOs sind ausschließlich mit der Innenpolitik beschäftigt, sie sind der Innenminister, sie agieren nur innerhalb des Unternehmens, sie sind wenig bis gar nicht sichtbar nach außen und haben auch gar nicht, haben auf der einen Seite vielleicht noch gar nicht den Mehrwert verstanden, was sie da alles verpassen, auf viele Dinge, die du gerade beschrieben hast. Es gibt aber auch gar nicht so viele Möglichkeiten dafür, Stand heute.

SPEAKER_01 45:00

Ja, also ich habe ja regelmäßig Tech Leads Breakfasts veranstaltet. Und ich stelle fest, dass gerade die Leute, die aus keinem Dienstleistungsunternehmen kommen, da sehr, sehr, sehr zurückhaltend sind. Weil die immer die Befürchtung haben, dass das so läuft, wie dass sie sich dann fühlen wie die Mädels früher in der Disco. Aha, ich bin ein Mädel und hier stehen fünf Jungs um mich rum. Die Jungs sind in dem Fall die Dienstleister, die pitchen mir irgendwelchen Kram, den sie mir verkaufen wollen. Also da sind die CTOs oder die Tech Leads insgesamt sehr, sehr vorsichtig geworden, nicht auf Veranstaltungen zu landen, wo sie dann mit haufenweise Dienstleistern am Tisch sitzen, die ihnen nur irgendwas verkaufen wollen, wo sie aber nichts lernen können. Auf der anderen Seite stelle ich fest, wenn diese aus Product Companies, diese Engineering Leads oder was auch immer sie waren, wenn die sich dann selbstständig machen, beispielsweise, auf einmal tauchen die auf jeder dieser Veranstaltungen und gehen davon aus, dass die anderen Product Company, CTOs and engineering leads, and so that are there, and their coaching and what services anbieten can. Nein, they come so many as you are.

SPEAKER_00 46:12

Yeah, we also have a pitch for the veranstalting. We have an Mai quasi a CTO roundtable, where we also have we won't CTOs. I think we have a ring geworfen, that is the form des Austauschs that we have, which is unsere Verantwortung als CTOs, die hier schon mehr outgoing sind als andere, die Brücke zu bauen für die anderen, die nachkommen sollen. Siehst du das auch so?

SPEAKER_01 46:45

Ja, natürlich. Halb zog er sie, halt zwangs sie hin. Aber am Ende müssen die Leute natürlich auch eine eigene Motivation haben. Ich kann sie natürlich nicht zwingen, zu solchen Formaten zu kommen. Aber ja, wir sind uns einig, es gab in der Vergangenheit gerade was Tech Leadership Themen angeht, und da dreht sich ja gerade alles auf links. Gerade was Tag Leadership Themen angeht, gab es eigentlich, insbesondere im deutschsprachigen Raum oder deutschsprachig wenig bis gar nichts.

SPEAKER_00 47:17

Was denkst du, warum ist das so? Ist das tatsächlich so, weil, naja, du hast, du hast vielleicht mehrere 10.000 Menschen im deutschsprachigen Tech-Bereich, die sich mit Engineering und dergleichen auseinandersetzen, aber am Ende des Tages hast du vielleicht nur tausend CTOs und das heißt, es ist zu sehr Nische, das Ganze?

SPEAKER_01 47:38

Ich weiß es nicht. Ich also, ich habe verschiedene Hypothesen darüber, ich weiß nicht, welche davon wahr ist. Es ist zum Teil auch so, dass die Leute das Gefühl haben, dass die Probleme, die sie haben, nur sie selbst haben und dass ihnen dabei keiner helfen kann, schon gar nicht irgendwie, wenn ich jetzt aus einem modernen Scale-Up komme in Berlin und mit einer Multikulti-Mannschaft arbeite und dann kommt da irgendwie ein Engineering-Lead aus einer relativ traditionellen deutschen Versicherung. Was soll ich von dem lernen, dass es das, was ich immer wieder feststelle, ist, dieses Tech-Leads sind extrem zurückhaltend, ihre Zeit zu investieren in sowas. Sie müssen sehr genau verstehen, dass das für sie einen Mehrwert bringt. Dann sind sie bereit, ihre Zeit zu investieren.

SPEAKER_00 48:33

Ja, jetzt haben wir aber schon wieder zwei verschiedene Rollen, die wir betrachten. Ich würde nochmal unterscheiden wollen zwischen dem Tech-Lead und dem CTO. Der Tech Lead ist vielleicht der zukünftige CTO, der ist da noch gar nicht angekommen, aber der CTO, der CTO, der schon in der Rolle ist, der sollte eigentlich schon weiter sein und schon mehr verstanden haben, was es da braucht.

SPEAKER_01 48:53

Ja, aber es ist tatsächlich oft so, dass die Leute sehr, sehr, sehr, sehr zurückhaltend sind, ihre Zeit zu investieren. Du musst ihnen sehr klar machen, dass oder es muss für sie sehr klar sein, dass das für sie Wert stiftet, was da passiert, dass ihre Zeit gut investiert ist. Und was ich auch dazu sagen kann, all diese Vorbehalte von wegen, nachher sind da Leute, von denen ich nichts lernen kann, haben sich immer als falsch herausgestellt. Ich hatte bei diesen Tech Leads Breakfasts alles Mögliche an Leuten an dem Tisch sitzen. Und das Interessante ist, wie groß die Überschneidungen, egal aus welchen Organisationen, egal aus welchem Reifegrad und so weiter die Leute kommen, wie groß die Überschneidungen dann doch sind. Und das ist das, für die Leute, die Kinder haben, das ist auch so, wenn man nur beim Bringen und Holen im Kindergarten die Leute sieht, denken, oh, das funktioniert ja alles so toll und bla bla bla. Aber die Masken fallen nach 15 Minuten auf dem Kinderspielplatz. Sagen wir, Szeneputzen war euch auch so ein Riesenproblem, oh ja, mir blusoft. Und das allein dieses, habt ihr auch diese Erwartungshaltung eurer Softwareentwickler, habt ihr auch diese Widerstände eurer Softwareentwickler gegen das und das, habt ihr auch die Widerstände eurer Organisation, verlangt eurganisation Folgendes von euch? Wie seid ihr damit umgegangen? Allein schon dieses, hey, ich bin damit nicht allein. Es geht auch anderen so, nicht überall wachsen sonst die Bäume in den Himmel, nur bei mir ist totales, total Bombardement an Dingen. Und zum anderen, vielleicht hat der eine den Kniff oder den Trick, wie er damit umgeht, den ich mir auch aneignen kann. Und das Lustige ist, dass ich, wir haben gerade kurz vorher darüber gesprochen, ich habe vor Jahren, mehrere Jahre lang im Java Magazin eine Kolumne geschrieben, DevOps Stories, mit verschiedenen Geschichten zu cross-funktionalen Teams, Communities of Practice und so weiter. Das war immer so aufgebaut, dass es eine Geschichte in so einem fiktiven Team gab und dann ein Erklärteil. Und ich habe immer wieder festgestellt, auf diesen Tag Leeds Breakfast, die ich veranstaltet habe, dass die Probleme, die ich da adressiert habe, immer noch die gleichen sind und immer noch in Organisationen diskutiert werden. Und das hat mich auch dazu gebracht, dass ich jetzt diese Geschichten als E-Book neu auflege, weil die Überschneidungen so unfassbar groß sind. Man meint das geil.

SPEAKER_00 51:18

Nimmst mal meine Frage gleich schon vorweg, weil ich wollte mich genau fragen, ob man auf diese Kolumnen auch noch heute irgendwie zugreifen kann. Aber wenn du sie jetzt auch noch als E-Book rausbringst, sehr gut.

SPEAKER_01 51:27

Ja. Sie werden dann Engineering Stories heißen, weil ich diesen DevOps-Begriff da rausnehme, weil es eigentlich nicht nur DevOps ist, sondern ganz viel außenrum, auch Hiring und Co. Ich habe die jetzt alle überarbeitet, damit sie von den Technologien und so nicht zu angestaubt sind. Aber die werde ich jetzt irgendwann demnächst als E-Book rausbringen.

SPEAKER_00 51:48

Also du versuchst den reinen Technik, also wozu es ja in eine technologische Richtung geht, das eher nochmal zu abstrahieren und das allgemeingültiger zu tun.

SPEAKER_01 51:56

In der technologischen Richtung ging das nie, da stehen dann halt Sachen drin, die heute kein Mensch mehr verwendet, ja. Drop Wizard oder irgendwie sowas. Dann lesen die Leute das dann. Dann denken, oh, geil, ich habe Besuche aus den 2000er Jahren bekommen oder sowas, ja. Solche Dinge habe ich dann rausgenommen, damit die Leute nicht über irgendwelche UL-Technologien im Java-Bereich stolpern oder sowas. Aber darum ging es auch nie, sondern das waren halt nur so Einsprenkel in diesen Geschichten, in diesem Team, das findet immer grob in demselben Team statt. Da gibt es irgendwelche Diskussionen, gibt es irgendwelche Reibereien und dann im Erklärteil bekommt man halt erstmal erklärt, warum das jetzt gerade so passiert ist und dann ein, wie kann man damit umgehen, wie kann man das lösen.

SPEAKER_00 52:38

Sehr gut. Konstantin, wir sind wieder am Ende angelangt und haben wieder einige Themen auf unserer Agenda liegen lassen müssen. Also entweder machen wir da jetzt eine Reihe draus, oder so führt das ja zu den. Aber trotzdem habe ich nochmal eine Runde Rapid-Fire-Fragen mitgebracht. Bei einigen weiß ich schon, was du antworten wirst. Ich stelle sie trotzdem. Hast du noch ein paar Minuten? Ja, dann los. Sehr gut. Product oder tech?

SPEAKER_01 53:02

Mittlerweile Product. Bauchgefühl oder Daten? Meine Kollegen hassen meinen Spruch, den ich von irgendeiner Valley-Größe kopiert habe.

SPEAKER_00 53:17

Das heißt, am liebsten Daten. Solange du nicht sagst, so I prefer my opinion over your data, dann sind es so. Nein, nein, nein. Das ist, glaube ich, okay. Sehr schön. Hiring oder Upskilling?

SPEAKER_01 53:28

Ich war immer Fraktion Nachwuchsförderung upskilling.

SPEAKER_00 53:31

Sehr gut. Haben wir, glaube ich, heute auch nochmal gut rausgestellt. So, Geschwindigkeit oder Richtung?

SPEAKER_01 53:37

Richtung.

SPEAKER_00 53:38

Und dann kommt irgendwann die Geschwindigkeit. Erst muss ich die Richtung stimmen. Sehr gut.

SPEAKER_01 53:43

Mein Kollege, derselbe wie mit dem Ball in der Beratung, hat immer gesagt, wenn du kein Ziel hast, ist jeder Schuss ein Treffer.

SPEAKER_00 53:50

Richtig. Oder euch jeder Schuss vorbei, ja. Eine Fähigkeit, die CTOs jetzt lernen müssen. Aber jetzt mal was anderes wie Product sagen.

SPEAKER_01 53:58

Nee, in Wert zu denken tatsächlich. Welchen Wert schaffen wir hier gerade? Schaffen wir hier Wert und wissen wir überhaupt, welchen Wert wir für wen schaffen?

SPEAKER_00 54:05

Sehr gut, sehr richtig. Und schließt auch gut den Bogen zum Anfang des Gesprächs. So sind wir auch irgendwo mit eingestiegen. Konstantin, es war mir wie immer ein Fest. Es ging wieder sehr schnell vorbei.

SPEAKER_01 54:16

Ja.

SPEAKER_00 54:17

Und die wird bestimmt genauso gut wie die erste Folge.

SPEAKER_01 54:19

Ich freue mich drauf.

SPEAKER_00 54:20

Dir noch eine schöne Woche, Konstantin. Ebenso. Danke. Ciao, ciao. Ciao.