Cloud Engineer Onboarding in 4 Wochen: Plan und Checkliste

Cloud-Engineer-Onboarding entscheidet oft schon in den ersten vier Wochen darüber, ob ein neuer Mitarbeitender nach kurzer Zeit produktiv wird oder monatelang Orientierung sucht. Trotzdem besteht Onboarding in vielen Teams noch aus Slack-Nachrichten, geteilten Dokumenten und der Hoffnung, dass irgendjemand spontan Zeit hat. Hier ist ein 4-Wochen-Plan, der Cloud-Engineer-Onboarding strukturiert. Ohne starre Kurslogik und ohne bestehendes Wissen neu aufzubauen.

Für wen dieser Onboarding-Plan gedacht ist

Der Plan eignet sich besonders für Cloud Engineers, SREs, Plattform-Teams und andere technische Rollen, in denen Wissen auf viele Systeme, Repositories, Dokumentationen und Personen verteilt ist. Er ist kein starres Schulungsprogramm, sondern ein praxistauglicher Orientierungsrahmen für die ersten vier Wochen.

Das Prinzip: Reihenfolge vor Vollständigkeit

Ein gutes Onboarding lehrt nicht alles, sondern das Richtige in der richtigen Reihenfolge. Jede Woche baut auf der vorherigen auf. Wer in Woche 1 mit Service Mesh anfängt, verbrennt Motivation; wer mit Zugängen und Architekturüberblick startet, gewinnt Tempo.

Der 4-Wochen-Plan

Woche 1 – Ankommen und Überblick

Ziel: handlungsfähig werden. Zugänge, Entwicklungsumgebung, ein erster grüner Build. Dazu der grobe Architekturüberblick: Welche Services gibt es, wie hängen sie zusammen, wo liegt was. Kein Tiefgang – Orientierung.

Woche 2 – Die eigene Domäne

Ziel: den eigenen Verantwortungsbereich verstehen. Die zwei oder drei Services, an denen die Person arbeiten wird, im Detail: Deployment-Pfad, Monitoring, typische Incidents. Gerade hier zahlt es sich aus, wenn internes Wissen – etwa Runbooks, Architektur-Dokumentation und Betriebswissen – als klarer Lernpfad strukturiert ist statt über mehrere Systeme verstreut zu liegen.

Woche 3 – Querschnitt und Plattform

Ziel: das große Ganze. CI/CD-Pipeline, Secrets-Management, Observability, Incident-Prozess. Themen, die alle Services betreffen und ohne die niemand eigenständig deployen sollte.

Woche 4 – Eigenständigkeit

Ziel: erste echte Verantwortung. Ein kleines Feature oder Bugfix end-to-end, inklusive Review und Deployment. Begleitet, aber selbst gefahren. Am Ende der Woche steht ein kurzes Gespräch: Was sitzt, wo sind Lücken?

Checkliste: Tribal Knowledge sichtbar machen

Der häufigste Onboarding-Killer ist implizites Wissen, das nur in Köpfen existiert. Diese Fragen decken es auf:

• Welche drei Dinge muss man wissen, die in keiner Doku stehen?
• Wen fragt man bei Problem X – und ist das dokumentiert?
• Welcher Schritt im Deployment ist „eigentlich klar", aber regelmäßig Ursache von Fehlern?
• Welche Altlasten erklärt man jedem Neuen mündlich?

Jede dieser Antworten gehört in einen Lernpfad – nicht in den nächsten mündlichen Erklärlauf.

Warum ein Pfad besser ist als eine Kursliste

Der Plan oben funktioniert nur, weil er Abhängigkeiten hat: Woche 3 setzt Woche 1 voraus. Genau das bilden klassische Systeme schlecht ab – mehr dazu im Beitrag Warum klassische LMS bei technischen Teams scheitern. Mit Caltrix lässt sich dieser 4-Wochen-Plan als strukturierter Pfad abbilden, der vorhandene Inhalte verlinkt statt sie neu zu erstellen.

Fazit

Ein wirksames Cloud-Engineer-Onboarding braucht nicht möglichst viele Inhalte, sondern eine sinnvolle Reihenfolge, sichtbare Abhängigkeiten und explizit dokumentiertes Erfahrungswissen. Vier Wochen reichen aus, um neue Teammitglieder handlungsfähig zu machen. Wenn aus losem Wissen ein strukturierter Pfad wird. Ein Plan auf Papier ist der Anfang. Ein gepflegter Lernpfad, den jede nächste Person direkt nutzen kann, ist die eigentliche Skalierung.