Also ich wollte gerade sagen, ist ewig her. Stimmt aber nicht ganz. Ich habe tatsächlich von einem Verein, wo ich und mein Sohn Mitglied bin, vor kurzem die Homepage gefixt. Die war noch in PHP geschrieben. Uralter Dialekt. Ich selber habe nie PHP programmiert. Also ich habe einen Smalltalk und Java Background. Das Ding war total kaputt. Naja, und dann halt mit Coding Assistance war es halt total einfach, das Ding zu debuggen, zu entwickeln und zu deployen. Und das war tatsächlich meine letzte Coding.

Ich muss tatsächlich sagen, für mich, ich bin Informatiker, ich habe Software studiert, habe auch am Anfang meiner Karriere Software entwickelt, aber für mich war immer irgendwie spannender, im Englischen würde man sagen, to make things happen, also Dinge geschehen lassen. Und für mich war immer irgendwie das Spannendere, Menschen zusammenzubringen, Teams aufzusetzen, also diese Kombination von Menschenprozessen und Technologien.

Deswegen bin ich relativ früh aus dem Coding raus und bin in so eine Tech-Management-Schiene gegangen. Ich glaube aber, bei Amazon spricht man immer von Superpowern, dass das auch meine Superpower ist. Also Organisationen aufzusetzen, die in der Lage sind, Business-Value oder Innovation zu liefern.

ist genau das Thema, das wir heute sprechen wollen. Wie kriegen wir denn die Superpower von AI aus den Organisationen rausgekitzelt? doch zuerst eine Frage. Wie viel Wert hat denn in Zukunft Source Code für dich? Wenn wir in Richtung disposable Software denken, wenn wir jetzt sagen, müssen wir ihr die Specs aus dem Spec Driven Development oder die Prompts sogar Und am Ende des Tages ist Quellcode gar nicht mehr das Zentrale, sondern das, was generiert werden kann.

Ja, also ich war noch nie und ich bin es weiterhin kein Fan von No-Code. Ich glaube schon, dass man mit diversen AI-getriebenen Tools sich unterschiedliche Rollen im Büro, in der Businessarbeit selber Tools bauen können. Ich glaube aber auch, Geschäftsanwendungen, also komplexe Anwendungen, wie wir sie sehen, bei Amazon, bei Autoherstellern, bei Luftfahrtkonzernen

sehr komplex sind, dass die nicht leicht zu betreiben sind und dass die in der Regel, alles was bei Amazon sprechen wir dann von Enterprise Kunden, Großkunden, dass die noch ganz viel Potenziale haben bei der digitalen Transformation. Also ich habe mich erst die und letzte Woche ziemlich geärgert über noch nicht wirklich gut gemachte User Flows. Und deswegen glaube ich, ist Source Code weiterhin wichtig. Ich glaube, die Abstraktion verändert sich. Also als ich ab

angefangen hab zu coden, dann hast das halt noch im Texteditor gemacht und alles was du machen konntest war anzustoßen und dann kam halt gerade XP raus, das heißt man hat dann angefangen, Unitest zu schreiben, aber das war eigentlich so, bis du mit Code umgegangen und wenn ich mir angucke, was eigentlich in diesen Zeitzeiten in letzten 25 Jahren passiert ist, allein schon auf der Source Code Ebene, also dann ist da halt mehr Abstraktion dazugekommen, das haben wir auch die 25 Jahre davor gesehen und für mich ist weiterhin Source Code ist the single source of truth.

Das heißt, die Wahrheit steckt ⁓

Ja, also ganz so würde ich es nicht sagen. Also ich glaube, Codes

ist wichtig. Du musst weiter Source Code lesen können. Du musst Source Code schreiben können. Du wirst aber deutlich produktiver sein. Jetzt wirst du aber deine Source Code Entwicklungsarbeit und Softwareentwicklung ist mehr als Source Code schreiben, wirst du delegieren. Also du hast und in den nächsten fünf Jahren sind es vielleicht dann die Analogie ist, du hast ganz pfiffige, schlaue, hoch motivierte Hochschulabsolventen zur Verfügung.

die aber über dein Geschäft nichts wissen. Und an die delegierst du deine Coding-Arbeit. Das heißt, du musst ziemlich gut sein in wie delegierst du, was gibt es für Regeln, wann sie eskalieren sollen und was ist eigentlich der Kontext, in dem sie sich bewegen. Und deswegen glaube ich, gibt es schon noch Artefakte neben dem Source-Code, die deutlich wichtiger werden. Ich glaube auch, die musst du auch versionieren. Also du musst ganz klar wissen,

Ich bin jetzt das Checkout-Team von so einer E-Commerce-Seite und so funktioniert der Checkout. Das heißt, du musst eigentlich klar wissen, wie ist in dieser Domäne die Architektur definiert, warum haben wir bestimmte Architektur-Entscheidungen getroffen, warum haben wir andere getroffen, wie sieht denn guter Code bei uns aus, wie testen wir, wie deployen wir und dann kannst du an diese Hochschulabsolventen, also Agenten, delegieren.

Das heißt, die Fachlichkeit sollte eigentlich schon vorher im Fokus stehen, kommt jetzt mehr im Fokus und wir sollten uns mehr damit beschäftigen. Wie sind die Abläufe? Wie sind die Prozesse? Und wie können wir möglichst klar formulieren, was wir eigentlich sehen wollen?

Ja, das ist die Hoffnung, ich Was ich aber nicht in allen Unternehmen sehe, ist die Hoffnung ist schon der Software Entwicklungs Organisationen und für mich war die kleinste Einheit in so einer Software Entwicklungs Organisation immer das Team. Also der einzelne Entwickler, die Entwicklerinnen sind schon super wichtig, ja auch für den Engineering Manager, für den Teamleiter, da muss ich seine Leute kümmern, die muss die fördern, muss sie fordern. Aber aus organisatorischer Sicht ist die kleinste Einheit eigentlich das Team. Und

Startups und Scale-ups, die sind schon eine Weile ziemlich guter in, also auf Basis von Lean Startup, tatsächlich Business Value zu liefern. Also die sind begeistert für ihre Kunden, die wollen Kundenprobleme lösen und dann iterieren sie, bis sie das Kundenproblem gelöst haben. Was ich leider sehe in vielen Organisationen ist, da ist Coding das große Problem, Geschwindigkeit und Qualität ist das Problem. Und da ist eigentlich, Sie würden es jetzt anders formulieren, aber das Ziel, was die haben,

Vielleicht ist es auch nur das erste Etappenziel, ist eine Feature Factory zu werden. Ja, also wir sind gut in dem, was uns jemand spezifiziert. Vielleicht arbeitet er sogar bei uns im Team mit, ein Product Owner, ein Business Analyst. Vielleicht arbeitet er auch irgendwie außerhalb vom Team im Fachbereich. Aber was quasi Business will, das bauen wir und dann deployen wir das. also done means works on my machine oder works in production. Und das ist für meiner, ja meiner Meinung nach ist es nicht genug.

Also dann means someone's need was met. Also ein Kunde ist zufrieden und dann hast das erfüllt. Und eigentlich, indem du jetzt... Und das ist auch ein Trend, ich sehe. Also bei AutoScout haben wir 2014, 2015, you build it, you run it! eingeführt. Wir hatten vorher ein gutes DevOps, dann you build it, you run it eingeführt. Amazon arbeitet so schon seit Mitte der 2000er Jahre. Und das ist schon ein großer Vorteil. Also du reduzierst die Cycle Time.

weil du Abhängigkeiten reduzierst zwischen Entwicklung und Betrieb. Aber es ist natürlich für den einzelnen Entwicklern eine ziemliche Belastung. Also, weil zuerst hat man gesagt, du musst jetzt Fullstack werden, Frontend, Backend, Datenbank, vielleicht auch noch Mobile. Und dann sagst du übrigens, jetzt muss auch noch Infrastructure als Code können. Bei Autoscout war jeder manuelle Change in Produktion und Incident. Und dann sagst du übrigens, wenn dein Code nicht funktioniert, stehst du auf. Und deswegen haben viele Organisationen auch you build it, you run it! nicht adaptiert.

Und das ist schade. Wenn du jetzt aber und AWS, wir haben gerade unterschiedliche spezielle Agenten released auf der re.Invent. Einer davon ist eben ein Infrastruktur Agent. Das heißt, der für dich, wenn du ein you build it, you run it! Team hast, für dieses Team die Incedents löst. Und das finde ich, das finde ich schon ziemlich gut. Und das sind eben Trends, die ich sehe. Und ich hoffe, dass das Unternehmen adaptieren. Die Entwickler können sich mehr fokussieren auf Kundenprobleme und sie können

you build it, you run it! adaptieren, dadurch noch mal schneller werden, die Qualität besser haben. Und was ich glaube auch, was passieren wird, ist der Data Mesh-Gedanke. Das heißt, dass man Teile der zentralen, hochspezialisierten, auch effizienzoptimierten Analytics-Abteilungen dezentraler aufstellt. Also du schon eine zentrale Plattform, aber eigentlich deine Microservice-Teams, die ja den Geschäftsprozess verstehen, die die transaktionalen Daten erzeugen.

dass die in der Zukunft auch verantwortlich sind für die analytischen Aspekte von ihren Daten. Auch weil sie ja Agenten zum Beispiel mit Daten versorgen müssen. Und das kannst du aber nur machen, vom kognitiven Load, wenn du die Leute halt von anderen Sachen befreist. Dafür sind Agenten da. Wobei Agenten natürlich auch eine totale Belastung sein können. Also ich merke das selber. Ich kode nicht, aber ich nutze halt AI und Agenten für viel Content-Erzeugung zum Beispiel.

