Me, Myself & IT Leadership

In dieser Folge geht es um Plattform-Konsolidierung und die Frage, wie IT-Führungskräfte den Kontakt zu den eigentlichen Nutzern ihrer Systeme verlieren. Daniel und Nova sprechen über gewachsene Bereichs- und Schatten-Plattformen, über Migrationsprojekte, die Fachbereiche nur noch als 'Migrationsobjekte' behandeln, und darüber, warum Vorstandsbeschlüsse, Anforderungs-Workshops und Feature-Paritätslisten bei der Standardisierung oft überschätzt werden. Als Gegenentwurf stellt Daniel das Konzept der Paved Roads vor und berichtet, wie eine Supermarktkette ihre Führungskräfte regelmäßig an die Kasse schickt, um den Arbeitsalltag der eigenen Leute zu verstehen. Die Folge lohnt sich für alle, die gerade mehrere Cloud- oder Tooling-Landschaften zusammenführen und merken, dass Reporting-Zahlen allein nicht zeigen, ob die neue Plattform im Alltag wirklich funktioniert. Die wichtigsten Themen: - Konsolidierungsprojekte behandeln Fachbereiche häufig nur noch als Migrationsobjekte, deren eigentliche Bedürfnisse dabei aus dem Blick geraten - Selbstgebaute Bereichs-Plattformen enthalten wertvolles Wissen darüber, welche Anforderungen die zentrale Lösung bisher nicht erfüllt hat - Vorstandsbeschlüsse geben Migrationsprojekten einen notwendigen Rahmen, lösen aber nicht automatisch die Probleme im täglichen Arbeiten - Anforderungs-Workshops liefern unvollständige Bilder, weil eingespielte Abläufe oft gar nicht mehr erwähnt werden - Feature-Parität um jeden Preis führt zu komplizierten und teuren Plattformen, ohne echte Zufriedenheit zu schaffen - Paved Roads bzw. Golden Paths sind ein Ansatz, um Standardwege so attraktiv zu gestalten, dass Teams sie freiwillig nutzen - Eine Nähe-Pyramide mit den Stufen Berichte, Befragung, Zuschauen und Selbstmachen hilft einzuordnen, wie gut man die eigenen Nutzer wirklich kennt - Kennzahlen wie Time-to-first-Deployment und Ticket-Wartezeit zeigen besser, ob Standardisierung im Alltag funktioniert, als reine Migrationsquoten Take-away: Standardisierung und gemeinsame Plattformen sind richtig und notwendig, ersetzen aber nicht den direkten Kontakt zu den Menschen, die damit arbeiten müssen. Wer wissen will, ob eine Plattform im Alltag funktioniert, muss irgendwann selbst an der Kasse sitzen, nicht nur Berichte darüber lesen.

Daniel and Nova talk about what gets lost when IT leaders consolidate platforms without ever sitting down with the people who actually use them. The episode takes its cue from a supermarket chain that sends its executives to work a shift at the checkout, and asks what the equivalent would look like in IT leadership. Daniel reflects on platform consolidation, the migration of business unit and shadow platforms into a shared solution, and why the human history behind self-built tools deserves more attention than it usually gets. He names three things that get overrated in consolidation projects (top-down mandates, requirements workshops, and feature parity) and argues for watching real work happen instead, borrowing ideas like paved roads, Gemba Walks, and Genchi Genbutsu. They also discuss which metrics actually reflect user experience during a migration, how AI can help analyze tickets and feedback at scale without replacing direct observation, and Daniel's own gaps as a leader who mostly hears about users secondhand. He commits to two concrete steps before year end: talking to business units about why they built their own platforms, and spending an intern day with a customer team. Key topics: - Why platform consolidation projects often treat business units mainly as migration objects instead of understanding their actual needs - The hidden knowledge built into self-built departmental and shadow platforms, and why shutting them down without analysis causes the same problem to resurface - Three overrated tools in standardization projects: top-down mandates, requirements workshops, and demands for full feature parity - The concept of paved roads or golden paths as a way to make a shared platform genuinely attractive rather than just mandatory - A four-level closeness pyramid for understanding users: reading reports, asking directly, observing work, and doing the work yourself - Which metrics reveal real user experience during migration, such as time to first production deployment and average ticket wait time - How AI can analyze large volumes of ticket and feedback data, and why that still cannot replace direct observation of daily work - Daniel's concrete commitments for the next twelve weeks: talking to two business units about their self-built platforms and doing an intern day with a customer team Key takeaway: Standardizing a platform also means promising people they will be able to work well with it, and that promise has to be checked against reality, not just against a board resolution. Reports and surveys only get you to the first rungs of understanding users. Real insight comes from watching people work, or doing the work yourself.

