Embedded Delivery Support - Wie es funktioniert
Ein Developer-Advocate-Engagement beginnt mit einem kurzen Gespräch und wechselt dann schnell in gemeinsame Sichtbarkeit und reale Arbeit. Es geht um praktische Unterstützung für die Menschen, die die Arbeit leisten, und für die Menschen, die Auslieferung verantworten.
Die Kurzfassung
- Wir sprechen 30 Minuten.
- Wir wählen einen von drei Startmodi.
- Wir arbeiten diesen Startmodus mit den Beteiligten durch.
- Wir erstellen die Leistungsvereinbarung gemeinsam mit dem CTO.
- Wir steigen remote ein und arbeiten mit den Personen, die für die jeweilige Aufgabe relevant sind.
- Am ersten Tag helfen wir möglichst an etwas Konkretem, oft durch Bugfixing im Pairing.
- Wir ziehen uns zurück, sobald das Team die Verbesserungen selbst tragen kann.
Wie es beginnt
Es gibt drei Wege für den Start. Das sind Optionen, keine feste Reihenfolge.
Option 1: Direkter Einstieg
Manchmal ist der beste Start, direkt einzusteigen und eng mit dem CTO oder einer anderen relevanten Person zu arbeiten.
Der CTO stellt uns vor, gibt uns Zugang und Raum, um direkt mit den Beteiligten zu arbeiten und dort zu pairen, wo es hilft.
Nach ein paar Tagen setzen wir uns mit dem CTO zusammen und definieren gemeinsam die passende Leistungsvereinbarung. Das ist ein Einstieg mit geringem Druck, bei dem der CTO die Kontrolle behält und von Anfang an informiert ist.
Option 2: Start mit Navigator
Manchmal ist der richtige Start ein vierwöchiger Navigator-Zeitraum, damit die Beteiligten ihre Sicht aus der normalen Arbeit einbringen können.
Navigator ersetzt zähe Interviewrunden durch leichtgewichtige tägliche Eingaben und eine qualitative Wochen-Synthese, die wirklich nutzbar ist. Das Ergebnis ist kein KPI-Dashboard. Es ist eine qualitative Wochen-Synthese: Muster, Risiken, Empfehlungen und Schlussfolgerungen aus der realen Arbeit. Ein Beispiel finden Sie auf der Navigator-Seite.
Option 3: Start mit dem KI-Kurs
Wenn ein Team mit KI sofort starten will, können wir das über den Kurs KI-gestützte Entwicklung für ein Entwicklerpaar tun.
Wir arbeiten dabei in der realen Codebasis des Teams. So entstehen die entscheidenden Fragen sofort im Kontext der täglichen Arbeit. Der Kurs endet wie vereinbart. Wenn danach breitere Unterstützung sinnvoll ist, entscheidet der CTO separat.
Danach definieren wir die Arbeit gemeinsam
Nach einem dieser drei Einstiege erstellen wir die Leistungsvereinbarung gemeinsam mit dem CTO und setzen sie um.
Wir arbeiten für den CTO. Das bedeutet: Der CTO bleibt nah dran und informiert.
Wir dokumentieren laufend und teilen diese Notizen mit dem CTO. Wir zeigen Fortschritt gegen die Leistungsvereinbarung und machen Hindernisse, Risiken und offene Punkte früh sichtbar. Der CTO soll jederzeit wissen, wo wir stehen, was besser wird und was Aufmerksamkeit braucht.
So bleibt der CTO in Führung, trifft fundierter Entscheidungen und handelt aus einer stärkeren Position.
Navigator ist unsere eigene Plattform. Das Logbook ist ein Produkt darin. Wir nutzen die Plattform auch, um die Zusammenarbeit strukturiert und sichtbar zu halten, statt uns in E-Mail-Ketten, Meetings und Beratungsnebel zu verlieren.
Was beim Start passiert
Wir kommen remote dazu und arbeiten sofort praktisch.
Das kann Pairing mit einem Entwickler sein, direkte Arbeit mit dem CTO, eine Entscheidungsklärung mit dem CEO oder Zusammenarbeit mit einer anderen Rolle, die für die konkrete Aufgabe relevant ist. Wir starten dort, wo die reale Arbeit ist.
Wir arbeiten über Navigator, unsere Plattform für strukturierte Zusammenarbeit. Das Logbook ist ein Teil davon. Navigator unterstützt auch Terminierung, Retainer, Abrechnung, gemeinsame Notizen und Sichtbarkeit über die Arbeit. Die normale Einheit ist ein Halbtagsblock.
Teams buchen meist Retainer mit 10 oder 20 Halbtagsblöcken pro Monat. Diese Blöcke werden dann nach Bedarf geplant und genutzt. Jede Person, die der CTO einbeziehen möchte, kann gegen den Retainer buchen und Blöcke nutzen.
Einige Sessions sind eins zu eins, andere mit mehreren Personen. Das richtet sich nach der Aufgabe.
Entscheidend ist, was in diesen Sessions passiert.
Wir nutzen sie für praktische Arbeit, zum Beispiel:
- Pairing mit einem Entwickler an einem realen Bug oder Change
- Arbeit mit dem CTO an einer Lieferentscheidung oder einem technischen Trade-off
- gemeinsame Entstörung eines Lieferproblems mit mehreren Beteiligten
- Review von Code, Tests oder Auslieferungsfluss im realen System
- Umwandlung wiederkehrender Reibung in einen konkreten nächsten Schritt
Wenn möglich, verankern wir die erste Session an etwas Konkretem. Ein typischer Fall ist Bugfixing im Pairing. Dann ist sofort klar, wie die Zusammenarbeit aussieht.
Sichtbar wird Unterstützung in der Arbeit selbst. Menschen bekommen Hilfe dort, wo sie feststecken. Der CTO bleibt informiert und in Führung. Der Kunde bleibt nie im Unklaren darüber, was passiert, was erledigt wurde und was als Nächstes ansteht. Teams bekommen Entlastung von wiederkehrender Reibung. Keine Methode, keine Slides, kein Reporting-Theater, kein Audit-Theater.
Wer eingebunden sein sollte
Ein gutes Engagement braucht:
- einen Sponsor, meist Eigentümer, Gründer oder CTO
- Entwickler, die direkt in Code, Tests und Auslieferung zusammenarbeiten wollen
- ausreichend Zugriff auf Produkt und realen Auslieferungspfad
- Einigkeit, dass wir für Lieferfähigkeit arbeiten, nicht für interne Politik
Mehr braucht es nicht. Es braucht kein Launch-Event.
Wie es endet
Das Engagement endet, wenn das Team die Veränderungen ohne uns tragen kann, die Auslieferung stabiler ist und dieselbe Reibung nicht Woche für Woche zurückkommt.
Das Ziel ist nicht Abhängigkeit. Das Ziel ist Fähigkeit.
Bereit, Ihrem Team dieselbe Zukunft zu geben? Und sich selbst die starke Position, die Sie verdienen?
Gespräch buchen