Und ich merke eigentlich, dass ich unkonzentrierter werde, weil dauernd irgendwer sich bei mir meldet und sagt, ich bin fertig, findest du mein Ergebnis gut? Soll ich weitermachen? Schau mal, ich hab schon weitergemacht, so ist mein Ergebnis. Dann schau ich drauf, denke mir so, was hast du da gemacht? Und deswegen glaube ich auch, und das sehe ich auch in Organisationen, dass eher ältere Mitarbeiter besser zurechtkommen mit Generative AI und ich nehme an, dann auch mit Agenten, weil die einfach schon besser wissen, wie du delegierst

Du hast ganz viele Themen jetzt schon angesprochen. Einmal den kognitiven Overload. Nein, du brauchst sehr gerne. Also kognitiver Overload, auch die Disruption, die man immer wieder bekommt. Man delegiert was, man hat einen Break. Das sind dann sozusagen diese Kontext-Switcher, die wir auch immer haben. Das solche Sachen, die eigentlich sehr, schwierig sind für die Entwickler und für auch die Lieferung. Du hast einen Artikel geschrieben.

Tut mir leid.

Your AI Coding Assistant will overwhelm your delivery pipeline. Also du hast eben gesagt, nicht nur die delivery pipeline, sondern auch vielleicht manchmal die Leute. Wie müssen wir uns organisatorisch aufstellen, dass wir quasi, wenn jetzt Coding nicht mehr das bottleneck war oder ist, wenn wir jetzt Code auf Masse schneller produzieren als sonst, was bedeutet das in der Kette der Lieferung? Wie müssen wir uns dafür aufstellen, dass wir wirklich auch die Power nutzen können?

Ja, also viele Kunden mit denen ich spreche und ich spreche mit 100 bis 120 Kunden, Führungskräften, Teams im Jahr und mein Team ungefähr mit 1500. Da ist mir die Erwartung, alles ändert sich jetzt. Und die gute Nachricht ist, ganz vieles ändert sich nicht. Viele Praktiken, die wir entwickelt haben in den letzten 20, 25 Jahren, sind die, die du eigentlich jetzt gerade brauchst. Und dann siehst du halt aber schon, also es gibt ja immer diese Adaptionskurve.

von Technologietrends, hast die Innovatoren, du hast die Early Adapters, also Leute, die das früher adaptieren. Die frühe Mehrheit, die späte Mehrheit und die Leute, die das nie adaptieren werden, die Leggards. Und du siehst halt schon, dass die Leute, die sich halt besser aufgestellt haben technologisch mit CI-CD, mit DevOps, mit You build it, you run it, XP-Praktiken, Domain-Driven-Design in der Organisation haben, dass die sich halt leichter tun, auch AI einzuführen. Und deswegen...

Der grundlegende Rat ist eigentlich, du musst mit einer Systemdenke an deine Softwareentwicklungsorganisation rangehen und das ist ein Value Stream. Und dann ist das halt wie so eine Fertigungsstraße in einer Fabrik, wenn du halt die eine Maschine optimierst und dann pumpt die halt, welche Zahl auch immer du jetzt in deiner Organisation erreißt, 20 Prozent mehr, 50 Prozent mehr. Ich kenne aber auch große Teams und Organisationen, die pumpen dreimal bis zehnmal so viel.

Deployments raus, also jetzt nicht nur Code Commits, aber lass uns jetzt mal bei dem Beispiel bleiben, zehnmal, zweimal so viel Code Commits und dann treffen die auf einen Release Prozess, der halt nicht voll automatisiert ist. Und wenn du in den DORA State of DevOps Report schaust, der letzte Report ist halt DORA State of AI Enabled Software Development, die sprechen aber auch immer noch darüber, wie viel Prozent Organisationen haben denn wirklich CI-CD und deployen mehrfach am Tag? Dann sind es 22 Prozent.

Müssten wir jetzt noch mal checken, aber ich glaube, sind 22%. Das heißt aber, das ist halt 70, 75%, 77 % sind, die das nicht können. Das heißt, die halt einmal die Woche, einmal im Monat, teilweise sogar seltener deployen. Das heißt, die haben manuelle Prozesse, die haben manuelle Tester, die haben Leute, die manuell Files von A nach B kopieren, manuell Server patchen. Und jetzt hast du eine Maschine in dieser Fabrik und die pumpt halt mehr Output raus.

Und dann werden einfach deine ganzen manuellen Prozesse, von denen du halt gedacht hast, die sind ja gut genug, die werden halt A, überfordert werden. Das zweite ist, die Tools, die AI Tools, die du ja verwendest und jetzt mehr Output generieren, die nehmen ja deinen aktuellen Source Code als Input. Ja, also den bringst du ja bei, so entwickeln wir hier. Das heißt, deine Qualität von den letzten zwei, fünfzehn Jahren wird ja auch verstärkt. Das heißt, du lieferst mehr Code

in der gleichen Qualität wie immer. Wahrscheinlich ist aber dein Release und Testprozess aufgelegt von der Kapazität auf die Qualität, die du sonst geliefert hast, aber in niedrigerer Menge. Das heißt, du lieferst jetzt auch viel mehr Bugs und den gleichen wenigen Business Value. Und damit wird halt deine CI-CD-Pipeline einfach überfordert werden. Und als Konsequenz, weil du die überforderst, wirst du, obwohl die eine Maschine vorne, ja, das Coding schneller ist,

Okay.

wirst du sogar nicht schneller werden aus Kundensicht, sondern die Features werden noch später kommen. Weil die haben große Releases, wo sie viele Features zusammenkoppeln und in diesen Releases haben sie jetzt mehr Fehler. Und deswegen musst du weiter immer noch eine lernende Organisation werden, wo du sagst, okay, ich habe hier einen Value Stream, ich habe hier unterschiedliche Schritte in meinem Value Stream und wenn wir hier was optimieren und es ist wichtig, dass du permanent optimierst, dann musst du aber klar sein, was sind denn die Konsequenzen und dann musst du da ...

Auf jeden Fall müssen wir schauen, dass wir unsere Hausaufgaben machen. Das heißt, einfach nur AI drauf werfen und mehr Code produzieren bedeutet noch nicht höhere Qualität und bessere Qualität in der Produktion. Und spannend war auch, dass du gesagt hast, dass wir vielleicht gar nicht schneller werden. Vielleicht ist das auch einer der Hebel, wo wir erst mal ran müssen, dass wir das Ganze in dem System betrachten und den ganzen Value Stream. Jetzt wird hier die Zukunft der AI im Moment so gemalt, dass wir ganz, ganz viele Agents haben.

Du hattest eben schon von den Rookies sozusagen, die man einstellen kann, aka Agents, berichtet, die werden in Societies vielleicht arbeiten oder im Swarm arbeiten und die werden, vielleicht gibt es auch solche Systeme wie Salesforce, die ihre eigenen Agents mitbringen, die dann mit anderen Systemen sprechen. Und das ist ja eine ganz andere Struktur jetzt plötzlich. Also das heißt, wie gehen wir denn damit es Agents gibt, die autonom einfach Tätigkeiten machen? Was

Wie verändert sich der Fokus im Team? Welche Sachen muss ich machen? Welche Sachen delegiere ich? Und wie gehe ich denn überhaupt damit wenn ich jetzt ganz, ganz viele von diesen Agents in der Organisation plötzlich am Rumschwirren habe?

Ja, also ich glaube, dass sie nicht autonom agieren. Und ich mag das Wort autonom auch überhaupt nicht oder nicht mehr. Ich mag das auch nicht mehr im organisatorischen Kontext. Ja, wenn man Leuten und Teams gesagt hat, ihr seid jetzt autonom, das stimmt halt einfach nicht. Also in der Organisation hast du immer Abhängigkeiten und deswegen kannst du eine lose Kopplung erzeugen. Aber Teams sind nicht autonom. Aber im Kontext von Agenten, also du kannst.

zur Zeit, und das wird noch eine ganze Weile so bleiben, keinen Agenten losschicken und den halt einfach frei für immer, ja und für immer ist aktuell also länger als einen Tag, autonom arbeiten lassen. Also dann verrennt er sich und liefert halt überhaupt keine Ergebnisse. Sondern deswegen habe ich diese Analogie auch verwendet von dem Hochschulabsolventen, den du einfach eng betreuen musst, an denen kannst du delegieren. Du musst aber, je besser du delegierst,

Je besser du dir Aufgabe planst, je klarer du sagst, was er darf, was er nicht darf und wann er sich bitte bei dir wieder melden soll, desto besser wird diese Teilautonomie für Stunden funktionieren oder auch nicht. Und ich glaube, wo man auch, was auch so ein häufiges Missverständnis ist, ich glaube schon, du wirst Agenten auf unterschiedlichen Ebenen einsetzen. Also Leute wie du und ich, aber auch Architekten.

Die Häuser planen, werden Agenten haben, die quasi sie in ihrer Arbeit an ihrem Laptop, an ihrem Rechner bei ihrer Arbeit unterstützen. Das heißt, du delegiert was, sie machen was, sie kommen wieder mit einem Ergebnis zurück. Wir werden aber auch innerhalb unserer Softwarearchitekturen, innerhalb von unserer Systeme Agenten haben, die auf Input warten, reagieren, etwas erarbeiten und dann wieder was zurückblieben.

