Platform Adoption vorantreiben

Lernziele

Nach dieser Lektion kannst du erklären, wie du Platform Adoption vorantreibst — ohne Tools zu mandatieren und ohne auf „wenn wir es bauen, kommen sie schon” zu setzen. Du kennst Hebel wie Golden Paths, Champions und messbare Journey-Metriken, weißt, wann Escape Hatches legitim sind, und kannst im Interview eine Adoption-Story erzählen, die Technik und Nutzerzentrierung verbindet.

Das Problem: die beste Plattform, die niemand nutzt

Du kennst das Bild: Ein Platform-Team liefert nach zwölf Monaten ein beeindruckendes Setup — Backstage-Portal, Golden-Path-Templates, GitOps-Pipeline, Policy-as-Code. Launch-Meeting mit Slides. Drei Monate später: Adoption bei 15 % der Teams, der Rest deployt weiter per kubectl apply und Shell-Skripte aus 2019. Management fragt: „Warum haben wir dafür ein Team?”

Technisch richtig reicht nicht. Adoption ist das eigentliche Produkt eines Platform Engineers — und im Interview die implizite Frage hinter fast jeder Behavioral- und System-Design-Runde: Kann diese Person Plattform als Produkt denken, nicht nur als Infrastruktur?

Der reflexhafte Fehler: Mandatierung. „Ab Q3 deployt jeder nur noch über die Plattform.” Das erzeugt kurzfristige Compliance und langfristigen Widerstand. Teams finden Escape Hatches, Management verliert das Vertrauen in dein Team, und du misst Adoption an Ticket-Zählern statt an echter Nutzung.

Adoption heißt: den besseren Weg bauen, nicht den einzigen

Stell dir Adoption als Wettbewerb vor: Dein Golden Path konkurriert mit dem Workaround, den das Team seit Jahren pflegt. Der Workaround ist hässlich, aber bekannt — er funktioniert für ihre Edge Cases, sie brauchen niemanden zum Fragen, und er ist morgen verfügbar. Dein Pfad muss auf den ersten Blick spürbar einfacher sein, nicht nur auf Folie 14 des Architecture Reviews.

Drei Prinzipien, die in Interviews glaubwürdig klingen, wenn du sie mit Beispielen untermauerst:

1. Mit Schmerz starten, nicht mit Architektur. Bevor du baust, verstehst du, welcher Pain so groß ist, dass Teams wechseln wollen. Time-to-First-Deploy von 12 Tagen auf unter einen Tag ist ein Grund zu wechseln. „Wir haben jetzt Service Mesh” ist es selten.

2. Golden Path, kein Zwangsweg. Der empfohlene Weg ist der einfachste — aber ein dokumentierter Escape Hatch existiert für echte Sonderfälle. Wer Escape Hatches verbietet, verliert die ehrlichen Teams; wer sie ignoriert, verliert die Standardisierung. Beides messen.

3. Adoption ist ein Produkt-Launch, kein Deploy. Docs, Onboarding-Sessions, Champions in Stream-Teams, schneller Feedback-Kanal — das gehört in dieselbe Story wie Terraform-Module und Helm-Charts.

Die Hebel, die wirklich wirken

Developer Journey zuerst: Kartiere den Weg vom Repo bis Production (siehe Lektion 7 im Platform-Pfad). Wo sind die zwei größten Schmerzpunkte nach Dauer und Häufigkeit? Dort setzt du die erste Adoption-Welle an — nicht beim fancy Feature, das nur zwei Teams brauchen.

Champions identifizieren: Suche nicht die lautesten Fans, sondern die respektierten Pragmatiker in Stream-Teams. Ein Tech Lead, den andere Teams zitieren, der deinen Golden Path für ein echtes Projekt nutzt und dabei laut sagt „hat uns drei Tage gespart” — das ist mehr wert als ein Management-Memo.

Time-to-Value unter eine Stunde: Wenn ein Entwickler in 45 Minuten vom leeren Repo zum laufenden Service in Staging kommt, erzählt er das weiter. Wenn er drei Meetings und ein Ticket braucht, erzählt er das auch weiter.

Docs, die Aufgaben lösen: Nicht „Architektur der Plattform”, sondern „Neuen Service in 30 Minuten deployen”. Task-orientiert, mit Copy-Paste-Commands, mit einem Abschnitt „Wenn das nicht klappt”.

Feedback-Schleife: „Issue #847 gemeldet — fix ist live” schafft Vertrauen, dass die Plattform lebt.

Metriken: was du messen solltest — und was nicht

Adoption ist messbar, aber nicht mit einem einzelnen KPI:

• Time-to-First-Deploy: Ob der Einstieg wirklich einfacher ist.
• Adoption Rate: % Teams mit wiederholten Deploys über den Pfad pro Quartal — nicht einmalige Klicks.
• Escape Hatch Usage: Roadmap-Input, wo der Golden Path noch nicht reicht.
• Support-Ticket-Frequenz: Frühwarnung für fehlende Docs oder UX.
• Developer Satisfaction nach Onboarding: Weiche Metrik, aber sensibel für Stimmung.

STAR-Story: Adoption ohne Mandat

Situation: Interne K8s-Plattform, 25 Teams, Adoption des Golden-Path-Scaffolders bei unter 20 %. Viele Teams nutzten ein veraltetes Bash-Skript aus einem Referenz-Repo.

Task: Ich sollte die Adoption für das Scaffolding in sechs Monaten auf über 50 % bringen — ohne Mandatierung, Budget für zwei Personen halbtags.

Action: Fünf Teams interviewt — nicht „warum nutzt ihr uns nicht”, sondern „was macht das Skript besser?” Antwort: automatische Library-Dependencies. Die habe ich in den Scaffolder eingebaut, drei Champion-Teams früh eingebunden, „Migration in 30 Minuten”-Workshop angeboten. Escape Hatch dokumentiert für Legacy-Java-8-Services.

Result: Adoption nach vier Monaten bei 58 %, Bash-Repo archiviert. Support-Tickets −40 %. Kein Mandat.

Praxis: Adoption-Plan für ein fiktives Feature

Nimm ein Feature — z. B. „Self-Service Observability-Stack pro Namespace” — und schreib in 30 Minuten:

1. Pain (5 min): Konkretes Problem in Kalenderzeit oder Incident-Zahl.
2. Champion-Plan (5 min): Welches Team zuerst — und warum?
3. Time-to-Value (5 min): Was muss in der ersten Stunde geschafft sein?
4. Drei Metriken (5 min): Mit Zielwerten nach 90 Tagen.
5. Escape Hatch (5 min): Wann ist der alte Weg noch legitim?
6. Interview-Pitch (5 min): 60 Sekunden als strukturierte Antwort.

Typische Stolperfallen

Build it and they will come: Ohne Journey-Erhebung und Champions ist selbst gute Technik ein Geheimtipp.

Mandatierung als erste Maßnahme: Erzeugt Checkbox-Compliance — Teams deployen formal über den Pfad und umgehen ihn technisch.

Nur Early Adopters zählen: Kubernetes-Enthusiasten adoptieren alles. Die Stille Mitte entscheidet, ob die Plattform skaliert.

Escape Hatches ignorieren: Hohe Escape-Hatch-Rate heißt nicht „Teams sind böse” — es heißt „Golden Path deckt echte Fälle nicht ab.”

Adoption ohne Support: Ein Portal ohne Slack-Kanal, Docs und Office Hours ist ein Friedhof mit Login.

Interview-Vorbereitung

„Wie bringst du Teams dazu, die interne Plattform zu nutzen?” — Struktur: Schmerz verstehen → Golden Path als besserer Weg → Champions + schneller Time-to-Value → Metriken → STAR-Beispiel.

Rechne mit diesen Follow-ups:

• „Was tust du, wenn Teams den Golden Path umgehen?” — Escape Hatch prüfen: legitim oder vermeidbar? Pain des Pfads nachbessern, nicht sofort eskalieren.
• „Welche Metriken zeigen dir, ob Adoption funktioniert?” — Wiederholte Nutzung, Time-to-First-Deploy, Ticket-Trend — keine Klickzähler.
• „Wie würdest du Adoption bei skeptischen Teams angehen?” — Respektierte Champions, konkreter Nutzen für ihr nächstes Projekt, nicht Plattform-Vision.

Checkliste

• Ich kann Adoption in einem Satz als Produktproblem erklären — nicht als Technikproblem.
• Ich habe eine STAR-Story zu Adoption (mit Metrik vorher/nachher).
• Ich kenne drei Hebel: Journey/Pain, Champions, Time-to-Value.
• Ich kann erklären, wann Escape Hatches sinnvoll sind und wie ich sie messe.
• Ich habe drei konkrete Metriken mit Zielwerten für ein fiktives Feature.

Zusammenfassung

Platform Adoption ist der Beweis, dass deine Plattform ein Produkt ist. Mandatierung erzeugt Widerstand; der bessere Weg erzeugt Pull. Starte beim größten Developer-Schmerz, identifiziere Champions, mach Time-to-Value unter eine Stunde, miss wiederholte Nutzung statt Klicks, und behandle Escape Hatches als Roadmap-Signal. Im Interview überzeugt eine Story mit echten Zahlen mehr als „wir haben kommuniziert, wie toll es ist.” In der nächsten Lektion verbindest du diese Adoption-Perspektive mit der Kommunikation in System-Design-Interviews — wenn du Architektur zeichnest und gleichzeitig ein Publikum mitnimmt.