Leadership ohne Authority

Lernziele

Nach dieser Lektion kannst du erklären, wie Platform Engineers ohne disziplinarische Macht technische Richtung vorgeben, Standards durchsetzen und Teams mitnehmen — ohne zum Gatekeeper zu werden. Du kennst die vier Hebel (Expertise, Prozess, Beziehungen, Ergebnisse), kannst ein STAR-Beispiel für Influence without Authority formulieren und weißt, wie du im Interview die Balance zwischen Golden Path und Team-Autonomie argumentierst.

Das Paradox der Platform-Rolle

Du hast kein Team, das dir berichtet. Du hast kein Budget, das du verteilst. Du hast kein OKR, das Stream-Teams dir schulden. Trotzdem entscheidest du mit, welche Kubernetes-Version läuft, welche CI-Pipeline Standard wird und ob ein Team einen eigenen Cluster bekommt oder in den Shared Pool muss.

Das ist Leadership ohne Authority — und es ist der Kern dessen, was Senior- und Staff-Platform-Interviews testen. Nicht „Kannst du Terraform?”, sondern „Kannst du 40 Teams auf einen gemeinsamen Weg bringen, ohne sie zu zwingen?”

Wer das nicht kann, baut entweder ein Ticket-System (Platform als Bottleneck) oder einen Wildwuchs (jedes Team macht sein Ding). Beides scheitert — nur mit unterschiedlicher Latenz.

Vier Hebel, die wirklich funktionieren

Expertise. Du musst nicht alles wissen, aber du musst in deinem Domäne die vertrauenswürdigste Stimme sein. Wenn du bei Network Policies unsicher bist, delegierst du — aber bei Cluster-Upgrades, GitOps-Strategien oder Developer-Onboarding solltest du die Person sein, die andere fragen. Expertise ist dein härtester Hebel, weil sie nicht von Organigrammen abhängt.

Prozess statt Person. RFCs, Architecture Decision Records, Tech Talks, Office Hours. Wer Entscheidungen in nachvollziehbare Prozesse packt, braucht weniger persönliche Überzeugungsarbeit. Ein RFC „Cluster-Upgrade-Strategie Q3” mit klaren Trade-offs überzeugt mehr als fünf Slack-DMs an Einzelpersonen — und überlebt deinen Urlaub.

Beziehungen vor Mandat. Platform-Arbeit ist 60 % Technik und 40 % Soziologie. Kenn die Tech Leads der Stream-Teams. Verstehe, warum Team Payments einen eigenen Ingress-Controller will. Wer nur über Policies spricht, verliert gegen jemanden, der vorher zugehört hat.

Ergebnisse sichtbar machen. Adoption, Lead Time, Incident-Rate, Ticket-Volumen — wenn du zeigen kannst, dass der Golden Path Deployments von 45 auf 12 Minuten bringt, brauchst du weniger Argumente. Metriken sind dein stiller Mandatsverstärker.

Konkretes Beispiel: Golden Path vs. Wildwuchs

Stell dir vor: Drei Teams deployen auf drei verschiedene Arten — Helm per Hand, raw YAML und ein selbstgebautes Bash-Skript. Du willst einen Golden Path mit Argo CD und einem Standard-Chart.

Gatekeeper-Ansatz (schlecht): „Ab nächstem Monat nur noch über unsere Pipeline. Alles andere wird abgelehnt.” → Drei Teams finden Workarounds, du wirst zum Ticket-Monster.

Leadership-Ansatz (gut):

1. Problem benennen: „Wir haben drei Deploy-Wege — das macht Upgrades und Incident-Response teuer.”
2. RFC schreiben: Golden Path mit klaren Vorteilen, dokumentiertem Escape Hatch und Migrationspfad.
3. Pilot-Team gewinnen: Team, das schon frustriert ist, als Early Adopter — Erfolg sichtbar machen.
4. Metriken zeigen: „Team Alpha deployt jetzt in 12 statt 45 Minuten.”
5. Escape Hatch offen lassen: „Wer aus gutem Grund abweicht, dokumentiert warum — kein Verbot, aber Transparenz.”

Im Interview erzählst du das als STAR: Situation (Wildwuchs), Task (Standardisierung ohne Rebellion), Action (RFC, Pilot, Metriken), Result (Adoption 70 % in drei Monaten, Ticket-Volumen −40 %).

Standards durchsetzen, Autonomie bewahren

Der häufigste Konflikt in Platform-Interviews: „Wie balancierst du Standards und Team-Autonomie?”