Was ich aber nicht sehe, ist, dass jetzt alle unsere Microservices, die klar definierte Businesslogik haben, abgelöst werden von Agenten. Sondern Agenten haben einen gewissen Anwendungsfall und das ist halt, wo du Unsicherheiten hast, an Systemgrenzen, wo du interpretieren musst. Wenn du aber eine klare Geschäftslogik hast, brauchst du da keine Agenten einsetzen.

Alles klar. Das heißt, wir schauen, dass wir mehr ⁓ uns auf das Was konzentrieren. Also was wollen wir erreichen? Definieren wir das detailliert genug und überlassen dann das Wie dem Agenten oder mehreren Agenten. Und was ich ganz spannend fand, ist, hast gesagt, wir definieren auch einen Zeitpunkt, an der mit dem Ergebnis wieder zurückkommen soll zu uns. Also das heißt, wir sind trotzdem noch in der Hauptrolle der Entscheidung aus deiner Sicht.

Und dieses Thema, wir haben im Teil des Teams einfach fünf, sechs Agenten herumschwirren, die kriegen was im Meeting mit, setzen das selbstständig ⁓ committen das und das läuft oder fixen irgendwie was. Siehst du das schon in naher Zukunft oder glaubst du fest daran, dass wir nach wie vor da in der Kontrolle sind und eher die Delegation dort sehen?

Also das wird sich weiterentwickeln. Wir sind wie in den frühen Tagen des Internets. In den frühen Tagen des Internets waren sich alle ziemlich klar, dass Online-Modehandel nicht stattfinden wird. Ja, weil, also, erstens die Bilder sind zu groß. Niemand wird die Infrastruktur bauen, also vielleicht Singapur. Und niemand wird irgendeine Hose kaufen, die du nicht vorher anprobiert hast. Faktisch ist Online-Modehandel nicht mehr wegzudenken. Und es glaubt...

Wir wissen noch nicht, was passieren wird und was nicht passieren wird. Und muss das Organisationen einfach offen sein. Aber was wir schon sehen können, sind eben die Entwicklungen für die nächsten ein, zwei Jahre. Und was ich sehe in den Amazon-Teams, aber auch bei Kunden, ist, je besser du planst, je besser du vorbereitest, je besser du etwas durchdenkst, und so ist es auch, wenn ich Content generieren lasse, wenn ich mal faul bin, wenn ich mal unaufmerksam bin, und obwohl ich irgendwie mittlerweile diverse Dokumente habe für meinen Kontext,

Editorial Guidelines, Zielgruppen Guidelines. Also noch ist die Qualität nicht da. Und das ist beim Coding ähnlich. Also du musst eher mehr investieren in die Planung. Und dieses Vibe Coding, ich sehe das nicht. Dass du dich einfach mal zurücklehnt und sagst, hey, Buddy, let's fix this bug. Vielleicht kannst du noch einen Bug fixen. Aber wenn du wirklich sagst, ich habe hier eine komplexe Business Logik und wir reden halt oft von ...

Also.

Umfeldern, die halt eine komplexe Businesslogik ist, da lehnst du dich nicht einfach zurück, sondern da bist du weiter nach vorne gebeugt, hochkonzentriert an deinem Laptop. Und mein Gefühl ist fast, also so geht es mir, dass ich, weil ich konzentrierter sein muss, in zu sagen, was soll mein Agent, was soll mein Tool machen, aber vor allem im Überprüfen, was es gemacht hat, mich fordert es mental fast mehr.

Mmh.

als

wenn ich das selber mache. Und deswegen ist auch Test Driven und Unit Tests und Test Automatisierung so wertvoll in der Entwicklung. Also ohne brauchst du überhaupt nicht anfangen zu entwickeln. Und das ist halt beim Content schwieriger. Aber vielleicht müsste ich mal, wenn ich einen Blogpost schreibe, zu sagen, okay, ich mache erst mal ein paar Tests.

Akzeptanzkriterien vielleicht. Aber wenn wir schon bei den Praktiken sind, sind die denn aktuell noch valide aus deiner Sicht? Test-driven-Development hat das noch seinen Stellenwert. Wir haben vorher gesagt, wir machen die Tests vorab, entwickeln dann den Code und entwickeln den Code anhand der Tests. Jetzt hat man das nicht unter Kontrolle direkt. Also das heißt, die Tests können im Vorfeld generiert werden, wenn ich dran denke. Sie werden in Masse generiert. Man sieht Fälle auch, wo

Ja, vielleicht auch das.

Zwar ein Test entsteht, aber nicht das Richtige getestet wird. Wir haben jetzt diesen Ansatz von Specdriven Development, was ähnlich dem Wasserfall vielleicht gilt. ich habe eine Spezifikationsphase, dann habe ich eine Designphase, dann habe ich eine Umsetzungsphase. Wir haben MCP-Server. Wir brauchen vielleicht keine CI-CD Pipelines mehr. Ich bin jetzt so bisschen überspitzt. Wir können direkt per MCP reindeployen, die Infrastruktur verändern und so ein vieraugendes Prinzip brauchen wir auch nicht mehr.

Denn am Ende sagen wir hier AI, schau mal was ich gemacht habe und dann ab in Produktion. Siehst du da solche Sachen, dass das Tooling aktuell das nicht forciert, diese ganzen Praktiken, die wir aufgebaut haben?

Also dies und das ist dead, liest du jeden Tag auf LinkedIn. Also dauernd sagt jemand, irgendwas ist tot, weil es halt bei denen nicht funktioniert hat. Ich glaube nicht, ich glaube nicht, dass diese grundlegenden Praktiken wie Test-driven, Domain-driven Design out sind. Im Gegenteil, ich glaube, sie sind wichtiger als jemals zuvor. Und das sehen wir schon auch, dass reife Organisationen besser sind, AI zu adaptieren.

Das war für mich auch eine der Kernnachrichten aus dem Dora State of DevOps Report. Der Neueste, der sagt, AI ist ein Amplifier. Also, es ist ein Verstärker. Und der nimmt, was du deiner Organisation hast und der verstärkt ist. Also, wenn du gutes CI-CD hast, dann kannst du halt auch schneller releasen. Dann pumpst du einfach am Mittwoch. Hast du schlechtes CI-CD, dann wird es halt noch schlechter werden. Haben wir vorhin besprochen. Wenn du schlechten Code hast, wird es noch schlechter werden. Also, AI ist ein Amplifier und du musst...

Du musst die grundsätzlichen Praktiken weiter haben und das wird sich nicht ändern. Es gibt deswegen Dinge, die sich verändern und es gibt andere Dinge, die sich absolut nicht verändern. Das Gleiche ist T-Shape Developer. Wird sich auch nicht verändern. Im Gegenteil, ich glaube, es wird sich sogar wieder verstärken. Da sind wir wieder beim Amplifier. Dadurch, dass du ja mehr an Agenten delegieren kannst, kannst du als Entwickler breiter werden.

Und das ist das, was wir sehen. Am Anfang, als AI-Tools rauskamen, hat man ja sehr lokal gedacht. Also wir reden eigentlich immer von dem Team. Wir reden von einem Software-System, aber man hat immer gedacht, der Software-Entwickler wird jetzt produktiver. Das heißt, in einem Team haben wir deutlich weniger Entwickler. Keiner hat aber daran gedacht, dass vielleicht die Produktmanager auch AI nutzen könnten. Und wenn du Tester hast, also viele Teams arbeiten auch ohne Tester, machen das die Entwickler. Aber wenn die Tester auch AI nutzen, dann ändert sich da gar nichts. Und tatsächlich ...

gehen wir derzeit bei Amazon davon aus, dass sich die Größe eines Teams nicht ändern wird. Also wir sprechen weiterhin von unseren Two-Pizza-Teams. Also bei uns eine gute Größe ist halt, dass du so ein Team mit zwei amerikanischen Pizzen satt bekommst. Eben weil die Produktmanager, und bei uns machen die das massiv, nutzen AI-Tools und die Entwickler nutzen AI-Tools. Und bei uns die Entwickler machen auch, you build it, you run it. Was wir aber sehen...

dass die Anzahl der Produkte und die Anzahl der Microservices, die sie jetzt in der Lage zu betreuen sind, die wächst halt.

Okay, das ist spannend. wenn du gerade darüber gesprochen hast, wie die Teams das bei euch einsetzen. Also ich unterscheide immer vom Vibe Coding, das ist so ein bisschen der Prototype Modus. Ich probiere jetzt mal was aus, ich möchte schnell was sehen. Mich interessiert eigentlich der Code nicht so richtig. Und dann gibt es AI Engineering sozusagen oder Engineering mit AI, wo man einfach sagt, okay, hier brauchen wir die Praktiken, die wir kennen. Hier müssen wir den Code solide machen mit der Unterstützung von AI, sodass wir produktionsreifen Code haben.

Und hast du einen Einblick oder kannst du das teilen, wie ihr quasi diese Sachen, jetzt per AI generiert, wie ihr die härtet oder wie man da nochmal explizit diesen Qualitätsfaktor reinkriegt bei euch?

Wir haben vollautomatisierte CI-CD Pipelines mit massiven Testbatterien. Da muss alles durch. Wir nutzen auch AI-Tools, diese Testbatterien zu stärken und zu härten. Das Gleiche ist mit CI-CD.

