Platform Engineering: Ein erfolgreiches Team aufbauen

Wer ein Platform Engineering Team aufbauen will, sollte nicht mit einem Organigramm beginnen. Der entscheidende Punkt ist eine wiederkehrende Reibung im Engineering: Teams warten auf Umgebungen, lösen Zugriffsfragen immer wieder neu, pflegen uneinheitliche CI/CD-Pipelines oder tragen Betriebsaufgaben, die sie vom Produkt abziehen. Eine interne Plattform kann diese Reibung senken – aber nur, wenn sie als Produkt für Entwickler und nicht als neue zentrale Kontrollinstanz verstanden wird.

Das klingt zunächst nach einer technischen Aufgabe. Tatsächlich ist es eine Veränderung von Verantwortlichkeiten, Entscheidungswegen und Serviceerwartungen. Plattformteams bewegen sich zwischen Entwicklung, Betrieb, Security, Architektur und FinOps. Genau deshalb scheitern viele Vorhaben nicht am Kubernetes-Cluster oder an Infrastructure as Code, sondern an einem unklaren Mandat.

Warum ein Platform Engineering Team aufbauen?

Platform Engineering ist kein neuer Name für das klassische Infrastrukturteam und auch kein Ersatz für DevOps. DevOps beschreibt vor allem eine Zusammenarbeit und gemeinsame Verantwortung zwischen Entwicklung und Betrieb. Ein Plattformteam entwickelt dagegen gezielt wiederverwendbare Fähigkeiten, die Produktteams im Alltag nutzen können: standardisierte Entwicklungsumgebungen, Deployment-Templates, Observability, Identity-Integration, Secrets-Management oder Self-Service für Infrastruktur.

Der Nutzen entsteht nicht automatisch durch Zentralisierung. Wenn ein Plattformteam nur Tickets entgegennimmt und zentrale Freigaben verwaltet, verlagert es Engpässe statt sie zu beseitigen. Sinnvoll wird es dort, wo mehrere Teams dieselben Probleme wiederholt und in unterschiedlicher Qualität lösen. Dann lohnt es sich, einen guten Standard zu bauen, ihn zu betreiben und anhand des Nutzerfeedbacks weiterzuentwickeln.

Für die IT-Leitung ist das ein Hebel für Lieferfähigkeit und Risikosteuerung. Für Engineering-Teams muss es vor allem eine spürbare Vereinfachung sein. Diese beiden Perspektiven gehören zusammen, sind aber nicht identisch: Governance darf nicht zur Wartezeit werden, und Entwicklerautonomie darf nicht bedeuten, dass jede Anwendung eigene Sicherheits- und Betriebsmechanismen erfindet.

Vor dem Team steht das Mandat

Bevor Rollen ausgeschrieben oder Plattformkomponenten ausgewählt werden, braucht es eine klare Antwort auf drei Fragen: Welches konkrete Problem löst die Plattform? Für welche internen Nutzer? Und woran erkennst du, dass sie nützlich ist?

Ein tragfähiges Mandat ist eng genug, um priorisieren zu können. Statt die gesamte Unternehmens-IT modernisieren zu wollen, kann der Start etwa auf den Weg von Code bis Produktion zielen: Repository-Standards, Build, Security-Prüfungen, Deployment, Telemetrie und ein nachvollziehbarer Umgang mit Ausnahmen. In einer anderen Organisation liegt der größte Hebel vielleicht bei Landing Zones, Identitäten und Zugriffsmodellen für Cloud-Workloads. Es hängt von der Ausgangslage ab.

Die Plattform als internes Produkt führen

Der Perspektivwechsel ist wesentlich: Produktteams sind keine Kunden im vertrieblichen Sinn, aber Nutzer mit echten Arbeitsabläufen. Sie sollten nicht gezwungen werden, abstrakte Plattformfähigkeiten zu verstehen, nur weil diese technisch elegant gebaut wurden. Entscheidend ist, ob sie einen sicheren und wartbaren Service schneller in Betrieb nehmen können.

Deshalb braucht die Plattform Produktverantwortung. Diese Rolle priorisiert nicht allein nach technologischer Attraktivität, sondern nach Nutzung, Reibung und Wirkung. Sie spricht regelmäßig mit Entwicklern, Architekten, Security und Betrieb, macht Zielkonflikte sichtbar und pflegt eine nachvollziehbare Roadmap. Ohne diese Verantwortung entsteht leicht eine Sammlung von Tools, aber kein Produkt.

