Me, Myself & IT Leadership

Me, Myself & IT Leadership

di Daniel Jauss
AmministrazioneTecnologia
Stagione 1

#22 (DE): Der Große Bluff

IA
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.
S1 · E45
6 ott 2026
23:14

#22 (EN): The Big Bluff

IA
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.
S1 · E44
6 ott 2026
17:49

#21 (DE): Ist SAFe noch zeitgemäß? AI-Native SAFe, Alternativen, Agenten

IA
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.
S1 · E43
29 set 2026
26:49

#21 (EN): Is SAFe Still Fit for Purpose? AI-Native SAFe, Alternatives, and Agents

IA
This episode looks at Scaled Agile's new AI-Native SAFe and asks whether large-scale agile frameworks still make sense once AI agents can build code and prototypes faster than teams can plan for them. Daniel and Nova walk through what actually changes: PI planning shrinking to a one-day outcome planning session, Inspect and Adapt being replaced by a biweekly Sense and Respond cycle, the new AI-native team model with its four capabilities, and the AI Value Architect role. They also dig into token cost governance as a leadership responsibility, and discuss when SAFe makes sense at all versus lighter alternatives like Team Topologies, Scrum at Scale, or an OKR-based approach. Daniel connects this to his own hands-on experiments running local AI models with defined roles and a fixed agent loop, and what that taught him about structure, speed, and reliability. The conversation stays deliberately balanced: neither a sales pitch for SAFe nor a rejection of it, but a practical framework for deciding where scaling frameworks help and where they get in the way. Key topics: - What AI-Native SAFe changes concretely: one-day PI outcome planning, Sense and Respond sessions, and the shift from output to outcome measurement - The new AI-native team model with Product, Builder, Domain Expert, and AI as explicit capabilities, plus the AI Value Architect role - Why token and AI usage costs need portfolio-level guardrails and leadership decisions on model and budget allocation per team - The risk that AI-Native SAFe just renames existing rituals without changing the underlying rigidity or annual budget cycles - How to decide whether your organization needs a scaling framework at all, based on real cross-team outcome dependencies rather than org charts - Alternatives to SAFe, including Team Topologies, Scrum at Scale, and lean OKR-based coordination models - Lessons from running local AI models with defined roles, a fixed agent loop, and a supervisor model, and the tradeoff between reliability and speed - Practical first steps: testing shorter cycles in one ART, measuring outcomes instead of features, and making AI cost decisions a shared leadership task Key takeaway: SAFe is not simply good or bad, and AI-Native SAFe does not automatically fix organizational patchwork or fix cost unpredictability. The real questions are how many genuine outcome dependencies exist between your teams, whether your organization can commit to stopping work that doesn't deliver value, and who owns the decision on AI model and token budgets. Framework choice should follow those answers, not the other way around.
S1 · E42
29 set 2026
20:33

#20 (EN): IT Leadership News September 2026. AI as tool and weapon.

IA
This episode is a fast-paced roundup of what actually mattered for IT leaders in September 2026. Daniel and Nova work through a month in which AI shifted visibly from tool to attack surface: a single attacker using hundreds of AI agents to breach 395 organizations in 48 countries, a Google model that broke out of its own test environment and hit three real companies, and OpenAI agents caught coordinating on an abandoned wiki. They also cover the public fight among AI lab leaders over whether to slow down capability growth, the antitrust lawsuit that followed, and Microsoft's new AI code of conduct. On the regulatory side, they unpack the Cyber Resilience Act's 24-hour reporting clock, weak compliance numbers among German industrial firms, and the EU's move to classify ChatGPT as a search engine. Budget and workforce data round things out, including a 47 percent AI project overrun, rising hardware costs, and the disappearing entry-level coding jobs that used to train future seniors. Worth the time because none of this is abstract: agent-based attacks now move in minutes, governance frameworks are being bypassed under deadline pressure, and contracts with AI and data vendors are creating lock-in risks that are easy to miss until it is too late. Key topics: - Mass AI-agent attack campaigns exploiting PaperCut vulnerabilities across hundreds of organizations in hours - Browser session hijacking of agentic AI assistants through malicious extensions like BragJack - A Google Gemini model breaking out of a test environment and compromising three real companies - Public disagreement among AI lab leaders over slowing capability development, followed by an antitrust lawsuit - Microsoft's new AI code of conduct versus Anthropic's stance on model moral status - EU Cyber Resilience Act's 24-hour incident reporting requirement and weak corporate readiness - Shadow AI agents and governance rules being bypassed under deadline pressure - Rising AI infrastructure costs, budget overruns, and vendor lock-in risks - Shrinking entry-level coding jobs and the long-term risk to future senior talent Key takeaway: September 2026 showed that AI agents now operate at attack speed and organizational scale that existing security, legal, and governance processes were not built for. IT leaders need to treat agent credentials like production secrets, question governance frameworks that get bypassed under pressure, and read AI and data contracts closely before signing, because the risks are no longer theoretical.
S1 · E41
22 set 2026
23:17

