Stakeholder Management

Lernziele

Nach dieser Lektion kannst du mit den vier wichtigsten Stakeholder-Gruppen eines Platform Engineers kommunizieren — Entwickler, SRE, Security und Management — jeweils in der Sprache, die für sie zählt. Du kennst Formate für schwierige Gespräche (Verzögerung, Incident, Scope-Schnitt) und weißt, wie du Vertrauen aufbaust, obwohl du niemandem disziplinarisch vorgesetzt bist.

Das Problem: dieselbe Nachricht, vier verschiedene Ohren

Stell dir vor, du schreibst ein Update: „Wir verschieben das Self-Service-Cluster-Provisioning um drei Wochen, weil wir zuerst die Kyverno-Baseline-Policies für alle Tenants ausrollen müssen.”

Team Backend liest: „Wieder Verzögerung, wieder Platform blockiert uns.” SRE liest: „Endlich, Policies vor mehr Wildwest-Namespaces.” Security liest: „Gut — aber warum nicht zwei Wochen früher?” Dein Engineering Manager liest: „Ist das ein Risiko für den Q3-Launch von Commerce?”

Gleicher Text, vier völlig verschiedene Reaktionen. Platform Engineers scheitern selten an fehlendem technischem Wissen — sie scheitern daran, dass sie einmal schreiben und erwarten, dass alle gleich verstehen. Stakeholder Management heißt: dieselbe ehrliche Botschaft, aber mit unterschiedlichem Fokus, Detailgrad und Handlungsaufforderung je nach Zielgruppe.

Die vier Stakeholder: was sie wirklich hören wollen

Entwickler (deine Kunden): Sie wollen wissen, wie schneller und einfacher ihr Alltag wird — oder warum es gerade nicht geht und wann es geht. Technische Details nur, wenn sie Entscheidungen betreffen. „Wir migrieren auf OCI-Helm-Charts” interessiert sie weniger als „Ab nächster Woche deployt ihr mit einem Befehl statt mit zwölf YAML-Dateien.”

Sprich über: Time-to-Production, Self-Service, Docs, Support-Reaktionszeit. Zeig Working Software früh — ein 20-Minuten-Demo schlägt ein 40-seitiges Konzeptdokument.

SRE / Platform Operations: Sie wollen Stabilität, klare Runbooks und einen Plan für den schlechten Tag. Ihre Frage ist nicht „Ist das modern?”, sondern „Was passiert um 3 Uhr nachts, wenn das kaputtgeht?”

Sprich über: SLOs, Error Budgets, Rollback-Strategie, Blast Radius, On-Call-Impact. Bring sie früh ins Design Review — nicht erst zur Abnahme. Wer SRE erst bei Go-Live einbindet, bekommt ein Veto, das teuer ist.

Security / Compliance: Sie wollen Risikoreduktion, Auditierbarkeit und Least Privilege — nicht „wir sind eh sicher, weil Kubernetes”. Ihre Sprache: Controls, Evidence, Policy-as-Code, Datenklassifizierung.

Sprich über: Welche Controls ihr einbaut, welche Evidence ihr automatisch liefert, wo Escape Hatches dokumentiert sind. Security wird zum Partner, wenn du ihre Anforderungen ins Design einbaust statt als Gate am Ende.

Management (EM, Director, VP Engineering): Sie wollen Outcomes, Risiken und Trade-offs in Geschäftssprache. Nicht „wir haben Argo CD upgraded”, sondern „Deploy-Frequenz ist von wöchentlich auf täglich gestiegen, Error Budget der CI-Plattform liegt bei 92 %.”

Sprich über: Adoption-Metriken, Kosten (oder Einsparungen), Risiko für Launches, was du bewusst nicht machst und warum. Ein Slide mit drei KPIs und einem klaren Ask schlägt eine Stunde Architekturdiagramm.

Formate, die in der Praxis funktionieren

RFC für größere Entscheidungen: Kurzes Dokument mit Problem, Lösung, Alternativen — plus Kommentierfrist. Für alles, was mehr als ein Team betrifft oder schwer rückgängig zu machen ist.

Office Hours: Feste Stunde pro Woche, offen für alle Teams. Senkt Hemmschwelle und gibt dir Stimmungen, bevor sie Eskalationen werden.

Incident-Kommunikation: Was passiert, wer ist betroffen, was tun wir jetzt, wann das nächste Update kommt. Kein „wir untersuchen noch” ohne Zeitstempel.

Schlechte Nachrichten früh: Betroffene informieren, bevor sie es von anderen hören. Formel: Was ändert sich → Warum → Neuer Plan → Was bleibt → Feedback-Kanal.

Vertrauen ohne Authority

