Wie technisches Onboarding in IT-Teams ablaufen kann

In den meisten Teams ist das Wissen für ein gutes Onboarding längst vorhanden. Es liegt nur verstreut und ohne erkennbare Reihenfolge da, sodass neue Kolleg:innen Wochen brauchen, um sich zu sortieren.

Der typische Ablauf in einem IT Team sieht so aus: Ein neuer Cloud Engineer fängt an, bekommt einen Laptop, die ersten Zugänge und einen Link zur Confluence-Startseite. Dann passiert wochenlang wenig, das messbar ist. Die Person liest sich durch, fragt nach, wartet auf Antworten und versucht herauszufinden, in welcher Reihenfolge das alles Sinn ergibt.

In vielen technischen Teams dauert es sechs bis acht Wochen, bis ein Neuzugang wirklich produktiv ist. In dieser Zeit bindet er sein eigenes Gehalt und zusätzlich die Zeit der erfahrenen Mitarbeitenden, die immer wieder dasselbe erklären müssen. Das ist für das Unternehmen teuer, schlecht planbar und für die neue Person oft frustrierend.

Der eigentliche Engpass: fehlende Reihenfolge

Die meisten Teams haben mehr Dokumentation, als jemand in den ersten Wochen lesen kann: Confluence-Seiten, Wiki-Einträge, Architektur-Docs, GitHub-Repos, interne Videos. Das Material ist vorhanden.

Was fehlt, ist eine sinnvolle Reihenfolge. Niemand weiß, womit man anfängt, was aufeinander aufbaut und was man getrost später lesen kann. Manche Themen bauen auf anderen auf. Ein Werkzeug zur Systemüberwachung ergibt zum Beispiel erst Sinn, wenn man die Systeme kennt, die es überwachen soll. Solche Abhängigkeiten entscheiden über das Tempo der Einarbeitung, stehen aber nirgends.

Kurz gesagt: Gutes Onboarding führt neue Teammitglieder in einer durchdachten Reihenfolge durch das vorhandene Material.

Ein realistischer 30-Tage-Plan fürs Onboarding

Diesen Weg kann man bewusst gestalten, statt ihn jedem Neuzugang selbst überlassen. Ein bewährter Ablauf über die ersten vier Wochen sieht ungefähr so aus.

Woche 1: Orientierung

Die erste Woche dient der allgemeinen Orientierung. Es geht darum, das Umfeld einzuordnen, bevor es in die Tiefe geht. Die neue Person soll verstehen, wofür das Team verantwortlich ist, welche Systeme es betreibt und wer wofür ansprechbar ist.

• Überblick über Domäne, Architektur und zentrale Systeme
• Wie das Team arbeitet: Stand-ups, Ticket-Schnitt, Weg in Produktion
• Erste Kontakte und klare Ansprechpartner

Wer am Ende der Woche weiß, welche Fragen er als Nächstes stellen muss, ist gut aufgestellt.

Woche 2: Architektur und Tooling

Jetzt wird aus dem Überblick echtes Verständnis. Die Entwicklungsumgebung wird vollständig eingerichtet, die zentralen Tools werden geübt, die Zusammenhänge zwischen den Systemen werden greifbar.

• Lokale Umgebung vollständig lauffähig
• Verständnis der wichtigsten Tools und ihrer Rolle
• Erste Themen in der Reihenfolge ihrer Abhängigkeiten angehen

Woche 3: Erste Tickets und Review-Prozess

Ab der dritten Woche arbeitet die neue Person an echten, kleinen Aufgaben: ein Bugfix, eine kleine Erweiterung, eine Anpassung an einem bestehenden Service. Entscheidend ist der vollständige Durchlauf vom Verstehen des Tickets bis zum Merge, unabhängig von der Größe der Aufgabe.

Der Review-Prozess wirkt hier als Lernformat. In ihm werden die internen Standards greifbar: Wie schreiben wir Code, wie dokumentieren wir, was erwarten wir an Tests.

Woche 4: Produktivität

