Delivery-Fluss und Durchlaufzeit
Wie lange braucht eine Änderung von der Entscheidung bis in die Produktion — und wo genau liegt sie dazwischen herum?
~/appetizer-labs/engineering-growth-assessment
Engineering Growth Assessment
Engineering-Wachstum ohne Delivery-Chaos
Ihr erfahrt, ob eure Engineering-Organisation und eure Plattform die nächste Wachstumsstufe tragen — und wo ihr investieren solltet, bevor Komplexität, Betriebsrisiko und Abstimmungsaufwand weiter steigen.
30 Minuten, kostenfrei, ohne Verkaufsgespräch.
Mehr Entwickler, gleiche Liefergeschwindigkeit
Das Muster ist überall dasselbe: Die Firma wächst, das Engineering-Budget wächst mit, und die Zeit von der Entscheidung bis zur Auslieferung wird trotzdem länger. Der Reflex ist dann, mehr Leute einzustellen. In den meisten Fällen ist das Problem aber kein Kapazitätsproblem, sondern ein Struktur- und Delivery-Problem: unklare Verantwortung, eine Plattform, die Tickets statt Selbstbedienung produziert, Betriebsaufgaben, die niemandem gehören, und Entscheidungen, die auf zu wenigen Schultern liegen. Zusätzliche Entwickler machen das nicht besser — sie erhöhen den Abstimmungsaufwand und damit den Engpass.
Wann dieses Assessment sinnvoll ist
- Die Entwicklungsmannschaft ist gewachsen, der Ausstoß nicht.
- Ein neues Produkt, ein neuer Markt, ein Zukauf oder ein großer Kunden-Rollout steht an.
- Der CTO oder die technische Leitung ist ausgeschieden, oder Verantwortlichkeiten sind unklar geworden.
- Plattform- und Betriebskomplexität wachsen schneller als die Produktfähigkeit.
- Wenige Schlüsselpersonen tragen unverhältnismäßig viel — Urlaub ist bereits ein Risiko.
- Es steht eine große Entscheidung an: Einstellungswelle, Reorganisation, Cloud-Migration, Plattforminvestition.
- Die Geschäftsführung will eine unabhängige zweite Meinung, bevor ein sechs- oder siebenstelliges Budget freigegeben wird.
Für wen das Assessment gedacht ist
Für die Person, die am Ende die Investitionsentscheidung verantwortet — und für die technische Führung, die sie umsetzen muss.
- CTOs und VPs of Engineering, die vor der nächsten Wachstumsstufe stehen und wissen wollen, was zuerst bricht.
- Heads of Engineering und Bereichsleitungen, die mehrere Teams verantworten und den Überblick über die Engpässe verlieren.
- Geschäftsführung und technische Programmverantwortliche, die eine unabhängige Einschätzung vor einer großen Investition brauchen.
- Engineering-Organisationen mit etwa zehn bis achtzig Entwickelnden, in denen Wachstum bereits Abstimmungskosten erzeugt.
- Investoren und Beiräte, die die technische Skalierungsfähigkeit eines Beteiligungsunternehmens einschätzen müssen — mit dessen Einverständnis.
Für wen es nicht gedacht ist
Lieber vorher aussortieren als hinterher enttäuschen. In diesen Fällen ist das Assessment das falsche Mittel:
- Ihr wisst bereits, was zu tun ist, und braucht Umsetzung statt Analyse. Dann fangt direkt mit der Umsetzung an.
- Es gibt keinen Sponsor auf Führungsebene, der Entscheidungen aus dem Ergebnis ableiten darf.
- Gesucht wird ein Gutachten, das eine bereits getroffene Entscheidung nachträglich absichert.
- Das Ziel ist die Bewertung einzelner Mitarbeitender. Wir bewerten Systeme, Prozesse und Verantwortungsschnitte — keine Personen.
- Ein Team, ein Produkt, eine überschaubare Codebasis: dafür genügt ein Architektur-Review oder ein Workshop.
Was das Assessment ausdrücklich nicht ist
Diese Grenzen stehen hier, damit aus einem festen Umfang kein unbegrenztes Audit wird. Jeder dieser Punkte lässt sich separat beauftragen, wenn die Analyse zeigt, dass er nötig ist.
- kein Penetrationstest und keine Sicherheitszertifizierung
- kein zeilenweises Code-Audit aller Services
- keine Cloud-Migration und keine Umsetzung
- keine Leistungsbeurteilung einzelner Mitarbeitender
- keine Strategieberatung ohne technische Prüfung
- keine Zusage eines bestimmten Produktivitäts- oder Wachstumsgewinns
Abgrenzung
Klassische Managementberatung liefert die Analyse und geht dann. Wir schreiben die Empfehlungen so, dass wir sie selbst umsetzen könnten — und in vielen Fällen tun wir das danach auch. Durchgeführt wird das Assessment vom Gründer, nicht von einem Juniorteam mit Foliendeck; wer die Interviews führt, schreibt auch den Bericht und sitzt im Readout.
Nicht zu verwechseln mit dem Delivery Bottleneck Assessment: Das schaut auf einen Lieferweg und dessen Durchlaufzeit und beantwortet, was in den nächsten Wochen den Fluss begrenzt. Dieses Assessment schaut auf die gesamte Engineering-Organisation — Struktur, Plattform, Führung, Kosten und Risiko — und beantwortet die Frage, ob sie die nächste Wachstumsstufe trägt.
Fragen, die das Assessment beantwortet
Am Ende steht zu jeder dieser Fragen eine Antwort mit Begründung — nicht eine Auflistung von Beobachtungen.
- 01Trägt die Engineering-Organisation die nächste Wachstumsstufe des Unternehmens?
- 02Wo bricht die Lieferfähigkeit zuerst?
- 03Wächst die Plattformkomplexität schneller als der Ausstoß?
- 04Wie viel Zeit verlieren die Teams durch Abstimmung, unklare Zuständigkeit und Betriebsaufgaben?
- 05Braucht ihr mehr Leute, bessere Systeme, klarere Führung — oder ein anderes Betriebsmodell?
- 06Welche Investitionen erhöhen den Durchsatz und welche erhöhen nur die Komplexität?
Was wir uns ansehen
Zwölf Dimensionen, jede mit einer Leitfrage. Was für euch nicht relevant ist, klären wir im Fit-Check ab — der Umfang bleibt fest, die Tiefe verteilen wir dorthin, wo das Risiko liegt.
Organisation und Verantwortung
Wer besitzt welchen Teil des Systems, und wo endet Verantwortung an einer Grenze, die niemand überschreiten darf?
Plattformreife und Enablement
Können Teams selbst ausliefern, oder brauchen sie für jeden Schritt ein Ticket bei einem anderen Team?
Architektur und Betriebskomplexität
Skaliert die Architektur mit der Zahl der Teams, oder erzwingt sie Abstimmung bei jeder Änderung?
Verlässlichkeit und Vorfallslast
Wie viel Kapazität bindet der Betrieb — Bereitschaft, Störungen, Nacharbeit — und ist der Trend steigend?
Kostenverlauf der Infrastruktur
Wachsen die Cloud- und Betriebskosten mit dem Geschäft oder schneller als das Geschäft?
Einarbeitung und Team-Autonomie
Wie lange dauert es, bis neue Entwickelnde eigenständig liefern — und was ist der Grund für die Dauer?
Technische Führung und Entscheidungswege
Wo werden technische Entscheidungen getroffen, wie werden sie festgehalten, und wer darf widersprechen?
Wissenskonzentration und Schlüsselpersonen
Welche Systeme kennt nur eine Person, und was passiert, wenn diese Person zwei Wochen ausfällt?
Governance, Sicherheit und Auflagen
Welche regulatorischen und sicherheitsbedingten Auflagen begrenzen das Tempo, und welche davon sind hausgemacht?
Einstellungsplan gegen Produktivitätsgrenze
Was unterstellt die Personalplanung an zusätzlicher Lieferleistung, und hält diese Annahme der aktuellen Struktur stand?
Bereitschaft für Produkte, Märkte, Teams, Zukäufe
Was müsste vorher stehen, damit ein neues Produkt, ein neuer Markt oder ein integriertes Team nicht am Bestand scheitert?
Ablauf
Acht Schritte, fester Umfang. Ihr wisst vorher, wessen Zeit gebraucht wird und wann.
- 01
Fit-Check und Zuschnitt
Ein Gespräch: Wachstumsanlass, Geschäftsziel, betroffene Teams, Grenzen des Umfangs. Wenn wir nicht die Richtigen sind, sagen wir das hier — nicht nach der Beauftragung.
- 02
Kickoff
Hypothesen, verfügbare Belege und Gesprächspartner werden festgelegt. Ab hier läuft die Uhr.
- 03
Sichtung der Belege
Architektur, Liefersystem, Verlässlichkeit, Kosten, Verantwortungsschnitt und Governance — anhand dessen, was vorhanden ist.
- 04
Interviews
Führungsebene, technische Leitung, Plattform und Betrieb sowie Entwickelnde aus den Produktteams. Vertraulich, einzeln, ohne Protokoll an die Führung.
- 05
Engpassanalyse
Wir trennen Symptome von Ursachen und benennen die Annahmen, die sich nicht halten lassen.
- 06
Priorisierung
Dringende Risiken, schnelle Verbesserungen und strukturelle Investitionen werden getrennt und in eine Reihenfolge gebracht.
- 07
Executive Readout
Eine Sitzung mit der Führungsebene: Entscheidungen, Zielkonflikte, empfohlene Reihenfolge der Investitionen.
- 08
Technische Übergabe
Eine Sitzung mit der technischen Führung: Roadmap, Verantwortliche, Abhängigkeiten und die Kennzahlen, die ihr ab jetzt erheben solltet.
Was ihr beisteuert
Ohne diese Punkte wird das Ergebnis dünn. Mehr brauchen wir nicht:
- eine sponsernde Person auf Führungsebene
- das aktuelle Wachstums- oder Veränderungsziel des Unternehmens
- einen Überblick über Organisation und Verantwortungsschnitt
- einen groben Überblick über Architektur und Plattform
- vorhandene Zahlen zu Delivery, Verlässlichkeit, Vorfällen und Cloud-Kosten
- Zugang zu den Gesprächspartnern für die Interviews
- vorhandene Roadmaps, frühere Audits oder Transformationspläne
Fehlende Kennzahlen sind kein Hindernis. Wenn ihr Durchlaufzeiten oder Vorfallskosten nicht messt, ist genau das ein Ergebnis — und steht so im Bericht. Für den Fit-Check braucht es keine Architekturdiagramme, keine Zugänge und keine Produktionsdaten.
Was ihr bekommt
Ein Bericht, zwei Sitzungen, eine Entscheidungsgrundlage. Alles gehört danach euch.
- Executive Summary
- Die Lage auf zwei Seiten, in der Sprache der Geschäftsführung.
- Risikokarte Engineering-Wachstum
- Wo Wachstum auf Grenzen trifft, nach Eintrittsnähe und Geschäftswirkung geordnet.
- Reifegrad im Ist-Zustand
- Einordnung je Dimension, jeweils mit dem Beleg, auf dem sie beruht.
- Engpässe und Ursachen
- Die begrenzenden Faktoren, getrennt von ihren Symptomen.
- Verantwortungs- und Schlüsselpersonenrisiko
- Welche Systeme an einzelnen Personen hängen und was der Ausfall kostet.
- Priorisierte Handlungsfelder
- Was sich zu tun lohnt, in einer begründeten Reihenfolge.
- Schnelle Verbesserungen und strukturelle Investitionen
- Getrennt ausgewiesen, damit das Dringende das Wichtige nicht verdrängt.
- Aktionsplan für 90 Tage
- Was in den ersten 90 Tagen passiert, mit Verantwortlichen und Abhängigkeiten.
- Fähigkeiten-Roadmap für 6 bis 12 Monate
- Welche Fähigkeit wann entstehen muss, damit das Wachstumsziel trägt.
- Empfohlener Weg der Zusammenarbeit
- Falls externe Unterstützung sinnvoll ist — als Option, nicht als Voraussetzung.
- Executive Readout und technische Übergabe
- Zwei Sitzungen: eine für die Entscheidung, eine für die Umsetzung.
Jede Empfehlung im Bericht trägt sieben Angaben: Beleg, erwartete Wirkung, Dringlichkeit, Aufwandsspanne, Abhängigkeit, verantwortliche Rolle und wie sicher wir uns sind. Eine Empfehlung ohne Beleg kommt nicht in den Bericht.
Dauer
5 bis 8 Arbeitstage vom Kickoff bis zum Readout. Der Aufwand auf unserer Seite liegt typischerweise bei 4 bis 6 Beratertagen — der Rest ist eure Terminlage.
- 5 bis 8 Arbeitstage Gesamtdauer, abhängig davon, wie schnell die Interviews zustande kommen.
- 3 bis 6 Interviews à 45 bis 60 Minuten, verteilt über Führung, Plattform und Produktteams.
- Zwei Termine mit euch: Readout und technische Übergabe.
- Der Fit-Check davor dauert 30 Minuten und kostet nichts.
Preis
Festpreis, keine Tagessatz-Diskussion. Der Einstieg liegt bei 6.500 bis 9.500 Euro zuzüglich Umsatzsteuer und Reisekosten. Ihr kauft keine Beratertage, sondern eine unabhängige Entscheidungsgrundlage und einen priorisierten Investitionsplan.
- Wo im Rahmen ihr landet, hängt an der Zahl der Teams und Produktbereiche, nicht an der Zahl der Termine.
- Größere oder stark verteilte Organisationen bekommen nach dem Fit-Check einen eigenen Zuschnitt — dann ist es ein anderes Angebot, kein aufgeblähtes.
- Der Preis steht vor der Beauftragung fest und ändert sich während der Durchführung nicht.
- Eine Folgebeauftragung ist nicht Teil des Angebots und keine Bedingung.
Wenn nach dem Fit-Check klar ist, dass ein kleinerer Schnitt genügt — ein Architektur-Review oder ein moderierter Entscheidungsworkshop — sagen wir das und verkaufen das kleinere Format.
Wie das Ergebnis aussieht
Der Bericht folgt immer derselben Gliederung. Unten steht sie vollständig, dazu eine Empfehlungskarte in genau der Form, in der sie im Bericht steht.
Gliederung des Berichts
- Entscheidungszusammenfassung
- Wachstumsziel und zugrunde gelegte Annahmen
- Fähigkeiten im Ist-Zustand
- Größte Risiken und Engpässe, je mit Beleg und Geschäftsfolge
- Verantwortungs- und Schlüsselpersonenkarte
- Investitionsoptionen und ihre Zielkonflikte
- Schnelle Verbesserungen
- Aktionsplan für 90 Tage
- Roadmap für 6 bis 12 Monate
- Kennzahlen und Messlücken
- Empfohlene Verantwortliche und Reihenfolge
- Optionale Umsetzungswege
Eine Empfehlung im Bericht
Beispielhafte Empfehlung — Aufbau, nicht Inhalt
- BelegBeispiel ausstehend
- Die Messung oder Beobachtung, auf der die Empfehlung beruht, mit Quelle.
- Erwartete WirkungBeispiel ausstehend
- Was sich verändert, wenn die Empfehlung umgesetzt wird — als Richtung und Größenordnung, nie als versprochene Zahl.
- Dringlichkeit
- Sofort, in diesem Quartal oder planbar — mit dem Ereignis, das die Frist setzt.
- Aufwandsspanne
- Eine Spanne, keine Punktschätzung, mit den Annahmen dahinter.
- Abhängigkeit
- Was vorher stehen muss, damit die Maßnahme überhaupt wirken kann.
- Verantwortliche Rolle
- Die Rolle, die es verantwortet — benannt als Rolle, nicht als Person.
- Sicherheit
- Hoch, mittel oder niedrig, mit der Begründung, warum sie nicht höher ist.
Zwei Felder sind als ausstehend markiert. Dort steht im echten Bericht ein konkreter Befund, und der bleibt hier leer, bis ein Auftraggeber die Veröffentlichung eines anonymisierten Beispiels freigegeben hat. Wir füllen sie nicht mit erfundenen Zahlen — das wäre genau die Art Beleg, die dieser Bericht widerlegen soll.
Was uns qualifiziert
Durchgeführt wird das Assessment von Matthias Bruns, Gründer von Appetizer Labs: 15+ Jahre in Software Engineering und technischer Führung, die letzten davon in Cloud-Native und Platform Engineering. Grundlage sind Projekte, in denen genau diese Fragen praktisch beantwortet wurden — technische Leitung verteilter Teams, Plattform- und Architekturarbeit im Konzernumfeld, Modernisierung gewachsener Systeme.
Was hier bewusst fehlt: Kennzahlen zu erzielten Ergebnissen. Wir veröffentlichen keine Zahl, die ein Auftraggeber nicht freigegeben hat, und dieses Angebot ist neu — es gibt also noch keine. Was ihr stattdessen prüfen könnt: die Projektmuster in den Referenzen und öffentlich einsehbaren Code.
Häufige Fragen
Müssen wir danach mit euch weiterarbeiten?
Nein. Der Bericht ist so geschrieben, dass euer Team ihn allein umsetzen kann: Verantwortliche, Abhängigkeiten und Reihenfolge stehen drin. Wenn ihr Unterstützung wollt, gibt es Wege dafür — sie sind eine Option im Bericht, keine Bedingung.
Wir messen unsere Durchlaufzeiten nicht. Geht das trotzdem?
Ja. Fehlende Messung ist selbst ein Befund und einer der häufigsten. Wir arbeiten dann mit dem, was da ist — Ticket-Historie, Deployment-Verlauf, Vorfallsdokumentation, und vor allem mit den Interviews. Im Bericht steht anschließend, welche drei bis fünf Kennzahlen ihr ab sofort erheben solltet.
Wie viel Zeit kostet uns das?
Pro Gesprächspartner 45 bis 60 Minuten, dazu zwei gemeinsame Termine für Readout und Übergabe. Das Zusammentragen der Unterlagen liegt erfahrungsgemäß bei einem halben Tag. Mehr fordern wir nicht an.
Bewertet ihr einzelne Mitarbeitende?
Nein, und wir liefern auch keine Grundlage dafür. Interviews sind vertraulich; im Bericht erscheinen Rollen und Systeme, keine Namen. Wenn eine Aussage nur mit Namen verständlich wäre, formulieren wir sie um oder lassen sie weg.
Ist das ein Sicherheitsaudit oder eine technische Due Diligence?
Weder noch, auch wenn es sich überschneidet. Wir prüfen keine Zertifizierungsfähigkeit und führen keinen Penetrationstest durch. Für eine Due Diligence im Beteiligungskontext ist der Zuschnitt anders — sprecht uns darauf an, dann klären wir im Fit-Check, ob dieses Format passt.
Wer führt das Assessment durch?
Der Gründer, durchgehend. Wer die Interviews führt, schreibt den Bericht und sitzt im Readout. Es gibt kein Juniorteam, das Material zuliefert, und keine Übergabe an jemanden, der eure Situation nur aus Notizen kennt.
Was passiert nach der Anfrage?
Ihr bekommt innerhalb von zwei Arbeitstagen eine Antwort mit zwei Terminvorschlägen für den 30-minütigen Fit-Check. Nach dem Fit-Check erhaltet ihr ein Festpreisangebot mit Zuschnitt, Zeitplan und den benötigten Gesprächspartnern — oder die Empfehlung, etwas anderes zu tun.
~/appetizer-labs/fit-check
Assessment besprechen
Beschreibt kurz eure Ausgangslage. Ihr bekommt eine Einschätzung, ob dieses Assessment zu eurer Situation passt — auch wenn die Antwort lautet, dass ihr es nicht braucht.
Noch nicht sicher, ob das der richtige Auftrag ist? Klärt es in einer Viertelstunde, mit dem Ingenieur, der die Arbeit später macht. Fit-Check buchen