Ingenieurteams in wachsenden Unternehmen kennen eine besondere Art von Frustration: Alle arbeiten, die Boards sind voll, Stand-ups finden pünktlich statt – und dennoch kann das Unternehmen nicht vorhersagen, wann etwas ausgeliefert wird. Features kommen verspätet, Releases erfordern manuelle Prozesse, die Tage in Anspruch nehmen, und die Diskrepanz zwischen dem, was das Team liefert, und den Erwartungen des Unternehmens wächst jedes Quartal unbemerkt.

Dieses Muster deutet selten auf ein Talentproblem hin. Es weist vielmehr auf ein Liefersystem, das mit dem Wachstum der Organisation nicht neu konzipiert wurde. Ein Prozess, der für acht Ingenieure ausgelegt ist, skaliert nicht auf dreißig. Der Koordinationsaufwand steigt. Technische Abkürzungen, die unter frühem Druck entstanden sind, werden zu strukturellen Engpässen für jedes nachfolgende Feature. Das Hinzufügen von Ingenieuren zu einem leistungsschwachen Liefersystem führt zu mehr Koordinationsaufwand, nicht zu mehr Output. Der Hebel liegt darin, zu diagnostizieren, was die Dinge tatsächlich verlangsamt, und dies dann zu beseitigen.

Die Diagnose zuerst

Bevor wir Empfehlungen aussprechen, integriert Gradion einen erfahrenen Ingenieur und Delivery Lead für zwei bis drei Wochen direkt in den Arbeitsrhythmus Ihres Teams. Ziel ist es, zu verstehen, wie die Auslieferung tatsächlich funktioniert: wie Entscheidungen getroffen werden, wie Code durch Reviews läuft, wo Übergaben scheitern, was die Codebasis über angesammelte Abkürzungen verrät und wo Verantwortlichkeiten unklar sind.

Dies ist keine Umfrage oder ein Workshop. Es ist eine praxisnahe Überprüfung durch Experten, die diese Muster bereits auf Fintech-Plattformen in der Schweiz, in Fertigungssystemen in Thailand und in der Handelsinfrastruktur in Deutschland beobachtet haben.

Das Ergebnis ist eine spezifische, priorisierte Liste von Engpässen. Wir messen anhand von vier DORA-Metriken – Bereitstellungshäufigkeit, Durchlaufzeit für Änderungen, mittlere Wiederherstellungszeit und Änderungsfehlerrate – und legen Ziele fest, die auf dem aktuellen Zustand Ihres Teams basieren, nicht auf einem Branchen-Benchmark, der für ein anderes Team mit einer anderer Historie gilt.

Wo die Governance es zulässt, setzen wir KI-gestützte Codebasis-Analysen ein, um die Bewertung zu beschleunigen. Statische Analysen, Abhängigkeits-Mappings, Lücken in der Testabdeckung und architektonische Anti-Pattern, deren manuelle Ermittlung Wochen dauern würde, können in Tagen identifiziert werden. Eine dreiwöchige Diagnose mit KI-Unterstützung liefert ein umfassenderes Bild der Engpässe als eine sechswöchige manuelle Überprüfung – und die Ergebnisse spiegeln die tatsächliche Codebasis wider, nicht das, was das Team über die Codebasis annimmt.

Was wir diagnostizieren und angehen

Lücken in Pipelines und ToolsManuelle Release-Schritte sind die häufigste Ursache für Lieferverzögerungen. Wir überprüfen die CI/CD-Konfiguration, identifizieren, wo die Automatisierung endet und menschliches Eingreifen beginnt, und bauen die Pipeline um, um diese Übergabe zu eliminieren. Wo Pipelines nicht existieren, bauen wir sie auf. Wo sie existieren, aber langsam oder fehlerhaft sind, beheben wir den spezifischen Fehler, anstatt sie von Grund auf neu zu erstellen.

