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 „bevor du das machst, brauchst du jenes" – und 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 und in eine sinnvolle Reihenfolge bringt. Drei Eigenschaften sind dabei entscheidend:

• 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 Levels. 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 Learning an: nicht als Ersatz für jedes LMS, sondern als Strukturierungs- und Orchestrierungsschicht für technisches Lernen. Bestehende Inhalte aus Wikis, Repositories, Videos, SharePoint, Confluence oder auch einem LMS werden zu Lernpfaden mit Reihenfolge, Voraussetzungen und Team-Kontext verbunden. Wer sehen will, wie ein solcher Pfad konkret aussieht, findet im Beitrag Cloud Engineer Onboarding in 4 Wochen ein durchgerechnetes 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. Wer technisches Onboarding und Skill-Aufbau wirksam gestalten will, braucht deshalb nicht nur Kurse, sondern Struktur über bestehendem Wissen.