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. Eine erfahrene Person aus dem Team begleitet sie dabei als Pate.

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
• Ein Pate aus dem Team mit festen Terminen, dazu 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.

Diese Aufgaben sind Praxisaufgaben: Der Pate sucht sie aus und geht das Ergebnis mit der neuen Person durch. 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 in einen festen Pfad mit klaren Voraussetzungen gebracht hatte, sank die Einarbeitungszeit auf knapp vier Wochen. Verändert hatte sich nicht der Inhalt, sondern die Verbindlichkeit: Die Reihenfolge stand fest und damit auch, wer der neuen Person was bis wann erklärt.

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. Ein Pate mit Frist. Eine erfahrene Person begleitet die Einarbeitung verbindlich, mit festen Terminen und Praxisaufgaben. Die Führungskraft sieht, wenn es hakt. Aufgeschrieben wird nur, was jemand nachschlagen muss.

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. Der Unterschied liegt nicht darin, ob Seniors erklären, sondern darin, ob klar ist, wer wem was bis wann beibringt.

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. Und selbst ein aktuelles Dokument sagt nicht, wer der neuen Person was beibringt und bis wann.

Nachhaltig wird der Plan erst, wenn er verbindlich ist: Jeder Schritt hat eine verantwortliche Person und eine Frist, der Pate steht mit Namen darin und jemand behält Reihenfolge, Abhängigkeiten und tote Verweise im Blick. Genau dafür haben wir Caltrix gebaut. Caltrix macht verbindlich, wer wem was bis wann beibringt. In Caltrix Learning bekommt die Einarbeitung einen Pfad mit Pate, Praxisaufgaben und Frist. Das Nachschlagbare bleibt, wo es ist, in Confluence, SharePoint, Wiki oder auf YouTube: Caltrix verlinkt es im Pfad, 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, mit einer Person, die ihn begleitet. Das Werkzeug hilft erst danach.

Onboarding-Checkliste für technische Teams

1. Zielrolle und gewünschte Stufe definieren
2. Einen Paten benennen und seine Termine für die ersten vier Wochen in den Kalender legen
3. Vorhandene Inhalte sammeln, statt neue zu produzieren
4. Abhängigkeiten klären: Was baut auf was auf?
5. Pro Phase einen klaren nächsten Schritt festlegen
6. Erste echte Aufgabe für Woche 3 als Praxisaufgabe mit dem Paten vorbereiten
7. Verantwortlichkeit für die Pflege benennen
8. 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 sauber durchdenkt und festlegt, wer der neuen Person was bis wann beibringt, verkürzt die Einarbeitungszeit deutlich. Die erfahrenen Leute im Team erklären dann nicht weniger, aber geplant statt immer dann, wenn gerade jemand fragt.

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