In dieser Folge nehmen Daniel und Nova den „White House Accord on Super Intelligence“ auseinander, das Papier, das Donald Trump als KI-Verfassung bezeichnet hat und das von den Chefs von Google, Anthropic, Meta, xAI, Nvidia und OpenAI unterschrieben wurde. Daniel hat das Dokument im Detail gelesen und zeigt, warum die vier dort beschriebenen Kontrollebenen zwar strukturell an bewährte Governance-Modelle erinnern, aber ohne verbindliche Standards, Prüfer, Fristen oder Konsequenzen wirkungslos bleiben. Auffällig ist auch, wer nicht unterschrieben hat: Microsoft, Amazon und Salesforce fehlen, obwohl ihre Clouds die Infrastruktur für den Großteil der Unternehmens-KI stellen. Für IT-Führungskräfte in Europa ist die Folge deshalb relevant, weil sie konkret einordnet, was dieses Papier für die eigene KI-Strategie, KI-Sicherheit und Anbieterabhängigkeit bedeutet, und zwar nichts. Verbindlich bleibt der EU AI Act, und Verantwortung für Agenten-Rechte, Prompt Injection und Datenabfluss liegt weiterhin im eigenen Haus. Daniel liefert dazu einen praktischen Bluff-Check mit vier Fragen für jedes Anbietergespräch. Die wichtigsten Themen: - Das Papier heißt offiziell „White House Accord on Super Intelligence“ und wurde von sechs großen KI-Firmen unterschrieben, aber nicht von Microsoft, Amazon und Salesforce. - Die vier beschriebenen Kontrollebenen ähneln dem Three-Lines-Modell aus Revision und Risikomanagement, enthalten aber keine verbindlichen Pflichten, keine Definition von „Frontier-Modell“ und keine Konsequenzen bei Verstößen. - Der externe Prüfer bewertet nur, ob ein Unternehmen seine eigenen Maßstäbe erfüllt, und der Bericht geht an das eigene Board, nicht an Kunden oder Behörden. - Donald Trump selbst bezeichnete die Vereinbarung als nur „moralisch bindend“, der Sprecher des Repräsentantenhauses nannte sie freiwillige Industrie-Zusagen. - Eine separate Anordnung lässt die US-Verwaltung künftig „Super Intelligence“ statt „Artificial Intelligence“ verwenden, ohne dass sich an der rechtlichen Definition oder den Fähigkeiten der Systeme etwas ändert. - Für Unternehmen bleibt die Verantwortung für KI-Strategie, Agenten-Rechte und Datenschutz vollständig im eigenen Haus, unabhängig von Zusagen der Anbieter. - Daniel schildert ein eigenes Erlebnis mit einer abrupten Umstellung der Abrechnung durch einen KI-Anbieter als Beleg dafür, dass Geschäftsinteressen vor Partnerschaft stehen. - Der vorgestellte Bluff-Check mit vier Fragen zu Verbindlichkeit, Prüfmaßstab, Konsequenz und Transparenz lässt sich direkt in Anbietergesprächen einsetzen. Take-away: Das Papier aus dem Weißen Haus ist keine Regulierung und kein Vertrag, sondern eine freiwillige Absichtserklärung ohne Durchsetzungsmechanismus. IT-Führungskräfte sollten die vorgeschlagene Vier-Ebenen-Struktur als Vorlage für die eigene KI-Governance nutzen, aber mit echten Standards, Konsequenzen und Berichtspflichten versehen, statt sich auf Selbstverpflichtungen der Anbieter zu verlassen.

