Technische Konzepte erklären

Lernziele

Nach dieser Lektion kannst du technische Konzepte zielgruppengerecht erklären — an Entwickler, Management und nicht-technische Stakeholder. Du kennst eine pragmatische Erklärungsstruktur, weißt, wie du auf dem richtigen Abstraktionsniveau bleibst, und erkennst, ob dein Gegenüber dich wirklich verstanden hat.

Das Problem: Du erklärst richtig — für die falsche Person

Ein Product Owner fragt: „Warum brauchen wir GitOps? Können die Entwickler nicht einfach deployen?” Du antwortest mit Pull-Request-Flows, Argo-CD-Reconciliation-Loops und dem Unterschied zwischen imperativen und deklarativen Deployments. Der PO nickt. In der Retro fragt er dieselbe Frage nochmal.

Das ist kein Dummheit-Problem. Du hast auf der falschen Ebene erklärt — zu viel Mechanik, zu wenig Nutzen. Platform Engineers sitzen ständig zwischen Welten: Entwickler wollen Details und Autonomie, Security will Nachweisbarkeit, Management will Risiko und Kosten verstehen, ohne YAML zu lesen. Wer immer dieselbe Erklärung gibt, scheitert bei mindestens drei von vier Gruppen.

Technische Kommunikation ist der Job, nicht die Nebenkompetenz. Golden Paths brauchen Verständnis, Budget braucht ROI-Erklärungen — und im Interview testet „Erkläre X einem Y” genau diese Fähigkeit.

Die Erklärungsstruktur: Problem zuerst, dann eine Ebene tiefer

Eine Struktur, die in fast jedem Kontext funktioniert:

1. Welches Problem löst das? — in der Sprache des Gegenübers
2. Was ist die Idee in einem Satz? — ohne Jargon, oder mit sofort erklärtem Jargon
3. Wie sieht das konkret aus? — ein Beispiel aus eurer Realität
4. Was ist der Trade-off? — ehrlich, das baut Vertrauen
5. Check: „Passt das zu eurem Bild — oder soll ich an einer Stelle tiefer gehen?”

Beispiel GitOps für einen Product Owner:

„Heute deployen manche Teams per Hand — das ist fehleranfällig und schwer nachvollziehbar, wer wann was geändert hat. GitOps heißt: Jede Infrastruktur-Änderung läuft wie Code-Review über Git. Vorteil für euch: Ihr seht in jedem Pull Request, was sich ändert, bevor es live geht. Nachteil: Teams brauchen zwei Wochen Einarbeitung, und wir müssen Legacy-Deploy-Skripte abschalten. Soll ich zeigen, wie ein typischer PR für ein neues Feature-Environment aussieht?”

Gleiches Thema für einen erfahrenen Entwickler, der Kubernetes nutzt, aber kein Argo:

„GitOps trennt wer deployt von was deployed wird. Du mergst ins Repo, Argo reconciled den Cluster-Zustand dauerhaft gegen den Git-Stand. Wenn jemand per kubectl editiert, korrigiert Argo zurück — außer du pausierst die Sync. Der Gewinn: dein Repo ist die Single Source of Truth, Rollbacks sind Git-Reverts. Der Preis: weniger Ad-hoc-Debugging im Cluster, mehr Disziplin im PR-Prozess.”

Gleiche Wahrheit, andere Tiefe.

Abstraktionsniveau wählen

Drei Zielgruppen, drei Regeln:

Nicht-technische Stakeholder (PO, Management, Legal): Metaphern und Outcomes. Keine Pod-Namen. „Namespace” wird zu „abgeschotteter Bereich für ein Team”. Zahlen helfen: „Wir sparen 20 Platform-Tickets pro Woche.”

Entwickler (nutzen die Plattform): Konkrete Workflows. Zeig den Happy Path: welcher Befehl, welches Portal, welcher PR. Sie wollen wissen, wie es ihr Leben ändert — nicht wie etcd funktioniert.

Peer Platform Engineers / SREs: Architektur, Grenzen, Betriebsmodell. Hier darfst du von CRDs und Controllern sprechen — aber trotzdem mit Problemstart, nicht mit Implementierungsdetails als Einstieg.

Der häufigste Fehler: Abstraktion nach unten korrigieren, wenn jemand nachfragt — aber nie nach oben, wenn die Augen glasig werden. Wenn du nach zwei Minuten keine Rückfrage bekommst, frag selbst: „War das zu technisch oder zu oberflächlich?”

Platform-Szenarien aus dem Alltag

