# CTO Strategy: AI Transformation Beyond Tool Rollout

**Podcast:** Becoming CTO Secrets
**Published:** 2026-08-21

## Transcript

Wenn dich dein CEO morgen fragt, was ist denn eigentlich unsere AI-Strategie und du möchtest ihm sowas erzählen wie, dass ihr jetzt gerade dabei seid, Co-Pilot auszurollen, dann ist das noch keine AI-Strategie.
Dann hast du erst mal nur ein Tool eingekauft.
Das kann natürlich ein Anfang sein, aber zu einer AI-Transformation oder einer AI-Strategie wird das erst, wenn dir auch klar ist oder wenn euch klar ist, was ihr überhaupt verändern wollt, was eure Engpässe sind, wie ihr den erfolgt, am Ende des Tages überhaupt messbar macht und was...
der Voraussicht der Return on Invest dann sein wird.
Als CTO tust du gut daran, hier im Driver Seat zu sitzen, denn wenn du das nicht tust, dann wirst du früher oder später zum Getriebenen der Erwartungen anderer.
Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es auch noch werden wollen.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und der Gründer.
der Becoming CTO Community.
Heute tatsächlich zum ersten Mal ohne Gast.
Das hier ist die erste Solo-Folge des Podcasts und ich habe mir dafür ganz bewusst ein Thema ausgesucht, um das aktuell kein CTO drum herum kommt, nämlich das Thema AI-Strategie und AI-Transformation.
Ich möchte heute mal darüber sprechen, warum das Thema wesentlich größer ist als ein reiner Tool-Rollout und als viele vielleicht denken.
Warum es gefährlich und verlockend ist, nur einfach irgendwelche Tätigkeiten schneller zu machen.
Was dein CEO wahrscheinlich gerade von anderen Unternehmern hört und was aus meiner Sicht in eine AI-Strategie im Jahr 2026 hineingehört.
Der Ausgangspunkt ist ja relativ klar.
AI soll erstmal Dinge besser machen, schneller machen, effizienter machen, billiger machen.
Das kann es auch, das wird es auch.
Aber im ersten Schritt sorgt es erstmal für einen zusätzlichen Komplexitätslayer.
Ich spreche mit sehr vielen CTOs, mit Tech-Unternehmern tagtäglich.
Verstehen, tun eigentlich alle das Thema Agentic AI oder auch Artificial Intelligence im Allgemeinen.
Nicht jeder auf die gleiche Art und Weise, nicht jeder hat die gleichen Herausforderungen.
Aber in einer Hinsicht sind sich alle dann doch relativ einig.
Sie sehen...
Viele sehen den Wald vor lauter Bäumen einfach nicht.
Ich glaube, das kann man so sagen.
Und was ich eben als zusätzlichen Komplexitätslayer angekündigt habe, das liegt einfach daran, dass jetzt viele neue Dinge dazukommen.
Es kommen neue Tools dazu, es kommen neue Accounts dazu, es kommen neue Prozesse dazu.
Mitarbeiter fangen auf einmal an, ihre eigenen privaten Accounts und Abos zu nutzen, weil das Unternehmen vielleicht noch nicht schnell genug ist.
Agents brauchen Zugriffe, müssen...
On-Geboardet müssen, Sunsetet werden müssen, gewartet werden.
Es verändert sich gerade sehr, sehr vieles.
Und natürlich sollen diese Veränderungen auch zu einer Verbesserung führen, zu einer Verschnellerung, einer höheren Effizienz, einem höheren Durchfluss.
Aber mal ehrlich, für viele CTOs ist das gerade eine zusätzliche Last.
Und viele wissen gar nicht, wo fangen sie an, wo hören sie auf, was ist der erste Schritt, wie kann dann überhaupt eine gemeinsame Strategie aussehen.
Denn was wir mal alle nicht vergessen sollten, Ein CTO hat heute schon eine ganze Menge zu tun.
Er hat Roadmaps für die nächsten 12 bis 24 Monate, ambitionierte Roadmaps.
Es gibt jetzt schon überbordende Erwartungshaltungen, was die Lieferfähigkeiten und Liefermöglichkeiten angeht.
Wir reden immer von den Delivery Capabilities der Teams.
Ja, die sind nicht immer da, wo sie sein sollen.
Und nur weil man jetzt irgendwas mit AI macht, verbessern die sich nicht automatisch.
Natürlich gibt es auch noch Themen um Kosten.
Es geht um, welche Modelle nimmt man, wie rechnet man das Ganze ab, wie zeigt man auch den Return on Invest.
Welche Folgeprobleme kommen dann überhaupt mit an Bord, wenn ich jetzt anfange, mit AI Dinge zu lösen.
Und was wir bei der ganzen Sache auch nicht vergessen dürfen, Teams sind nicht immer optimal aufgestellt.
Sie haben unterschiedliche Reife gerade.
Die Organisation hat jetzt schon natürliche Constraints, die lösen sich mit AI nicht auf.
Im Gegenteil, diese Constraints oder auch die...
Die Engpässe in der Organisation im Durchfluss, die werden mit AI nur noch sichtbarer.
Denn was viele vergessen, aktuell wird an vielen Stellen nur lokal optimiert.
Der Software-Engineer, der jetzt anfängt, sein Engineering zu enhancen, zu verbessern, indem er Cloud-Code einsetzt, indem er Codecs einsetzt, der wird vielleicht 30 bis 40 Prozent schneller sein.
Vielleicht wird er auch drei bis viermal schneller sein.
Das ist eigentlich egal.
Am Ende des Tages bedeutet das noch lange nicht, dass der Gesamtdurchlauf des Systems besser geworden ist.
Denn dieses Mehr an Reviews oder Pull-Requests, die jetzt entstehen, die gereviewt werden müssen mit der dreifachen, der vierfachen, der fünffachen Anzahl an Lines of Code, wer soll das denn reviewen, wenn die Prozesse dafür noch gar nicht vorgesehen sind?
Was macht denn QA?
Wie viel manueller QA-Aufwand muss denn aktuell noch geleistet werden?
So, ihr seht schon, der Engineer, der kann sich jetzt mehrere Sachen überlegen.
Den Mehraufwand oder das Mehr an Effizienz, was er jetzt hinzugewonnen hat, Sorgt das dann dafür, dass er jetzt 20 Minuten länger Kaffeepause macht?
Oder fängt er an, neue Aufgaben anzunehmen, mehr Aufgaben zu liefern?
Was dann wiederum dazu führt, dass das Bottleneck hinten raus weiterhin, ja, dass wir einen größeren Rückstau haben.
Das Problem ist, und Engpässe fangen nicht an zu verschwinden, Engpässe fangen an zu wandern.
In vielen Organisationen war Software Engineering, also das Schreiben von Code, ein Engpass, weil...
Produktmanagement immer in der Lage war, in kurzer Zeit sehr viel mehr an Tickets im Backlog einzustellen und zu planen, was in den nächsten Monaten passieren soll, als Engineering in der Lage war, wegzuarbeiten.
Das ist ein Fakt.
Ob der Engpass jetzt nach vorne wandert Richtung Requirements Engineering, ob der Engpass jetzt nach hinten wandert Richtung Abnahme oder vielleicht sogar Richtung Kunden, der irgendwann Abnahme betreiben muss, sogar noch nicht mal in der eigenen Organisation, sondern vielleicht in der externen Organisation, das sei mal dahingestellt.
Wenn ihr am Ende des Tages überhaupt gar nicht schneller liefern könnt, dann habt ihr vielleicht sehr viele mehr Kosten verursacht, dann habt ihr lokal optimiert, aber dann habt ihr relativ wenig gewonnen.
Ein weiteres Problem ist, was ich sehe, Unternehmer sind sehr häufig bauchgesteuert, sie haben einen guten Riecher und vor allen Dingen unterhalten die sich mit sehr vielen anderen Unternehmern.
Sie unterhalten sich mit CEOs, sie unterhalten sich mit Investoren und was dort gerade reihenweise erzählt wird, ist atemberaubend.
Da wird von doppelter Geschwindigkeit gesprochen, von hey, wir haben mit der halben Mannschaft, haben wir ein Vielfaches des Outputs jetzt geschaffen.
So, diese Geschichten, das Problem ist dieser Geschichten, die sind nicht alle wahr.
Da sind vielleicht noch nicht mal jede zweite dieser Geschichte ist wahr.
Das ist aber auch völlig irrelevant.
Relevant ist das Bild, das in den Köpfen einiger CEOs entstehen und die fangen dann irgendwann an, das zu vergleichen.
Das ist wie eine Art Halo-Effekt, so könnt ihr euch das vorstellen.
Und die fangen das dann so an zu vergleichen mit dem, was in ihrer eigenen Organisation gerade passiert.
Und dann schauen sie hin und stellen fest, bei uns passiert das ja gar nicht.
Und es ist völlig egal, ob diese Geschichten jetzt aus Wichtigtuerei entstanden sind, ob das Übertreibung sind.
Diese Geschichten sind im Umlauf.
Kein CEO mag das Gefühl, hinten zu liegen.
oder einem Trend hinterher zu laufen.
Und wenn er das Gefühl hat, dieses Thema ist in seiner Organisation nicht besetzt, dann wird er sich jemanden suchen und wird dort Druck machen und wird verlangen, dass dieses Thema besetzt ist.
Ich halte es für sinnvoll, wenn man seinem CEO hier mindestens ein paar Schritte voraus ist.
Einfach um auch ihn selber in die Lage zu versetzen, positive Erfolgsmeldungen zeigen zu können.
Das Problem ist tatsächlich, wenn der CTO hier keine eigene...
Meinung hat, keine eigene Agenda hat, keine eigene Sicht auf das Thema hat und dieses Thema nicht und und das Thema nicht selber vorantreibt, dann passiert Folgendes.
Dann werden die fremden Geschichten, die fremden Erfolgsgeschichten, egal ob sie stimmen oder nicht, die werden zu einem Benchmark, zum internen Benchmark für das, was passieren soll und ob man erfolgreich ist oder nicht.
Der CTO muss anschließend erklären, warum das nicht übertragbar ist auf seine Situation.
Er muss es wieder gerade biegen, er muss es richtig stellen, er muss sich erklären, er muss sich rechtfertigen, er muss das Thema selber ausräumen.
Alles nicht gut.
Im Driver Seed zu sein stattdessen heißt, du bist derjenige, der die Roadmap vorgibt.
Du ownst das Thema, du sammelst Requirements ein, du hast die Landkarte gezeichnet, du weißt genau, wo es hingehen soll, das Zielbild ist dir klar.
Du weißt, wie du den Fortschritt messen kannst, du weißt, wie du Erfolg messen kannst.
Und es heißt auch, du musst nicht alles selbst auswählen.
Aber es muss klar sein, mit welchem Prozess das passiert.
Wenn du das Thema nicht selbst treibst, dann wirst du nämlich von den Erwartungen getrieben werden, ganz einfach.
Warum ist AI-Strategie denn jetzt so groß oder größer, wie ich das anfangs genannt habe?
AI ist ja nicht gleich AI.
Also es gibt AI im Produkt.
Es gibt für den CTO ganz massiv, ne?
Kehr vor deiner eigenen Haustür.
Es gibt AI im Agentic SDLC.
Es gibt aber auch AI in Finance.
Es gibt AI in Operations.
Es gibt AI in Sales.
Es gibt AI in HR.
Und so weiter.
Und wenn man nicht aufpasst, dann bauen die gerade die Shadow-IT von morgen.
Mit kleinen Tools, die hier und da laufen, die keiner überwacht, für die es keine Guardrails gibt, die nicht gewartet werden, wo nicht klar ist, was passiert mit den Daten, die die sammeln, die die auswerten, mit denen die bearbeiten.
Und es muss am Ende des Tages auch nicht zwangsläufig der CTO sein, der das Thema und das kann auch der CIO sein, das kann der CDO sein, also der Chief Digital Officer.
oder auch der Chief AI Officer, den es mittlerweile in Organisationen auch gibt.
In der Regel haben diese Organisationen aber nicht unbedingt diese Rollen besetzt.
Den CTO haben sie an vieler Stelle schon.
Es ist sehr sinnvoll, dass der CTO diese Aufgabe mit übernimmt und seine eigene strategische Sicht dazu.
Das Thema kann man natürlich beliebig groß machen.
Wenn wer ein Startup hat mit drei, vier Leuten, da geht es erstmal nicht um einen formalen Prozess.
Da geht es erstmal darum, was können wir wie ausprobieren.
Da gibt es kleine Piloten, da stirbt das eine hier, da wird das andere da erstellt.
Alles gut.
Auf der anderen Seite gibt es aber auch schon größere Unternehmen, die haben laufende Zertifizierungen, die haben Kunden mit bestimmten Requirements, die sind in einer Domäne unterwegs, wo du nicht einfach so irgendwelche Dinge neu...
bauen kannst, wo nicht klar ist, wo die Daten hinfließen.
Also solltest du dir von vornherein ein paar sehr simple, aber sinnvolle Gedanken machen zu vier Leitfragen.
Das eine ist, welche Arbeit soll am Ende des Tages besser werden?
Also was ist der konkrete Use Case?
Welche Tools werden sich da gewünscht?
Was soll da konkret getan werden?
Geht es um Recherche?
Geht es um Dokumentanalyse?
Geht es um Coding?
Geht es um Support?
Geht es um Sales?
Was auch immer.
Das alles hat eine große Auswirkung darauf.
wie die Lösung am Ende des Tages aussehen soll.
Und vor allen Dingen, ohne Use Case lässt sich kein seriöser Return on Invest berechnen.
Die zweite Frage ist, welche Daten sollen denn eigentlich verarbeitet werden?
Geht es um Vertragsdaten, geht es um Quellcode, geht es um Kundendaten?
Das hat an verschiedenen Stellen sehr unterschiedliche Auswirkungen.
Und vor allen Dingen, wie schützt du deine Organisation davor und die einzelnen Individuen und auch dein eigenes Business, dass das nicht einfach abfließt?
Dann ist die Frage, was darf das System denn eigentlich tun?
Was darf es denn lesen oder tun?
Wo gehen denn Konnektoren hin?
Darf es nur lesen?
Darf es auch schreiben?
Mit welchen Tools ist es angebunden?
Was sind die technischen Grenzen?
Einfach nur zu sagen, ja, sensible Daten nicht, ist ein bisschen zu ungenau heutzutage und muss präzisiert werden.
Und natürlich spielt es auch eine Rolle, um welche User in der Organisation geht es denn.
Wer nutzt das denn?
Wie häufig nutzt er denn das?
Welche Modelle möchte ich denn anbieten?
Allein die Auswahl des Modells.
hat signifikante Auswirkungen auf die Kosten, die das später produziert.
Wenn ihr in einer Organisation mit 10.000 Mitarbeitern seid und ihr habt jetzt angefangen, AI einzusetzen und ihr stellt fest, ihr habt jetzt schon 100.000 Euro im Monat an zusätzlichen AI-Kosten, dann wird das irgendwann Fragen verursachen.
Und dann kommt auch sehr schnell die Frage nach dem Return on Invest.
Und dann stellt sich auch die Frage, ja, wo kommen wir denn dann dahin, wenn auf einmal alle AI nutzen wollen?
Wer darf denn welches Modell nutzen?
Wer darf denn welches Modell explizit nicht nutzen?
Für was lohnt sich ein Fable?
Für was lohnt sich ein Opus?
Für was lohnt sich ein Sonnet?
Kleiner Spoiler hier an der Stelle.
Wenn ihr Engineering-Aufgaben erledigen wollt, da reicht ein Sonnet 5 auf jeden Fall aus.
Zu relativ geringen Kosten.
Da braucht ihr kein Opus, da braucht ihr kein Fable.
CTOs, die ihre Organisation dazu anweisen, die ihre Organisation mit Opus oder mit Fable Entwicklungsarbeit leisten lassen.
schmeißen hier Perlen vor die Säule.
Das ist ein riesen Mehraufwand an Kosten, der da entsteht, unabhängig davon, ob ihr das jetzt innerhalb eurer Subscriptions macht oder nicht.
Stellt mal fest, innerhalb der Subscriptions sind viele tausend Euro an Tokens, sind aktuell subventioniert für 200 Dollar im Monat zu haben.
Das funktioniert aber nur so lange, wie ihr euch innerhalb der Parameter von Cloud Code bewegt.
Sobald irgendwie API-Nutzung drin ist, seid ihr nämlich schon wieder außerhalb davon.
Also sich darüber Gedanken zu machen, Was verwende ich denn wo?
Das macht durchaus Sinn, auch jetzt schon.
Und aus all diesen Fragestellungen lässt sich dann irgendwann ein Betriebsmodell ableiten.
Betriebsmodell klingt immer so förmlich, aber es muss ja klar sein, wer arbeitet mit welchem Stack?
Gibt es Sandbox-Systeme?
Gibt es befristete Experimente?
Gibt es feste Budgets pro Mitarbeiter, pro Team und so weiter?
Gibt es Ausnahmeprozesse?
Wer darf denn welches Modell überhaupt bestellen?
Gibt es unternehmerische Restriktionen innerhalb des Unternehmens, welche Modelle überhaupt angeboten werden?
Ist das nur eins?
Sind das mehrere?
Und unter welchen Voraussetzungen macht man die zugänglich und für wen?
Wer darf die denn bestellen?
Und tatsächlich ist die Auswahl des Modells eigentlich die nachgelagerte Frage.
Zuallererst muss mal geklärt werden, welche Aufgaben, welche Daten, welche Rechte, welches Volumen.
So, das kommt zuerst.
Und anschließend könnt ihr darüber reden, welches Modell, in welchem Workspace.
welche Agents dürfen verwendet werden, welches Abrechnungsmodell und so weiter.
Das soll nicht in einen Topf geworfen werden.
Die Modellwahl ist das Resultat der vier Fragen, die wir jetzt gerade eben gestellt haben.
Das ist nicht der Ausgangspunkt.
Und wenn du dich jetzt fragst, wie kannst du das Ganze denn messen, auch als CTO, gerade für deine Organisation, du bist später vielleicht, du musst dir Gedanken machen darüber, nach welchen Kriterien du AI in der Organisation erlauben möchtest oder ausrollen lassen möchtest.
Du bist später nicht derjenige, der für jeden Teil der Organisation zuständig ist, um zu gucken, was ist denn der Return on Invest.
In Engineering ist das natürlich anders.
Wenn du 10.000 Euro im Monat für Tokens ausgibst und für Subscriptions in deiner Organisation, ja, auch dann musst du zeigen, was bringt das denn am Ende des Tages.
Also was bedeutet das denn für den Throughput?
Was bedeutet das für Lead Time?
Was bedeutet das für Cycle Time?
Geht die Anzahl der Bugs runter oder geht die rauf?
Finden wir Fehler eher früher oder später?
Haben wir einen messbaren Impact auf Business Value?
Was sind denn, kriegen wir auf einmal mehr Storys mit höherer Storypoint-Zahl in die Sprints rein?
Wollen wir das denn überhaupt?
Ist das die Messgröße, mit der wir eine höhere Lieferfähigkeit darstellbar machen?
Was wir festgestellt haben ist, du kannst da sehr schnell in eine Metrik-Falle reintappen.
Deine Cycle-Time, wenn du mit zwei wöchentlichen Sprints arbeitest.
dann kann es gut sein, dass die Cycle Times von deinen Features erstmal gleich bleibt, weil du immer innerhalb eines Zwei-Wochen-Sprints in der Lage bist, von der Anforderung bis zum Requirements Engineering, bis zur Umsetzung und zur Abnahme, dass innerhalb von einem Prozess, naja, sagen wir mal zwei Wochen Engineering-Zyklus plus eine Woche davor Requirements Engineering plus Abnahme, so.
Wenn dieser Prozess am Ende des Tages gleich bleibt, dann guckt der Investor auf deine Zahlen und stellt fest, Deine Lead-Time, deine Cycle-Time ist nahezu gleich geblieben bei wesentlich höheren Kosten.
Und dann fragt er sich zurecht, warum ist das so?
Dann kann es aber natürlich sein, dass gleichzeitig die Komplexität der Stories, die du in der Lage bist, innerhalb eines Sprints zu lösen, ist vielleicht hochgegangen.
Oder die Anzahl der Stories, die du in der Lage bist, in einem Sprint zu lösen, ist wesentlich hochgegangen.
Also ist es sehr wichtig zu verstehen, was sagt denn jede einzelne Zahl aus und wie kann ich diese Zahl...
tatsächlich auch an den Mann bringen, unerklärbar machen.
Nicht jede Zahl hat immer die gleiche Aussagekraft.
Oder die Metriken sind meistens korrekt.
Nicht alles sind die richtige Antwort auf die Frage, die gestellt wird.
Wir haben jetzt vom Jahr 2025 bis jetzt mehrere Entwicklungsstufen gesehen.
Wenn wir von Autonomiestufen in der Softwareentwicklung sprechen, dann ist das durchaus vergleichbar mit dem Stufenmodell in der Automobilindustrie, wenn es um autonomes Fahren geht.
Auch da werden wir...
Habe jetzt nicht genau nachgeschaut, aber ich glaube, es gibt da auch fünf Stufen.
Und auch hier, ich sehe im Bereich der Softwareentwicklung fünf Stufen von manuell auf Stufe 1, wo wir bis vor ein paar Jahren noch unterwegs waren, bis zu Stufe 5 der sogenannten Dark Factory, in der vollautomatisiert Softwareprodukte gebaut werden mit nur dem Menschen als Eingabeparameter, der seine...
seine Wünsche, seine Ziele formuliert und am Ende sicherstellen muss, dass das richtige Ergebnis rausgekommen ist, was er sich auch gewünscht hat.
Und dazwischen drin ist kein Human mehr in der Loop.
Und dazwischen gibt es verschiedene Ausprägungsstufen.
Die meisten sind mittlerweile auf Stufe 2.
Das bedeutet AI-Assisted Code.
Vielleicht sind sogar viele schon weiter.
Aber AI-Assisted-Code ist das, was wir bis 2024 noch mit Cursor gesehen haben, wo wir alle gestaunt haben, was Cursor alles kann.
Im Wesentlichen geht es da um Code Completion, es geht um Chats, es geht um kleinere Änderungen.
Aus heutiger Sicht wahrscheinlich alles vernachlässigbar.
Stufe 3 ist dann tatsächlich der...
Der Agentic AI-Ansatz, das heißt der Agent analysiert, der Agent plant, der Agent implementiert oder spinnt sogar andere Agents, aber der Mensch ist immer noch sehr nah dran.
Der Mensch wird ständig wieder gefragt für Rückmeldungen, der Mensch muss abnehmen, der Mensch muss kontrollieren.
Er steuert und prüft.
Stufe 4 sind wir dann in eine Richtung unterwegs, die ja viele schon kritisch sehen oder an der sich schon die Spreu vom Weizen trennt.
Denn hier geht es um Orchestrierung.
Also das ist die Weiterentwicklung des Agentic AI-Ansatzes.
Hier reden wir davon, dass wir schon vorhinein mehrere Agents definieren mit verschiedenen Rollen, mit Skills, mit festen Zielen, mit Budgets, mit Rechten und so weiter und natürlich auch mit Eskalationswegen.
Und dann muss sichergestellt werden, dass der Human nur noch an ganz bestimmten Gateway-Points oder Break-Points innerhalb dieses Prozesses mit dabei ist und überwacht.
Es gibt schon einige Organisationen und CTOs da draußen, die irgendwo zwischen Stufe 3 und Stufe 4 sind.
Ob wir Stufe 5 eine Dark Fabric je erreichen werden, das werden wir am Ende des Tages irgendwann sehen.
So, und es geht auch nicht nur darum, jetzt zu gucken, wie komme ich jetzt möglichst schnell auf Stufe 5, das wäre unseriös, sondern auf welcher Stufe befindet ihr euch denn jetzt aktuell?
Was ist die nächste Stufe und in welchem Zeitraum könnt ihr sie erreichen?
Und vor allen Dingen, was fehlt für den nächsten Schritt?
Mit wachsender Code-Produktion?
dieser berühmte Engpass wandert an andere Stellen.
Der wandert zu Architektur, der wandert zu Requirements Engineering, der wandert zu Review und zu QA.
Das sind auch Bereiche, mit denen man mit Engeantica auch eine ganze Menge tun kann.
Ich habe das jetzt an der einen oder anderen Stelle schon mal erzählt.
Aber der Code wird billiger, das technische Urteil wird es nicht.
Das ist, glaube ich, der Einsatz, mit dem man das Ganze gut zusammenfassen kann.
So, und jetzt kommt auch noch ein Knackpunkt, der sich auch ein bisschen der Kontrolle des CTOs aktuell entzieht.
Denn der Rest der Organisation, der wartet aktuell nicht darauf, dass da irgendwas passiert, sondern interessanterweise werden die gerade selbst sehr aktiv.
Der CFO baut eigene Agenten und eigene Tools.
Sales hat schon Themen automatisiert oder setzt Tools von Drittanbietern ein, um die eigenen Sales-Prozesse zu streamlinen.
Haben wir jetzt alles schon gesehen.
Operations verbindet halt Tools mit internen Daten und fängt damit an zu arbeiten.
Warum?
Weil es noch keine Strategie gibt.
Und Strategie bedeutet auch, anderen vielleicht die ein oder andere Möglichkeit wegzunehmen und auch mit den Konsequenzen davon klarzukommen.
Ich glaube, es gibt ein paar Fragen, die ihr euch jetzt unabhängig von der Unternehmensgröße in meinem Hinterkopf haben solltet.
Welche Firmenzugänge und privaten Accounts existieren denn eigentlich?
Welche Daten dürfen am Ende des Tages wohin?
Wer genehmigt denn die Tools und wer verteilt die API-Keys für Anthropic, für Codex und so weiter?
Wer entfernt die Zugänge am Ende des Tages auch wieder?
Welche Agents dürfen denn was genau?
Und wer verwaltet das?
Also Wildwuchs schön und gut.
Am Anfang ist der Wildwuchs einfach nur Experiment.
Und irgendwann ist der Wildwuchs einfach nur Wildwuchs und dann muss er weg.
Ich will jetzt auch gar nicht mit einem 90-Tages-Plan irgendwo ankommen.
Das ist immer so Kindergarten.
Ich glaube, in welchem Zeitraum man das machen kann, das liegt bei jedem Einzelnen.
Das ist auch ein bisschen abhängig davon, in welcher Organisation man sich befindet und wie schnell die Organisation arbeitet.
Es braucht nicht unbedingt immer eine sechs Monate Strategiephase, die notwendig ist, sondern hier müssen einfach bestimmte Rahmenparameter geprüft sein.
Gibt es Firmenzugänge?
Sind private Accounts erlaubt?
Ja oder nein?
Gibt es APIs?
Gibt es Agents?
Wer inventarisiert das Ganze?
Welche Use Cases müssen bedient werden?
Sehr, sehr wichtig.
Gibt es Regeln für die Daten, mit denen gearbeitet wird?
Also welche Daten dürfen denn überhaupt rein?
Auf welche Daten darf zugegriffen werden?
Welche Daten dürfen verarbeitet werden?
Es müssen Default Workspaces angelegt werden.
Es geht um Spezialtools.
Es gibt Ausnahmeprozess mit Sicherheit und so weiter.
Gibt es irgendwo Pilotprojekte, die gestartet werden unter besonderen Voraussetzungen?
Was sind denn die Bedingungen für diese Pilotprojekte?
Und so weiter und so fort.
Wie ist die Qualität des Ergebnisses?
Wie viel Nacharbeit ist denn notwendig?
Wie viel Rework ist denn notwendig?
Was bedeutet es denn auf der Zeitschiene?
Wie viel Zeit haben wir denn gewonnen?
Was hat uns das dann am Ende des Tages gekostet?
Haben wir sehr viele Policy-Verstöße gemessen oder messen können?
Verschieben sich Engpässe tatsächlich nur?
Können wir Engpässe auch wirklich auflösen?
Das wäre natürlich super schön.
Müssen wir Leute rollenbezogen trainieren?
Müssen Modelle rollenbezogen trainiert werden?
Ich glaube, viele haben sich darüber noch keine Gedanken gemacht.
Und dann geht es natürlich auch darum, es muss ausgerollt werden, es muss vielleicht mal was gestoppt werden, es muss was zurückgerollt werden, vielleicht muss auch irgendwann konsolidiert werden.
Nicht jede Lizenz sollte immer da sein, um zu bleiben.
Das sind eine ganze Menge Themen, die da auf Organisationen hereinprasseln.
Ich wiederhole meine These vom Anfang.
Ich halte den CTO für die geeignetste, für die kompetenteste Person, um die Einführung einer...
AI-Strategie im Unternehmen zu denken, auszurollen und umzusetzen.
Dafür muss er natürlich wissen, wo die Engpässe liegen, welche Use Cases es gibt.
Das Thema Daten und Rechte, wer darf auf was zugreifen?
Ich habe es jetzt schon ein paar Mal genannt.
Was investieren wir?
Woran messen wir den Return von unserer Investition?
Wichtigste Aufgabe des CTO macht ihn zur wichtigsten C-Level-Rolle im Jahr 2026 und darüber hinaus.
Wo wir, glaube ich, in einem Jahr von jetzt anstehen, können viele noch gar nicht abschätzen.
Ziel soll es sein, dass der CTO im Driver Seat ist.
Es geht aber auch darum, technische und organisatorische Komplexität zusammenzubringen und zu versuchen, aufzulösen.
Und vielleicht denkst du jetzt so, ja, okay, interessiert mich alles nicht, das sind alles Themen, da lasse ich andere sich darum kümmern.
Das Problem ist, wenn du diese Fragen nicht beantwortest, dann kommt irgendjemand anderes und fängt sie an für dich zu beantworten.
Das ganz, ganz sicher.
Die Frage ist nur, ob du derjenige sein möchtest, dem die Antworten auf diese Fragen diktiert werden oder der bei dir höchstens mal anfragt, was du dir gerne hättest, aber Strategie und Policy passieren woanders oder ob du derjenige sein möchtest, der das aktiv mit...
vorantreibt.
Ich weiß, was ich tun würde.
Das diskutieren wir unter anderem auch in der Community.
Im Coaching haben wir das Thema auch immer mal wieder, wenn es darum geht, wie messe ich denn Erfolg im Agentic SDLC?
Wie weit sind denn eigentlich andere?
Was sind denn für Best Practices haben sich denn aktuell schon etabliert?
Was funktioniert überhaupt nicht?
Wie sehen denn Investoren das Ganze?
Wie pushen Investoren auch ihre Organisation?
Das sind alles Themen, die wir mehrfach in der Community und im Coaching besprochen haben.
Und natürlich, und das mache ich tatsächlich viel zu selten, wenn dir der Podcast gefällt, abonniere ihn doch, sei es auf YouTube, sei es hier auf Spotify, auf Apple Podcasts, Audible, RTL Plus, wo auch immer du ihn findest.
Lass auch gerne eine Bewertung da, denn das hilft, das ganze Thema nochmal nach vorne zu bringen.
Ihr wisst, das füttert den Algorithmus.
Also, ich habe in der Vergangenheit viel zu wenig darauf aufmerksam gemacht.
Mach das doch mal.
Leite die Folge mal an jemanden weiter, den das interessieren könnte.
Abonniert das Ganze, gebt mir einen Daumen hoch.
Mega gut.
Ich verabschiede mich.
Danke für eure Aufmerksamkeit.
Ciao, ciao.