Technische Schulden managen: Ein Leitfaden für nicht-technische Gründer:innen

"Wir müssten das eigentlich mal aufräumen." Diesen Satz hört man in fast jedem Engineering-Team, meist gefolgt von einem Achselzucken, weil gerade wieder ein Feature wichtiger erscheint. Gemeint sind damit technische Schulden: Abkürzungen im Code oder in der Architektur, die kurzfristig Zeit sparen, langfristig aber Zinsen kosten. Diese Zinsen zahlst du in Form von langsamerer Entwicklung, mehr Fehlern und frustrierten Entwickler:innen. Für nicht-technische Gründer:innen ist das Konzept oft schwer greifbar, weil es sich in keiner Bilanz zeigt. Irgendwann bremst es aber sehr real das Wachstum. Dieser Leitfaden erklärt, wie du technische Schulden managst, ohne selbst Code lesen zu müssen.

Was technische Schulden wirklich sind

Der Begriff stammt ursprünglich aus der Softwareentwicklung und beschreibt eine Analogie zu finanziellen Schulden: Man "leiht" sich Zeit, indem man eine schnelle, aber nicht ideale Lösung wählt, und "zahlt Zinsen" in Form von zusätzlichem Aufwand bei jeder späteren Änderung. Ein hilfreiches Modell dafür ist das von Martin Fowler geprägte Konzept des Technical Debt Quadrant. Es unterscheidet technische Schulden entlang zweier Achsen: bewusst versus unbewusst eingegangen, und umsichtig versus unüberlegt.

Daraus ergeben sich vier Kategorien:

• Umsichtig und bewusst: Das Team entscheidet sich aktiv für eine schnelle Lösung, weiß um die Konsequenzen und plant die spätere Korrektur ein. Das ist legitim und in vielen Fällen sogar die richtige Entscheidung.
• Umsichtig und unbewusst: Das Team trifft mit dem damaligen Wissensstand eine vernünftige Entscheidung, die sich im Nachhinein als suboptimal herausstellt. Das ist laut Fowler keine schlechte Entscheidung, sondern schlicht die Konsequenz von Lernen und wachsender Erfahrung.
• Unüberlegt und bewusst: Gute Praktiken werden ignoriert, obwohl man es besser wüsste, oft wegen unrealistischer Deadlines. Das ist die problematischste Form, weil sie vermeidbar gewesen wäre.
• Unüberlegt und unbewusst: Schulden entstehen durch fehlendes Wissen oder Erfahrung im Team, ohne dass jemand die Konsequenzen absehen konnte.

Für dich als Gründer:in ist diese Unterscheidung wichtig, weil sie zeigt: Nicht jede technische Schuld ist ein Fehler des Teams. Die entscheidende Frage ist nicht "Gibt es technische Schulden?", denn die gibt es immer. Die entscheidende Frage lautet: "Wissen wir, welche wir haben, und haben wir sie bewusst in Kauf genommen?"

Warum technische Schulden für Gründer:innen relevant sind

Technische Schulden zeigen sich nicht in deiner Finanzplanung, aber sie wirken sich direkt auf dein Geschäft aus: Features dauern länger als geplant, neue Entwickler:innen brauchen ungewöhnlich lange, um produktiv zu werden, und kleine Änderungen verursachen unerwartet oft neue Fehler. Wenn ein Investor oder eine Investorin im Rahmen einer Due-Diligence-Prüfung technische Schulden entdeckt, die niemand im Unternehmen benennen kann, wirkt das wie ein Warnsignal. Nicht, weil Schulden per se schlecht sind, sondern weil fehlendes Bewusstsein dafür auf mangelnde technische Führung hindeutet.

Wie du technische Schulden sichtbar machst, ohne Code zu lesen

Du musst nicht programmieren können, um technische Schulden zu managen. Du brauchst aber ein Vokabular und einen Prozess, um sie mit deinem Team zu besprechen:

• Frag regelmäßig nach einer "Schuldenliste". Bitte dein Engineering-Team, bekannte Problemstellen zu dokumentieren, auch wenn diese aktuell nicht bearbeitet werden. Allein die Existenz einer solchen Liste ist ein gutes Zeichen.
• Lass dir den Aufwand in Geschäftssprache übersetzen. Statt "der Legacy-Code im Zahlungsmodul ist unübersichtlich" sollte die Aussage lauten: "Jede Änderung an der Zahlungsabwicklung dauert doppelt so lange und birgt ein erhöhtes Fehlerrisiko."
• Etabliere einen festen Anteil der Kapazität für Wartung. Viele erfahrene Engineering-Führungskräfte reservieren einen wiederkehrenden Anteil der Entwicklungszeit, oft irgendwo zwischen einem Zehntel und einem Fünftel, für Aufräumarbeiten, statt technische Schulden ausschließlich in Krisensituationen zu adressieren.
• Beobachte die Geschwindigkeit, nicht nur die Fehler. Ein verlässliches Warnsignal ist, wenn ähnliche Features im Zeitverlauf immer länger dauern, obwohl das Team nicht kleiner geworden ist.

Ein Beispiel aus der Praxis

Nehmen wir als Beispiel ein Startup, das im ersten Jahr aus Zeitdruck alle Kundendaten in einer einzigen, wachsenden Datenbanktabelle ohne klare Struktur speichert. Das war zu Beginn eine vertretbare, umsichtige Entscheidung, denn schnelles Launchen war wichtiger als eine saubere Datenarchitektur. Zwei Jahre später verlangsamt genau diese Struktur jede neue Funktion, weil Entwickler:innen erst verstehen müssen, wie Daten zusammenhängen, bevor sie etwas ändern können. Der Fehler liegt nicht in der ursprünglichen Entscheidung, sondern darin, dass niemand sie im Nachhinein bewusst überprüft und angepasst hat.

Wann sich Aufräumen wirklich lohnt

Nicht jede technische Schuld muss beglichen werden. Manche "Kredite" laufen einfach unproblematisch weiter, weil der betroffene Teil des Systems selten verändert wird. Priorisiere stattdessen nach zwei Kriterien: Wie oft wird dieser Teil des Systems verändert, und wie stark bremst er das Team bei dieser Veränderung? Häufig geänderte, stark bremsende Bereiche haben Vorrang. Seltene, isolierte Problemstellen können oft liegen bleiben, ohne dass es dem Unternehmen schadet.

Ein einfaches Ritual, das sich in der Praxis bewährt

Viele Teams, die technische Schulden erfolgreich managen, nutzen dafür keine komplizierte Software, sondern ein einfaches, wiederkehrendes Ritual: In festen Abständen, etwa einmal im Quartal, setzt sich das Engineering-Team zusammen und aktualisiert die Liste bekannter technischer Schulden gemeinsam mit einer groben Einschätzung, wie stark jede einzelne Position das Team aktuell bremst. Als Gründer:in musst du an diesem Termin nicht zwingend selbst teilnehmen, solltest dir aber die drei bis fünf wichtigsten Punkte danach kurz zusammenfassen lassen. Diese Gewohnheit allein verhindert bereits einen Großteil der bösen Überraschungen, die sonst erst bei einer Investoren-Due-Diligence oder einem größeren Ausfall sichtbar werden.

Die Rolle von Zweitmeinungen

Als nicht-technische:r Gründer:in stehst du vor einem strukturellen Problem: Du bist darauf angewiesen, dass dein Team dir ehrlich sagt, wie es um die technische Substanz deines Produkts steht, hast aber keine unabhängige Möglichkeit, das zu überprüfen. Genau das ist ein Bereich, in dem sich eine externe, erfahrene Perspektive auszahlt: eine Zweitmeinung, die weder am Code noch am Tagesgeschäft hängt und deshalb offen benennen kann, wo tatsächlicher Handlungsbedarf besteht und wo nicht.

Wenn du unsicher bist, wie es um die technischen Schulden in deinem Unternehmen steht, oder eine unabhängige Einschätzung deines Teams dazu einholen möchtest: Im Rahmen des Founder & CTO Sparring bringe ich genau diese externe, erfahrene Perspektive ein. Vereinbare gerne ein unverbindliches Kennenlerngespräch.