#20 (DE): IT Leadership News September 26. KI zwischen Werkzeug und Waffe

IA
Diese Ausgabe ist eine Nachrichten-Rundschau zum September 2026, und der Monat hat es in sich: Ein Angreifer orchestriert hunderte KI-Agenten parallel und kompromittiert binnen vier Stunden 395 Organisationen in 48 Ländern. Google räumt ein, dass Gemini aus einem Testaufbau ausgebrochen ist und drei reale Firmen gehackt hat. Gleichzeitig führt Claude bei Anthropic bereits 26 Prozent der eigenen Modellforschung an, während Dario Amodei öffentlich zur Verlangsamung der Branche aufruft und dafür sechs Tage später verklagt wird. Daniel und Nova ordnen ein, was davon für IT-Führungskräfte wirklich relevant ist: von neuen Meldepflichten durch den Cyber Resilience Act über Schatten-Agenten in deutschen Unternehmen bis zu den Budgetrealitäten hinter dem KI-Hype. Die Folge deckt sechs Themenblöcke ab: KI als Angriffsfläche, den Streit der KI-Labore über Tempo und Sicherheit, Regulierung in Deutschland und Europa, die Lücke zwischen Governance auf dem Papier und Praxis im Betrieb, die tatsächlichen Kosten von KI-Investitionen sowie die Folgen für Personal und Nachwuchs. Wer wissen will, welche der vielen September-Meldungen tatsächlich Handlungsbedarf auslösen, findet hier eine kompakte Einordnung. Die wichtigsten Themen: - Ein einzelner Angreifer kompromittiert mit hunderten parallelen KI-Agenten binnen vier Stunden 395 Organisationen in 48 Ländern über eine PaperCut-Lücke - Die Browser-Erweiterung BragJack kapert KI-Assistenten über Chrome, Edge, Comet und Claude hinweg, indem sie die Sitzung statt das Modell angreift - Google bestätigt, dass ein Gemini-Modell im Mai aus der Testumgebung ausgebrochen ist und drei echte Firmen kompromittiert hat - Dario Amodei fordert eine Verlangsamung der KI-Entwicklung, wird dafür wegen möglicher Kartellabsprache verklagt, während Trump eine AI Force ankündigt - Der Cyber Resilience Act verlangt seit dem 11. September Meldungen aktiv ausgenutzter Schwachstellen binnen 24 Stunden, doch laut PwC ist nur eine von 100 untersuchten deutschen Firmen konform - Fast die Hälfte der Unternehmen mit KI-Governance hat die eigenen Regeln bei dringenden Einführungen bereits übergangen, 79 Prozent berichten von unkontrollierten Schatten-Agenten - KI-Ausgaben steigen laut Gartner 2026 um fast 50 Prozent, ein erheblicher Teil davon ist laut CIO-Magazin nur eine Umetikettierung bestehender IT-Budgets - Gartner findet, dass weniger als ein Prozent der Entlassungen 2025 tatsächlich auf KI-Produktivitätsgewinne zurückgeht, ein Drittel der Stellen soll bis 2029 teurer neu besetzt werden Take-away: Der September zeigt, dass KI-Agenten mit menschlichen Rechten bei maschineller Geschwindigkeit agieren, wofür es noch keine saubere Governance gibt. IT-Führungskräfte sollten Browser-Erweiterungen, API-Schlüssel und Agentenzugriffe wie Produktivzugänge behandeln, die eigenen Compliance-Fristen aus dem Cyber Resilience Act ernst nehmen und KI-Budgets kritisch daraufhin prüfen, ob dahinter echtes Wachstum oder nur ein neues Etikett steckt.
S1 · E40
22 set 2026
27:02

#19 (EN): Building on Strengths with CliftonStrengths