Das heißt wieder der Amplifier. bin jetzt in der Lage mehr zu machen, aber die Basics müssen im Platz sein. Ich muss gute Tests haben. Ich muss mich absichern können und ich habe die Verantwortung dafür. Also das ist glaube ich auch ein wichtiger Punkt. Ich kann nicht sagen, die KI hat das jetzt generiert, weil am Ende des Tages ist es ein Tool, das landet bei mir und ich schiebe das in Produktion sozusagen. Deshalb steht mein Name dran und ich muss davor.

Nein.

sichergestellt haben, dass das, ich dort ... ... reinbringe, auch meinen Namen verdient

Ganz genau.

Ja, sehr cool. Jetzt noch mal zu deiner Rolle. Du bist Executive in Residence. Was ist das eigentlich und was machst du so täglich?

Ja, also die Rolle ist, Amazon arbeitet ja immer sehr kundenorientiert. Das heißt, man hat sich AWS-Kunden angeschaut, die Cloud adaptieren und hat eben früh gemerkt, das eine ist, sie müssen neue Technologien adaptieren. Aber, und das haben wir halt selber bei Amazon.com gelernt, als wir Microservices, Infrastructure as Code und lose gekoppelte Organisationen eingeführt haben.

Du brauchst halt auch die richtige Kultur und die richtige Arbeitsweise. Und man hat dann auch sehr schnell festgestellt, dass Kunden oder Menschen überhaupt lieber von Leuten etwas lernen, die selber diese Erfahrung gemacht haben als Leute, die es nur nach einem Buch haben oder am Beratungshintergrund. Das heißt, wir haben schon große Beratungsteams. Wir sind aber ein Team von ehemaligen Kundenführungskräften und jeder von uns hat selber in unterschiedlichen Umfeldern ⁓

Cloud und agile und digitale Transformation gemacht. Also ich habe mit Auto Scout und Hope Shopping Europe eher ein Startup und Scale-Up Hintergrund. Wir haben aber einen ehemaligen CIO von McDonald's im Team. Wir haben einen ehemaligen CTO von Bank im Team. Wir haben einen ehemaligen CIO von der US Einwanderungsbehörde im Team. Also wir sind relativ divers, weltweit verteilt. Und der Hauptzweck ist halt, dass wir mit aktuellen AWS Kunden teilen.

Wie haben wir denn gewisse Dinge gemacht? Was sehen wir in der Community? Was sind gerade best practices? Was sind Do's und Don'ts? Und wir teilen, was macht Amazon? Und das machen wir einerseits in Kundengesprächen. Also ich bin tatsächlich kostenloser Berater für große Amazon-Kunden oder AWS-Kunden. Wir sprechen auf Konferenzen, also auf unseren eigenen Konferenzen, der re:Invent, dem AWS Summit. Das findet auch jetzt bald wieder in Hamburg statt. Ich habe aber letztes Jahr im Oktober auch auf dem Gartner Summit Symposium

Tokio gesprochen zum Beispiel. schreiben Blogposts, genau das mache ich zurzeit ziemlich gerne. Da habe ich mich irgendwie reingefuchst, wie ich eben auch mit AI besser Blogs schreiben kann, gar nicht mal schneller, sondern besser. Und wir schreiben Bücher. Das hattest du schon erwähnt, genau. habe letztes Jahr mit der Sophie ein Buch veröffentlicht.

Bist du dann auch wirklich Teil dieser Organisation? Also gibst du dir manchmal so ein halbes Jahr, wo du wirklich dort dann auch in einer gewissen Rolle dann arbeitest, ⁓ ich sag mal, richtig aufzusaugen, wo die Organisation eigentlich steht und besseres Feedback zu geben? Oder ist das eher so eine Advisor-Rolle dann?

Also das ist vor allem eine Advisor-Rolle. hast aber die Möglichkeit, du könntest schon in Service-Teams oder andere Technologie-Teams, also ich bin Teil von Marketing und wir haben auch eine große Marketing-Tech-Organisation, die auch Softwareentwicklung macht und da könnte ich zum Beispiel auch für eine gewisse Zeit tätig werden.

klingt super spannend. Wenn du jetzt mit deinen Executives sprichst und die Kunden berätst, was hörst du denn aktuell? Weil wir haben natürlich mehrere Sachen. Auf der einen Seite kommt die AI-Welle mit enormem Druck auf uns zu. Aber wir haben natürlich auch politische Herausforderungen international. Und wirtschaftlich wird im Moment auch ihr auf die Bremse getreten. Was siehst du denn so? Was sind die Hauptschmerzen? Oder was hört man dann in der Branche so?

es gibt nicht die eine Meldung, weil dafür sind, also wir sind ein globales Team, also ich betreue tatsächlich Kunden global, aber die Kunden sind so unterschiedlich, die Branchen sind so unterschiedlich. Du hast aber auch in Branchen Unternehmen, bei denen läuft es sehr gut. hast Unternehmen in Branchen in der gleichen Branche, da läuft es gerade schwieriger. Die haben unterschiedliche Kulturen. Wie gehen sie damit

die befinden sich auch in unterschiedlichen Stadien der Cloud-Adaptionen. Es gibt große Unternehmen, die haben schon vor 10, 15 Jahren angefangen, Cloud zu adaptieren. Die sind natürlich viel weiter als jemand, der sehr skeptisch war und jetzt anfängt, Cloud zu adaptieren und das eher in so einem Lift-and-Shift. Das heißt, die betreiben dann halt ihre Server in der Cloud. Deswegen kann man das nicht sagen. Was vielleicht das einzige Ding ist, was bei allen gleich ist

das nur weil jetzt Generative AI kam von ein paar Jahren und jetzt Agentic am Horizont auftaucht, dass alle anderen Hausaufgaben, die sie hatten, nicht weggegangen sind.

Ja, das...

Also die Prioritäten sind immer noch

die gleichen. Sie haben die gleiche technische Schuld. Sie haben Kostendruck. Sie wollen innovativ sein. Und sie bekommen halt aber neue Themen drauf. Und das ist das, was man dann sieht wieder. AI ist ein Amplifier. Also wenn du halt die letzten Jahre investiert hast in deine Organisation, in deine Leute, in deine Technologien, in deine Systeme, dann bist du jetzt besser aufgestellt, die nächste Innovationswelle besser adaptieren zu können.

Deswegen ist es sehr wichtig, dass du eine lernende Organisation bist und tatsächlich in der Lage bist, zu investieren in deinen Leuten, in deinen Technologien. Dafür musst du aber auch der Lage sein, und das sind halt die meisten Tech-Organisationen nicht, nachzuweisen, dass es gut ist, in dich zu investieren.

Das heißt, eine Lernorganisation zu werden, sich immer weiterzuentwickeln, also darauf einzustellen, dass der nächste Change kommen wird. Ich habe hier ein anderes Zitat von dir. Unternehmen, die Schwierigkeiten hatten, ein agiles Mindset DevOps-Praktiken, Cloud-Native-Technologien einzuführen, werden sich aus denselben Gründen auch mit KI schwer tun. Das geht so bisschen in die Richtung, die du eben angesprochen hast. Aber warum ist das so? Was fehlt Ihnen? Und wie können die das vor allem aufholen? Weil die haben ja jetzt vor sich dann nochmal so ein Riesenbrett und

haben die anderen noch nicht durchgebohrt. Was rädst du solchen Kunden?

Ja, ist aus einer McKinsey-Studie und die sagt, dass quasi deine digitale Reife ein sehr guter Vorhersagenindikator ist, für wie gut du AI adaptieren wirst. Da sind wir halt eben genau dabei. Also hast du denn deine Systeme und deine Daten in der Cloud? Kannst du denn da schnell Änderungen durchführen? Kannst du die Änderungen durchführen mit einem geringen Blast-Radius?

Und wenn du das nicht kannst und deine Daten nicht in der Cloud hast, dann tust du dich halt echt schwer, AI bei dir zu adaptieren.

Das heißt, wir können jetzt aber nicht stoppen. Die AI steht ja da und die kommt über uns gerollt. Wie kann ich das im laufenden Rad? Also das heißt, fix the basics, reingehen.

Ja, fix

the basics ist so ein Spruch, den hört man ja seit Ewigkeiten, was die Leute dann ja machen. Fix the basics ist, okay, wir müssen jetzt einmal die Foundations, also die Grundlage schaffen und dann starten sie halt Projekte, die zwei, drei Jahre dauern sollten, fünf Jahre dauern. Wir brauchen einen neuen Data Lake. Wir müssen den Mainframe modernisieren. Wir müssen dies, das.

Dann machen die langwierige Projekte, unglaublich viel Geld kosten. Nach ein, zwei Jahren sagt das CFO, zeig mir mal, was ist der Wert von der Initiative? Sie sind nicht in Lage, den Wert zu zeigen. Oft werden dann die Budgets auch zusammengestrichen. Und wenn dann nach drei, vier, fünf Jahren irgendwie ein Erfolg gemeldet wird, dann ist es aber ein Erfolg von, wir haben jetzt folgende Fähigkeiten. Wir können jetzt auch einmal am Tag releasen. Wir können einen Echtzeitreport machen. Was sie aber nicht machen, ist

