DevOps-Team im Mittelstand aufbauen — Rollen, Skills, Org-Modell

Mittelständische Unternehmen erleben den DevOps-Aufbau heute aus einer anderen Position als noch vor fünf Jahren. Cloud-Migrationen sind im Gange oder abgeschlossen, Kubernetes ist kein Exoten-Thema mehr, und der Markt für DevOps- und Platform-Profile ist nach den großen Tech-Korrekturen 2023 zwar entspannter, aber für seniorige Profile weiterhin eng. Gleichzeitig ist die Erwartung an Auslieferungs-Geschwindigkeit gewachsen — wöchentliche, oft tägliche Releases gelten in vielen Branchen mittlerweile als Mindeststandard. Wer hier ein Team aufbaut, entscheidet nicht nur über eine Personalfrage, sondern über die Architektur der nächsten fünf Jahre. Dieser Leitfaden zeigt, welche Team-Topologie wann passt, welche Rollen wirklich notwendig sind, was sie 2026 im DACH-Raum kosten und wie ein realistischer 30-60-90-Tage-Onboarding-Plan aussieht. Für die Einordnung in die Gesamtstrategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Der DevOps-Team-Mythos

Es gibt eine hartnäckige Erzählung in mittelständischen IT-Organisationen, die etwa so klingt: „Wir stellen einen DevOps-Engineer ein und sind dann DevOps.“ Diese Vorstellung ist aus zwei Gründen falsch. Erstens ist DevOps kein Job-Titel, sondern eine Arbeitsweise — die Zusammenführung von Entwicklung und Betrieb in geteilter Verantwortung. Zweitens entsteht der DevOps-Wert nicht aus einer einzelnen Person, sondern aus den Strukturen, Werkzeugen und Prozessen, die diese Arbeitsweise ermöglichen. Ein DevOps-Engineer ohne Mandat, ohne Plattform und ohne kulturelle Rückendeckung produziert vor allem Frustration.

Die etwas präzisere Lesart ist die folgende. Was wir umgangssprachlich „DevOps-Team“ nennen, ist in der heutigen Praxis fast immer ein Platform-Engineering-Team — eine kleine Gruppe von Spezialistinnen und Spezialisten, deren interne Kunden die Produkt-Teams sind. Ihre Aufgabe ist nicht, Code in Produktion zu schieben, sondern den Produkt-Teams eine Selbstbedienungs-Plattform zu bauen, mit der diese ihren Code selbst sicher und schnell ausliefern können. Dieser semantische Unterschied ist nicht akademisch, sondern er bestimmt direkt die Stellenbeschreibung, die KPIs und die Erwartungshaltung.

Der zweite Mythos betrifft die Größe. „Wir sind zu klein für ein DevOps-Team“ ist eine Aussage, die Geschäftsführungen häufig treffen, ohne sie quantitativ zu prüfen. Die Faustregel aus unserer Praxis lautet: ab acht bis zwölf Entwicklerinnen und Entwicklern entsteht ein Platform-Bedarf, der ohne dedizierte Rolle nicht mehr gut beigewirtschaftet werden kann. Unterhalb dieser Schwelle ist es vernünftig, dass ein bis zwei Senior-Entwickler 20 bis 30 Prozent ihrer Arbeitszeit auf Pipeline, Infrastruktur und Monitoring verwenden. Oberhalb dieser Schwelle ist das nicht mehr realistisch — die Plattform-Arbeit wird verdrängt, technische Schulden wachsen, und die Auslieferungs-Geschwindigkeit sinkt.

Team-Topologien nach Skelton und Pais

Das Buch „Team Topologies“ von Matthew Skelton und Manuel Pais hat seit 2019 eine sehr klare Sprache für die Frage geschaffen, wie Software-Teams strukturiert sein sollten. Vier Team-Typen werden unterschieden, und für den Aufbau eines DevOps-Teams ist diese Sprache wichtig, weil sie das Missverständnis „DevOps = ein Team das alles macht“ auflöst.