Abdeckung der TestautomatisierungEine geringe Abdeckung erzeugt eine Rückkopplungsschleife, die alles nachgelagerte verlangsamt: Entwickler können nicht sicher refaktorisieren, Reviewer werden vorsichtiger, und Release-Fenster schrumpfen, um das Risiko zu minimieren. Wir identifizieren die risikoreichsten ungetesteten Pfade und etablieren automatisierte Suiten auf Unit-, Integrations- und End-to-End-Ebene – ausreichend Abdeckung, damit die Pipeline vertrauenswürdig ist, nicht erschöpfende Abdeckung um ihrer selbst willen.

Sprint-Hygiene und ArbeitsflussGeschwindigkeitsverluste sind oft auf vorhersehbare strukturelle Muster zurückzuführen: Planung, die Abhängigkeitsketten ignoriert, Review-Warteschlangen, die mehrtägige Wartezeiten verursachen, und Ticket-Workflows, die verschleiern, ob Arbeit abgeschlossen oder lediglich in Bearbeitung ist. Bei der DataFlow Group verbrauchten manuelle Deployment-Prozesse 30 % der Engineering-Kapazität, noch bevor ein Sprint-Hygiene-Problem überhaupt sichtbar wurde – das Team schien ausgelastet, weil es das auch war, aber der Aufwand wurde vom Release-Management statt von der Feature-Bereitstellung absorbiert. Wir führen spezifische Anpassungen ein, die die größten Hebel für die Beseitigung von Verzögerungen bieten: Work-in-Progress-Limits, klarere Definitionen von „Done“, Abhängigkeits-Mappings vor der Planung und Review-SLAs.

Triage technischer SchuldenNicht jede technische Schuld bremst die Lieferfähigkeit gleichermaßen. Wir unterscheiden zwischen aktiver technischer Schuld, die aktuelle Arbeiten behindert, und passiver Schuld. Die Triage erstellt eine priorisierte Liste mit geschätztem Aufwand und Auswirkungen auf die Lieferfähigkeit. Dies gibt der technischen Führung eine fundierte Grundlage, um zu entscheiden, was sofort angegangen und was aufgeschoben werden soll. Für Unternehmen, bei denen technische Schuld die dominierende Einschränkung darstellt, empfehlen wir ein dediziertes Programm zur Schuldenreduzierung – ein separates, tiefgreifendes Engagement, das auf systematische Behebung abzielt.

Tool-Akzeptanz und Workflow-Reibung.Neue Plattformen mit geringer Akzeptanz sind eine Lieferbremse, die sich als Tooling-Erfolg tarnt. Wir identifizieren, wo Teams Workarounds entwickelt haben, wo Schnittstellen Reibung erzeugen, die die tägliche Arbeit verlangsamt, und wo die Diskrepanz zwischen Systemdesign und tatsächlicher Nutzung Kapazitäten bindet. Wenn die Diagnose die Akzeptanz als Engpass identifiziert, arbeiten wir mit der UX-Praxis von Gradion zusammen, um die Workflows und Schnittstellen neu zu gestalten, die Widerstand verursachen – nicht durch zusätzliche Schulungen, sondern durch die Behebung des Tools selbst.

Wenn die Führung der Engpass ist, nicht die Tools.

Probleme mit der Liefergeschwindigkeit liegen selten nur an den Tools. Sie zeigen sich auch in Verantwortlichkeitslücken: Niemand ist für den Release-Prozess durchgängig verantwortlich, Standards sind undokumentiert, was zu inkonsistenten Entscheidungen führt, und Eskalationswege sind unklar, sodass Blockaden tagelang ungelöst bleiben. Dies sind strukturelle und organisatorische Probleme, die sich nicht allein durch Pipeline-Automatisierung beheben lassen.

Wenn die Diagnose die Führung als Engpass identifiziert, bietet Gradion ein Interims-VP-Engineering- oder Fractional-CTO-Engagement an, das beide Ebenen parallel adressiert. Die technische Arbeit verbessert Tools und Prozesse. Das Leadership-Engagement etabliert die Standards, Verantwortlichkeitsklarheit und Rechenschaftsstrukturen, die verhindern, dass die Verbesserungen nach Beendigung des Engagements rückgängig gemacht werden.