dass sie rückwärts von Kunden arbeiten und Kundenprobleme lösen. Und das ist quasi den Rat, ich gebe. Also, ja, du musst halt deine Hausaufgaben machen. Also, da kommst du nicht drum herum. Die Frage ist aber, machst du ihn effizient? Und das ist das, was viele versuchen. Wir machen jetzt ganz effizient irgendeinen Layer oder machst du den effektiv? Das heißt, wir gucken, was sind denn auf Basis von unserer Geschäftsstrategie, was sind denn die wichtigsten Initiativen, die wir jetzt eigentlich live bringen müssen?

Und dann wäre es natürlich leichter, die live zu bringen, wenn du schon digital-native Organisationen, Infrastrukturen hättest. Wenn du das nicht hast, dann musst du die halt aufbauen. Aber für diesen Use-Case und auch in diesem Use-Case nicht anfangen, jetzt machen wir erst mal die Foundations und wieder in Layern denken, sondern musst halt immer in einem Use-Case in vertikalen Scheiben Wert liefern.

heißt direkt vom Kunden kommen Verticals, Lices einmal durch die ganze Organisation, dich so aufzustellen, dass du jetzt nicht ein Projekt hast, wo du Haken an deine KPI machst. Wir können jetzt einmal am Tag deployen, sondern dass wir sagen, wir können für den Kunden besser liefern, weil wir die ganze Kette in Richtung diesen Kunden und diesem Projekt vielleicht optimiert haben. Ja, sehr spannend. ist, was ich auch bemerke, ist, dass oft AI aktuell als Technologie eingeführt wird.

Ja.

Ja, so die sagen, hey, cool, wir brauchen unbedingt gewisse Modelle, wir brauchen gewisse Assistenten, wir brauchen jetzt irgendwelche Services, die das machen. Aber AI fühlt sich für mich eher an wie eine Transformation. Und wie sieht denn eine gute AI-Strategie aus, deiner Sicht? Kannst uns da auf dem Bierdeckel hier kurz eine Strategie gemeinsam aufstellen, wir zwei?

Ich das kannst du nicht. Ich glaube, es ist schon okay, dass du sagst, ich habe mir da ein neues Tool bestellt, neue Technik, packe ich jetzt aus, aus dem Karton, oder sind ja Kabel. Wie funktioniert denn das? Wo stecke ich das an? Wo starte ich das? Wie funktioniert das jetzt? Also ich glaube, ist schon okay, dass man sagt, ich habe eine neue Technologie und muss mich erst mal damit auseinandersetzen. Was sind denn die Chancen und Risiken, die Stärken und Schwächen von diesem Tool? Was du dann halt nicht machen darfst, ist,

Jetzt machen wir die neue zentrale AI-Organisation. Wir brauchen ein neues Team mit neuen Rollen. Gartner gibt es eine PowerPoint, ein PowerPoint-Slides. Da sagen die, man wird 26 neue Rollen in einer Organisation brauchen, AI machen zu können. Ich glaube, das ist total falsch, weil wenn du so viele neue Rollen einführst, dann sind das hochspezialisierte Rollen. Die sind nicht T-shaped, die sind I-shaped. Du schaffst ganz viele Abhängigkeiten, die reden miteinander und es wird alles langsam werden. Hocheffizient, aber total langsam.

Was du halt machen musst, also A musst du sagen, okay, wir sind jetzt im Entdeckermodus. Wir müssen Experimente machen. Und wenn man ein Experiment macht, dann scheitern Experimente auch. Also deswegen, wenn es heißt, 70 % der AI Use Cases floppen, dann sag ich als ehemaliger CTO im Startup-Hintergrund, so what? Du musst halt dafür sorgen, dass die 30%, die wirklich funktionieren, ein Kundenproblem lösen.

Und du musst dafür sorgen, dass du nachweisen kannst über Messungen und über A-B-Tests, dass diese AI-Use-Cases wirklich ein Problem lösen. Und da denken viele Organisationen zu klein. Also was ich ganz viel beobachte, ist, man weiß nicht so recht, was kann man mit AI machen, aber man könnte ja effizienter werden. Das heißt, E-Mails schreiben, Powerpoints machen. Aber ist es das, was wir echt wollen? Also mehr E-Mails, mehr Powerpoints?

Ich glaube nicht. Und was machen die Leute dann, wenn die Agenten die E-Mails und die Powerpoints machen? Mehr Meetings? Also das kann es ja nicht sein. Und mich erinnert es halt auch an die frühen Tage des Internets. Ich war da Softwareentwickler, Consultant bei der KPMG in der E-Business Unit. Was haben wir gemacht? Wir haben Workflows, also Prozesse digitalisiert und zwar Urlaubsanträge zum Beispiel, ganz gerne, Reisekosten. Aber das ist ja nicht, was dann Internet groß gemacht hat.

sondern es war ja, dass du gesagt hast, okay, wie könnte man eigentlich unser Geschäftsmodell neu erfinden? Und deswegen sind ja dann die vielen, vielen, vielen coolen Dinge passiert, die wir jetzt alle nutzen. Und super spannend wurde es ja, als dann Software, Internet mit Hardware, Mobile Fonts zusammen kamen. Und ich glaube, das wird wieder passieren. Und wenn du eine AI-Strategie haben willst, dann musst du sagen, okay, was ist eigentlich unser Geschäftsprozess? Was sind die Kundenbedürfnisse? Und daraus machst du eine Strategie. Und das ist auch, so denken wir bei Amazon.

Jeff Bezos hat in einem Interview mal gesagt, er würde ganz viel gefragt, was sich ändern würde. Das war aber dann schon einige Zeit her und da ging es noch digital. Und er hat gesagt, er wird es ganz oft gefragt. Er hält aber viel wichtiger die Frage, was ändert sich nicht? Also zum Beispiel bei Amazon, Retail, E-Commerce, wann das ändert sich nicht. Die Leute wollen billiger Produkte und sie wollen schnellere Lieferungen. Und aus diesen Dingen, die sich nicht ändern, da kannst du eine Strategie machen.

Aus den Dingen, die sich da unterändern, kannst du keine Strategie machen. Aber dafür musst du dir ja klar sein, was sind denn die grundlegenden Kundenprobleme in meinem Geschäftsmodell? Was wollen die Leute und wofür sind sie bereit, Geld zu bezahlen? Und dann setzt du da AI an.

Das ist spannend. Was ich manchmal jetzt beobachte, ist, dass AI so die Rettung ist. Das heißt, ich habe irgendwelche Prozesse, die ich vielleicht nicht verstehe oder die historisch gewachsen sind. Ich habe irgendwelche Architekturen, die ich jetzt nicht mehr gut durchdringen kann. Und dann sage ich, egal, wir werfen jetzt AI da drauf und die wird das Problem uns lösen.

Erkenn ich denn einen wirklich guten Use Case? Also so einer, Potenzial hat, wirklich eine Veränderung hervorzurufen? ist das, weil vieles im Moment, ja, Daten zuzugreifen, Daten aufzubereiten, zu strukturieren, zusammenzufassen, was die LLMs auch sehr gut können. Aber du hattest ja eben von Use Cases gesprochen, die die Firma verändern können und das Business Modell verändern können. Wie komme ich denn mehr an die ran?

die wirst du nicht in deinem Konferenzraum finden. Und das ist das, was halt viele probieren. Also man macht halt einen Workshop. Man stellt sich an Flipcharts und man überlegt sich was. Und deswegen ist für mich auch eine ganz wichtige Grundlage, so wie Domain Driven Designs, die ICT Unit Test ist halt Lean Startup Thinking. Das heißt, du musst rausgehen aus deinem Büro, musst zu deinen Kunden gehen und dann musst du Daten und Anekdoten sammeln über was sind denn deren Probleme.

Wenn deine Daten und Anekdoten nicht zusammenpassen, dann glaub den Anekdoten, weil was dir deine Kunden erzählen, kann falsch sein. Und dann musst du halt gucken, was sind wirklich Kundenprobleme, die es jetzt wert sind, die zu lösen. Und dann guckst du halt zusammen mit guten Leuten aus deiner Organisation, zusammen mit AWS, mit Partnern, okay, wie können wir neue Technologie einsetzen, dieses Kundenproblem zu lösen? Und nicht gleich mit der Lösung kommen, sondern muss wirklich klar sein, was ist das Kundenbedürfnis? Und das ist halt weiterhin...

ein mentales Modell, das in vielen Unternehmen nicht vorhanden ist, sondern das ist immer noch Plan, Build, Run. Am Wochenende hat mir mein Schwager gesagt, alle Kunden wollen dies und das. Also schreibe ich eine User Story, irgendwas und dann lasse ich die halt entwickeln. Und wenn die entwickelt ist, dann geht die halt in Produktion und dann

wird schon irgendwas passieren. viele wissen halt nicht, wenn sie ein Feature liefern, hat dieses Ding einen positiven Effekt auf wesentliche Geschäftskennzahlen. Und oft hat es halt nichts. Und deswegen musst du auch hypothesengetrieben arbeiten. Du musst sagen, okay, ich habe hier eine Hypothese und wir glauben, indem wir dieses Feature bauen, werden wir dieses Ergebnis erzielen. Und dann musst du aber vorher schon definieren, was ist die KPI, die sich verändern muss und bis wohin, dass wir sagen, das war jetzt gut.

Und das ist eben hypothesengetriebene Entwicklung. Und das verändert total, dieses kennzahlgetriebene verändert total, wie du Features baust. Und das ändert sich auch mit AI nicht.