Schwache Antwort: „Wir setzen Standards durch Policy-as-Code.” — Das ist ein Mechanismus, keine Strategie.

Starke Antwort: „Standards dort, wo der Blast Radius groß ist — Netzwerk, Secrets, Cluster-Upgrades. Autonomie dort, wo Teams schnell experimentieren müssen — App-Code, Feature-Flags, interne Libraries. Der Golden Path ist der Default, nicht das Gesetz. Wer abweicht, braucht einen dokumentierten Grund — nicht meine Erlaubnis.”

Das zeigt: Du verstehst, dass Platform-Teams Produkte für interne Kunden bauen. Zwang tötet Adoption. Guardrails schützen, ohne zu ersticken.

Praxis: Dein Leadership-Portfolio

Bevor das nächste Interview kommt, schreib drei Geschichten auf — je eine Seite, STAR-Format:

1. Technische Richtung ohne Titel: Wann hast du eine Architekturentscheidung beeinflusst, obwohl du nicht der Entscheider warst? (RFC, Tech Talk, Pilot)
2. Konflikt gelöst: Wann wollten zwei Teams widersprüchliches — und wie hast du vermittelt?
3. Adoption vor Zwang: Wann hast du ein Platform-Feature eingeführt, das Teams freiwillig genutzt haben?

Für jede Geschichte: Was war der messbare Outcome? Wenn du keinen hast, formuliere einen realistischen: „Ticket-Volumen sank”, „drei Teams migrierten im ersten Quartal”, „Upgrade-Zeit halbiert”. Ohne Result wirkt es wie Vorsatz, nicht wie Leadership.

Übe jede Geschichte laut in unter drei Minuten. Behavioral-Interviews bei Platform-Rollen dauern oft 45 Minuten — du brauchst mindestens zwei starke Stories parat.

Typische Stolperfallen

„Ich habe es durchgesetzt.” Klingt nach Gatekeeper, nicht nach Leader. Besser: „Ich habe die Trade-offs transparent gemacht und ein Pilot-Team gewonnen.”

Kein konkretes Beispiel. „Ich glaube an Influence through Expertise” ohne Story ist wertlos. Interviewende wollen Situationen, keine Manifeste.

Nur Top-down denken. Wer Platform als Kontrollinstanz beschreibt, hat die Rolle nicht verstanden. Platform ist Enablement — auch wenn Guardrails dazugehören.

Stream-Teams als Gegner. „Die Devs verstehen Security nicht” ist ein rotes Tuch. Reife Kandidaten sprechen von Partnerschaft und gemeinsamen Zielen.

Interview-Vorbereitung

Deine Kernbotschaft: Platform Leadership ist Einfluss durch Expertise, transparente Prozesse und nachweisbare Ergebnisse — nicht durch Weisungsrecht.

Rechne mit diesen Fragen:

• „Wie führst du ohne formale Authority?” — Vier Hebel nennen, STAR-Beispiel mit messbarem Outcome.
• „Wie balancierst du Standards und Autonomie?” — Blast-Radius-Denken: Guardrails wo nötig, Escape Hatch wo sinnvoll.
• „Wie gibst du technische Richtung vor, ohne Gatekeeper zu werden?” — RFC/ADR-Prozess, Pilot-Teams, Adoption-Metriken statt Verbot.
• „Erzähl von einem Konflikt mit einem Stream-Team.” — Zuhören, Interessen verstehen, Win-win oder dokumentierter Trade-off — nie „ich habe recht bekommen”.

Checkliste

Vor deiner nächsten Senior-/Staff-Runde:

• Ich habe mindestens zwei STAR-Stories zu Influence without Authority (je unter drei Minuten).
• Jede Story hat ein messbares Result — nicht nur gute Absichten.
• Ich kann Golden Path vs. Escape Hatch in zwei Sätzen erklären.
• Ich kenne die vier Hebel und kann jeden mit einem Beispiel belegen.
• Ich beschreibe Stream-Teams als Kunden/Partner, nicht als Gegner.
• Ich habe ein Beispiel für einen RFC oder ADR, den ich geschrieben oder mitgetragen habe.

Zusammenfassung

Platform Engineers führen ohne Titel — durch Expertise, transparente Prozesse, echte Beziehungen und sichtbare Ergebnisse. Der Unterschied zwischen Gatekeeper und Leader: Der eine blockiert, der andere macht den besseren Weg so attraktiv, dass Teams ihn freiwillig wählen. Im Interview beweist du das nicht mit Schlagworten, sondern mit konkreten Geschichten und messbaren Outcomes.