IT-Onboarding mit Schulungen beschleunigen

Neue Kolleginnen und Kollegen in der IT kosten in den ersten Wochen vor allem Zeit, Nerven und Geld. Viele Teams hoffen, dass sich das schon einruckelt. Meist passiert aber das Gegenteil: jeder arbeitet ein bisschen anders, Basiswissen fehlt, Standards werden ignoriert, und nach ein paar Monaten ist der Wildwuchs perfekt. Ein strukturiertes IT-Onboarding mit klar gebündelten Schulungen spart dir genau diese Schleifen.

Was IT-Onboarding eigentlich leisten soll

IT-Onboarding ist mehr als ein „Herzlich willkommen“ und ein paar Links zum Wiki. Ziel ist, dass neue Kolleginnen und Kollegen:

• fachlich schnell arbeitsfähig sind,
• eure Tools effizient nutzen können,
• eure Standards kennen und anwenden,
• und sich im Tech-Stack sicher bewegen.

Dafür reicht keine einmalige Präsentation. Du brauchst einen roten Faden, der die ersten Tage und Wochen strukturiert:

1. Orientierung: Was ist die Architektur, was sind die wichtigsten Systeme, wie sieht euer Entwicklungs- oder Betriebsprozess aus?
2. Basiskompetenz: Welche Technologien, Tools und Frameworks nutzt ihr, und auf welchem Mindestniveau müssen alle sein?
3. Standards: Wie schreibt ihr Code, dokumentiert, deployed, monitored, testet?
4. Team-spezifische Vertiefung: Was ist in diesem Team besonders wichtig, welche Verantwortlichkeiten, welche Services?

Je besser du diese Ebenen trennst und planst, desto weniger Chaos entsteht im Alltag.

Typische Probleme ohne strukturiertes IT-Onboarding

Wenn du neue Leute „on the job“ einarbeitest, tauchen immer wieder die gleichen Muster auf:

• Jeder erklärt etwas anders, vieles doppelt, manches gar nicht.
• Senior-Entwickler blocken halbe Tage für Ad-hoc-Schulungen.
• Neue Kollegen basteln sich eigene Workarounds, weil ihnen Grundlagen fehlen.
• Sicherheits- und Qualitätsstandards werden unbewusst unterlaufen.
• Nach einem Jahr arbeitet das Team in drei verschiedenen Stilen.

Die Kosten sind schwer messbar, aber real:

• Mehr Bugs, mehr Rework, mehr Abstimmungsaufwand.
• Langsameres Tempo bei Projekten.
• Höhere Frustration, sowohl bei Neuen als auch bei Erfahrenen.

Ein durchdachtes Schulungskonzept im Onboarding schafft hier einen Rahmen, der diese Reibungsverluste deutlich reduziert.

Wissensstand klären, bevor du Schulungen planst

Bevor du Basis-Schulungen bündelst, brauchst du ein klares Bild: Was sollen alle können, und was können die Neuen wirklich?

Hilfreich sind drei einfache Schritte:

1. Muss-Liste definieren Erstelle für jede Rolle eine Liste mit Fähigkeiten, die wirklich alle haben müssen. Zum Beispiel für eine Developer-Rolle:

• Git-Grundlagen und euer Workflow (z. B. Feature-Branches, Pull Requests, Code Review)
• Arbeit mit eurer CI/CD-Pipeline
• Logging, Monitoring, Alerting im produktiven System lesen können
• Basiswissen zu Security in eurem Kontext (z. B. OWASP Top 10, Secrets-Handling)
• Architektur-Überblick der wichtigsten Services

2. Selbsteinschätzung einholen Lass neue Kolleginnen und Kollegen ihren Wissensstand kurz einschätzen. Keine Prüfung, eher ein Raster wie:

• „Git Rebase sicher anwenden“: keine Erfahrung, Grundkenntnisse, sicher, Expertin/Experte
• „Kubernetes Deployment anpassen“: keine Erfahrung, …

So erkennst du, wo echte Lücken sind.

3. Kurztest oder Pairing-Session Ein kleiner praktischer Check, z. B. ein Mini-Ticket gemeinsam bearbeiten, zeigt schnell, ob die Einschätzung passt. Das ist oft ehrlicher als reine Selbstauskunft.

Auf dieser Basis entscheidest du, welche Schulungsmodule Pflicht sind und wo individuelle Vertiefung reicht.

Basis-Schulungen bündeln: Weg von „Einzelunterricht“

Statt jedem Neuzugang individuell alles zu erklären, lohnt es sich, Basis-Schulungen zu bündeln. Das spart Zeit und sorgt für einheitliche Inhalte.

Typische Basismodule im IT-Kontext:

• Tooling-Basics: IDE-Setup, Git-Workflow, Ticket-System, Wiki, Chat- und Kollaborationstools.
• Architektur-Überblick: Hauptsysteme, Schnittstellen, Domain-Modelle, Deployments.
• Entwicklungsprozess: Wie entstehen bei euch Features, wie laufen Releases, wie funktionieren Reviews.
• Qualitätsstandards: Code-Style, Test-Strategie, Definition of Done, Dokumentationsregeln.
• Security- und Compliance-Grundlagen: Passwortrichtlinien, Umgang mit Kundendaten, Geheimhaltung, Berechtigungen.

Diese Inhalte kannst du z. B. monatlich als kompakten Onboarding-Block anbieten, in dem alle Neuen gemeinsam geschult werden. Ideal ist eine Mischung aus:

• kurzen Theorie-Slots,
• Live-Demos,
• kleinen praktischen Übungen,
• und Zeit für Fragen.

Für stark technische Grundlagen wie Programmiersprachen, Frameworks oder Datenbanken lohnt sich oft eine externe Schulung als Ergänzung, vor allem wenn du mehrere Leute gleichzeitig einarbeitest. Aktuelle Termine und passende Kurse findest du bei cmt.de.

Standards vermitteln, nicht nur erwähnen

Viele Unternehmen haben schöne PDFs mit Coding-Guidelines und Prozessbeschreibungen. Gelesen werden sie selten. Standards musst du aktiv vermitteln und einüben.

Ein paar bewährte Ansätze:

• Standards in Übungen einbauen Wenn du Git erklärst, dann gleich in eurem echten Repository mit euren Branch-Regeln. Wenn du Tests erklärst, dann mit euren Test-Frameworks und eurem Build-Prozess.

• Checklisten nutzen Für Pull Requests, Deployments oder Tickets kurze, verbindliche Checklisten etablieren. Neue Kolleginnen und Kollegen arbeiten die bewusst durch, bis sie verinnerlicht sind.

• Beispiele zeigen Gute Beispiele aus eurem Code zeigen, nicht nur die Theorie erklären. „So sieht bei uns ein akzeptabler Pull Request aus“ ist konkreter als jede Guideline.

• Standards im Review einfordern Code Reviews und Pair Programming bewusst nutzen, um Standards zu verstärken. Kommentare nicht nur auf technische Fehler, sondern auch auf Einhaltung der Regeln richten.

• Konfiguration im Tooling Wo möglich, Standards automatisieren: Linter, Formatter, CI-Checks, Branch-Protection-Regeln. So spürt man Abweichungen sofort.

Standards werden dann gelebt, wenn sie im Alltag ständig sichtbar sind, nicht nur in einem Onboarding-Deck.

Wissen angleichen: Wer braucht welche Tiefe?

Nicht alle müssen alles gleich gut können. Aber es sollte einen gemeinsamen Sockel geben, auf dem ihr aufbaut.

Eine einfache Struktur ist:

Ebene	Zielgruppe	Inhalt
Basis	alle im IT-Team	Tools, Prozesse, Security-Grundlagen
Rolle	z. B. Dev, Ops, QA, Product	rollenspezifische Tools und Methoden
Spezial	z. B. Cloud, Data, Security-Spezis	tiefe Technologie- oder Domänenkenntnisse

Im Onboarding geht es vor allem um die Basis- und Rollenebene:

• Basis-Ebene: Alle sprechen dieselbe Sprache, kennen dieselben Begriffe und Werkzeuge. Das reduziert Missverständnisse in Tickets, Meetings und Dokumentation massiv.

• Rollen-Ebene: Hier vertiefst du zielgerichtet. Ein Dev bekommt andere Schulungen als jemand im IT-Support, auch wenn beide denselben Architektur-Überblick hatten.

Hilfreich ist ein einfaches Curriculum pro Rolle, zum Beispiel:

• Woche 1: Basis-Schulungen (Unternehmens-IT, Tools, Prozesse, Architektur)
• Woche 2: Rollenbasics (z. B. Entwicklungsprozess im Detail, Build- und Release-Prozess)
• Woche 3+: Vertiefung im Team, Pairing, Teilnahme an produktiven Aufgaben

Wichtig: Onboarding heißt nicht, dass alle nach zwei Wochen Experten sind. Es geht um einen stabilen Start und eine klare Lernperspektive.

Praxisbeispiel: IT-Onboarding in einem Münchner Entwicklungsteam

Nehmen wir ein typisches Münchner Software-Team mit 15 Leuten, Microservices im Backend, Web-Frontend, Cloud-Hosting. Neue Entwicklerinnen und Entwickler wurden bisher so eingearbeitet:

• Tag 1: Setup mit einem Kollegen
• Tag 2 bis 10: Mitlaufen, Tickets mit Bearbeitung „auf Sicht“
• Nach 3 Monaten: „Jetzt läuft es langsam“

Um das zu verbessern, definieren sie ein Onboarding-Paket:

1. Vorbereitete Umgebung Accounts, Berechtigungen, Basis-Setup sind spätestens am ersten Tag fertig. Es gibt ein kurzes Setup-Skript und eine Anleitung mit Screenshots.

2. Onboarding-Woche Die erste Woche ist klar strukturiert:

• Tag 1: Teamvorstellung, Architektur-Überblick, Tooling-Basics
• Tag 2: Git-Workflow, Branch-Strategie, Pull-Request-Regeln, erste kleine Änderung im echten Code
• Tag 3: Build- und Release-Prozess, CI/CD, Tests, Qualitätsstandards
• Tag 4: Monitoring, Logging, Incident-Prozess, Umgang mit produktiven Daten
• Tag 5: Pairing mit einem erfahrenen Entwickler, erstes echtes Ticket

3. Mentor und Check-ins Jede neue Person bekommt eine Mentorin oder einen Mentor. Am Ende von Woche 1, 3 und 6 gibt es einen kurzen Check-in: Was funktioniert, wo fehlen noch Grundlagen, welche Schulung ist als nächstes sinnvoll?

4. Standardisierte Schulungsmodule Für Git, CI/CD, Testing und Architektur gibt es vorbereitete Sessions, die alle Neuen durchlaufen. Die Unterlagen liegen im Wiki, werden aber immer live erklärt.

Ergebnis nach ein paar Monaten: Neue Kolleginnen und Kollegen sind nach 3 bis 4 Wochen produktiv, nicht erst nach 3 Monaten. Senior-Entwickler verbringen weniger Zeit mit Ad-hoc-Erklärungen und mehr mit fachlich anspruchsvollen Themen.

Interne vs. externe Schulungen: sinnvoll kombinieren

Nicht jede Schulung musst du selbst bauen. Eine grobe Daumenregel:

• Intern abbilden solltest du:

• Architektur-Überblick und Systemlandschaft

• interne Prozesse, Tools, Standards

• Sicherheits- und Compliance-Regeln im Unternehmenskontext

• Extern einkaufen kannst du:

• Grundlagen und Vertiefungen in Programmiersprachen und Frameworks

• moderne Plattform- und Cloud-Themen

• Best Practices in Bereichen wie Testing, Clean Code, DevOps

Dein Vorteil: Externe Schulungen liefern saubere Grundlagen und aktuelle Best Practices, intern setzt du dann den Kontext und eure Spezifika oben drauf. So verschwendest du keine Zeit damit, zum x-ten Mal die Basics von Java, Python, Kubernetes oder React intern zu erklären.

Erfolg messen: Wird das Onboarding wirklich besser?

Ohne Messpunkte bleibt IT-Onboarding Bauchgefühl. Du kannst mit einfachen Kennzahlen starten:

• Wie lange dauert es im Schnitt, bis neue Kolleginnen und Kollegen eigenständig Tickets bearbeiten?
• Wie viele Rückfragen zu Basics kommen im ersten Monat?
• Wie oft werden in Reviews grundlegende Standards angemahnt?
• Wie bewerten die Neuen das Onboarding (kurze, gezielte Umfrage nach 4 bis 6 Wochen)?

Wenn du strukturiert Schulungen einführst, sollten diese Werte sich nach und nach verbessern. Wichtig ist, dass du das Onboarding als lebendes System siehst: Feedback einsammeln, Module nachschärfen, Inhalte aktualisieren.

Fazit: Onboarding wie ein kleines Curriculum planen

Ein gutes IT-Onboarding entsteht nicht nebenbei. Wenn du es wie ein kleines Curriculum planst, mit klaren Lernzielen, gebündelten Basis-Schulungen und gelebten Standards, zahlst du direkt auf Produktivität und Qualität ein.

Die Kernpunkte:

• Definiere, was alle können müssen, und was rollenspezifisch ist.
• Bündle Basis-Schulungen, statt alles ad hoc zu erklären.
• Vermittle Standards praxisnah, im echten System, mit echten Beispielen.
• Nutze interne Schulungen für euren Kontext und ergänze externe Trainings für Technologie-Basics.
• Miss den Erfolg und passe dein Onboarding laufend an.

So werden neue Kolleginnen und Kollegen nicht nur schneller produktiv, sie arbeiten von Anfang an so, wie es zu euren Anforderungen und Qualitätsansprüchen passt.