Nachhaltige Veränderung, keine temporäre Verbesserung.Technische Korrekturen machen sich rückgängig, wenn sich die Organisation nicht parallel zu den Tools verändert. Wenn das Velocity-Programm signifikante Prozessänderungen beinhaltet – neue Release-Praktiken, neue Verantwortlichkeitsstrukturen, neue Review-Zyklen – arbeiten wir mit Ihrer Führung zusammen, um den Übergang zu steuern. Dies ist kein separater Change-Management-Workstream. Es ist fest in unsere Implementierung jeder strukturellen Änderung integriert: Wir kommunizieren die Gründe, beziehen die betroffenen Teams ein, messen die Akzeptanz und passen an, bis die neue Praxis zum Standard wird.

So sieht die Rolle in der Praxis aus.Der Interims- oder Fractional-Leader integriert sich in Ihre bestehende Managementstruktur – nimmt an Führungssitzungen teil, arbeitet direkt mit Engineering Managern zusammen und trifft Entscheidungen mit der erforderlichen Autorität der Rolle. Sie sind kein externer Berater. Sie agieren für die Dauer des Engagements als vollwertiges Mitglied Ihres Führungsteams.

Typische Dauer:3–6 Monate, abhängig vom Umfang der erforderlichen strukturellen Änderungen. Das Engagement beinhaltet eine definierte Übergabephase, in der die Rolle entweder an eine feste Neueinstellung übergeben oder die Organisationsstruktur so angepasst wird, dass die Rolle nicht mehr benötigt wird. Ziel ist es immer, die Organisation autark zu hinterlassen und nicht von der fortgesetzten Präsenz von Gradion abhängig zu machen.

Bewährt in der Praxis

ein führender B2B-Marktplatzbetreiber – Liefergeschwindigkeit um 25 % gesteigert, API-Latenz um 70 % reduziert.ein führender B2B-Marktplatzbetreiber betreibt Deutschlands führenden B2B-Überschussmarktplatz. Jahrelange architektonische Komplexität hatte jede Bereitstellung zu einem Risiko gemacht. Entwickler scheuten sich, den Code anzufassen; die Bereitstellungsfrequenz war gesunken, um die Stabilität zu gewährleisten. Gradion refaktorierte das Backend, containerisierte die Services und restrukturierte den Release-Prozess. Die Liefergeschwindigkeit stieg um 25 %. Die API-Latenz sank um 70 %. Das Team erweiterte den Umfang nach dem Engagement, anstatt ihn zu reduzieren – das deutlichste Zeichen dafür, dass das Vertrauen in das System wiederhergestellt war.

DataFlow Group (eine globale Plattform zur Überprüfung von Qualifikationen) – 5x schnellere Deployments, 30 % der Engineering-Kapazität zurückgewonnen.Die DataFlow Group betreibt Infrastruktur für Hintergrundprüfungen und Dokumentenverifizierung in verschiedenen internationalen Rechtsräumen. Manuelle Bereitstellungsprozesse führten zu Fehlern und banden erhebliche Engineering-Kapazitäten. Gradion hat die Infrastruktur neu aufgebaut, automatisierte Bereitstellung, Autoscaling und Monitoring eingeführt und manuelle Schritte durch Infrastructure as Code eliminiert. Bereitstellungen erfolgten fünfmal schneller. Dreißig Prozent des Engineering-Aufwands wurden im Release Management eingespart. Neunundneunzig Prozent der Bereitstellungsschritte liefen automatisiert ab.

Shopware – 40 % Reduzierung der Produktentwicklungskosten.Gradion hat das 21-köpfige KI-Produktteam von Shopware aufgebaut und operativ geführt. Das Engagement führte zu einer Reduzierung der Produktentwicklungskosten um etwa 40 % und beschleunigte gleichzeitig die Feature-Bereitstellung. Dies war keine reine Tool-Optimierung, sondern ein Engagement zur Teamgestaltung und Optimierung des Lieferprozesses, bei dem Gradion als Engineering-Organisation für einen definierten Produktbereich agierte.

