Technische Schulden

Die langsame Todesspirale

Technische Schulden killen Unternehmen nicht über Nacht. Sie ersticken sie langsam.

Am Anfang dauern Dinge nur etwas länger. Ein Feature, das zwei Tage dauern sollte, braucht eine Woche. Dann zwei Wochen. Dann einen Monat. Entwickler fangen an, sich über “die Codebase” zu beschweren. Die Besten updaten still ihre LinkedIn-Profile.

Der CEO fragt, warum alles so lange dauert. Du - ich! - hast keine gute Antwort - oder besser gesagt, du hast eine Antwort, die wie eine Ausrede klingt. “Wir haben technische Schulden.” Seine Augen werden glasig. Er hört: “Engineering will Fun-Stuff machen statt Features zu shippen.” oder “Engineering weiss nicht, was sie machen.”

Währenddessen wachsen die Schulden. Jede Abkürzung, die Entwickler nehmen, um heute zu überleben, macht die Arbeit von morgen schwerer. Jeder Patch fügt Komplexität hinzu. Das Team verbringt mehr Zeit mit Workarounds als mit echter Entwicklung. Und der Druck für einen Rewrite wächst - obwohl du weißt, dass Rewrites meistens scheitern.

Wie du hier gelandet bist

Technische Schulden häufen sich auf vorhersehbare Weise an:

• Speed-Druck in den frühen Tagen: Musste schnell shippen, also wurden Ecken abgeschnitten um zu überleben. Niemand ist zurückgegangen um aufzuräumen.
• Wachstum ohne Refactoring: Architektur für 10.000 User konnte 100.000 nicht handlen. Features wurden als Quick Fixes hinzugefügt. Entwickler warteten auf den großen Rewrite statt kontinuierlicher Verbesserungen.
• Falsche Annahmen: Engineering hat falsch geraten, was sich leicht ändern lassen muss. Technologie passte nicht immer zu den Business-Anforderungen.
• Geerbtes Chaos: Frühere Leader oder externe Teams haben Entscheidungen getroffen, die jetzt deine sind. Der Code hat das Unternehmen so weit gebracht, aber jetzt ist es dein Problem.
• Wissensverlust: Die ursprünglichen Engineers sind gegangen und haben Tribal Knowledge mitgenommen. Dokumentation fehlte oder wurde nie gemacht. Keine ordentliche Übergabe.

Spielt es eine Rolle, wie du hier gelandet bist? Nicht wirklich. Du bist hier. Die Frage ist, was du dagegen tust.

Die Rewrite-Falle

Wenn die Schulden schlimm genug sind, schlägt immer jemand einen Rewrite vor. Meistens ein Senior Engineer. Manchmal der CTO selbst. Das Argument ist verführerisch: “Die Codebase ist nicht mehr zu retten. Wir müssen von vorne anfangen. Dann wird alles gut.”

Ich habe diesen Film schon oft gesehen. Wenn du wirklich einen großen Turnaround brauchst, muss er strategisch geplant sein. Der Rewrite dauert doppelt so lange wie geplant. Feature Parity ist schwerer als erwartet. Features werden zum alten Code hinzugefügt, die auch zur neuen Codebase hinzugefügt werden müssen. Das Ziel bewegt sich die ganze Zeit. PLUS das Business kann nicht stoppen, also wartest du zwei Systeme. Die neue Codebase fängt an, eigene Schulden anzuhäufen wegen Zeitdruck. Zwei Jahre später bist du da, wo du angefangen hast - oder schlimmer.

Rewrites können funktionieren. Aber die meisten tun es nicht. Und die CTOs, die Rewrites pushen ohne zu verstehen warum sie meistens scheitern, bereiten sich auf karrierebeendende Desaster vor. Wenn der Rewrite nicht neue Features in der halben Zeit oder mit doppelter Geschwindigkeit liefert, merkt es keiner. Und du hast zu viel versprochen, also wird niemand glücklich sein.

Die Alternative - inkrementelles Refactoring während du Features shippst - ist schwerer zu verkaufen aber wahrscheinlicher erfolgreich. Es braucht Disziplin, Priorisierung, Willenskraft und die Fähigkeit, den Business Case für das Abzahlen von Schulden zu machen. Das ist eine der wichtigsten strategischen Entscheidungen, die du treffen wirst.

Den Business Case machen

Hier scheitern die meisten CTOs: sie können technische Schulden nicht in Business-Sprache übersetzen.

“Wir müssen das Authentication-Modul refactoren” bedeutet dem CEO nichts. “Wir verbringen 30% der Engineering-Zeit damit, Probleme in unserem Login-System zu umgehen, und es hat dieses Quartal zwei Ausfälle verursacht” - das versteht er. Argumentiere immer in seiner Welt und seinem Glaubenssystem.

Technische Schulden haben messbare Kosten:

Velocity-Verlust

Tracke, wie lange ähnliche Features jetzt brauchen vs. vor einem Jahr. Tracke die Zeit von Idee bis das Feature Geld verdient. Zeig die Trendlinie. Sie ist meistens hässlich.

Incident-Häufigkeit