Auch die Cloud Native Computing Foundation (CNCF) beschreibt interne Plattformen als Produkte, die Entwicklerteams mit wiederverwendbaren Fähigkeiten unterstützen. Entscheidend ist dabei nicht die Anzahl der eingesetzten Werkzeuge, sondern die Qualität der bereitgestellten Entwicklererfahrung.

Den ersten Scope bewusst klein halten

Der erste Plattform-Use-Case sollte häufig sein, schmerzhaft genug und technisch beherrschbar. Ein standardisierter Golden Path für einen gängigen Anwendungstyp ist oft sinnvoller als ein großer Plattform-Neubau. Ein solcher Pfad beschreibt nicht nur einen Technologie-Stack, sondern den unterstützten Weg von der Erstellung bis zum Betrieb – inklusive Logging, Monitoring, Sicherheitsvorgaben und Ownership.

Wichtig ist: Golden Paths sind Angebote mit klaren Leitplanken, keine Zwangsarchitektur für jeden Sonderfall. Legacy-Systeme, regulatorische Anforderungen oder Spezial-Workloads können Ausnahmen notwendig machen. Diese sollten jedoch bewusst entschieden, dokumentiert und möglichst nicht zum Standard erhoben werden.

Das Team nach Fähigkeiten, nicht nach Toolnamen zuschneiden

Ein kleines, wirksames Plattformteam braucht unterschiedliche Blickwinkel. Platform Engineers bringen Erfahrung mit Automatisierung, Cloud- und Laufzeitplattformen sowie Developer Experience mit. Site Reliability Engineering und Betriebsexpertise sorgen dafür, dass Verfügbarkeit, Kapazität, Incident-Abläufe und Telemetrie nicht nachträglich ergänzt werden. Security Engineering muss früh integriert sein, besonders bei Identitäten, Secrets, Software-Lieferkette und Policy-as-Code.

Dazu kommen Architekturkompetenz und Produktverantwortung. Diese Fähigkeiten müssen nicht zwingend alle als eigene Vollzeitrollen im ersten Team vorhanden sein. In kleineren Organisationen kann ein Kernteam mit verbindlich eingebundenen Experten funktionieren. Entscheidend ist, dass diese Expertise in die Priorisierung und Umsetzung einfließt – nicht erst als Abnahme am Ende.

Vorsicht ist bei einem Teamzuschnitt geboten, der ausschließlich aus Infrastruktur-Spezialisten besteht. Dann liegt die Versuchung nahe, die Plattform von unten nach oben zu definieren: Cluster, Netzwerke, Pipelines und Policies zuerst, Entwicklererlebnis später. Besser ist eine Kombination aus tiefem Betriebswissen und Menschen, die den Alltag der Softwareentwicklung kennen.

Ein Betriebsmodell, das Verantwortung nicht verwischt

Ein Plattformteam betreibt eigene Plattformservices. Es übernimmt aber nicht automatisch den Betrieb jeder Anwendung, die diese Services nutzt. Produktteams bleiben für ihren Code, ihre fachliche Funktion und vereinbarte Serviceziele verantwortlich. Das Plattformteam verantwortet die Zuverlässigkeit, Sicherheit und Weiterentwicklung der bereitgestellten Fähigkeiten innerhalb klarer Grenzen.

Diese Grenzen müssen schriftlich werden. Wer reagiert auf einen Ausfall der CI-Plattform? Wer verantwortet die Laufzeit eines Services? Wie werden Schwachstellen in Basis-Images, Bibliotheken oder Anwendungscode behandelt? Welche SLOs gelten und welche Support-Zeiten sind realistisch? Solche Fragen wirken operativ, entscheiden aber darüber, ob die Plattform Vertrauen gewinnt.

Self-Service braucht sichere Standardwege

Self-Service bedeutet nicht, dass jeder alles darf. Er bedeutet, dass häufige, freigegebene Abläufe ohne manuelle Übergaben funktionieren. Ein Entwicklerteam sollte zum Beispiel eine neue Umgebung bereitstellen oder einen Service ausrollen können, ohne dafür mehrere Tickets zu eröffnen. Gleichzeitig müssen Identitäten, Berechtigungen, Netzgrenzen und Audit-Anforderungen technisch durchsetzbar bleiben.

