Die Zahl, Die Ihr CFO Nicht Sieht
Ihr Engineering-Team kostet €500.000 pro Jahr. Das sind fünf Senior-Entwickler zu je €100K, voll eingerechnet. Ihr CFO sieht diese Zahl, genehmigt sie und geht weiter.
Aber hier ist, was nicht in der GuV auftaucht: Technische Schulden kosten Sie weitere €200.000–€400.000 pro Jahr an verlorener Geschwindigkeit.
Das ist keine zukünftige Verbindlichkeit. Das ist Geld, das Sie jetzt verbrennen, jeden Sprint, in der Lücke zwischen dem, was Ihr Team in einer sauberen Codebasis liefern könnte, und dem, was sie tatsächlich liefern, während sie Legacy-Systeme navigieren, fragile Tests und architektonische Entscheidungen, die vor drei Jahren von Leuten getroffen wurden, die nicht mehr dort arbeiten.
Nennen Sie es die Geschwindigkeitssteuer — und es ist der größte Posten in Ihrem Engineering-Budget, den niemand verfolgt.
Wie Geschwindigkeitsverlust Tatsächlich Aussieht
Technische Schulden kündigen sich nicht an. Sie zeigen sich als:
- Längere Schätzfenster. Ein Feature, das 3 Tage dauern sollte, wird auf 2 Wochen geschätzt, weil "wir zuerst das Zahlungsmodul refactoren müssen."
- Scope-Kürzungen mitten im Sprint. Sie haben fünf Features geplant; Sie haben zwei ausgeliefert, und der Rest wurde verschoben, weil "die Integration komplexer war als gedacht."
- Context-Switching-Overhead. Entwickler verbringen 40% ihrer Zeit damit zu verstehen, warum der Code so funktioniert, anstatt neue Funktionalität zu bauen.
- Bug-Schwärme nach Releases. Jedes Deployment bringt drei neue Probleme hervor, weil niemand sicher ist, dass die Test-Suite tatsächlich Edge-Cases abdeckt.
Nichts davon erscheint als "technische Schulden" in Ihrem Budget. Es erscheint als Opportunitätskosten — Features, die Sie nicht ausgeliefert haben, Kunden, die Sie nicht ongeboardet haben, Umsatz, den Sie nicht abgeschlossen haben.
Die Geschwindigkeitssteuer-Formel
Lassen Sie uns das in Zahlen fassen. Angenommen, Ihr Engineering-Team könnte mit 100% Geschwindigkeit in einer Greenfield-Codebasis mit moderner Architektur und solider Test-Abdeckung arbeiten. In Wirklichkeit liefern typische Teams folgendes:
| Codebasis-Gesundheit | Effektive Geschwindigkeit | Geschwindigkeitssteuer |
|---|---|---|
| Sauberer, moderner Stack | 90–100% | 0–10% |
| Moderate technische Schulden | 60–75% | 25–40% |
| Schwere Legacy-Last | 40–50% | 50–60% |
| Krisenmodus | 20–30% | 70–80% |
Übersetzung in Euro:
Wenn Ihr Team €500K/Jahr kostet und mit 60% Geschwindigkeit aufgrund moderater technischer Schulden arbeitet, zahlen Sie effektiv €200K für Output, den Sie nicht bekommen. Das ist die Geschwindigkeitssteuer.
Skalieren Sie das auf eine 15-Personen-Engineering-Organisation (€1,5M/Jahr), und moderate technische Schulden kosten Sie €600K jährlich — mehr als vier Gehälter von Senior-Entwicklern.
Warum Das Sich Im Laufe Der Zeit Verstärkt
Die Geschwindigkeitssteuer bleibt nicht konstant — sie beschleunigt sich. Deshalb:
1. Schulden sammeln Zinsen
Jedes Feature, das auf wackeligen Fundamenten gebaut wird, erbt diese Instabilität. Ein Zahlungsmodul, das 2021 gebaut wurde und "gut funktioniert", wird 2026 zur tragenden Wand — und jetzt können Sie es nicht refactoren, ohne den gesamten Checkout-Ablauf zu riskieren.
2. Team-Wissen verfällt
Die Ingenieure, die das ursprüngliche System gebaut haben, gehen. Die neuen Mitarbeiter erben Code ohne Dokumentation, implizite Annahmen und in Stored Procedures vergrabene Geschäftslogik. Die Geschwindigkeit sinkt weiter, weil niemand sicher ist, etwas anzufassen.
3. Onboarding wird schwieriger
Ein neuer Entwickler, der zu einer sauberen Codebasis kommt, trägt in Woche 2 bedeutungsvoll bei. Ein neuer Entwickler, der zu einer Legacy-Codebasis kommt, verbringt 8 Wochen nur damit zu lernen, was er nicht anfassen soll. Ihre effektive Teamgröße schrumpft mit jeder Einstellung.
Das Ergebnis? Die Geschwindigkeitssteuer wächst von 25% auf 40% auf 60% über 3–5 Jahre — nicht weil Ihr Team schlechter wurde, sondern weil das System, in dem sie arbeiten, fragiler wurde.
Der Versteckte ROI von Neuanfängen
Hier ändern erweiterte Teams die Gleichung. Wenn Sie externe Entwickler für ein Greenfield-Projekt, eine Modernisierungsmaßnahme oder einen parallelen Rebuild hinzuziehen, fügen Sie nicht nur Headcount hinzu — Sie kaufen Geschwindigkeit zurück.
Hier ist die Mathematik:
- Szenario A: Fügen Sie 2 Entwickler zu Ihrem bestehenden Team hinzu (€200K/Jahr). Sie erben dieselbe 60% Geschwindigkeitssteuer. Effektiver Output: €120K.
- Szenario B: Holen Sie 2 erweiterte Entwickler, um ein Ersatzmodul isoliert zu bauen (€200K/Jahr). Keine Legacy-Last. Effektiver Output: €180K.
Gleiche Kosten, 50% mehr Output — weil sie die Geschwindigkeitssteuer nicht zahlen.
Noch besser: Sobald das neue Modul ausgeliefert wird und das Legacy-Modul ersetzt, verbessert sich die Geschwindigkeit Ihres gesamten Teams. Sie haben den Steuersatz von 40% auf 25% über das Board hinweg reduziert und damit zusätzliche €75K/Jahr an effektiver Kapazität freigeschaltet — permanent.
Wann Schulden Abbezahlen vs. Umgehen
Nicht alle technischen Schulden sollten refactored werden. Manchmal ist der ROI nicht da. So entscheiden Sie:
| Situation | Bester Ansatz |
|---|---|
| Kern-Produktbereich, hohe Änderungsfrequenz | Schulden abbezahlen. Geschwindigkeitssteuer verstärkt sich hier. |
| Stabiles Modul, selten berührt | In Ruhe lassen. Kein Geschwindigkeitseinfluss, wenn Sie nicht daran arbeiten. |
| Kritischer Pfad für neue Features | Parallelen Ersatz bauen (erweitertes Team isoliert). |
| Gesamte Plattform altert | Strangler-Fig-Pattern: neue Arbeit auf modernen Stack leiten, alten verhungern lassen. |
Die Schlüsselerkenntnis: Refactoring ist teuer, aber Nichtstun auch. Die Frage ist nicht, ob man technische Schulden angehen soll — sondern ob die Geschwindigkeit, die Sie freischalten, mehr wert ist als die Kosten der Behebung.
Die Bottom Line
Ihr Engineering-Budget besteht nicht nur aus Gehältern und Cloud-Kosten. Es ist auch die unsichtbare Steuer, die Sie jedes Mal zahlen, wenn Ihr Team langsamer arbeitet als es sollte, weil das System sie bei jeder Gelegenheit bekämpft.
Die meisten Unternehmen akzeptieren dies als Geschäftskosten. Aber die Mathematik ist klar: Eine 40% Geschwindigkeitssteuer auf eine €1M Engineering-Organisation ist ein €400K jährlicher Abfluss — genug, um ein ganzes paralleles Team zu finanzieren, das mit voller Geschwindigkeit auf einem modernen Stack arbeitet.
Die Unternehmen, die gewinnen, sind nicht die mit den größten Teams. Es sind die, die erkennen, wann das System zum Engpass geworden ist — und die die Disziplin haben, es zu umgehen, anstatt mehr Leute darauf zu werfen.
Stecken Sie fest in der Geschwindigkeitssteuer?
Division5 hilft Ihnen, Engineering-Kapazität zurückzukaufen durch Nearshore-erweiterte Teams, die isoliert von Ihren Legacy-Systemen arbeiten. Ob Sie ein Ersatzmodul bauen, Ihren Stack modernisieren oder skalieren, ohne technische Schulden zu erben — unsere Entwickler liefern vom ersten Tag an mit voller Geschwindigkeit.
Lassen Sie uns über die Freisetzung Ihrer Team-Geschwindigkeit sprechen