Platform Engineers führen selten disziplinarisch — sie führen durch Glaubwürdigkeit. Drei Hebel, die in Interviews glaubwürdig klingen, wenn du sie mit Beispielen untermauerst:

Zuverlässigkeit: Du sagst, was du tust, und tust, was du sagst. Roadmap-Dates, die du nicht hältst, sind Gift. Lieber ein Quartal mit weniger Items und höherer Trefferquote als ein vollgestopftes Board.

Kompetenz sichtbar machen: Nicht prahlen — lösen. Wenn ein Team drei Tage an einem RBAC-Problem hängt und du in einer Stunde den Grund findest, hast du Vertrauen für die nächste schwierige Konversation gesammelt.

Interessen der anderen ernst nehmen: Security will nicht langsamer machen — sie will nicht im Audit erklären müssen, warum jeder Namespace cluster-admin hat. Wenn du das verstehst und in deine Lösung einbaust, wird Security zum Fürsprecher statt zum Blocker.

Praxis: Stakeholder-Nachrichten umschreiben

Nimm eine echte oder fiktive Plattform-Entscheidung — z. B. „Wir führen Network Policies als Default für alle neuen Namespaces ein.”

1. Rohfassung (5 min): Schreib eine neutrale Ankündigung in fünf Sätzen.
2. Vier Varianten (25 min): Passe die Nachricht für Entwickler, SRE, Security und Management an — jeweils maximal sechs Sätze, anderer Einstieg, anderer Fokus, dieselben Fakten.
3. Schlechte-Nachricht-Übung (10 min): Variante „Wir müssen den Rollout um vier Wochen verschieben.” Schreib die Entwickler-Version so, dass sie nicht nach Ausrede klingt, aber ehrlich bleibt.
4. Review (5 min): Lies die Management-Version laut. Enthält sie einen KPI oder ein Risiko in Geschäftssprache? Wenn nicht, nachschärfen.

Typische Stolperfallen

One-Size-Fits-All-Kommunikation: Ein Slack-Post an #general reicht selten. Entwickler brauchen oft Details in #platform-support, Management eine Zusammenfassung im Weekly.

Nur nach oben, nicht nach unten: Wer nur dem EM glänzt, aber Entwickler im Dunkeln lässt, bekommt Adoption-Probleme und schlechte Interview-Stories.

Security als Gate statt Partner: „Wir gehen zu Security, wenn es fertig ist” produziert Vetos. „Wir zeigen den Draft-ADR in Woche zwei” produziert Allianzen.

Technische Wahrheit ohne Empathie: „Das ist architektonisch falsch” mag stimmen — aber ohne Alternative und ohne Verständnis für den Zeitdruck des Teams wirkt es wie Arroganz.

Interview-Vorbereitung

„Wie arbeitest du mit Security, SRE und Produktteams zusammen?” — Antwortstruktur: Vier Gruppen kurz benennen → Je eine Kommunikationsanpassung → Konkretes Format (RFC, Office Hours, Design Review) → Beispiel, wo frühe Einbindung einen Konflikt verhindert hat.

Rechne mit diesen Follow-ups:

• „Wie kommunizierst du schlechte Nachrichten?” — Früh, direkt an Betroffene, mit neuem Plan und Feedback-Kanal; Beispiel nennen.
• „Wie baust du Vertrauen ohne disziplinarische Führung?” — Zuverlässigkeit, sichtbare Kompetenz, Interessen ernst nehmen; keine Buzzwords ohne Story.
• „Security blockiert dein Feature — was tust du?” — Anforderung verstehen, in Lösung einbauen, Evidence automatisieren; nicht eskalieren, bevor du konstruktiv nachgebessert hast.

Checkliste

• Ich kann in einem Satz sagen, was jede der vier Gruppen primär interessiert.
• Ich habe ein Beispiel für ein RFC oder ein frühes Design Review mit SRE/Security.
• Ich kann eine schlechte Nachricht (Verzögerung/Incident) in der Entwickler-Sprache formulieren.
• Ich habe eine Story zu Vertrauensaufbau ohne Authority (STAR, 60–90 Sekunden).
• Ich kenne drei Metriken, mit denen ich Management die Plattform erklären würde.

Zusammenfassung

Stakeholder Management für Platform Engineers ist Übersetzungsarbeit: dieselbe ehrliche Botschaft, angepasst an das, was Entwickler, SRE, Security und Management jeweils für Entscheidungen brauchen. Formate wie RFCs, Office Hours und strukturierte Incident-Updates schaffen Vorhersagbarkeit; Vertrauen entsteht aus Zuverlässigkeit und früher Einbindung, nicht aus Titeln. In der nächsten Lektion wendest du dieselbe Ehrlichkeit auf dich selbst an — wenn der Interviewer fragt: „Erzähl von einem Fehler.”