Und bedeutet natürlich Kontakt mit den Kunden, skin in the game. Also nicht von einem Schwager, die das erzählen lassen, sondern wirklich mal herausfinden, was sind die die Probleme, die da gelöst werden? Und eigentlich wollen ja Software Entwickler oder Techies Probleme lösen. Also das heißt, das sind ist eigentlich die Kernaufgabe, die wir alle haben. Du hast eben gesprochen über Hypothesen aufstellen und messen. Wie messe ich denn aus deiner Sicht den Impact von AI? Weil viel kommt jetzt hier.

Überall sieht man es, Effizienz 30 % hoch durch AI. Alle müssen das benutzen.

Ja, aber

Effizienz ist ja eine Nicht-Kennzahl, also genauso wie Geschwindigkeit. Du hast vorhin auch gesagt, ich habe die Analogie verwendet von der Fabrik und diese Maschine, macht jetzt mehr Code. Die Kennzahl, die sich eigentlich verändert, ist Output oder Throughput. Also wie viele Einheiten, Workitems pro Zeit macht diese Maschine? Das ist Throughput.

Das andere ist, wie lange braucht es denn, bis wir von, wir fangen damit an zu arbeiten, bis wir haben es geliefert, bis wir es geliefert haben. Das ist Cycle Time oder Lead Time. Und vielen Leuten sind diese grundsätzlichen Kennzahlen überhaupt nicht klar, die eigentlich die Leistungsfähigkeit von der Softwareentwicklungsorganisation ausmachen. Und das Gleiche ist dann auch, wenn du eher einsetzen willst. Und die allerwichtigste Kennzahl und Fähigkeit ist, wie viel Business Value sind wir in der Lage, in einem Release zu liefern?

Und es ist natürlich viel einfacher, festzustellen, wenn du sagst, ein Feature oder ein Change ist ein Release. Weil dann kannst du isoliert sagen, okay, dieser Change, dieses Deployment hat folgende Auswirkungen gehabt. Dafür musst du es aber testen. Das heißt, du musst es irgendwie messen und du musst es vergleichen. Und was nicht funktioniert, ist, dass du halt dann den Tag, an dem du es deployed hast, mit dem Vortag vergleichst. Sondern musst sagen, nein, wir machen den AB-Test mit 50 Prozent des Traffics. Alte Variante, 50 Prozent auf die neue Variante

Und dann kannst du wirklich periodengenau messen. Und dann kannst du als Software-Entfüllungsorganisation auch in einer hohen Skalierung sagen, wir haben die Conversion Rate, wir haben den Umsatz, wir haben dies das, was auch immer deine KPIs sind, durch so und so viele kleine Releases ⁓ was weiß ich erhöht. Also wie viel Business Value liefern wir? Und in dem Moment, wo du als IT-organisation in Lage bist zu sagen, dass du nicht nur Kosten verursacht, sondern Business Value lieferst, hast du auf einmal eine ganz andere Budget-Diskussion.

Das zweite ist, was ist Cycle oder Lead Time? Das dritte ist der throughput. Cycle und Lead Time kannst du total schnell verändern. throughput ist verdammt hart. Das vierte ist Qualität und für Qualität hast du keine Ahnung, 25 oder 50 Metriken, Funktionale, nicht Funktionale, Verfügbarkeit, Security, Governance. Was auch ganz wichtig ist, wir sprechen von einer lernenden Organisation, die sich iterativ verbessert. Das heißt, du musst die Motivation deiner Leute messen.

Bei Amazon machen wir das auch. Wir führen Umfragen durch, wir messen Sentiment in unseren Teams, wie zufrieden motiviert sind die Leute in dem Umfeld, wie sie gerade arbeiten. Und dann ganz final würde ich schon noch sagen, Kosten musst du auch messen. Und für mich ist Kosten reduzieren Mastery, weil irgendwie eine Applikation mit 1000 Servern zu betreiben, das kann jeder, aber wenn du in der Lage bist, die gleiche Applikation mit drei zu betreiben, das ist schon ziemlich cool.

jeden Fall. Jetzt haben wir hauptsächlich die Delivery Pipeline besprochen mit diesen Messwerten und sehr wertvoll. Wenn wir jetzt sagen im AI-Umfeld wird oft im Business-Kontext gedacht, ich mache das Beispiel an einem Chatbot im Support. Also das heißt mein Business hat sehr sehr viel Supportanfragen und ich denke, okay wir werden jetzt besser, wir holen uns jetzt eine AI, die kriegt unser ganzes Wissen des Unternehmens und ich habe jetzt so einen Chatbot, der allen helfen kann.

Und ich merke dann, dass diese AI innerhalb der gleichen Zeit die doppelte Anzahl an Anfragen vielleicht beantworten kann. Aber der Impact oder das ganze Ziel sollte ja sein, eigentlich weniger Anfragen generell zu haben, meine Qualität besser ist. auch wieder dieses ganze System zu betrachten. Ist das ihr auch der Punkt Richtung AI oder fängt das an mit den Werten, die du beschrieben hast?

glaube, dass es nicht spezifisch ist für AI. Also ja, du hast ein lokales Problem und dann kannst du schon diese lokale Problem lösen. Und ich glaube, es ist gut, dass deine Chatpots besser sind und die Leute schneller Hilfe brauchen, wenn sie Probleme haben. Und dann musst du aber schon als Produktmanager sagen, was ist denn die Root Cause? Die liegt ja gar nicht in meinem Team, sondern die ist woanders. Und das ist, wie Amazon arbeitet. Also bei Amazon haben wir dieses Modell von diesem

Und Andon-Cord aus dem Kanban. Das heißt, du kannst sagen, wir müssen jetzt hier in diesem Prozess anhalten, weil wir müssen hier was Substantielles fixen. Je länger dieser Prozess läuft, desto kaputt wird irgendwas werden. Und das ist schon, aber das ist halt Unternehmenskultur. Das ist Unternehmenskultur, ob du jetzt sagst, du fixst grundsätzliche Probleme.

Das ja spannend. Das heißt, kann als Ingenieur bei Amazon sagen, hier läuft irgendwas komplett schief. Ich ziehe so eine virtuelle Leine und das geht durch die Eskalation und ich bekomme Gehör, warum das so ist.

Ja, natürlich in deinem Kontext seines Produktes. Aber das Beispiel, das wir gerne verwenden, ist, du bist jetzt Call-Center-Mitarbeiter und du bekommst jetzt zum dritten Mal am gleichen Tag eine Reklamation wegen einem bestimmten Tisch, der halt zerkratzt ist oder irgendwas. Und dann kannst du sagen, du drückst auf den Knopf und nimmst dieses Produkt von der Webseite. Das heißt, es wird nicht weiterverkauft, bis dieses Problem untersucht und gelöst ist.

Das ist ja cool. Also komplette Power auch da, wo sie hin muss. Sehr spannend.

Genau, Empowerment

an der Stelle, aber natürlich im Rahmen der Kompetenz dieses Mitarbeiters in diesem Prozess. Also schon, du kannst jetzt nicht alles stoppen.

Das ist es.

Ja, und das gilt auch für organisatorische Prozesse in der Softwareentwicklung bei AWS Cloud dann genauso.

Naja, bei uns wir sprechen immer von einem Mechanismus, also Prozesse heißen bei uns Mechanismen und wenn du in einem Prozess, der quasi automatisiert läuft und dieser Mechanismus jetzt aber einen Schaden produziert, dann kannst du den stoppen. Wenn du den stoppst, ist aber natürlich klar, dass du Aufmerksamkeit hast und dann müssen alle Leute, die verantwortlich sind für diesen Prozess, zusammenarbeiten, dass dieser sich wiederholende Fehler, der Schaden erzeugt, beseitigt wird. Deswegen ist bei uns auch ein

organisatorisches Prinzip. Du sollst früh eskalieren, du sollst hoch eskalieren. Aber wenn du eskalierst sollst du auch Lösungsvorschlag haben.

Dann brauchst du natürlich auch die psychologische Sicherheit, machen zu können. Das heißt, mit logischer Forschung reinkommen und Support vom Management. Ansonsten wird keiner den roten Knopf drücken wahrscheinlich.

Die psychologische Sicherheit bekommst du bei uns, wenn du Daten und Anekdoten hast.

Also datengetriebene

Also mit einer Meinung,

mit einer Meinung kommst du nicht weit. Du musst Daten haben. Also wir sind eine datengetriebene Organisation.

sehr spannend. Sehr cool. Ich möchte noch mal einen Switch machen rüber. Wenn ich jetzt merke in meiner Organisation, mein C-Level, CTO, CIO, CEO, die sind alle irgendwie beschäftigt mit Keep the lights on mit dem Daily Business und ich sehe jetzt auf LinkedIn noch ein neues Tool und wieder ein neues Modell und hier was veröffentlicht und ich komme nicht so richtig weiter. Was müssen wir dort machen? Also was ist denn dein Impuls für das Management? Was ist der Impuls für die Leute, die diese

Sachen entdecken und in die Organisation bringen wollen.

Also da gibt es eigentlich keine Pauschalungsrezepte. Also ich glaube, als Management tut es tatsächlich immer gut, dieses berühmte Offside zu machen, wo du tatsächlich mal rausgehst, wo du mal ein, zwei, drei Schritte zurücktrittst und du überlegst, was machen wir denn hier eigentlich? Also ich finde im Deutschen dieses Wort eigentlich auch wirklich gut, wo du dich rückgesehenst auf, was sind unsere Ziele? Also Zielorientierung ist für mich ganz wichtig und dann musst du halt rückwärts von diesen Zielen arbeiten und sagen, okay

