Konflikte und Priorisierung

Lernziele

Nach dieser Lektion kannst du Konflikte zwischen Entwicklerteams und begrenzter Plattform-Kapazität strukturiert lösen — nicht durch Lautstärke, sondern durch transparente Priorisierung. Du kennst ein Framework, um widersprüchliche Feature-Wünsche in eine begründete Roadmap-Reihenfolge zu übersetzen, und hast mindestens zwei STAR-ready Stories vorbereitet, die zeigen, wie du unpopuläre Entscheidungen kommunizierst, ohne Vertrauen zu verlieren.

Das Problem: alle wollen alles sofort

Als Platform Engineer sitzt du zwischen mindestens drei konkurrierenden Kräften. Team Payments will Multi-Region-Cluster bis Q2, weil der Launch dort steht. Team Data braucht dringend GPU-Nodes für ein Modell-Retraining. Security fordert, dass erst Kyverno-Policies für alle Namespaces live sind, bevor irgendwer neue Cluster bekommt. Dein Team hat sechs Leute und Kapazität für vielleicht zwei größere Initiativen im Quartal.

Das ist kein Ausnahmefall — das ist der Normalzustand. Plattform-Teams sind Schnittstelle, nicht Endpunkt. Wer in Interviews sagt „Ich höre allen zu und finde einen Kompromiss”, klingt nett, aber unglaubwürdig: Ein Kompromiss, bei dem jeder halb zufrieden ist, liefert oft nichts Fertiges. Senior-Kandidaten zeigen stattdessen einen Prozess: Konflikt benennen, Daten sammeln, transparent priorisieren, Entscheidung dokumentieren, kommunizieren — auch wenn nicht jeder gewinnt.

Priorisierung: Daten schlagen Meinungen

Bevor du über Frameworks sprichst, gilt eine Grundregel: Priorisierung ohne Daten ist Politik. Wer „Team A schreit lauter” als Kriterium nennt, hat den Job als Platform Product Owner noch nicht verstanden.

Drei Datenquellen, die in echten Organisationen funktionieren:

Nutzungs- und Journey-Metriken: Wie viele Teams sind betroffen? Wie viele Deployments pro Woche warten auf diese Capability? Was kostet der Status quo in Kalendertagen? „12 Teams warten im Median 9 Tage auf Cluster-Provisioning” ist ein Argument. „Team X ist unzufrieden” ist Stimmung.

Business-Kontext vom Product Owner: Welcher Launch, welche Compliance-Frist, welches Revenue-Risiko? Du musst nicht selbst CFO sein — aber du musst die Frage stellen und die Antwort in deine Entscheidung einbauen.

Aufwand und Risiko deines Teams: Nicht alles, was dringend ist, ist in einem Sprint machbar. Ein ehrlicher T-Shirt-Size-Schätzung verhindert Roadmap-Versprechen, die du nicht halten kannst.

Darauf setzt du ein Raster — RICE ist in Platform-Kontexten am verbreitetsten:

• Reach: Wie viele Teams oder Deployments profitieren im nächsten Quartal?
• Impact: Wie stark reduziert es Wartezeit, Incidents oder Cognitive Load? (Skala 0,25 bis 3)
• Confidence: Wie sicher bist du bei Reach und Impact — hast du Interviews, Tickets, Telemetrie, oder nur eine Slack-Nachricht?
• Effort: Person-Wochen deines Teams, inklusive Betrieb danach.

Beispiel: GPU-Nodes für ein Team (R: 1, I: 3, C: 0,8, E: 4) vs. Self-Service-Provisioning für 15 Teams (R: 15, I: 2, C: 0,9, E: 6). Die Rechnung liefert ein Gespräch, kein Orakel — aber sie zwingt alle, dieselben Variablen zu benennen.

Konflikte lösen: der Ablauf in fünf Schritten

Wenn zwei Teams widersprüchliche Features wollen, hilft diese Reihenfolge — und genau die kannst du als STAR-Story erzählen:

1. Interessen trennen von Positionen. „Wir brauchen Argo CD” ist eine Position. „Wir wollen ohne Platform-Ticket deployen können” ist ein Interesse. Oft wollen beide Seiten dasselbe, nur mit anderem Tool-Vorschlag.

2. Gemeinsame Constraints auf den Tisch legen. Kapazität, Security-Mindestanforderungen, Wartungsfenster. Das sind keine Ausreden — das sind die Spielregeln, innerhalb derer priorisiert wird.

3. Optionen benennen, nicht nur Ja/Nein. „GPU-Nodes jetzt” vs. „GPU-Nodes in vier Wochen plus temporärer Zugang über Shared Pool” vs. „Managed Service extern bis die Plattform-Capability steht”. Drei Optionen machen aus einem Konflikt eine Entscheidung.

4. Entscheiden und dokumentieren. Ein ADR (Architecture Decision Record) mit: Kontext, betrachtete Alternativen, Entscheidung, Konsequenzen. Nicht für die Schublade — verlinkt in der öffentlichen Roadmap, damit niemand drei Monate später behauptet, die Entscheidung sei vom Himmel gefallen.

5. Kommunizieren, wer was wann bekommt — und was nicht. Das Team, das warten muss, braucht ein Datum und einen Grund, kein „wir schauen mal”. Vertrauen entsteht aus Vorhersagbarkeit, nicht aus Zustimmung zu jeder Entscheidung.