This episode dissects the so-called AI constitution signed at the White House on September 29th, officially the White House Accord on Super Intelligence. Daniel read the actual one-page document and the accompanying executive order renaming AI to Super Intelligence in US federal usage, and walks through why the agreement looks like corporate governance but carries no enforceable obligations. The discussion covers who signed, Google, Anthropic, Meta, xAI, Nvidia, and who conspicuously didn't, Microsoft, Amazon, and Salesforce, the three hyperscalers most companies actually run their AI workloads on. Daniel and Nova compare the document's four-layer control structure to the three-lines-of-defense model used in corporate audit, explain why the wording, should instead of must, no defined frontier model, no named reviewer, no binding consequences, makes it toothless, and translate all of this into three concrete action areas for IT leaders: AI strategy under the EU AI Act, AI security and shared responsibility for agent permissions and data access, and provider diversity to avoid lock-in. The episode closes with a practical four-question bluff check IT leaders can use in any vendor conversation: is the promise contractual, who audits it and against what standard, what happens on breach, and who receives the audit report. Daniel also shares a real experience of a major AI provider changing subscription billing overnight, reinforcing why self-regulation from AI vendors should not be mistaken for a security strategy. Key topics: - What the White House Accord on Super Intelligence actually says versus what headlines claimed - Why Microsoft, Amazon, and Salesforce did not sign, and what that means for companies running Azure or AWS - The four-layer control model compared to the three-lines-of-defense audit framework used in enterprises - Specific wording gaps: should versus must, no definition of frontier models, no named external reviewer, no enforceable consequences - The executive order renaming AI to Super Intelligence in US government usage and why that terminology shift raises expectations - Three concrete areas IT leaders must own regardless of the paper: AI strategy under the EU AI Act, internal AI security and agent permissions, and provider diversity - A four-question bluff check for evaluating any AI vendor promise: commitment, review standard, consequences, transparency - Lessons from a real billing change by a major AI provider and why contracts beat trust Key takeaway: A voluntary industry statement with no enforceable standard, no independent reviewer, and no customer-facing reporting does not replace your own AI governance. Treat vendor security promises as unverified until they appear in a contract, get checked against a named standard, carry real consequences, and get reported to someone other than the vendor's own board.

Scaled Agile hat mit AI-Native SAFe eine grundlegende Überarbeitung des Frameworks vorgestellt: Das zweitägige PI-Planning wird durch ein eintägiges PI-Outcome-Planning ersetzt, Inspect and Adapt fällt weg und wird durch ein zweiwöchentliches Sense-and-Respond-Event abgelöst, und mit dem AI Value Architect kommt eine neue Rolle hinzu. Daniel und Nova ordnen ein, was davon wirklich neu ist, wo es nur Etikettenwechsel gibt und warum der eigentliche Engpass sich von der Lieferung hin zur Frage verschoben hat, ob das Gelieferte überhaupt Wirkung zeigt. Daniel bringt dazu eigene Erfahrungen aus Experimenten mit lokalen KI-Modellen ein: Erst als er seinen Agenten feste Rollen und einen strukturierten Loop gegeben hat, wurden die Ergebnisse verlässlich, allerdings auch langsamer und teurer. Diese Erfahrung spiegelt die Kernfrage der Folge: Wie viel Struktur braucht eine Organisation oder ein Agentensystem, damit die Ergebnisse stimmen, und ab wann bremst genau diese Struktur nur noch. Die wichtigsten Themen: - AI-Native SAFe verschiebt den Fokus von Output auf Outcomes und reagiert damit auf eine Welt, in der KI-Agenten das Bauen selbst kaum noch zum Engpass machen - Das klassische PI-Planning wird von zwei Tagen auf einen Tag verkürzt und dreht sich künftig um Outcome-Breakouts statt um Feature-Listen - Inspect and Adapt entfällt zugunsten von Sense and Respond, einem zweiwöchentlichen zweistündigen Termin zum Wahrnehmen und Nachsteuern, inklusive bewusstem Stoppen nicht wirksamer Arbeit - Die neue Rolle AI Value Architect soll Teams beim Heben von KI-Potenzialen helfen, sollte aus Daniels Sicht aber eine Übergangsrolle bleiben statt eine feste Planstelle - Token-Kosten brechen die Annahme fixer IT-Budgets und müssen wie Cloud-Kosten aktiv gesteuert werden, inklusive Leitplanken auf Portfolioebene - Core SAFe und AI-Native SAFe laufen offiziell parallel, was den in vielen Konzernen ohnehin bestehenden Flickenteppich an Arbeitsweisen nicht automatisch löst - SAFe lohnt sich vor allem dort, wo viele Teams echte Abhängigkeiten im Ergebnis haben, für lose gekoppelte Einheiten reichen leichtere Ansätze wie Team Topologies oder eine OKR-Klammer - Daniels eigene Experimente mit lokalen KI-Modellen zeigen im Kleinen dieselbe Abwägung wie große Skalierungsframeworks: mehr Struktur erhöht Verlässlichkeit, aber auch Kosten und Trägheit Take-away: Framework-Entscheidungen sollten nicht ideologisch getroffen werden, sondern anhand der tatsächlichen Abhängigkeiten zwischen Teams. Wer bereits mit SAFe arbeitet, sollte AI-Native SAFe in einem ART testen, wer es nicht tut, sollte nicht erst klassisches SAFe einführen, um es danach umzubauen. Unabhängig vom Framework lohnt es sich, Outcomes statt Output zu messen, kürzere Feedback-Takte auszuprobieren und Token-Kosten sowie Modellwahl explizit zur Führungsaufgabe zu machen.