Team-Typ	Aufgabe	Beispiel im Mittelstand
Stream-aligned Team	End-to-End-Verantwortung für einen Wertstrom, von Anforderung bis Produktion	Produkt-Team „Bestell-Portal“ mit Entwicklung, Test und Bereitschaft für genau diesen Service
Platform Team	Baut und betreibt eine interne Entwickler-Plattform mit Self-Service-APIs	Drei- bis fünf-Personen-Team baut Pipelines, K8s-Cluster, Observability als Self-Service
Enabling Team	Befähigt Stream-aligned-Teams temporär in einem Spezial-Thema, ohne dauerhaft zu übernehmen	Security-Enabling-Team begleitet ein Stream-Team beim Einbau von SLSA-Provenance
Complicated-Subsystem Team	Verantwortet ein technisch komplexes Sub-System, das tiefe Spezialisierung verlangt	Datenbank-Plattform-Team für Postgres-Cluster und Migrations-Tooling

Für den DACH-Mittelstand sind in der Regel zwei dieser Team-Typen unmittelbar relevant. Stream-aligned Teams sind die Produkt-Teams, die bereits existieren. Hinzu kommt ein Platform Team — und das ist genau die Gruppe, die Geschäftsführungen umgangssprachlich „DevOps-Team“ nennen. In größeren Organisationen mit 80 plus Entwicklerinnen und Entwicklern entstehen zusätzlich ein temporäres Enabling Team und gelegentlich ein Complicated-Subsystem-Team. In typischen Mittelständlern bleibt es bei den ersten beiden Typen.

Der wichtigste Lerneffekt aus Team Topologies ist die Begrenzung der kognitiven Last. Ein Team kann nicht beliebig viele Verantwortungsbereiche tragen — wenn die Plattform versucht, gleichzeitig Pipelines, Kubernetes, Datenbanken, Observability, Security und Cost-Management abzudecken, kollabiert sie. Eine seriöse Plattform-Strategie definiert von Beginn an, welche Domänen das Platform-Team abdeckt und welche nicht.

Rollen-Profile im Detail

Die folgenden fünf Rollen-Profile bilden den Kern eines reifen DevOps-Aufbaus. In kleinen Mittelständlern verschmelzen mehrere dieser Rollen in einer Person; ab etwa 40 Entwicklerinnen und Entwicklern lohnt die Trennung. Die Beschreibungen sind bewusst praxisorientiert und nicht stellenanzeigen-glatt.

• Platform EngineerBaut die interne Entwickler-Plattform — Pipelines, IaC-Module, Service-Templates, Self-Service-Portale. Denkt produktorientiert: die internen Kunden sind die Produkt-Teams. Starke Skills in Terraform, Kubernetes, GitOps und mindestens einer Programmiersprache jenseits von YAML. Wichtiger Indikator: hat schon einmal eine Plattform abgeschaltet, weil sie zu komplex wurde.
• Site Reliability Engineer (SRE)Operativ-fokussiert auf Zuverlässigkeit. Definiert SLOs und Error-Budgets, leitet Post-Mortems, baut Runbooks und Automatisierung. Bringt Stärken in Observability-Stacks, Tracing, Incident-Response und Capacity-Planning mit. Im Mittelstand oft die Person, die die Bereitschafts-Rotation aufbaut und die ersten ehrlichen Verfügbarkeits-Zahlen produziert.
• DevOps Engineer (Generalist)In Teams unter 40 Entwicklerinnen und Entwicklern oft die Kombi-Rolle aus Platform und SRE. Pipelines, Cloud-Konten, Container-Registry, Monitoring, Secrets-Management — alles aus einer Hand. Senior-Profile in dieser Rolle sind selten, weil die Breite hoch ist; die meisten Generalisten haben ein bis zwei klare Stärken und Schwächen.
• Cloud ArchitectVerantwortet die übergreifende Cloud-Architektur — Account-Struktur, Netzwerk-Design, Identity, Cost-Architektur, Multi-Region-Strategie. Arbeitet querschnittlich mit allen Teams. Eine Cloud-Architect-Rolle ist erst sinnvoll, wenn mindestens drei produktive Cloud-Konten und mehrere VPCs koordiniert werden müssen. Vorher reicht ein Platform Engineer mit Architektur-Mandat.
• Release EngineerSpezialist für die Auslieferungs-Strecke selbst — Versionierung, Build-Reproducibility, Artefakt-Signing, SBOM-Generierung, Release-Notes-Automatisierung. Eine eigenständige Release-Engineer-Rolle entsteht meist ab 50 plus Entwicklerinnen und Entwicklern oder bei Compliance-Druck (regulierte Branchen, BSI-IT-Grundschutz hoch, NIS2 wesentliche Einrichtungen). Sonst Teil der Platform-Rolle.