STAR-Story: unpopuläre Priorisierung

Eine Story, die du als Vorlage nutzen und auf deine Erfahrung anpassen kannst:

Situation: Zwei Stream-Teams, 40 Entwickler insgesamt, ein Platform-Team mit drei Engineers. Team Commerce wollte ein neues Observability-Dashboard im Portal; Team Platform-Internal (ironischerweise ein App-Team) blockierte indirekt alles, weil sie zuerst ein VPC-Peering für eine Compliance-Audit-Frist in sechs Wochen brauchten.

Task: Als Platform Engineer sollte ich die Q3-Roadmap vorschlagen — mit Platz für genau eine größere Initiative neben dem laufenden Betrieb.

Action: Ich habe mit beiden Tech Leads Interviews geführt — nicht „was wollt ihr”, sondern „was passiert, wenn es Q3 nicht kommt?” Commerce: unbequem, aber workaround-fähig. Platform-Internal: Audit-Finding, mögliches Deployment-Freeze. Ich habe die RICE-Rechnung transparent gemacht, drei Optionen skizziert und ein ADR geschrieben. Übergang: minimales Grafana-Deep-Link-Dashboard in zwei Tagen mit einem Commerce-Entwickler.

Result: VPC-Peering vor Audit-Frist fertig, kein Freeze. Commerce nutzte den Deep-Link drei Monate, danach das Portal-Feature. Null Escalations.

Praxis: zwei Stories in 45 Minuten vorbereiten

1. Story-Inventar (10 min): Liste drei Konfliktsituationen aus Projekten. Ohne Plattform-Erfahrung: DevOps- oder Teamlead-Kontext — die Struktur überträgt sich.

2. STAR ausformulieren (20 min): Stärkste Situation wählen, pro Buchstabe max. vier Sätze. Action in Ich-Form? Result mit Zahl?

3. Zweite Story (10 min): Etwas, das du bewusst nicht gemacht hast — und warum.

4. Laut üben (5 min): 90 Sekunden pro Story. Zu lang? Situation kürzen.

Typische Stolperfallen

Konsens-Illusion: „Alle einbinden, bis alle zustimmen” skaliert nicht und verzögert Entscheidungen. Konsultation ja, Vetorecht für jedes Team nein.

Priorisierung nur im Kopf: Ohne dokumentiertes Raster wird jede Roadmap-Änderung zum Machtspiel. Schreib die Rechnung auf — auch wenn sie unvollkommen ist.

Nur nach oben kommunizieren: Teams, die warten müssen, erfahren es oft als Letzte. Schlechte Nachrichten gehören direkt an die Betroffenen, nicht nur ins Management-Update.

Technische Lösung für Organisationsproblem: Wenn zwei Teams dasselbe Problem haben, aber unterschiedliche Workarounds, ist manchmal Standardisierung die Antwort — manchmal ein fehlender Product Owner auf einer Seite. Erkenne, wann du nicht der richtige Schiedsrichter bist.

Interview-Vorbereitung

Die Frage „Zwei Teams wollen widersprüchliche Platform-Features — wie gehst du vor?” beantwortest du am stärksten so: Konflikt benennen (unterschiedliche Interessen, gleiche Kapazität) → Daten (Metriken, Business-Fristen, Aufwand) → Framework (RICE o. Ä., kurz erklärt) → Prozess (Optionen, ADR, Kommunikation) → STAR-Beispiel (konkret, mit Ergebnis).

Rechne mit diesen Follow-ups:

• „Wie priorisierst du die Roadmap bei begrenzter Kapazität?” — RICE mit Beispiel-Zahlen, öffentliche Roadmap, regelmäßiger Review-Rhythmus.
• „Beschreibe eine unpopuläre Priorisierung.” — Fertige STAR-Story, ehrlich über das Team, das warten musste, und was du zur Abmilderung getan hast.
• „Was, wenn Management deine Priorisierung überschreibt?” — Umsetzen, dokumentieren, später mit Daten nach evaluieren — nicht passive Aggression.

Checkliste

• Ich habe mindestens zwei STAR-Stories zu Konflikt und Priorisierung (je 60–90 Sekunden).
• Ich kann RICE in zwei Sätzen erklären und ein Beispiel mit Zahlen rechnen.
• Ich kenne drei Datenquellen für Priorisierung (Metriken, Business-Kontext, Aufwand).
• Ich kann den Unterschied zwischen Interesse und Position an einem Plattform-Beispiel zeigen.
• Ich habe eine Antwort auf „unpopuläre Entscheidung” — inklusive wie ich sie kommuniziert habe.

Zusammenfassung

Konflikte sind bei Platform Engineers Normalzustand, kein Zeichen von Scheitern. Wer überzeugt, sammelt Daten statt Meinungen, priorisiert transparent mit einem nachvollziehbaren Raster wie RICE, dokumentiert Entscheidungen in ADRs und kommuniziert klar, wer was wann bekommt. Im Interview zählt eine konkrete STAR-Story mehr als das Wort „Kompromiss”. In der nächsten Lektion geht es darum, dieselbe Klarheit auf unterschiedliche Stakeholder-Gruppen zu übertragen — Security, SRE, Management und Entwickler sprechen nicht dieselbe Sprache, auch wenn sie über dieselbe Plattform reden.