Technische Schulden reduzieren in IT-Organisationen: Manuel Gass (Jimdo)

Das Problem, das niemand laut ausspricht

Technische Schulden in der IT gelten als Infrastruktur-Problem – doch Führungskräfte großer Organisationen wissen: Es ist ein Strategie- und Führungsthema. Unzureichende Flexibilität führt zu kostspieligen Migrationsprojekten, die Jahre andauern. Intern lässt sich vieles kontrollieren. Externe Technologieveränderungen erfordern jedoch Agilität, die oft fehlt.

Technische Schulden reduzieren in der IT-Organisation klingt nach einem Infrastruktur-Thema. Es ist in Wirklichkeit ein Strategie- und Führungsproblem.

Manuel Gass, Head of Product Platforms bei Jimdo, bringt es direkt auf den Punkt:

„Es gibt sehr sehr viel, dass wir intern beeinflussen können, aber externe Faktoren kannst einfach nicht beeinflussen. Wenn sich Technologie verändert und wir nicht flexibel genug sind, landen wir in lustigen Migrationsprojekten, die dann Jahrzehnte hinweggehen — und das will jeder gern anfangen, aber keiner.”

Gass verantwortet bei Jimdo die Plattform-Teams — jene Engineering-Einheiten, die keine direkten Kundenfunktionen liefern, sondern die Infrastruktur bereitstellen, auf der alle anderen Product Teams aufbauen. Seit knapp eineinhalb bis zwei Jahren in dieser Rolle, mit rund zehn Jahren Gesamterfahrung im Produktmanagement, kennt er das Grundproblem aus drei Perspektiven: als Produktmanager, als Plattformverantwortlicher und als interner Dienstleister für andere Engineering-Teams.

Das Kerndilemma: Plattform-Teams werden von Feature-Teams mit kurzfristigen Requests überflutet. Wer jeden Request bedient, zerstört die Architektur. Wer jeden Request ablehnt, verliert die interne Legitimität. Die Lösung liegt nicht in besseren Tools — sondern in präziser Strategie, expliziten Baselines und einer Kultur gemeinsamer Ziele.

Die wichtigsten Erkenntnisse

• Ohne Engineering-Strategie ist Balance unmöglich. Unternehmens-, Produkt- und Engineering-Strategie müssen präzise definiert sein, bevor Kapazitätsentscheidungen sinnvoll getroffen werden können.
• RICE funktioniert in 9 von 10 Fällen — und beim zehnten bricht das Framework zusammen. Für Plattform-Priorisierung braucht es eine explizite Kapazitäts-Baseline, keine universellen Scoring-Formeln.
• Generische Plattform-Architektur schlägt use-case-spezifische Optimierung. Der Pull-and-Push-Ansatz findet den kleinsten gemeinsamen Nenner und schützt vor kostspieligen Migrationen.
• ~80 % der Koordinationsarbeit erledigen gemeinsame Ziele — nicht Policies oder Reporting-Strukturen.
• Kaskadierende Goals (OKR-ähnlich) ermöglichen lokale Autonomie bei strategischer Alignment. Teams entscheiden selbst über Priorisierung — innerhalb eines klar definierten Zielrahmens.
• Execution schlägt perfekte strategische Dokumentation. Das Rad am Laufen halten und iterieren ist wichtiger als die Strategie von oben nach unten durchzureichen.
• Langfrist-Commitment braucht konkrete Kausalität. „Wir denken, das kommt in zwei Jahren irgendwie hin” erzeugt kein Budget — ein detailliertes Bild von Zukunftszustand und notwendiger Infrastruktur schon.

Im Detail: Wie Plattform-Teams technische Schulden strategisch abbauen

Technische Schulden sind kein Engineeringproblem – sie sind ein Strategieproblem. Ohne klare Unternehmen- und Produktstrategie lässt sich der Abbau nicht systematisch gestalten. Plattform-Teams müssen technische Schulden daher als strategisches Investment betrachten und in ihre Roadmap-Priorisierung integrieren, um Umsetzungsgeschwindigkeit und Coordination nachhaltig zu verbessern.

Warum technische Schulden ein Strategieproblem sind, kein Engineering-Problem

Die meisten IT-Organisationen behandeln technische Schulden als Backlog-Thema: ein bisschen Refactoring hier, ein Architektur-Review da. Manuel Gass arbeitet mit einem anderen Ausgangspunkt.