selbstkritisch, wo sind wir gut, wo sind wir nicht gut. Ansonsten, was total gut funktioniert, ⁓ Veränderungen zu treiben, sind Show and Tells. Also du kannst schon neue Tools einsetzen. Musst du vielleicht auch nicht jedem sagen. Also muss schon Compliance sein, natürlich, zu den Richtlinien deiner Organisation. Und was halt gut funktioniert, auch wenn du willst, dass halt in der Belegschaft Tools und Arbeitsweisen adaptiert ist, dass

andere Leute in der gleichen oder in einer ähnlichen Tätigkeit zeigen, wie sie diese neuen Tools eigentlich nutzen und was sie damit erreichen können. Und das ist eigentlich am besten, wie du so grassroots bottom-up-mäßig irgendwas einführen kannst. also, weiß ich jetzt nicht, ob ich es da hinten im Regal habe, aber es gibt ein Buch, ich glaube, da sind 49 Patterns drin für Change Management. Und es geht halt von machen Brownback Lounge oder geh Mittag essen.

Mit deinem Manager zu, schreib ein Dokument. Das ist halt hochsituativ.

Also das heißt, nicht aufgeben, weiter pushen, dass das Thema so interessant ist und mit Ideen, vielleicht auch in Hackathons einfach mal mit reinbringen und Prototypen entwickeln, bis man dort die passende Sichtbarkeit bekommt. Jetzt haben wir auf der anderen Seite aber auch die Leute, jetzt die zwei, drei Jahre, die das Thema schon sehr überall ist, die hartnäckig das ignorieren und die vielleicht auch gewisse Ängste haben. Das ist auch Teil der Organisation. Wie hole ich die denn aus der Reserve?

Ist das ein Thema auch für das Gesamtsystem? Wie geht man damit ⁓ Weil die early Adapter, die haben wir, die sind schon mit an Bord. Die wollen das auch, wie eben besprochen, die kommen da mit den Ideen selbst. Aber es gibt bestimmt auch einen Großteil, der jetzt einfach Angst den Job hat, der vielleicht auch Bedenken hat Richtung Datenschutz und der vielleicht auch seinen, wirklich dann einfach seine Expertise in Gefahr sieht. Wie siehst du das und was für Impulse hast du denn?

Ich glaube, das Erste ist, man muss anerkennen, dass unterschiedliche Leute unterschiedlich auf Neuigkeiten reagieren. Deswegen gibt es diese Kurve, der Early Adapter, Early Majority, Late Majority. Du weißt aber auch nicht, je nachdem, welches Thema es ist, wer sich bei diesem Thema in welche Gruppe einsortiert. Du musst wieder situativ entscheiden. Du weißt aber, du wirst diese Gruppe haben. Was auch klar ist, die meisten Veränderungen passieren nicht von einem auf den anderen Tag.

Also eine Cloud-Adaption zieht sich über Jahre hin, digitale Transformation zieht sich über Jahre hin, die Einführung von AI wird sich über Jahre hinziehen. Das heißt, du kannst dir das auch zu Nutze machen, dass du sagst, du nimmst die Early Adapters, die setzt du auf die neuen Systeme und du hast ja immer auch Bestandssysteme, Bestandsgeschäftsprozesse, wo du Leute brauchst, die sich darum gerne kümmern. Das heißt, du kannst diesen Chain schon entzehren. Also was ich oft beobachte, ist, dass man glaubt, man muss jetzt

an einem Tag X zu einem All-Hands-Meeting oder was auch immer die komplette Belegschaft zu zusammenbringen und an dem Tag müssen alle sagen, Yippie! Und das brauchst du ja aber gar nicht. Also kannst du dir den Stress einfach auch nehmen, indem du das ein bisschen entzehrst. Was du auch hast in so einer Population ist, unterschiedliche Leute lernen unterschiedlich. Das heißt, manche sagen, komm, ich mach das am Wochenende selber, ich mach einen Kurs, brauchst dich gar nicht kümmern, zahl mir die Zertifizierung. Andere Leute sagen,

Da will ich jetzt aber eine Woche nach Italien auf ein Training gehen und ich will die Reisekosten auch bezahlt haben. ja, das Wochenende davor und danach würde ich ja auch bleiben. Und ich glaube, es ist okay, dass du für unterschiedliche Leute unterschiedliche Lernformate hast. Und genauso ist auch klar, dass unterschiedliche Leute unterschiedliche Informationen aufnehmen. Das heißt, du musst alles zehnmal sagen und zwar auf unterschiedlichen Kanälen.

Und manche Leute wollen halt sehr daten- und faktenorientiert, manche wollen eher sehr visonär hören. Das heißt, du musst die gleiche Nachricht unterschiedlich transportieren. Und das ist eigentlich, was man dann immer als Change Management sagt. Ich glaube aber, irgendwann ist auch der Punkt, wo du sagen musst, das ist der Bus, den Bus diskutieren wir nicht, wir führen hier AI ein. Der Bus fährt seit drei Jahren jedes Quartal einmal ab.

Jedes Quartal können Leute auf diesen Bus aufspringen, auf ein Team, eine Applikation das er hier einführt. Und irgendwann muss man aber auch sagen, der Bus fährt und heute fährt dein Bus. Also es ist schon dieses fordern und fördern.

Ja.

Also die klassischen Elemente einer Transformation. was man natürlich auch sieht ist, oder was man oft hört, ist, die AI nimmt einem nicht die Jobs weg, sondern die Leute, die nicht AI beherrschen, sind in Gefahr, nicht mehr am Ball zu sein. Und vielleicht ist das einer der Punkte, nickst du schüttest den Kopf. Hast du dazu auch noch ein Gedanke?

Ja, ich glaube, das stimmt schon, aber das wird, ich glaube, das wird zu pointiert gesagt. wir müssen nur zurückgehen in der Geschichte.

Internet Technologien. füllen Internet ein und damit automatisieren wir Reisekosten und Urlaubsanträge. Und dann glauben wir, wir brauchen viel weniger Leute im Büro. Ist ja aber auch nicht passiert. Also deswegen die Frage ist auch immer, was hast du denn für ein Mindset? Also ist der Kuchen so groß, wie er ist und der Kuchen wird nur anders verteilt oder hast du eher so ein Gross- und Wachstumsmindset, wo du sagst, hey,

Eigentlich können wir jetzt unsere ganze technische Schuld endlich mal bereinigen, was auch Jahre als Monate dauern wird. Wir können internationalisieren, können neue Kundengruppen erschließen, wir können die Kunden zufriedener machen. Ich glaube ja, die Arbeitswelt wird sich verändern, aber es wird länger dauern, als wir glauben und weiß.

lange dauert, wird es auch jetzt nicht sich so krass anfühlen, wie es immer suggeriert wird.

Das heißt, bisschen auf die Bremse treten, der FOMO standhalten die Transformation wird zwar voranschreiten, aber es gibt noch genug Zeiten und Möglichkeiten mit aufzuspringen in dem Thema.

Ja, also ich hätte es nicht gesagt, die Bremse steigen, aber vielleicht Gelassenheit und Neugier entwickeln. Also ein bisschen gelassen sein, nicht alles so ernst nehmen und aber du musst neugierig sein. Du musst schon schauen, was passiert, was finde ich gut, was kann ich nutzen, was machen andere. Du musst ja nicht der Innovator sein. Du musst nicht alles selber neu erfinden. Du kannst ja links und rechts gucken, was machen eigentlich die Kollegen. Und das ist schon okay, dass du bei manchen Tools sagst,

Brauche ich jetzt nicht. Ich schreibe meine E-Mail schon noch selber. Kann ich gut. Oder du sagst, hey, das ist jetzt schon cool. Das mache ich auch. Und ich habe von einem CEO, von einem deutschen Mittelständler gehört, ganz klassischer Maschinenbau, irgendwo in der Provinz, so ein typischer Hidden Champion, sagte, das ging ⁓ Generative AI, dass es die erste Technologie ist, die von den älteren Mitarbeitern in seinem Unternehmen eigentlich mehr begrüßt wird als von den jüngeren.

Ja.

weil die älteren generative AI wahrnehmen, als ein Tool, das ihnen eigentlich hilft. Hilft Schwächen aufzubügeln, geht los mit Englisch, mit Übersetzungen, mit Tool und Techniken zu verstehen. Und das fand ich eigentlich eine sehr bemerkenswerte Rückmeldung. Also fand ich eigentlich, und ich konnte das sehr gut nachvollziehen.

Teilst du den Gedanken, dass deine Expertise, also wenn du viel Fach-KnowHow hast, dass dann die AI besser für dich funktioniert, weil du sie besser guiden kannst? Oder teilst du ihr diesen Gedanken, wir brauchen jetzt viel mehr oder wir können jetzt viel mehr neue junge Leute einstellen, die noch überhaupt kein Wissen haben, weil die AI wird alles machen?

Absolut. Absolut.

Ich glaube, als digitale Techniken eingeführt wurde, da war die Lücke zwischen digital Nativen, digital Neugierigen und digital Skeptischen Leuten viel größer, als es jetzt mit AI ist. Weil eben AI Lücken und Defizite, die du hast, für dich ausbügeln kann. Aber nur wenn du und das, da schlägt halt Erfahrung rein und es gibt halt kein Kompressionsalgorithmus für Erfahrung.

