Warum klassische LMS bei technischen Teams oft an Grenzen stoßen

Viele größere Unternehmen betreiben ein Learning-Management-System und trotzdem lernen technische Teams im Alltag oft an ganz anderen Orten: über YouTube, Confluence, interne Wikis, GitHub-READMEs oder direkte Zusammenarbeit im Team. Das ist kein Zufall. Klassische LMS wurden für andere Lernlogiken gebaut, als sie in Engineering-, Plattform- oder SRE-Teams gebraucht werden.

Wofür klassische LMS gebaut wurden und wo ihre Grenzen liegen

Klassische Systeme wie Moodle, Cornerstone oder SAP SuccessFactors Learning sind stark, wenn es um Pflichtschulungen, formale Lernangebote, zentrale Kursverwaltung und Nachweise geht. Ihr Datenmodell ist der Kurs: ein definierter Inhalt, der erstellt, freigegeben, ausgerollt und abgeschlossen wird. Für Compliance, Zertifizierungen und standardisierte Trainings ist das sinnvoll. Für technisches Onboarding und kontinuierlichen Skill-Aufbau in dynamischen Teams reicht diese Logik oft nicht aus.

Technisches Wissen ist nicht kursförmig. Es ist verteilt, ändert sich wöchentlich und lebt dort, wo gearbeitet wird. Ein LMS, das verlangt, dieses Wissen erst in Kursform zu gießen, erzeugt genau die Reibung, an der es scheitert.

Drei Gründe für das Scheitern

1. Der Content veraltet schneller, als ihn jemand pflegt

Eine Kubernetes-Schulung von vor 18 Monaten ist teilweise falsch. Niemand im Team hat Zeit, LMS-Kurse aktuell zu halten, also bleibt der Inhalt stehen, verliert Vertrauen und wird umgangen. Das eigentliche Wissen liegt längst in einer Confluence-Seite, die gestern aktualisiert wurde.

2. Es ignoriert Abhängigkeiten

Lernen in technischen Domänen ist eine Reihenfolge: Erst Netzwerkgrundlagen, dann Service Mesh. Erst Git, dann CI/CD. Ein LMS kennt Kurslisten, aber keine Voraussetzungen. Es kann nicht sagen „erst das, dann jenes". Genau diese Struktur ist beim Onboarding entscheidend.

3. Es zwingt zu Doppelarbeit

Das beste Material existiert bereits: ein hervorragendes Konferenzvideo, die interne Architektur-Doku, ein präziser Blogpost. Ein LMS verlangt, all das neu als Kurs nachzubauen. Wer einen Vollzeitjob als Engineer hat, tut das nicht.

Was technische Teams stattdessen brauchen

Nicht noch ein System, das Inhalte hostet, davon gibt es genug. Sondern eine Schicht, die vorhandene Inhalte kuratiert, in eine sinnvolle Reihenfolge bringt und festlegt, wer sie weitergibt. Vier Eigenschaften sind dabei entscheidend:

• Menschen statt Kurse: Das meiste technische Wissen geht über Pairing, Review und die Frage an die Kollegin, die es kann. Ein Pfad macht daraus Schritte mit Pate, Praxisaufgabe und Frist, statt es erst in Kursform zu gießen.
• Link-basiert statt Content-Hosting: Das Material bleibt an seiner Quelle und wird nur referenziert. Änderungen an der Quelle müssen nicht zusätzlich in einem separaten Kurssystem nachgezogen werden.
• Abhängigkeiten als Kern: Module haben Voraussetzungen und Stufen. Der Pfad zeigt, was in welcher Reihenfolge sinnvoll ist.
• Pro Rolle, pro Team: Ein Backend-Onboarding sieht anders aus als das eines Data Engineers. Pfade sind zugeschnitten, nicht generisch.

Genau hier setzt Caltrix an, nicht als Ersatz für jedes LMS, sondern an dessen Voraussetzung: Eine Kursplattform setzt eine Lernabteilung voraus, die Fachleute zu Autoren macht und die Redaktion führt. Caltrix setzt keine voraus: Es organisiert die Weitergabe zwischen Menschen. In Caltrix Learning werden bestehende Inhalte aus Wikis, Repositories, Videos, SharePoint, Confluence oder auch einem LMS zu Lernpfaden mit Reihenfolge, Voraussetzungen, Pate und Frist verbunden. Wer sehen will, wie ein solcher Pfad konkret aussieht, findet im Beitrag Cloud Engineer Onboarding in 4 Wochen ein ausgearbeitetes Beispiel.

Wann ein LMS trotzdem sinnvoll ist

Ein klassisches LMS ist die richtige Wahl, wenn ihr verpflichtende Trainings ausrollen, Zertifizierungen verwalten oder auditierbare Lernnachweise führen müsst. Auch standardisierte Schulungen, die zentral erstellt und an viele Bereiche verteilt werden, lassen sich in einem LMS gut verwalten. Das Problem beginnt dort, wo technisches Lernen nicht aus abgeschlossenen Kursen besteht, sondern aus vielen verteilten Quellen, Erfahrungswissen und einer sinnvollen Reihenfolge im Arbeitskontext.

Fazit

Klassische LMS sind nicht grundsätzlich ungeeignet. Sie lösen nur andere Aufgaben. Für Compliance, Pflichtschulungen und formale Lernnachweise sind sie oft die richtige Wahl. Technische Teams brauchen darüber hinaus jedoch etwas, das vorhandenes Wissen aus unterschiedlichen Quellen in eine sinnvolle Reihenfolge bringt und festlegt, wer es wem bis wann beibringt. Wer technisches Onboarding und Skill-Aufbau wirksam gestalten will, braucht deshalb nicht nur Kurse, sondern Struktur über bestehendem Wissen und Menschen, die es verbindlich weitergeben. Wie aus diesem Skill-Aufbau ein Kompetenzstand wird, der sich nicht von Hand pflegen lässt, steht auf der Seite zur Software für Personalentwicklung.