Engineering-Diagnose
Aus einer Anfrage zu Effizienz und Infrastruktur wurden eine Roadmap, neu verteilte Rollen und eine nachverfolgbare Umsetzung
- 3 → 1
- drei Rollen in der Umsetzung gingen vom Gründer an einen eigenen PM über
- 30 %
- der Arbeitswoche einer Teilzeitkraft gingen in unstrukturierten Meetings verloren
- 16
- Personen im Daily Standup, später auf das Produktteam reduziert
Fallakte
- Branche
- Energieeffizienzberatung
- Region
- Deutschland
- Leistung
- Engineering-Diagnose
- Team
- Wayne ArendseLeiter Delivery & TransformationYurii KotulaCEO & Leiter Engineering
- Systeme
- WordPress
- .NET
- Azure
- KI-Automatisierung
- Jira und Confluence für die Umsetzung
- fachlich geht es um deutsche Förderprogramme (BAFA, KfW)
Über den Kunden
Der Kunde ist ein deutsches Beratungsunternehmen mit rund 20 Mitarbeitenden. Es hilft Hauseigentümern und Unternehmen, energieeffiziente Sanierungen zu planen und staatliche Fördermittel zu sichern. Das Produkt läuft überwiegend auf WordPress, darauf baut ein neuerer Bereich mit .NET, Azure und KI auf.
Am Anfang stand ein kostenloses Audit der Prozesse und der Technik. Um eine Rettung hatte der Kunde nicht gebeten. Sichtbar wurde das Problem erst durch die Daten aus der Umsetzung.
Das geschäftliche Problem
Das Unternehmen wollte effizienter arbeiten und seine Infrastruktur modernisieren. Die Umsetzung war nicht planbar, und zu viel davon lag bei einer einzigen Person. Der Gründer war CEO, Product Manager und Projektmanager zugleich, also lief jede Entscheidung über ihn.
Wie das konkret aussah, zeigte die Arbeitswoche. Montags gingen ganze Vormittage für Meetings drauf. Am Daily Standup nahmen 16 Personen teil, und für jeden Einzelnen war das meiste davon ohne Belang. Eine Teilzeitkraft verlor 30 % ihrer ohnehin knappen Wochenstunden in unstrukturierten Meetings. Prioritäten wurden ständig neu verhandelt, nach dem Muster „alles ist Priorität Nr. 1“.
Was auf dem Spiel stand
- 30 % der knappen Wochenstunden einer wichtigen Teilzeitkraft gingen in unstrukturierten Meetings verloren.
- Tägliche Standups mit 16 Teilnehmenden, die meisten ohne relevanten Beitrag. Das riss das Team jeden Tag aus der konzentrierten Arbeit.
- Jede Woche gingen ganze Montagvormittage in Meetings auf, und genau diese Zeit fehlte dem Team für konzentrierte Arbeit.
Was nicht funktionierte
- Drei Führungsrollen (CEO, Product Manager, Projektmanager) lagen bei einer Person. Alle Entscheidungen des Teams liefen über diese eine Stelle.
- Feedback war auf vier Tools verteilt (Figma, Teams, Google Sheets, Asana), und Entwickler übersahen Kommentare in Figma.
- Keine Unit-Tests, keine automatisierte Pipeline, keine eigene QA.
- Keine Übergabe vor Abwesenheiten. Im restlichen Team musste dann eine einzelne Person alles abdecken.
Vorgehen bei der Diagnose
Das Audit lief auf drei Ebenen gleichzeitig, denn der Engpass war genauso organisatorisch und operativ wie technisch.
Strategie
Wofür braucht das Unternehmen seine Umsetzungskapazität?
Der Wert des Unternehmens hängt davon ab, dass es Verbesserungen an Produkt und Prozessen stetig ausliefert. Genau diese Kapazität fraßen ein überlasteter Verantwortlicher und das ständige Umpriorisieren. Drei Schritte: den Gründer aus der täglichen Koordination lösen, damit er sich wieder um die Ausrichtung des Produkts kümmert; ein einheitliches Modell zur Priorisierung einführen, statt Prioritäten mündlich neu auszuhandeln; zugesagte Arbeit von geplanter Arbeit trennen, damit Einträge in der Roadmap nicht mehr wie Versprechen klingen.
Abläufe
Wo bleibt die Zeit wirklich?
Meetings und unklare Zuständigkeiten fraßen die Zeit für konzentrierte Arbeit, und Aufgaben wie Entscheidungen lagen verstreut in verschiedenen Tools. Drei Schritte: Standups auf das Produktteam beschränken; Aufgaben und Entscheidungen an einer einzigen verbindlichen Stelle bündeln; Übergaben vor Abwesenheiten einführen, damit nicht mehr eine einzelne Person alles auffangen muss.
Technologie
Trägt das System die Last zuverlässig?
Für den Bereich .NET, Azure und KI musste die Infrastruktur modernisiert werden, und es gab kein Sicherheitsnetz aus Tests. Drei Schritte: die Migration zu Azure parallel zum bestehenden WordPress-Produkt begleiten; eine Definition of Done einführen, die Tests einschließt; Automatisierungen bauen, die wiederkehrende manuelle Arbeit im Haus übernehmen.
Was sich geändert hat
Die Koordination liegt jetzt bei einem eigenen Verantwortlichen für die Umsetzung.
Ein fest ins Team eingebundener Projektmanager übernahm Sprint-Planung, Koordination und Review. Der Gründer bestätigte, dass er das tägliche Projektmanagement abgegeben hat und sich wieder der Produktstrategie widmet. Standups finden nur noch im Produktteam statt, und feste Priorisierungsrunden ersetzen das ständige mündliche Umpriorisieren.
Alle Arbeit läuft über eine verbindliche Quelle.
Aufgaben werden jetzt in Jira verfolgt, Anforderungen schriftlich festgehalten statt mündlich weitergegeben. Die Feedback-Kanäle sind festgelegt: Jira für Aufgaben, Figma für Design und Texte, Teams für die tägliche Kommunikation. Retrospektiven finden alle zwei Wochen statt, ihre Maßnahmen werden nachverfolgt. Ein in Confluence dokumentiertes Übergabe-Framework wurde bei einer echten Abwesenheit im Team erprobt.
Neu hinzu kamen KI und Automatisierung.
Ein Engineering-Team von Intelvision begann, wiederkehrende interne Prozesse zu automatisieren, und unterstützte die Migration zu Azure. Es arbeitete sich in ein neues Technologiefeld und einen zeitweise unklaren Umfang ein, während die laufende Umsetzung weiterging.
Entscheidungen
Erst diagnostizieren, dann Stellen besetzen.
Am Anfang stand ein kostenloses Audit der Prozesse und der Technik, keine sofortige Einstellung. Mehr Leute an einem Engpass, den niemand untersucht hatte, hätten das Durcheinander vergrößert, nicht die Leistung.
Ein eigener PM statt mehr Entwickler.
Der Engpass lag bei Koordination und Entscheidungen, nicht bei Entwicklerstunden. Die erste neue Rolle beseitigte den Engpass bei der einen verantwortlichen Person, statt darunter mehr Kapazität aufzubauen.
Zeiterfassung zum Kalibrieren, nicht zum Überwachen.
Das Team hatte früher Zeiterfassung als Strafinstrument erlebt und war entsprechend vorbelastet. Deshalb wurde sie ausdrücklich eingeführt, um Schätzungen zu kalibrieren, mit der klaren Zusage, dass die Daten nicht in Leistungsbeurteilungen einfließen. In Retro 4 bestätigte sich, dass die Entwickler positiv reagierten.
Ergebnisse
| Kennzahl | Vorher | Nachher |
|---|---|---|
| Entscheidungshoheit | Eine Person ist CEO, PM und Projektmanager zugleich | Eigener PM verantwortet die Umsetzung; der Gründer kümmert sich um die Produktstrategie |
| Teilnahme am Standup | 16 Personen, für die meisten ohne Belang | Nur das Produktteam, 15 bis 30 Minuten |
| Feedback-Kanäle | Auf vier Tools verteilt, Kommentare gingen unter | Eine verbindliche Quelle pro Zweck: Jira, Figma, Teams |
| Vertretung bei Abwesenheit | Keine Übergabe, eine Person im Team musste alles abdecken | Übergabe-Framework in Confluence, bei einer echten Abwesenheit erprobt |

Strike Team
Erfahrene Engineering-Leads finden in einer Engineering Diagnostic zum Festpreis den eigentlichen Engpass und bleiben, bis er behoben ist. Project Rescue, Fractional CTO, Architektur und Business Cases.
Mehr zum Strike TeamKommen wir ins Gespräch
Meist beginnen wir mit einer Beratung. Sie bekommen eine klare Antwort, ob wir helfen können und was als Erstes passieren sollte.
Ihr Ansprechpartner
Yurii Kotula
CEO und Engineering-Leiter
Das erste Gespräch führen Sie mit Yurii. Schicken Sie das Formular oder wählen Sie direkt einen Termin in seinem Kalender.
Termin mit Yurii buchen