Hier liegt eine zentrale Architekturentscheidung: Regeln möglichst in wiederverwendbare Bausteine, Vorlagen und automatisierte Prüfungen zu verlagern, statt sie in PDFs oder Einzelfreigaben zu verstecken. Automatisierung reduziert jedoch nicht jede Entscheidung. Bei hohem Schutzbedarf, neuen Datenflüssen oder ungewöhnlichen Architekturen bleibt fachliche Prüfung notwendig. Gute Plattformen machen diesen Weg transparent, statt Ausnahmen informell zu dulden.

Security, Compliance und Souveränität von Beginn an einbauen

Security wird oft als Argument für Zentralisierung verwendet. Das ist nachvollziehbar, aber nicht ausreichend. Ein zentral bereitgestellter Dienst kann einen großflächigen Ausfall oder ein attraktives Ziel schaffen, wenn er schlecht segmentiert, unzureichend überwacht oder ohne belastbare Wiederherstellungsprozesse betrieben wird. Platform Engineering muss daher sowohl Standardisierung als auch Resilienz liefern.

Für regulierte oder besonders schutzbedürftige Umgebungen gehören Datenklassifikation, Verschlüsselung, Schlüsselverwaltung, Protokollierung und Nachweisfähigkeit in den Plattform-Backlog. Bei Cloud-Nutzung kommen Fragen nach Datenräumen, Kontrollmöglichkeiten, Vertragsgestaltung und Exit-Fähigkeit hinzu. Digitale Souveränität ist dabei keine Produkteigenschaft, die man einkauft. Sie entsteht aus Architektur, Betriebsmodell, Kompetenzen und realistischen Alternativen.

Die Security-Organisation sollte deshalb nicht nur Regeln formulieren, sondern mit dem Plattformteam automatisierbare Kontrollen gestalten. Das erhöht die Akzeptanz, weil sichere Wege nicht länger mehr Handarbeit bedeuten müssen als unsichere.

Wirkung messen, nicht Aktivität

Die Zahl bereitgestellter Plattformkomponenten sagt wenig über ihren Nutzen. Aussagekräftiger sind Nutzungsdaten und Ergebnisse: Wie lange dauert es, einen unterstützten Service produktiv zu bringen? Wie viele manuelle Übergaben entfallen? Wie zuverlässig sind die Plattformservices? Wie viele Teams nutzen einen Standardweg freiwillig? Und wo verlassen sie ihn – aus berechtigtem Grund oder weil der Weg nicht passt?

Diese Kennzahlen dürfen nicht isoliert zu Zielvorgaben für einzelne Teams werden. Eine kürzere Deployment-Zeit ist kein Gewinn, wenn Sicherheitsprüfungen umgangen werden oder die Qualität der Änderungen sinkt. Sinnvoll ist ein gemeinsames Bild aus Geschwindigkeit, Zuverlässigkeit, Sicherheit und Entwicklererlebnis. Ergänze die Messwerte durch qualitative Rückmeldungen. Ein regelmäßiges Gespräch mit Produktteams zeigt oft früher als ein Dashboard, wo die Plattform Reibung erzeugt.

Die ersten 90 Tage: sichtbar liefern, bewusst lernen

In den ersten Wochen lohnt sich eine Bestandsaufnahme entlang echter Entwicklerwege. Nicht: Welche Tools sind vorhanden? Sondern: Was passiert, wenn ein Team heute einen neuen Service bereitstellt, eine Berechtigung benötigt oder einen Sicherheitsvorfall nachvollziehen muss? Daraus lassen sich die teuersten Wartezeiten und riskantesten manuellen Schritte ableiten.

Wähle anschließend einen Pilotbereich mit einem engagierten Produktteam. Liefere einen klar abgegrenzten Standardweg und betreibe ihn gemeinsam mit den Nutzern. Das schafft Feedback, macht implizite Anforderungen sichtbar und verhindert, dass eine Plattform im Architekturzirkel entsteht. Erst wenn Nutzung, Support und Verantwortlichkeiten im kleinen Rahmen funktionieren, solltest du die Fähigkeiten breiter ausrollen.

Ein Platform Engineering Team aufzubauen ist damit keine Reorganisation mit Enddatum. Es ist die Entscheidung, interne Entwicklerplattformen dauerhaft wie Produkte zu behandeln: mit klaren Nutzern, verbindlicher Verantwortung und dem Mut, Standards zu verbessern, sobald die Praxis ihnen widerspricht.