In der vierten Woche verschiebt sich das Ziel von Lernen zu Beitragen. Die neue Person übernimmt Aufgaben eigenständiger, fragt gezielter und braucht weniger Begleitung. Ein gutes Maß ist, ob sie die nächste Aufgabe selbst angehen kann und weiß, wo sie bei Unsicherheit andockt.

Wer das erreicht, ist nach rund vier Wochen produktiv, statt nach zwei Monaten.

Mini-Case: Viel Doku, trotzdem langsame Einarbeitung

Ein Plattform-Team stellte innerhalb eines halben Jahres drei neue Engineers ein. Die Doku war umfangreich und gepflegt. Trotzdem brauchte jeder Neuzugang rund acht Wochen bis zum ersten eigenständigen Beitrag.

Der Grund: Jeder bekam dieselbe lange Linkliste und musste sich selbst sortieren. Zwei Seniors erklärten parallel immer wieder dieselben Grundlagen, je nachdem, wer gerade Zeit hatte. Die Reihenfolge entstand jedes Mal neu, mündlich und zufällig.

Nachdem das Team die Inhalte einmal in einen festen Pfad mit klaren Voraussetzungen gebracht hatte, sank die Einarbeitungszeit auf knapp vier Wochen. Verändert hatte sich allein die Struktur über den Inhalten.

Was gutes technisches Onboarding strukturell braucht

Ein Onboarding-Plan funktioniert nur, wenn drei Dinge zusammenkommen.

1. Ein klarer nächster Schritt. Niemand soll vor der gesamten Wissensmenge auf einmal stehen, sondern immer wissen, was als Nächstes dran ist.
2. Sichtbare Abhängigkeiten. Themen werden in einer Reihenfolge gelernt, die trägt.
3. Wiederverwendbarkeit. Erfahrene Mitarbeitende strukturieren ihr Wissen einmal und können es danach wiederverwenden, statt es bei jedem Neuzugang erneut zu erklären.

In vielen Teams hängt das Onboarding an einzelnen Seniors, die alles ad hoc erklären, wenn sie Zeit haben. Das ist teuer und bricht weg, sobald diese Person fehlt.

Warum ein Plan allein nicht reicht

Ein einmal aufgeschriebener Ablauf hilft beim nächsten Onboarding, veraltet aber schnell, wenn niemand ihn pflegt. Ein Dokument ist schnell erstellt aber nach drei Monaten kaum noch aktuell: tote Links, neue Tools, geänderte Reihenfolge.

Nachhaltig wird der Plan erst, wenn er Teil eines Systems ist, das Reihenfolge, Abhängigkeiten und tote Verweise im Blick behält. Genau dafür haben wir mit Caltrix ein Werkzeug gebaut. Es legt eine Struktur über das, was bereits in Confluence, SharePoint, Wiki oder auf YouTube existiert, speichert die Inhalte selbst aber nicht und macht für jeden Neuzugang sichtbar, was als Nächstes kommt.

Der eigentliche Hebel liegt aber in der Entscheidung selbst, Onboarding bewusst als durchdachten Weg anzulegen. Das Werkzeug hilft erst danach.

Onboarding-Checkliste für technische Teams

1. Zielrolle und gewünschtes Level definieren
2. Vorhandene Inhalte sammeln, statt neue zu produzieren
3. Abhängigkeiten klären: Was baut auf was auf?
4. Pro Phase einen klaren nächsten Schritt festlegen
5. Erste echte Aufgabe für Woche 3 vorbereiten
6. Verantwortlichkeit für die Pflege benennen
7. Nach vier Wochen prüfen: Kann die Person eigenständig weiterarbeiten?

Fazit

Technisches Onboarding scheitert selten am Wissen und fast immer an der fehlenden Reihenfolge. Wer den Weg von Tag 1 bis zum ersten produktiven Beitrag einmal sauber durchdenkt, halbiert die Einarbeitungszeit und entlastet gleichzeitig die erfahrenen Leute im Team.

Aus einem stillen Kostenfaktor wird so ein planbarer Prozess. Und neue Teammitglieder erleben von Tag 1 an, dass jemand ihren Weg durchdacht hat.