„Ohne irgendwie Unternehmensstrategie und auch die Produktstrategie sehr sehr präzise — in unserem Fall auch eine praktische Software Development oder Engineering Strategie dahinter zu haben — ist es fast schon unmöglich, das richtig aufzubauen, weil ich muss wissen, in welche Richtung ich laufe.”

Ohne diese strategische Klarheit fehlt dem Plattform-Team die Entscheidungsgrundlage für die wichtigste Frage überhaupt: Welche Architektur-Investitionen sind heute notwendig, damit wir in drei Jahren noch handlungsfähig sind?

Das ist keine akademische Frage. Plattform-Teams, die ohne klare Langfristige Architektur IT-Organisation arbeiten, akkumulieren technische Schulden nicht trotz ihrer Arbeit — sondern durch sie. Jede reaktive Entscheidung, die kurzfristig Kapazität freimacht, kostet langfristig Flexibilität.

Der Pull-and-Push-Ansatz: Generische Plattformen statt Speziallösungen

Das erste operative Framework aus dem Gespräch mit Gass ist der Pull-and-Push-Ansatz für generische Plattform-Architektur.

Die Logik: Plattform-Teams werden mit Use Cases aus allen Produkt-Teams konfrontiert. Der naheliegende Fehler ist, für jeden Use Case eine maßgeschneiderte Lösung zu bauen. Das erzeugt kurzfristig Zufriedenheit — und langfristig ein Architektur-Chaos, das zum Migrations-Alptraum wird.

Der Gegenansatz funktioniert in vier Schritten:

1. Use Cases von internen Kunden sammeln und dokumentieren — vollständig, ohne Vorfilterung
2. Common Denominators identifizieren — was ist der kleinste gemeinsame Nenner über alle Use Cases?
3. Generische Lösung entwickeln, die nicht auf Spezialfälle optimiert ist
4. Mit der Zeit iterieren und neue Anforderungen flexibel integrieren

„Wir versuchen im gemeinsamen kleinsten gemeinsamen Nenner mehr oder weniger zu finden und das dann praktisch so aufzusetzen, dass es dann mit der Zeit mitwachsen kann.”

Der entscheidende Unterschied: Eine generische Lösung kann mit neuen Use Cases wachsen. Eine use-case-spezifische Lösung muss bei jeder neuen Anforderung entweder verbogen oder ersetzt werden. Genau letzteres erzeugt die Migrationsprojekte, die Jahre dauern — und die laut Gass zwar jeder anfangen, aber keiner zu Ende führen will.

Für Führungskräfte in größeren IT-Organisationen bedeutet das konkret: Capacity Planning für Plattform-Teams muss Generizität als explizites Qualitätskriterium enthalten, nicht als nachgelagerten Optimierungsschritt.

Priorisierung ohne Äpfel-Birnen-Problem: Die Kapazitäts-Baseline

Das zweite Framework adressiert das klassische Priorisierungsdilemma in Plattform-Teams: Wie wägt man technischen Schuldenabbau gegen neue Feature-Requests ab?

Gass ist direkt in seiner Einschätzung von Standard-Frameworks:

„Wir meistens Äpfel mit Birnen vergleichen wollen. So, wir kommen dann mit lustigen Frameworks raus, wie mit RICE und so weiter, wo wir es versuchen über einen Kamm zu scheren. Meistens nicht machbar, weil es bei neun von zehn Fällen funktioniert, bei einem von zehn nicht — bei einem durch den einen Fall kippt das ganze Framework praktisch in sich zusammen.”

Das bedeutet nicht, dass RICE wertlos ist. Es bedeutet, dass Portfolio-Management IT-Projekte in Plattform-Kontexten eine zusätzliche Schicht braucht: eine explizite Baseline für kurzfristige versus langfristige Kapazität.

Das Baseline-Framework funktioniert so:

• Analyse: Wie viel Prozent der Kapazität können kurzfristige Requests absorbieren, ohne die langfristige Architektur zu beschädigen?
• Baseline festlegen: z. B. 30 % kurzfristig, 70 % langfristig — die konkrete Zahl ist kontextabhängig, die Explizitheit ist es nicht
• Transparent kommunizieren: Interne Stakeholder müssen verstehen, warum nicht jeder Request sofort bedient wird
• Regelmäßig überprüfen: Ohne Dogmatismus — die Baseline ist ein Werkzeug, keine heilige Zahl