Eine häufige Stolperfalle: Stellenanzeigen, die alle fünf Rollen gleichzeitig fordern. „Wir suchen einen DevOps Engineer mit tiefer Kubernetes-Erfahrung, Cloud-Architektur-Skills, SRE-Background und Compliance-Know-how für 75.000 Euro.“ Solche Anzeigen bleiben unbesetzt. Ein realistischer Stellenzuschnitt definiert eine klare Hauptrolle plus ein bis zwei sekundäre Schwerpunkte, und akzeptiert, dass die übrigen Domänen extern oder über andere Personen abgedeckt werden.

Skill-Set 2026

Die Anforderungs-Landschaft hat sich gegenüber 2022 verschoben. Klassische CI/CD-Tools sind Commodity geworden, dafür sind drei Bereiche schärfer gefragt: Platform-as-Product-Denken, Security-Engineering in der Pipeline und KI-gestütztes Tooling. Die folgende Liste zeigt das Pflicht-Set für seniorige DevOps-Profile 2026.

Skill-Bereich	2026 Pflicht	2026 nice-to-have
Infrastructure-as-Code	Terraform oder OpenTofu, Modul-Design, Test-Frameworks	Pulumi, Crossplane, CDK
Container und Orchestrierung	Kubernetes, Helm, Container-Image-Härtung	Service Mesh, Cilium, eBPF-Tooling
CI/CD	GitHub Actions oder GitLab CI, GitOps mit ArgoCD oder Flux	Reusable-Workflow-Design, Buildkite, Tekton
Observability	Prometheus, Grafana, OpenTelemetry, strukturiertes Logging	eBPF-Profiling, Loki, Tempo, Continuous Profiling
Security in der Pipeline	SBOM, SLSA-Level-2 plus, Sigstore, Secret-Scanning, IaC-Scanning	SLSA-3, Hardware-Attestation, Confidential-Builds
Programmierung	Mindestens eine Sprache jenseits YAML: Go, Python oder Rust	TypeScript für Plattform-CLIs und Self-Service-Portale
Soft-Skills	Produkt-Denken für interne Plattform, Schreibkompetenz, Moderation	Mentoring, Coaching-Erfahrung

Auffällig ist die Verschiebung beim Security-Set. Was 2022 als Nice-to-have galt — SBOMs, signierte Artefakte, Provenance-Daten — ist 2026 in vielen Stellenausschreibungen Pflicht. Das ist eine direkte Folge der NIS2-Umsetzung und der wachsenden Anforderungen an Software-Supply-Chain-Sicherheit. Für die Pipeline-Detailtiefe siehe unseren Cluster zu CI/CD-Pipeline aufbauen.

Build vs Buy vs Hybrid

Die Frage, ob ein DevOps-Team selbst aufgebaut oder als Service eingekauft wird, ist eine der häufigsten Entscheidungs-Diskussionen in mittelständischen Geschäftsführungen. Die ehrliche Antwort lautet fast immer: Hybrid. Reines Build dauert in DACH-Verhältnissen typischerweise 12 bis 24 Monate, weil Senior-Profile knapp sind und Onboarding-Zeit braucht. Reines Buy schafft Geschwindigkeit, aber Abhängigkeit, weil das interne Wissen fehlt, sobald der Vertrag ausläuft.

Der Hybrid-Pfad sieht in der Praxis so aus: ein Managed-Service-Partner oder eine spezialisierte Beratung übernimmt die Erst-Einrichtung von Plattform, Pipelines und Observability in drei bis sechs Monaten. Parallel wird intern eine erste Person eingestellt, die diese Aufbau-Phase begleitet, dokumentiert und nach der Übergabe als Knowledge-Owner fungiert. Diese erste Person ist meist ein seniorer DevOps Engineer mit Generalisten-Profil, nicht ein Junior. Nach der Übergabe wird das interne Team auf zwei bis drei Personen erweitert.

Gehälter DACH 2026

