Wie erklärst du Technical Debt einem nicht-technischen Publikum?

Question

Accepted Answer

**Ich übersetze Tech Debt in die Sprache, die das Publikum bereits nutzt: Geld, Geschwindigkeit und Risiko.** Ein nicht-technischer Stakeholder kümmert sich nicht um Coupling oder Test Coverage; er kümmert sich darum, dass Features langsamer und teurer in der Auslieferung werden. Also rahme ich Debt als finanzielles und Delivery-Problem, nicht als Code-Problem.

## Das Framing, das ich verwende

- **Die Finanzmetapher, vorsichtig eingesetzt.** „Wir haben eine Abkürzung genommen, um schnell auszuliefern, wie einen Kredit aufzunehmen. Es hat funktioniert, und jetzt zahlen wir jeden Sprint Zinsen darauf. Jedes neue Feature in diesem Bereich kostet wegen dieser Zinsen mehr." Das kommt an, weil jeder Schulden und Zinsen versteht.
- **Mach es mit ihren Metriken konkret.** Nicht „der Code ist unordentlich", sondern „dieses Feature hat drei Wochen gedauert; vor zwei Jahren brauchte dieselbe Größe eine Woche. Der Unterschied ist der Wartungs-Overhead, den wir angehäuft haben."
- **Verknüpfe es mit Ergebnissen, die ihnen wichtig sind.** Langsamere Auslieferung, mehr Bugs, die Kunden erreichen, schwierigeres Onboarding für neue Mitarbeiter, steigendes Risiko eines Ausfalls. Verbinde Debt mit Umsatz, Reputation und Roadmap-Geschwindigkeit.

## Wie ich daraus eine Entscheidung mache, keine Beschwerde

- Präsentiere es als **Trade-off mit Optionen**, nicht als Forderung: „Wir können weiter Features in der aktuellen, sich verlangsamenden Geschwindigkeit ausliefern, oder jetzt zwei Sprints investieren, um die künftigen Feature-Kosten um etwa ein Drittel zu senken."
- Quantifiziere, wo ich kann: pro Sprint verlorene Zeit, Incident-Häufigkeit, der Prozentsatz der Kapazität, der für Feuerwehreinsätze aufgewendet wird.
- Sei ehrlich, dass **manche Debt in Ordnung ist.** Nicht jede Debt sollte abbezahlt werden; der Punkt ist, die Debt abzubauen, die die Auslieferung aktiv besteuert.

## Fallstricke

- **Jargon verwenden** („refactoren", „Coupling", „die Architektur ist falsch"). Das lässt dich klingen, als wolltest du den Code vergolden.
- Es so rahmen, als wollten Entwickler sauberen Code um seiner selbst willen; das liest sich als selbstgefällig.
- Wolf rufen — alles als Debt zu bezeichnen untergräbt die Glaubwürdigkeit, wenn etwas wirklich Dringendes auftaucht.

## Warum es wichtig ist

Wenn du Tech Debt nicht in geschäftlichen Begriffen erklären kannst, wird sie nie finanziert, und das Team kommt langsam zum Stillstand, während die Führung sich fragt, warum die Velocity sinkt. Es als Kosten, Geschwindigkeit und Risiko zu rahmen ist das, was dir die Zeit verschafft, es zu beheben, bevor es zur Krise wird.