Schulden verursachen Ausfälle. Ausfälle kosten Geld und Reputation. Verbinde die Punkte.

Bug-Rate

Bugs sind teuer. Mit technischen Schulden werden sie mehr - sie sind leichter zu erzeugen und schwerer zu fixen.

Hiring und Retention

Gute Engineers wollen nicht lange in einem Chaos arbeiten. Wenn sie das Vertrauen ins Unternehmen verlieren, gehen sie. Wenn du Leute verlierst oder nicht einstellen kannst, sind Schulden ein Faktor.

Opportunity Cost

Jede Stunde für Workarounds ist eine Stunde, die nicht für Revenue-treibende Features ausgegeben wird.

Wenn du Zahlen drauf hast, wird “technische Schulden” plötzlich ein Business-Problem, kein Engineering-Hobby. Geheimnis: Viele Probleme, die CTOs für technische Probleme halten, sind eigentlich Business-Probleme. Lass das Business wissen und entscheiden (der CEO - das macht ihn auch glücklicher).

Was wirklich funktioniert

Ich habe CTOs in mehreren Unternehmen geholfen, aus Schulden rauszukommen. Der Ansatz, der funktioniert:

Gnadenlose Triage ist essentiell beim Angehen von technischen Schulden. Nicht alle Schulden haben den gleichen Impact - manche Teile deiner Codebase sind vielleicht hässlich aber relativ harmlos, während andere Teile aktiv die Produktivität deines Teams ruinieren oder Feuer verursachen. Fokussiere deine Anstrengungen auf die Schulden, die wirklich deine Delivery verletzen oder Risiken erzeugen, nicht nur auf den Code, der Engineers nervt.

Zu versuchen, magische “20% Zeit für Refactoring” rauszuschneiden funktioniert in der Realität fast nie. Der bessere Ansatz ist, Schulden anzugehen während du arbeitest: wenn ein neues Feature das Payment-System berührt, nutze die Gelegenheit um die Retry-Logik zu fixen während du sowieso in der Codebase bist. Diese inkrementellen Verbesserungen können sich schnell summieren und brauchen kein separates, unternehmensweites Mandat oder langwierige Genehmigungsprozesse.

Sichtbarkeit ist auch wichtig. Du brauchst kein fancy Dashboard oder komplexe Static-Analysis-Tools. Stattdessen führe eine einfache, geteilte Liste der bekannten Debt-Items und - am wichtigsten - ihren Business-Impact. Reviewe diese Liste regelmäßig mit dem Team und der Führung, und feiere jedes Mal wenn etwas Wichtiges geschlossen wird.

Am wichtigsten aber ist, aufzuhören neue Schulden zu machen. Das ist oft noch schwerer als abzuzahlen was du schon hast. Es bedeutet die Bar für Code Reviews zu heben, unrealistische Timelines herauszufordern, und bewusste Architektur-Entscheidungen zu treffen. Wenn neue Schulden schneller dazukommen als du abzahlst, wirst du den Kreislauf nie durchbrechen.

Die Politik der Schulden

Technische Schulden sind emotional. Sie sind mit Schuldzuweisungen, Frustration und Angst verbunden.

Die Engineers, die die Schulden erzeugt haben (falls sie noch da sind), fühlen sich defensiv. Die Engineers, die sie geerbt haben, fühlen sich verärgert. Der CEO ist frustriert, dass Engineering immer meckert statt zu shippen. Der CTO fühlt sich in der Mitte gefangen.

Das zu navigieren braucht mehr als technisches Können. Du musst das Gespräch entpersonalisieren. Die Schulden sind niemandes Schuld - oder besser, sie sind aller Schuld, was das Gleiche ist. Was zählt ist sie zu fixen, nicht Schuld zuzuweisen.

Du brauchst auch Verbündete. Ein CFO, der die Kosten von technischen Schulden versteht, wird ein mächtiger Fürsprecher. Ein Product Leader, der sieht wie Schulden Feature-Delivery verlangsamen, kann helfen Paydown-Arbeit zu priorisieren. Baue diese Beziehungen auf bevor du sie brauchst.

Technische Schulden sind eines der einsamsten Probleme, mit denen ein CTO konfrontiert ist. Du kannst es dem CEO nicht vollständig erklären. Deine Engineers sind frustriert und schauen zu dir für Antworten. Das Board sieht nur, dass Features zu lange dauern.

Was hilft ist jemand, der das durchgemacht hat - der in mehreren Unternehmen aus Schulden rausgegraben hat und weiß was funktioniert. Jemand, der dir helfen kann den Business Case zu machen, gnadenlos zu priorisieren und einen realistischen Paydown-Plan zu erstellen. Jemand, der die Politik genauso versteht wie die technischen Lösungen.

Ich habe CTOs in mehreren Unternehmen geholfen, aus technischen Schulden rauszukommen - den Case beim Leadership zu machen, zu priorisieren was zu fixen ist, und nachhaltige Praktiken aufzubauen. Wenn deine Velocity stirbt und du nicht weißt wie du rauskommen sollst - lass uns reden.

Mehr über CTO Coaching