Die DACH-Gehälter haben sich nach den Korrekturen 2023 stabilisiert und liegen 2026 wieder auf einem leicht ansteigenden Pfad. Die folgenden Brutto-Jahresgehalts-Ranges sind Mittelwerte für mittelständische Unternehmen mit 200 bis 2.000 Mitarbeitenden. Konzern-Gehälter liegen 10 bis 25 Prozent darüber, Start-ups oft 5 bis 15 Prozent darunter mit Equity-Komponenten.

Rolle	Junior (2–3 J.)	Mid (4–6 J.)	Senior / Lead (7+ J.)
DevOps Engineer	55.000–70.000 €	70.000–95.000 €	95.000–125.000 €
Platform Engineer	60.000–75.000 €	75.000–100.000 €	100.000–130.000 €
Site Reliability Engineer	60.000–78.000 €	78.000–105.000 €	105.000–135.000 €
Cloud Architect	—	85.000–110.000 €	110.000–145.000 €
Release Engineer	55.000–70.000 €	70.000–95.000 €	95.000–125.000 €

Regional-Aufschläge gelten weiterhin: München, Zürich und Frankfurt liegen 10 bis 20 Prozent über diesen Werten, Berlin und Hamburg moderat darüber, Köln, Stuttgart und Wien auf dem Mittelwert, ostdeutsche Standorte und ländliche Räume 5 bis 15 Prozent darunter. Remote-First-Stellen orientieren sich tendenziell am Mittelwert ohne Aufschlag. Zertifizierungen wie CKA, CKAD, AWS Solutions Architect Professional oder Google Cloud Professional Cloud Architect rechtfertigen 3 bis 7 Prozent Aufschlag, sind aber selten Stellen-entscheidend.

Wichtig für die Kalkulation: zum Brutto-Gehalt kommen rund 21 Prozent Arbeitgeber-Lohnnebenkosten plus Sachkosten (Hardware, Lizenzen, Schulung) von 8.000 bis 15.000 Euro pro Person und Jahr. Eine Senior-Platform-Engineer-Rolle bei 115.000 Euro brutto kostet das Unternehmen real rund 155.000 bis 165.000 Euro pro Jahr.

Recruiting-Tipps für den engen DACH-Markt

Der Markt für seniorige DevOps-Profile bleibt 2026 eng, auch wenn er nicht mehr so überhitzt ist wie 2021. Vier Recruiting-Hebel haben in unserer Begleitung von Mittelstands-Aufbauten am stärksten gewirkt.

• Stellenanzeige verschlankenEine klare Hauptrolle plus zwei Schwerpunkte schlägt jede „Eierlegende Wollmilchsau“-Anzeige. Wenn ein Profil tatsächlich alle fünf Rollen beherrscht, ist es in einem mittelständischen Gehalts-Rahmen nicht zu halten. Die ehrliche Anzeige zieht die besseren Bewerbungen an.
• Remote-First oder mindestens 60 Prozent RemoteSeniorige Profile fragen heute zuerst nach dem Remote-Modell. Wer auf voller Präsenzpflicht besteht, halbiert seinen Bewerber-Pool sofort. Eine Mischung aus zwei Bürotagen pro Woche und drei Remote-Tagen ist 2026 der häufigste Kompromiss.
• Community-Sichtbarkeit aufbauenKonferenz-Talks der eigenen Mitarbeitenden, Blog-Posts mit echtem technischen Inhalt, ein offener GitHub-Account mit interessanten internen Tools. Diese Sichtbarkeit zieht 2026 mehr seniorige Bewerbungen an als jede LinkedIn-Anzeige.
• Interview-Prozess straffenMaximal drei Termine, davon einer technisches Pairing statt Whiteboard-Theater, Entscheidung innerhalb von zehn Arbeitstagen nach Erstgespräch. Längere Prozesse verlieren die besten Profile an konkurrierende Angebote.

Onboarding-Playbook 30-60-90

Ein strukturiertes Onboarding ist im DevOps-Kontext besonders wichtig, weil die Rolle sehr kontextabhängig ist. Eine seniorige Person kann ihre Skills nicht entfalten, wenn sie die Plattform, die Service-Landschaft und die kulturellen Regeln nicht kennt. Das folgende 30-60-90-Modell hat sich in mehreren mittelständischen Aufbauten bewährt.