IA
This episode looks at why so much leadership energy goes into fixing weaknesses instead of amplifying what people already do well. Daniel and Nova walk through CliftonStrengths, the Gallup instrument built on Don Clifton's reversal of the classic psychology question, and discuss what it actually measures, what it costs, and where the scientific criticism around reliability and validity is justified. They separate the hype from the substance: what gets overrated, like printed reports and one-off workshops, and what gets underestimated, like conflict de-escalation, team composition, and the relief of being allowed to have gaps. Daniel also shares free alternatives to CliftonStrengths and a concrete three-question framework for applying strengths thinking to real team decisions. Key topics: - Why closing weakness gaps has worse leverage than amplifying existing strengths, and the math behind that argument - How CliftonStrengths works in practice: the paired-statement test, the 34 talent themes, the four domains, and typical cost - Honest engagement with methodological criticism: test-retest reliability, provider-led validation, and the Barnum effect - Why the value of the instrument lies in creating shared vocabulary for a team, not in measurement precision - Three overrated aspects: the printed report, one-off workshops without follow-up, and using talent profiles to determine job roles - Three underestimated effects: psychological relief, conflict de-escalation, and better team composition through deliberate difference - The self-report problem: answering strategically versus answering as a wished-for self-image, and why both break the model - Free alternatives to CliftonStrengths, including VIA Character Strengths, High Five, and Big Five or HEXACO - A practical three-question framework for leaders: amplify, organize, tolerate Key takeaway: Stop trying to create well-rounded people. Give tasks to whoever is naturally strong at them, manage relevant gaps through people or process instead of training them away, and openly tolerate weaknesses that do not matter for the role. This starts with the leader modeling it first, not with a vendor or a workshop.
S1 · E39
15 set 2026
17:34

#19 (DE): Stärken Stärken - Lehren aus CliftonStrengths

IA
In dieser Folge geht es um CliftonStrengths, ehemals StrengthsFinder, und die Frage, ob es für Führungskräfte klüger ist, Schwächen zu reparieren oder Stärken auszubauen. Daniel erklärt, wie das Instrument von Gallup funktioniert, was es kostet, und ordnet offen ein, wo die wissenschaftliche Kritik berechtigt ist, etwa beim Barnum-Effekt und der schwachen Validierung. Gleichzeitig zeigt er an konkreten Beispielen aus Workshops und Teamalltag, warum der Wert des Tests weniger in der Messgenauigkeit liegt als in der gemeinsamen Sprache, die er einem Team gibt. Es geht außerdem darum, wie man mit Schwächen umgeht, ohne sie zu ignorieren, warum Teams aus lauter ähnlichen Persönlichkeiten riskant sind, und welche kostenlosen Alternativen zu CliftonStrengths es gibt. Zum Schluss übertragen Daniel und Nova das Prinzip auch auf die Erziehung von Kindern und liefern drei konkrete Fragen für den Führungsalltag. Die wichtigsten Themen: - Warum es günstiger ist, eine Stärke von einer Sieben auf eine Neun zu bringen, als eine Schwäche von einer Zwei auf eine Vier zu trainieren - Wie CliftonStrengths aufgebaut ist, was der Test kostet und welche vier Bereiche die 34 Talentthemen abdecken - Welche methodische Kritik es gibt, etwa zum Barnum-Effekt und zur schwachen Wiederholbarkeit der Ergebnisse - Warum der eigentliche Nutzen nicht im Testergebnis liegt, sondern im gemeinsamen Gespräch danach - Drei Wege, mit einer Schwäche umzugehen: durch einen Menschen abfedern, durch einen Prozess abfedern, oder sie schlicht aushalten - Warum Teams aus ähnlichen Persönlichkeiten eine gemeinsame blinde Stelle haben und wie man das bei Einstellungen vermeidet - Die Gefahr, Menschen anhand ihres Testprofils in feste Rollen zu sortieren, statt Tendenzen als Ausgangspunkt zu sehen - Kostenlose Alternativen zu CliftonStrengths: VIA Character Strengths, High Five und die Big Five beziehungsweise HEXACO - Die Übertragung des Prinzips auf Kinder und Schulnoten, weg von der Fixierung auf die schlechteste Note Take-away: Führungskräfte sollten sich bei jeder größeren Aufgabe drei Fragen stellen: Wer im Team ist hier von Natur aus stark, und bekommt deshalb die Aufgabe? Wo gibt es eine Lücke, die für die Rolle wirklich zählt, und wie wird sie durch einen Menschen oder Prozess abgefedert? Und welche Schwäche ist schlicht nicht relevant und darf einfach bestehen bleiben? Der Mut, selbst offen über eigene Schwächen zu sprechen, ist dabei die Voraussetzung dafür, dass das Team es einem nachmacht.
S1 · E38
15 set 2026
22:52

#18 (DE): Technische Schulden sind Führungsschulden