Das Ergebnis: Plattform-Teams können technische Schulden reduzieren, ohne intern als Blockierer wahrgenommen zu werden — weil die Kapazitätslogik sichtbar und nachvollziehbar ist.

Cross-funktionale Koordination: Ein Schritt vorausdenken

Plattform-Teams haben eine strukturelle Besonderheit: Sie liefern nicht an externe Kunden, sondern an interne Product Teams. Das verändert die Koordinationslogik grundlegend.

„Wir sind ja praktisch dafür da, andere schneller zu machen. Wir müssen normalerweise einen Schritt weiterdenken, wie z. B. Produkt-Teams, Feature-Teams, die wir praktisch mit unseren Kapabilitäten ein bisschen weiterschreiben.”

Cross-funktionale Teams koordinieren bedeutet im Plattform-Kontext: antizipieren, nicht nur reagieren. Das Plattform-Team muss die zukünftige Produkt-Roadmap kennen, bevor die Feature-Teams ihre nächsten Anforderungen stellen — sonst ist die Architektur immer einen Schritt hinter der Realität.

Das hat praktische Konsequenzen für IT-Governance Frameworks:

• Plattform-Teams brauchen Zugang zu Produkt-Roadmaps frühzeitig — nicht als Zuschauer, sondern als aktive Mitgestalter
• Die Schnittstelle zwischen Plattform- und Feature-Teams muss strukturiert sein, nicht ad hoc
• Strategische Architektur-Planung findet nicht im Plattform-Team allein statt, sondern in der Interaktion mit allen abhängigen Teams

Das kaskadierende Goals-System: Autonomie mit Alignment

Wie verhindert man, dass dezentrale Entscheidungen die Technologiestrategie langfristig untergraben? Gass’ Antwort ist ein OKR-ähnliches System mit expliziter Kaskadierung.

„Im besten Fall kommt alles von unten nach oben. Also praktisch die Teams entscheiden, was lokal priorisiert wird. Um das Ganze natürlich zu supporten, haben wir natürlich Metriken und Goals, die von oben nach unten kaskadieren.”

Die vier Schritte:

1. Unternehmens- und Produktstrategie definieren — präzise, nicht als Hochglanzdokument
2. Top-Level Goals und Metriken kaskadieren — von Leadership an Teams, nicht als Diktat, sondern als Orientierungsrahmen
3. Teams arbeiten autonome Prioritäten aus, die zu den kaskadierten Goals beitragen
4. Regelmäßige Überprüfung: Erreichen wir unsere Ziele? Was muss nachgesteuert werden?

OKR-Kaskadierung im Unternehmen funktioniert hier nicht als bürokratisches Reporting-Instrument, sondern als Mechanismus, der lokale Autonomie und strategisches Alignment gleichzeitig ermöglicht. Team-Autonomie Performance steigt — weil Teams wissen, warum ihre Entscheidungen zählen.

Gemeinsame Ziele ersetzen Policies — und machen ~80 % der Arbeit

Das vielleicht überraschendste Ergebnis aus dem Gespräch: Der effektivste Hebel gegen technische Schulden und Koordinationsprobleme ist kultureller Natur.

„Sobald ich praktisch crossfunktional das gemeinsame Ziel habe und wir alle das Ziel erreichen wollen, kommt keiner in die Arbeit und macht schlechte Arbeit. Sondern jeder versucht sein Bestes zu geben.”

Und quantifiziert:

„Dieses um das gemeinsame Ziel zu schauen hilft extrem und das macht glaube ich schon relativ 80 % der Arbeit an sich selbst.”

Gemeinsame Ziele Organisationskultur schlägt Policy-getriebene Governance. Regeln und Kontrollmechanismen sind teuer — in Management-Zeit, in Reibungsverlusten, in Motivationsverlust. Ein Team, das ein geteiltes Ziel versteht und internalisiert hat, braucht weniger Regeln, weniger Eskalationen und weniger Overhead.

Das bedeutet nicht, dass Struktur irrelevant ist. Es bedeutet, dass Struktur den Rahmen setzt — und Ziele den Antrieb liefern.

Strategisches Storytelling: Wie man Buy-in für langfristige Investitionen schafft

Das letzte Framework adressiert