Tage 1 bis 30 — Verstehen. Architektur-Walkthroughs mit allen wichtigen Service-Ownern, Zugriffsrechte auf alle relevanten Systeme, Pairing-Sessions mit jedem Produkt-Team, Lesen vorhandener Runbooks und Architektur-Dokumente, Schatten-Bereitschaft bei der ersten Incident-Rotation. Keine Erwartung produktiver Beiträge in dieser Phase. Wöchentliches 1-zu-1 mit der Führungskraft, monatliches Check-in mit der Geschäftsführung.

Tage 31 bis 60 — Erste Beiträge. Eine konkrete Pipeline-Verbesserung, eine Observability-Lücke schließen, ein Runbook automatisieren, ein wiederkehrendes Operations-Ticket dauerhaft eliminieren. Der Beitrag muss sichtbar sein, aber nicht risikoreich. Parallel: eine schriftliche Bewertung der aktuellen Plattform mit drei bis fünf priorisierten Verbesserungs-Vorschlägen.

Tage 61 bis 90 — Verantwortungsübernahme. Eigene Bereitschaftsrotation, Verantwortung für eine Service-Domain, ein dokumentiertes Architektur-Improvement im Backlog, erste Architektur-Entscheidung mit unterstützender Begleitung. Am Ende von Tag 90 ein gemeinsames Retrospektive-Gespräch zwischen neuer Person, Führungskraft und einem Produkt-Team-Vertreter mit ehrlichem Feedback in beide Richtungen.

Ohne diesen Pfad bleiben neue DevOps-Profile zu lange Beobachter und kündigen in den ersten zwölf Monaten überdurchschnittlich häufig. In unserer Begleitung haben Onboarding-Strukturen die 12-Monats-Fluktuation neuer DevOps-Profile von branchen-üblichen 25 bis 30 Prozent auf unter 10 Prozent gedrückt — das ist ein direkter wirtschaftlicher Hebel.

Wann ein 1-Person-DevOps-Team zu wenig ist

Viele mittelständische Unternehmen starten mit einer Single-Person-DevOps-Rolle und bleiben länger dabei, als gut ist. Vier Indikatoren zeigen, dass die Schwelle zur zweiten und dritten Person überschritten ist.

Erstens, Bereitschaft. Wenn eine einzelne Person dauerhaft 24/7-Verantwortung trägt, ist Burnout in zwölf bis 18 Monaten nahezu sicher. Eine seriöse Bereitschaftsrotation braucht mindestens drei, besser vier Personen. Zweitens, Bus-Faktor. Eine Plattform, die nur eine Person versteht, ist ein Risiko auf der Ebene von Geschäftskontinuität — fällt diese Person für einen Monat aus, steht die Auslieferung still. Drittens, Liefer-Drosselung. Wenn Produkt-Teams regelmäßig auf Plattform-Tickets warten und die Wartezeiten über zwei Wochen liegen, drosselt die Plattform den gesamten Wertstrom. Viertens, Compliance-Druck. NIS2-Anforderungen, BSI-IT-Grundschutz hohe Schutzbedarfe oder DORA-Anforderungen sind mit einer Einzelperson nicht seriös erfüllbar.

Eine pragmatische Skalierungs-Schwelle: ab acht Entwicklerinnen und Entwicklern eine erste Person, ab 25 die zweite, ab 50 die dritte, ab 80 die vierte plus erste Spezialisierung. Diese Schwellen sind keine harten Regeln, aber sie sind in unserer Begleitung mehrfach bestätigt worden. Für die operativen Aspekte der zweiten und dritten Person siehe auch unseren Cluster zu SRE im Mittelstand sowie zu Observability- und Monitoring-Stack.

Reepa-Coaching für DevOps-Aufbauten

Wir begleiten mittelständische Unternehmen seit mehreren Jahren beim Aufbau und der Professionalisierung von DevOps- und Platform-Engineering-Teams — als Hybrid-Modell aus initialer Einrichtung und langfristigem Coaching. Unser typischer Pfad beginnt mit einem zwei- bis vierwöchigen Assessment der aktuellen Plattform-Reife, gefolgt von einem 90-Tage-Aufbau-Sprint zusammen mit der ersten internen Person, und mündet in eine monatliche Coaching-Begleitung über sechs bis zwölf Monate. Wir übernehmen dabei explizit keine dauerhafte operative Verantwortung — unser Ziel ist immer die saubere Übergabe an ein internes Team, das die Plattform selbst betreibt.

Häufige Fragen