"Wir brauchen Zeit für Refactoring" – dieser Satz landet in vielen Führungsrunden ungefähr so gut wie "Wir brauchen Zeit, um die Küche aufzuräumen" auf einer Dinnerparty. Alle nicken kurz, niemand macht etwas, und beim nächsten Meeting ist das Thema wieder weg. Das Problem ist nicht das Argument. Das Problem ist, dass man in einer Sprache spricht, die das Gegenüber zwar hört, aber nicht versteht.

Warum technische Argumente nicht ankommen

Nicht-technische Entscheider denken nicht in Klassen, Abhängigkeiten oder zyklomatischer Komplexität. Sie denken in Risiken, Kosten und Chancen. Wer über schlechten Code spricht, ohne diese Übersetzungsarbeit zu leisten, verliert das Gespräch – nicht weil das Gegenüber unwillig ist, sondern weil die Brücke fehlt. Man könnte genauso gut auf Finnisch über Architekturmuster sprechen.

Die Übersetzung: Technik in Geschäftsrisiken

Jedes technische Problem hat eine wirtschaftliche Entsprechung. Die Aufgabe ist, sie sichtbar zu machen:

  • Langsame Entwicklung: "Ein neues Feature dauert bei uns durchschnittlich drei Wochen. In einem vergleichbaren System ohne unsere technischen Schulden wären es drei Tage. Das kostet uns pro Feature etwa X Entwicklertage."
  • Häufige Bugs: "Wir haben in diesem Quartal N Incidents gehabt, die auf Code in Modul X zurückzuführen sind. Jeder Incident kostet uns durchschnittlich Y Stunden Behebungsaufwand plus Reputationsrisiko beim Kunden."
  • Schwieriges Onboarding: "Neue Entwickler brauchen bei uns sechs Monate, bis sie produktiv eigenständig liefern können. Branchenüblich sind sechs Wochen."

Investition statt Kosten

Refactoring als Kostenstelle zu kommunizieren ist ein Fehler. Die richtige Rahmung ist Investition mit messbarem ROI: "Wenn wir jetzt X investieren, reduzieren wir unsere Entwicklungszeit um Y% – das bedeutet, wir liefern ab dann Z Features mehr pro Quartal." Plötzlich klingt es nicht mehr nach Küche aufräumen, sondern nach einem vernünftigen Geschäftsvorschlag.

Konkrete Zahlen sind hier entscheidend. Schätzungen, die auf Beobachtungen basieren, sind glaubwürdiger als abstrakte Versprechen.

Der richtige Zeitpunkt

Das Gespräch über technische Schulden führt man am besten nicht dann, wenn der nächste Incident gerade aufgetreten ist. Dann ist die Stimmung reaktiv, die Diskussion emotional, und Entscheidungen werden aus Panik getroffen statt aus Überzeugung. Besser: Im Rahmen einer regelmäßigen Retrospektive oder einer Quartalsplanung – mit vorbereiteten Zahlen, ruhig und lösungsorientiert.

Wer technische Schulden als Geschäftsrisiko kommuniziert, bekommt kein Mitleid – er bekommt Budget.

Fazit

Die Fähigkeit, technische Komplexität in wirtschaftliche Sprache zu übersetzen, ist eine Kernkompetenz für jeden, der Modernisierung vorantreiben will. Sie erfordert Vorbereitung, Zahlen und die Bereitschaft, das eigene Framing zu verlassen. Wer das beherrscht, gewinnt nicht nur Budgets – er gewinnt Verbündete. Und manchmal sogar das nächste Quartal.