eine E-Commerce-SaaS-Holdinggesellschaft – Geschwindigkeit innerhalb weniger Tage nach der Akquisition wiederhergestellt.eine E-Commerce-SaaS-Holdinggesellschaft verwaltet ein Portfolio von E-Commerce-Plattformen innerhalb eines großen europäischen Private-Equity-Portfolios – mit über 50 Milliarden Euro GMV und mehr als 120.000 Händlern. Nach einer Akquisition sah sich die Engineering-Organisation mit Instabilität und Wissensverlust konfrontiert. Das Vertrauen in die Bereitstellungsprozesse war zusammengebrochen. Gradion setzte innerhalb weniger Tage ein erfahrenes Team ein, stabilisierte die Kernsysteme, etablierte Wissenstransferprozesse und stellte die kontinuierliche Bereitstellung wieder her, ohne den laufenden Betrieb zu stören. Das Engagement zeigte, dass die Wiederherstellung der Geschwindigkeit nach einer Akquisition ein Problem des Lieferprozesses ist, nicht ein Einstellungsproblem.

Engagement-Struktur

Geschwindigkeitsdiagnose3 Wochen. Ein erfahrener Ingenieur und ein Delivery Lead integrieren sich in den Arbeitsrhythmus Ihres Teams. Das Ergebnis ist eine priorisierte Liste von Engpässen, gemessen an DORA-Baselines, mit einer nach Hebelwirkung organisierten Liefer-Roadmap. KI-gestützte Codebasis-Analyse wird, wo es die Governance erlaubt, eingesetzt, um die Bewertung zu verdichten und architektonische Engpässe aufzudecken. Wir benötigen Zugang zu Ihren Repositories, Ihrer CI/CD-Konfiguration und die Teilnahme an Ihren bestehenden Meetings (Standups, Planning, Retrospektiven). Als Festpreis-Engagement konzipiert.

Geschwindigkeitsprogramm3–6 Monate. Gradion-Ingenieure arbeiten eng mit Ihrem Team zusammen, um die in der Diagnose identifizierten Engpässe zu beseitigen – dazu gehören der Neuaufbau von Pipelines, die Etablierung von Testabdeckung, die Behebung struktureller Schulden und die Anpassung von Lieferprozessen. Jede Phase zielt auf spezifische Engpässe mit messbaren Verbesserungszielen, die sich an der DORA-Baseline orientieren. Eine messbare Verbesserung der Bereitstellungsfrequenz ist typischerweise innerhalb von sechs bis acht Wochen sichtbar. Die Gestaltung richtet sich nach Teamgröße, Komplexität der Engpässe und Phasenstruktur.

Interim Engineering-Führung3–6 Monate. Für Organisationen, bei denen die Diagnose die Führungsstruktur als primären Engpass identifiziert. Ein Gradion Principal agiert als Interim VP Engineering oder Fractional CTO innerhalb Ihrer bestehenden Managementstruktur – mit Entscheidungsbefugnis, direkter Teameinbindung und einem definierten Übergabeplan. Dies läuft parallel zum Geschwindigkeitsprogramm, wenn sowohl technische als auch organisatorische Engpässe vorliegen. Die Gestaltung richtet sich nach der organisatorischen Komplexität und den Übergabeanforderungen.

Geschwindigkeit oder Schuldenabbau: Welches Engagement ist das Richtige?

Wenn das System grundsätzlich intakt ist, aber der Lieferprozess gestört ist – manuelle Releases, fehlende Automatisierung, unklare Verantwortlichkeiten, Koordinationsaufwand – dann handelt es sich um ein Geschwindigkeitsproblem. Der Engpass liegt im Arbeitsfluss innerhalb der Organisation.

Wenn die Codebasis selbst der Engpass ist – Kopplungen, die eine unabhängige Bereitstellung verhindern, ungetestete kritische Pfade, Abhängigkeitsdrift, architektonische Entscheidungen, die jede Funktion blockieren – dann handelt es sich um ein Schuldenproblem. Der Engpass liegt in der Grundlage, auf der das Team aufbaut.

Die meisten Organisationen kennen beide Herausforderungen. Unsere Geschwindigkeitsdiagnose identifiziert die primäre Engstelle und leitet daraus Empfehlungen ab. Manche Projekte kombinieren beide Ansätze. Die Unterscheidung ist wichtig, da die Interventionen unterschiedlich sind: Geschwindigkeitsarbeit optimiert Prozesse und Tools; Schuldenabbau verändert Codebasis und Architektur.