Wenn du halt weißt, wie Dinge funktionieren, wenn du weißt, wie Geschäftsprozesse funktionieren, wenn du weißt, welche Fehler häufig in deinen Geschäftsprozessen auftreten, wenn du weißt, worauf du achten musst und schon gelernt hast, wie man delegiert, dann kannst du diese Agenten, die du vielleicht zur Verfügung gestellt bekommst, besser einsetzen. Und du wirst vielleicht bessere Ergebnisse erzielen als jemand, der halt dieses ganze Know-how und die Erfahrung nicht hat.

Das ist sehr spannend. Wie siehst du das denn, wenn die nächste Generation diese Erfahrung quasi nicht mehr so richtig machen kann, weil sie beschleunigt wird durch, ich bekomme ja alles gesagt durch die AI. Also diese wirklichen Dinge, von denen du eben gesprochen hast, die wir gemacht haben im Leben, dass wir gesagt haben, okay, wir wissen jetzt genau, jetzt biegt die AI falsch ab, wir bringen sie jetzt mal wieder auf Kurs, weil wir rein aus der Erfahrung wissen. Und wenn wir jetzt sagen,

diese Erfahrung, Zeit gebraucht hat, die Lernkurven immer und immer wieder gebraucht haben, wenn die nächsten Generationen die nicht mehr bekommen. Was passiert dann?

Ich nix.

Also die Entwicklergeneration vor mir, also die Tante meiner Frau, die hat Fortran entwickelt in dem Forschungsinstitut am CERN. Und die kann noch richtig tief in Maschinencode reinschauen. Und die haben sich gefragt, was wird wohl passieren, wenn diese neuen Smalltalk-Entwickler nicht mehr den Maschinencode reinschauen können? Ich habe Smalltalk gelernt, ich kann keinen Maschinencode lesen und was, es passiert nichts.

Also ich glaube, es findet halt eine Abstraktion statt und die Systeme verstecken halt von der Abstraktion und ich finde das total gut, weil du kannst dich halt, du musst dich nicht mit Maschinencode auseinandersetzen. Du kannst dich halt auseinandersetzen mit deinem Kunde, mit deinem Geschäftsproblem. Du kannst endlich deine technische Schuld abbauen. Ich finde das cool. Also ich habe da, ich habe überhaupt keine Bedenken davor.

Ja.

Und Bottom Line, werden wahrscheinlich neue Erfahrungen einfach machen, die wir wieder gewinnbringend einsetzen können, wenn wir positiv noch vonderschauen.

Ja, und AI ist halt ein Tool und du kannst es für Diagnose

nutzen und für vieles auch, aber man wird deswegen ja nicht dümmer nur, weil man vielleicht weniger Details hat. Und die Details, die du in deinem Job brauchst, und es gibt Leute weiterhin, die Maschinencode lesen können, diese Spezialisten, haben diese Fähigkeit, weil sie in ihrem Job gebraucht wird, und die können dann auch tief eintauchen.

Ja super. Ich habe jetzt noch mal einen Schwenk zu dir persönlich. Du hast in Beschreibung deiner Rolle gesagt, eine deiner Aufgaben ist es, Blog, Post zu schreiben, eventuell auch Bücher zu schreiben. Du hast da sehr viel Spaß dran. Du sprichst international. Wie wichtig ist das jetzt für die Zuhörer vielleicht draußen oder für den ein oder anderen in seiner Tech-Karriere, genau so was zu tun? Eher mehr in den Social Media präsent zu sein, mal zu sprechen.

Hat es dir geholfen? empfiehst du den Zuhörern hier?

Ich habe schon immer gerne meine Erfahrungen geteilt. Also ich bin gerne auf Konferenzen gegangen und habe meine Erfahrungen geteilt. Aber das muss nicht jeder. Also es ist, wenn du sagst, du bist einfach total ein Software-Entwickler, du bist Produktmanager, du bist Engineering-Manager und du willst einfach Kundenprobleme lösen, technische Dinge bauen, dann kannst du es machen. Und ich finde, niemand muss auf Social Media sein und sich da durchquälen durch irgendwelche Guides, damit er irgendwelche Likes bekommt. Also

gibt es überhaupt keinen Grund. Also ich bin großer Fan davon, vom Selbstmanagement, das zu tun, was einem gut tut, das was man gerne macht. Klar, es ist Arbeit, also wir werden dafür bezahlt, auch Dinge zu tun, die man vielleicht nicht machen würde, wenn man nicht bezahlt würde. Aber ich glaube, Social Media soll man machen, wenn man gerne teilt, also aktiv posten. Man sollte vielleicht schon aktiv sein und sich ein Feed aufbauen über die Sachen, die einen interessiert, dass man was lernen kann. Also ist immer wieder dieses Thema neugierig sein. Aber

Niemand muss Social Media machen.

Klar, niemand muss aber

Communities, Wissen teilen. Das ist natürlich auch ein toller Format, ⁓ sich weiterzuentwickeln, mal über den Tellerrand zu schauen und nicht immer nur im gleichen Kosmos unterwegs zu sein. Ja, sehr schön. Und wenn du jetzt, hast du schon paar Mal erwähnt, du schreibst in dein Blogpost, wie setzt du denn genau jetzt AI an? wenn man, also das heißt mit Sicherheit nicht, das ist meine Idee, schreib mir einen Post raus, sondern du hast

Am Anfang schon gesagt, hast Research-Unterstützung, du hast vielleicht auch ... einen Agenten, dich irgendwie ... challenged bei der Diskussion oder erzähl einfach mal, wie entsteht denn so ein Artikel, wie setzt du AI in deinem täglichen Business ein?

aktuell, weil das ist ein Prozess der verändert sich, so wie es bei einem Softwareentwickler sich die Tools aktuell weiterentwickeln, habe ich einen 3-stufigen Prozess und die erste Stufe ist halt ganz klar rauszuarbeiten, was ist eigentlich das Thema in dem Blog, also was ist das Problem, was ist der Core Insight und was ist die Kernzielgruppe und das hört sich jetzt total banal an, aber da musst du schon ein bisschen bisschen dran arbeiten. Das Ding habe ich schnell.

Das generiert dann Artifakte, die kannst du dann halt in deinen Kontext legen, in Project Knowledge. Phase zwei ist quasi wie Software Design. Also wie ist denn die Struktur von diesem Blogpost? Was sind denn die Argumente, die du hast? Wie erklärst du diesen Sachverhalt? Was willst du, dass die Leute mitnehmen? Und das ist eigentlich das Härteste. Also das kann manchmal auch Tage dauern tatsächlich. Und dann ist es quasi nur noch wie so Mandala ausmalen.

Also, schreiben geht dann eigentlich schnell und ähnlich war das beim Buch. Die Struktur machen von den Kapiteln, was sind die Kerninhalte, das hat irgendwie ewig gedauert und wenn du dann gesagt hast, okay, ich weiß, was will ich eigentlich da schreiben, dann hast du es halt quasi nur noch runtergeschrieben. Das war dann wie ausmachen. Klar, musst du editieren und das war aber relativ einfach. Und das ist dann die vierte Phase. Also, wir haben schon einen Blog Barraiser, der das Ding also inhaltlich nochmal checkt. Wir haben dann auch

Copyeditor, aber eigentlich musst du selber nochmal ein Editing machen, dass du halt gut, richtig, verständlich, kurz und knapp, also eigentlich so viele Wörter wie möglich rausstreichen kannst, dass du es machst. Und eher kurz und knapp schreiben ist halt aufwendiger, als wenn du sagst, du machst halt irgendwie ewig lange Sätze.

Ja spannend. Also ich habe jetzt auf jeden Fall was mitgenommen, was ich mir bestimmt nochmal durchhören werde und mit in meinen Baukasten mit reinnehmen. Ja, vielen Dank, Matthias. Wir haben jetzt hier knapp über eine Stunde zusammen gesprochen. Kurz zum Abschluss. Ich möchte ein neues Format einfügen im Podcast und zwar möchte ich dich fragen nach einer Frage, die ich dann mitnehme in die nächste Episode zu dem nächsten Gast. Das Spannende ist, du wirst nicht das Thema wissen, über was wir sprechen. Du kennst doch den Gast nicht, aber

Welche Frage wirst du mir mitgeben, die ich meinem nächsten Gast stellen kann?

Wie machst du Selbstmanagement? Wie organisierst du dich selbst?

Wie machst du Selbstverständnismen? Wie organisierst du dich selbst? Alles klar, werde ich mitnehmen. Vielleicht hörst du hier rein und wirst die Antwort dann hören auf deine Frage. wenn dich Leute kontaktieren würden oder deine Blogpost, über die wir gesprochen haben, lesen möchten, wo finden sie dich denn am besten? Wo können sie mehr über dich erfahren?

Also gut findet man mich auf LinkedIn und die Blogposts, sind auf dem AWS Executive in Residence Blog. Aber wenn man nach meinem Namen und Blog googelt, dann findet man die.

Perfekt.

werde das auch gerne mit in die Show und uns mit aufnehmen. Also Matthias, nochmal vielen Dank für deine Zeit. Also ich habe einiges mitgenommen. Es gab nochmal neue Impulse, eine neue Sicht auf das Thema AI. Es war schön, dass du dir die Zeit genommen Und an alle anderen, vielen Dank, dass ihr zugehört habt. Ich hoffe, ihr fand das genauso spannend wie ich und ihr seid auch bei der nächsten Folge wieder mit dabei. Dankeschön und bis dann. Ciao.

ja.

freue mich sehr. Vielen Dank.