IT-Systeme und Software-Lösungen werden komplexer, verteilter und stärker miteinander vernetzt. Geschäftsprozesse greifen ineainander, Daten werden weitergegeben und überall verarbeitet.
Gleichzeitig führt die zunehmende Spezialisierung dazu, dass sich technische Rollen immer weiter voneinander entfernen: Netzwerk, Datenbanken, Cloud, Security, Betriebssysteme, Programmierung, DevOps, Containerisierung, CI/CD, Monitoring und KI.
Spezialisierung ist notwendig. Niemand kann heute noch die gesamte IT in gleicher fachlicher Kompetenz beherrschen.
Das eigentliche Problem entsteht dort, wo Spezialisierung mit einem fehlenden Verständnis für Zusammenhänge verwechselt wird.
Hier setzt das Konzept des T-Shaped Knowledge an.
Was bedeutet T-Shaped Knowledge?
Das „T“ beschreibt eine Kombination aus fachlicher Spezialisierung und interdisziplinärer Anschlussfähigkeit.
Der senkrechte Strich steht für ein Fachgebiet, in dem eine Person über ausgeprägte Kompetenz verfügt. Das kann beispielsweise Software Engineering, Netzwerkarchitektur, Cloud Computing oder IT-Security sein.
Der waagerechte Strich steht für ein breiteres Verständnis angrenzender Disziplinen.
Dabei geht es ausdrücklich nicht darum, jede technische Schicht selbst beherrschen zu müssen.
Ein Software Engineer muss weder Netzwerkadministrator noch Datenbankadministrator, UX-Designer, Cloud Architect und Elektrotechniker sein. Er muss auch nicht jede Ebene des OSI-Modells bis zur physikalischen Übertragung einzelner Bits technisch analysieren können.
Entscheidend ist vielmehr die Fähigkeit, technische Zusammenhänge zu modellieren und Probleme über die Grenzen der eigenen Spezialisierung hinweg einzuordnen.
IT-Probleme sind selten disziplinrein
Eine Anwendung ist nicht erreichbar.
Die Ursache könnte in der Programmierung liegen. Sie könnte aber ebenso im DNS, Netzwerk, Routing, einer Firewall, einem Load Balancer, einem Zertifikat, einem Container, dem Betriebssystem, einer Datenbank oder einer externen Abhängigkeit liegen.
Die technische Herausforderung besteht deshalb zunächst nicht darin, die richtige Lösung zu kennen.
Sie besteht darin, den Problemraum korrekt einzugrenzen.
Ein Spezialist mit engem Zuständigkeitsverständnis könnte sagen:
„Das ist nicht mein Bereich.“
Ein T-Shaped Engineer stellt dagegen zunächst Hypothesen auf:
„Welche Komponenten könnten diesen Fehler verursachen und wie kann ich die Ursache systematisch eingrenzen?“
Dafür muss er nicht jede dieser Komponenten selbst administrieren können.
Er muss verstehen, welche Abhängigkeiten bestehen, welche Messgrößen relevant sind und wann die Expertise eines anderen Spezialisten erforderlich ist.
T-Shaped bedeutet Systemverständnis
Genau hier liegt ein häufiges Missverständnis.
T-Shaped Knowledge bedeutet nicht:
„Ich kann alles.“
Es bedeutet:
„Ich beherrsche ein Fachgebiet und verstehe ausreichend viele angrenzende Bereiche, um technische Systeme als Gesamtheit analysieren zu können.“
Ein Software Engineer sollte beispielsweise nachvollziehen können, dass zwischen einer Benutzeranfrage und einer Datenbankabfrage zahlreiche technische Komponenten liegen können:
Client → DNS → Netzwerk → Firewall → Load Balancer → Anwendung → Datenbank → externe Services
Wenn eine Anfrage fehlschlägt, muss er nicht jede dieser Komponenten selbst implementieren oder administrieren.
Er sollte jedoch in der Lage sein, die möglichen Fehlerdomänen zu unterscheiden und durch geeignete Tests und Messungen schrittweise einzugrenzen, wo die Ursache liegt.
This is Systemdenken in der IT.
Von der Fachkompetenz zur Problemlösungskompetenz
Damit verschiebt sich auch die Definition eines guten IT-Spezialisten.
Es reicht nicht aus, möglichst viel Wissen innerhalb einer einzelnen Technologie anzusammeln.
Entscheidend ist die Fähigkeit, dieses Wissen in einem komplexen System anzuwenden.
Dazu gehören beispielsweise:
- Abhängigkeiten erkennen
- technische Hypothesen formulieren
- Fehlerdomänen eingrenzen
- relevante Metriken und Logs identifizieren
- Ursache und Symptom unterscheiden
- technische Trade-offs bewerten
- andere Fachbereiche gezielt einbinden
- Lösungen hinsichtlich ihrer Auswirkungen auf das Gesamtsystem beurteilen
Das ist ein wesentlicher Unterschied zwischen Technologiewissen und Engineering-Kompetenz.
Auch KI verändert daran wenig
KI kann heute Programmierung erzeugen, Konfigurationen analysieren, Logs interpretieren und technische Lösungsvorschläge entwickeln.
Dadurch wird reines Auswendigwissen teilweise weniger wertvoll.
Gleichzeitig steigt die Bedeutung der Fähigkeit, Ergebnisse fachlich zu validieren.
Wenn ein KI-System eine Änderung an der Programmierung vorschlägt, muss jemand beurteilen können, ob das Problem tatsächlich in der Programmierung liegt.
Wenn eine Konfiguration verändert werden soll, muss jemand verstehen, welche Auswirkungen das auf Netzwerk, Security, Betrieb und abhängige Systeme haben kann.
KI kann damit die technische Arbeit beschleunigen.
Sie ersetzt jedoch nicht automatisch das Systemverständnis, das notwendig ist, um ihre Ergebnisse sinnvoll zu bewerten.
Die Zukunft gehört nicht den Universalisten
T-Shaped Knowledge bedeutet deshalb auch nicht, dass Spezialisten überflüssig werden.
Im Gegenteil.
Komplexe IT-Systeme benötigen weiterhin hochspezialisierte Experten.
Aber diese Spezialisten müssen miteinander kommunizieren und ihre Arbeit in einem gemeinsamen technischen Kontext verstehen können.
Die entscheidende Kompetenz ist deshalb nicht:
„Ich kenne jede Technologie.“
Und auch nicht:
„Das ist nicht mein Zuständigkeitsbereich.“
But rather:
„Ich verstehe mein Fachgebiet, erkenne seine Schnittstellen zu anderen Bereichen und kann Probleme systematisch über diese Grenzen hinweg analysieren.“
Das ist T-Shaped Engineering.
Fachliche Spezialisierung plus Systemverständnis.
Und genau diese Kombination wird in einer zunehmend verteilten, automatisierten und KI-gestützten IT-Landschaft immer wichtiger.