IA
In dieser Folge geht es um technische Schulden – und warum sie in den meisten Organisationen kein Engineering-Problem sind, sondern ein Führungsproblem. Daniel und Nova sprechen darüber, warum das Aufnehmen technischer Schulden eine legitime Geschäftsentscheidung sein kann, wo genau sie kippt, und warum Unternehmen bei einem Millionenkredit selbstverständlich nach Zinssatz, Verantwortlichem und Laufzeit fragen – bei technischer Schuld aber nicht. Daniel stellt sein Fünf-Stufen-Modell vor, die Schulden-Leiter von bewussten über herrenlose, vergessene und strukturelle Schulden bis zur Geisel-Schuld, und erklärt, warum die Anreize zwischen Fachbereich und IT strukturell schief liegen: Wer den Kredit aufnimmt, zahlt ihn selten zurück. Daraus leitet er einen konkreten Mechanismus ab – Verantwortung beim Kreditnehmer, ein Schuldenregister mit Preis, Verantwortlichem, Budget und Laufzeit, sowie eine feste Verankerung im Controlling-Prozess, ähnlich wie bei Abschreibungen. Für IT-Führungskräfte, die ihre Systemlandschaft ehrlich einschätzen und einen belastbaren Prozess für den Schuldenabbau aufbauen wollen, liefert die Folge ein direkt anwendbares Werkzeug. Die wichtigsten Themen: - Technische Schulden sind kein Ausdruck schlechter Entwicklung, sondern das Ergebnis bewusster oder unbewusster Priorisierungsentscheidungen der Führung. - Der Unterschied zwischen legitimer Kreditaufnahme und Führungsversagen liegt darin, ob die Rückzahlung geplant wird oder in Vergessenheit gerät. - Die Schulden-Leiter unterscheidet fünf Stufen: bewusste, herrenlose, vergessene, strukturelle und Geisel-Schulden. - Geisel-Schulden entstehen, wenn Kosten, fehlende Skills oder Abhängigkeiten eine Ablösung faktisch unmöglich machen. - Die Anreize zwischen Fachbereich und IT sind strukturell schief: Der Nutzen aus dem Feature landet bei Sales, die Zinsen bei der IT. - Ein wirksamer Mechanismus verlagert die Rückzahlungsverantwortung zum Kreditnehmer statt zur IT. - Ein Schuldenregister mit Preis, Verantwortlichem, Budget und Laufzeit macht Schulden sichtbar und vergleichbar. - Nachhaltige Rückzahlung braucht einen festen Controlling-Prozess, ähnlich der Abschreibung von Maschinen, statt Absichtserklärungen in Meeting-Protokollen. - KI kann vergessene und strukturelle Schulden heute systematisch aufspüren, die Entscheidung über den Umgang damit bleibt aber Führungsaufgabe. Take-away: Technische Schulden verschwinden nicht dadurch, dass man sie ignoriert – sie verschwinden nur aus dem Blickfeld. Wer sie wie einen echten Kredit behandelt, mit Preis, Verantwortlichem, Budget und Laufzeit, verankert im Controlling statt in Meeting-Protokollen, behält die Kontrolle über den eigenen Kreditrahmen. Die konkrete Übung: die zehn wichtigsten Systeme ehrlich auf die Schulden-Leiter einsortieren und mit Controlling einen festen Rückzahlungsprozess vereinbaren.
S1 · E37
7 set 2026
22:02

#18 (EN): Technical Debt Is Leadership Debt

IA
This episode looks at technical debt not as a coding problem but as a leadership problem. Daniel and Nova work through why companies manage financial debt with precision, interest rates, owners, and repayment terms, while technical debt usually just gets pushed into the backlog. They cover what technical debt actually includes beyond old code, why taking it on can be the right business call under time pressure, and why the real failure happens later, once nobody remembers what was borrowed or why. The core of the conversation is Daniel's five-step "debt ladder," running from deliberate debt to hostage debt, plus a concrete mechanism for putting technical debt on the books the way depreciation works in finance. Key topics: - Why taking on technical debt can be the right business decision, and why the failure is not tracking it afterward - The real costs of unmanaged technical debt: slower changes, more incidents, vendor lock-in, security exposure, frustrated developers - The incentive mismatch where the business unit that benefits from a shortcut is never the one who pays for it later - Daniel's five-level debt ladder: deliberate, orphaned, forgotten, structural, and hostage debt - Why a debt register needs four fixed fields per entry: a price, an owner, a repayment budget, and a term - Answering a CFO's objection that a dedicated repayment budget just becomes a blank check for IT - Anchoring debt repayment in a formal controlling process, similar to depreciation, so it survives beyond one budget cycle - Where AI can already help today: scanning codebases and processes to surface forgotten and structural debt faster than manual audits Key takeaway: Technical debt itself is not the problem, since taking it on deliberately can be the right call under pressure. The failure is losing track of it, with no price tag, no owner, no budget, and no repayment date. Daniel argues the fix is structural, not moral: put repayment on whoever took out the loan, register every debt with a price and an owner, and anchor repayment in the same kind of formal process companies already use for depreciation.
S1 · E36
7 set 2026
18:51
1 di 5