Kubernetes einem Entwickler erklären, der es nicht nutzt: Nicht mit der Control Plane starten. „Stell dir vor, du schreibst eine App und willst sie hochskalieren, ohne Server zu kaufen. Kubernetes nimmt deinen Container und verteilt ihn auf Maschinen, startet ihn neu wenn er crasht, und skaliert bei Last. Du beschreibst was laufen soll, nicht wie die Maschine heißt. Bei euch würdet ihr kein kubectl brauchen — der Golden Path macht das über ein Backstage-Template.”

Policy-as-Code für Security: Regeln einmal schreiben — kein Container als root, nur approved Images — jeder Deploy scheitert automatisch bei Verstoß. Audit-Logs statt Slack-Nachfragen.

IDP für CTO: Self-Service statt Boilerplate — neuer Service in 30 Minuten statt drei Tagen, mit Security-Defaults. Adoption und Lead Time messen, nicht nur Cluster-Status.

Praxis: Erklären üben

Nimm drei Konzepte aus deinem Alltag — z. B. Namespaces, Helm, Observability-Stack. Schreib für jede Zielgruppe (PO, Entwickler, Peer) eine Erklärung in maximal 120 Wörtern. Regeln:

• Erster Satz = Problem, kein Fachbegriff
• Maximal ein neuer Fachbegriff pro Absatz, sofort erklärt
• Abschluss mit Frage oder Angebot zum Vertiefen

Übung mit Partner oder Aufnahme: Erkläre „Was ist ein Golden Path?” in 90 Sekunden, als wäre dein Gegenüber ein neues Entwicklerteam. Stoppe. Lass das Gegenüber in eigenen Worten paraphrasieren. Wenn die Paraphrase falsch ist, war deine Erklärung nicht klar — nicht das Gegenüber schuld.

Whiteboard-Simulation: Drei Boxen reichen oft: Entwickler → Portal → Cluster. Wer zehn Boxen malt, verliert das Publikum.

Typische Stolperfallen

Definition statt Nutzen. „Kubernetes ist ein Container-Orchestrierer” — korrekt, aber nutzlos ohne Kontext.

Assumed knowledge. „Du kennst ja CRDs” — vielleicht nicht. Kurz checken.

Zu lang ohne Checkpoint. Nach 90 Sekunden Pause und fragen, ob die Richtung stimmt.

Überzeugen wollen statt erklären. Wenn jemand skeptisch ist, Trade-offs benennen statt zu verkaufen. Gerade Platform Engineers verlieren Glaubwürdigkeit, wenn sie Tools als Allheilmittel darstellen.

Interview-Vorbereitung

Frage: „Wie erklärst du ein technisches Konzept einem nicht-technischen Stakeholder?”

Antwort: Mit dem Problem starten, das für sie relevant ist — Zeit, Risiko, Kosten. Einen Satz ohne Jargon. Ein konkretes Beispiel aus der Praxis. Trade-off nennen. Dann fragen, ob sie tiefer oder breiter wollen wissen.

Frage: „Wie würdest du Kubernetes einem Entwickler erklären, der es nicht nutzt?”

Antwort: Nicht mit Architektur-Diagrammen. Workflow-Fokus: Was muss der Entwickler tun, was macht die Plattform automatisch? Golden Path erwähnen, wenn passend. Beispiel: „Neuer Service über Template, Pipeline deployt, ihr müsst keine Server verwalten.”

Frage: „Wie merkst du, ob dein Gegenüber dich verstanden hat?”

Antwort: Paraphrase-Check: „Kannst du in eigenen Worten sagen, was sich für euch ändert?” Rückfragen sind ein gutes Zeichen. Glasige Augen oder höfliches Nicken ohne Frage — zurück auf eine Ebene höher und ein konkretes Beispiel.

Checkliste

• Erklärung startet mit Problem/Nutzen, nicht mit Definition
• Zielgruppe vorher klar — PO, Entwickler oder Peer?
• Maximal ein neuer Fachbegriff pro Absatz
• Konkretes Beispiel aus Plattform-Alltag eingebaut
• Mindestens ein Trade-off genannt
• Checkpoint-Frage am Ende („Soll ich tiefer gehen?”)
• Drei Konzepte schriftlich für verschiedene Zielgruppen geübt

Zusammenfassung

Platform Engineers sind Übersetzer: dasselbe Konzept, unterschiedliche Tiefe je nach Publikum. Starke Erklärungen starten mit dem Problem, liefern einen klaren Satz, ein Beispiel und einen Trade-off — und prüfen aktiv, ob das Gegenüber folgen kann.

In der nächsten Lektion gehst du systematisch in die Interview-Vorbereitung: Recherche, Checklisten und Mindset für Platform-Engineering-Rollen.