Bruce Lee sagte einmal: "Ich fürchte nicht den Mann, der 10.000 Tritte trainiert hat. Ich fürchte den Mann, der einen einzigen Tritt 10.000 Mal trainiert hat." In der Kampfkunst – und in der Technik – gibt es immer die Versuchung, dem Neuen nachzujagen: eine andere Bewegung, eine andere Waffe, eine glänzende Technik, die einen Vorteil verspricht. Doch dieser Drang lenkt oft von dem ab, was wirklich zählt: die Beherrschung der Grundlagen.
Wenn wir zu viele neue Techniken üben, verlieren wir die Präzision und Effektivität der Grundlagen. Es nützt nichts, mehr Tritttechniken zu trainieren, wenn wir die bekannten Tritte nicht auf ein Niveau gebracht haben, auf dem sie wirklich nützlich sind. Mehr zu üben, statt vorhandene Fähigkeiten zu perfektionieren, bedeutet Verschwendung wertvoller Trainingszeit – Zeit, die wir besser nutzen könnten, um wirklich besser zu werden.
Das Äquivalent von 10.000 Tritten in Tech-Unternehmen
In modernen DevOps- und Engineering-Teams werden neue Tools oft zu schnell und unüberlegt eingeführt – zum Nachteil des Produkts. Zeit und Ressourcen sind begrenzt, und ihre falsche Nutzung wirkt sich direkt auf die Qualität aus.
Ein Beispiel: Ein Team betrieb wenige, kleine Dienste auf virtuellen Maschinen – einfache Python-Skripte in Docker-Containern auf stabilem Ubuntu. Wartung und Updates waren unkompliziert, jeder mit Grundkenntnissen konnte sie durchführen.
Dann entschied das Team, die Dienste in die Cloud auf Kubernetes zu migrieren. Dafür wurden neue Automatisierungsebenen und Tools eingeführt, mit denen die meisten Teammitglieder kaum vertraut waren. VMs wurden durch Virtual Scale Sets ersetzt, redundanter Netzwerkspeicher hinzugefügt, Azure-Komponenten integriert und ein neues Monitoring-Backend samt Datenbank eingerichtet.
Plötzlich erforderte selbst die Lösung kleinster Probleme deutlich mehr Spezialwissen. Wissensinseln entstanden, da nur wenige den Überblick behielten. Die Entwicklung verlangsamte sich, Fehleranalysen dauerten Stunden oder Tage – ohne erkennbaren Mehrwert für das Produkt, aber mit massivem Produktivitätsverlust.
Ein weiteres sehr typisches Muster betrifft Jenkins: Stellt euch ein Unternehmen vor, das das allseits beliebte Jenkins in der typischen, veralteten Installation hat. Das Team beschließt, auf GitHub umzusteigen, aber da die alten Pipelines kompliziert sind, findet es nie die Zeit, sie alle umzustellen. Jetzt sind also zwei Pipelinesysteme im Einsatz. Irgendwann wechseln ein paar andere Teams von GitHub zu Azure DevOps, was das Hipster-Team dazu ermutigt, für seine eigene Lösung zu plädieren, von der noch nie jemand gehört hat, die aber angeblich alle Probleme löst, weil sie neu, klein und glänzend ist.
Zu diesem Zeitpunkt ist Jenkins immer noch ein Problem, das genau die gleiche Menge an Engagement erfordert, und obendrein haben die Teams Wissensinseln und Barrieren geschaffen.
Sollten wir also zu Perl zurückkehren?
Wir könnten unzählige Beispiele nennen: neue Programmiersprachen, Monitoring-Tools, Cloud-Anbieter oder komplette Tech-Stack-Migrationen, nur weil „neu“ besser klingen soll – ohne dass es wirklich Vorteile bringt.
Oft führt eine Erweiterung des Tech-Stacks nicht zu besseren Ergebnissen, sondern zu unerwünschten Nebenwirkungen. Teams mit begrenztem Stack dagegen verstehen Code, Infrastruktur und Produkt über Abteilungsgrenzen hinweg – und sind die wirklich agilen Unternehmen.
Wir prüfen daher oft die Anzahl der eingesetzten Tools als Reifegrad-Indikator: Nutzt das Team eine kleine, bewusste Auswahl für maximalen Nutzen, oder herrscht Tool-Anarchie? In der Praxis gibt es selten Schwarz oder Weiß, aber die Unterschiede wirken sich direkt auf Produktivität und Übersicht aus.
Warum nicht einfach neue Tools hinzufügen?
Neue Tools erhöhen Komplexität, verringern Produktivität, erschweren Wartung, reduzieren den Teamfokus und erschweren den Wissensaustausch.
Komplexität: Der stille Killer moderner Technik
Komplexität untergräbt Produktivität schneller als schlechter Code. Jedes neue Tool bringt versteckte Kosten: Infrastruktur, Datenbanken, Build-Systeme, Paketmanager, Wissenserwerb, Ablösung alter Tools, Datenmigration – alles summiert sich schnell.
Viele Unternehmen haben diesen Kampf verloren: Sie sind langsamer, instabiler, Fehlerbehebung dauert länger und Entwicklung wird teurer. Statt neue Komplexität aufzubauen, sollten wir vereinfachen und verschlanken.
Produktivität: Versteckte Kosten neuer Tools
Ein neues Tool kostet Zeit – und oft noch mehr, wenn Komplexität steigt: Wartung, Dokumentation und Überblick über Nutzung verdoppeln sich, kleine Details summieren sich zu großen Problemen. In Unternehmen mit mehreren Wissensdatenbanken entstehen direkt Produktivitätsverluste, wenn Informationen im falschen Tool gesucht werden.
Wartbarkeit: Ohne Verantwortliche bricht alles zusammen
Jedes Tool braucht Pflege – intern oder ausgelagert. Die Kosten verschwinden nicht, selbst bei SaaS-Lösungen ist eine Abschaltung oft nur theoretisch möglich. Ohne klaren Eigentümer entstehen unkontrollierte Nutzungen, komplexe Anwendungsfälle und schwer wartbare Systeme.
Teamfokus: Einfachheit sichert Koordination
Mehrere parallele Systeme führen dazu, dass Teams Fehlerbehebung umgehen, Daten vernachlässigen und zwischen Tools hin- und herwechseln. Das verringert Produktivität und kann zu Fehlentscheidungen führen. Wir setzen deshalb auf Tool-Eigentümer – ein Team, nicht eine einzelne Person, das für Nutzung, Updates und Verwaltung verantwortlich ist. Ohne klare Eigentümerschaft entstehen Chaos und ineffiziente Prozesse.
Wissensaustausch: Gemeinsames Verständnis statt Einzelwissen
Jedes Team muss wissen, wie Tools genutzt und gepflegt werden. Neue Programmiersprachen oder Systeme erfordern Zeit, Refactoring und kontinuierliche Pflege. Tools müssen aufeinander abgestimmt eingesetzt werden, sonst entstehen Fehler und Verzögerungen.
KI wird es nicht richten
Diese Meinung ist zwar bei vielen Unternehmen beliebt, die den Kampf gegen die Komplexität verloren haben, aber sie ist falsch. Wenn man dem Chaos noch KI hinzufügt, fügt man letztlich nur eine weitere Ebene der Komplexität hinzu, über die man noch weniger Kontrolle hat. Wenn eure Komplexität einen Punkt erreicht hat, an dem kein menschliches Team mehr die Chance hat, die Vorgänge zu verstehen, sitzt ihr auf einer tickenden Zeitbombe.
Wir schätzen den Einsatz von KI-Tools in meiner täglichen Arbeit sehr und empfehlen, sie zu nutzen, um Komplexität in den Griff zu bekommen und sie zu reduzieren, anstatt sie blindlings zu erhöhen.
Wie wir fokussiert bleiben
Bevor ein neues Tool eingeführt wird, fragen wir:
Neue Tools starten wir stets mit einem MVP statt einem POC. So erkennen wir schnell, ob das Tool wirklich nötig ist.
Wir hören auf, 9.999 Kicks zu trainieren – und konzentrieren uns auf die, die den Unterschied machen.
Wenn wir zu viele neue Techniken üben, verlieren wir die Präzision und Effektivität der Grundlagen. Es nützt nichts, mehr Tritttechniken zu trainieren, wenn wir die bekannten Tritte nicht auf ein Niveau gebracht haben, auf dem sie wirklich nützlich sind. Mehr zu üben, statt vorhandene Fähigkeiten zu perfektionieren, bedeutet Verschwendung wertvoller Trainingszeit – Zeit, die wir besser nutzen könnten, um wirklich besser zu werden.
Das Äquivalent von 10.000 Tritten in Tech-Unternehmen
In modernen DevOps- und Engineering-Teams werden neue Tools oft zu schnell und unüberlegt eingeführt – zum Nachteil des Produkts. Zeit und Ressourcen sind begrenzt, und ihre falsche Nutzung wirkt sich direkt auf die Qualität aus.
Ein Beispiel: Ein Team betrieb wenige, kleine Dienste auf virtuellen Maschinen – einfache Python-Skripte in Docker-Containern auf stabilem Ubuntu. Wartung und Updates waren unkompliziert, jeder mit Grundkenntnissen konnte sie durchführen.
Dann entschied das Team, die Dienste in die Cloud auf Kubernetes zu migrieren. Dafür wurden neue Automatisierungsebenen und Tools eingeführt, mit denen die meisten Teammitglieder kaum vertraut waren. VMs wurden durch Virtual Scale Sets ersetzt, redundanter Netzwerkspeicher hinzugefügt, Azure-Komponenten integriert und ein neues Monitoring-Backend samt Datenbank eingerichtet.
Plötzlich erforderte selbst die Lösung kleinster Probleme deutlich mehr Spezialwissen. Wissensinseln entstanden, da nur wenige den Überblick behielten. Die Entwicklung verlangsamte sich, Fehleranalysen dauerten Stunden oder Tage – ohne erkennbaren Mehrwert für das Produkt, aber mit massivem Produktivitätsverlust.
Ein weiteres sehr typisches Muster betrifft Jenkins: Stellt euch ein Unternehmen vor, das das allseits beliebte Jenkins in der typischen, veralteten Installation hat. Das Team beschließt, auf GitHub umzusteigen, aber da die alten Pipelines kompliziert sind, findet es nie die Zeit, sie alle umzustellen. Jetzt sind also zwei Pipelinesysteme im Einsatz. Irgendwann wechseln ein paar andere Teams von GitHub zu Azure DevOps, was das Hipster-Team dazu ermutigt, für seine eigene Lösung zu plädieren, von der noch nie jemand gehört hat, die aber angeblich alle Probleme löst, weil sie neu, klein und glänzend ist.
Zu diesem Zeitpunkt ist Jenkins immer noch ein Problem, das genau die gleiche Menge an Engagement erfordert, und obendrein haben die Teams Wissensinseln und Barrieren geschaffen.
Sollten wir also zu Perl zurückkehren?
Wir könnten unzählige Beispiele nennen: neue Programmiersprachen, Monitoring-Tools, Cloud-Anbieter oder komplette Tech-Stack-Migrationen, nur weil „neu“ besser klingen soll – ohne dass es wirklich Vorteile bringt.
Oft führt eine Erweiterung des Tech-Stacks nicht zu besseren Ergebnissen, sondern zu unerwünschten Nebenwirkungen. Teams mit begrenztem Stack dagegen verstehen Code, Infrastruktur und Produkt über Abteilungsgrenzen hinweg – und sind die wirklich agilen Unternehmen.
Wir prüfen daher oft die Anzahl der eingesetzten Tools als Reifegrad-Indikator: Nutzt das Team eine kleine, bewusste Auswahl für maximalen Nutzen, oder herrscht Tool-Anarchie? In der Praxis gibt es selten Schwarz oder Weiß, aber die Unterschiede wirken sich direkt auf Produktivität und Übersicht aus.
Warum nicht einfach neue Tools hinzufügen?
Neue Tools erhöhen Komplexität, verringern Produktivität, erschweren Wartung, reduzieren den Teamfokus und erschweren den Wissensaustausch.
Komplexität: Der stille Killer moderner Technik
Komplexität untergräbt Produktivität schneller als schlechter Code. Jedes neue Tool bringt versteckte Kosten: Infrastruktur, Datenbanken, Build-Systeme, Paketmanager, Wissenserwerb, Ablösung alter Tools, Datenmigration – alles summiert sich schnell.
Viele Unternehmen haben diesen Kampf verloren: Sie sind langsamer, instabiler, Fehlerbehebung dauert länger und Entwicklung wird teurer. Statt neue Komplexität aufzubauen, sollten wir vereinfachen und verschlanken.
Produktivität: Versteckte Kosten neuer Tools
Ein neues Tool kostet Zeit – und oft noch mehr, wenn Komplexität steigt: Wartung, Dokumentation und Überblick über Nutzung verdoppeln sich, kleine Details summieren sich zu großen Problemen. In Unternehmen mit mehreren Wissensdatenbanken entstehen direkt Produktivitätsverluste, wenn Informationen im falschen Tool gesucht werden.
Wartbarkeit: Ohne Verantwortliche bricht alles zusammen
Jedes Tool braucht Pflege – intern oder ausgelagert. Die Kosten verschwinden nicht, selbst bei SaaS-Lösungen ist eine Abschaltung oft nur theoretisch möglich. Ohne klaren Eigentümer entstehen unkontrollierte Nutzungen, komplexe Anwendungsfälle und schwer wartbare Systeme.
Teamfokus: Einfachheit sichert Koordination
Mehrere parallele Systeme führen dazu, dass Teams Fehlerbehebung umgehen, Daten vernachlässigen und zwischen Tools hin- und herwechseln. Das verringert Produktivität und kann zu Fehlentscheidungen führen. Wir setzen deshalb auf Tool-Eigentümer – ein Team, nicht eine einzelne Person, das für Nutzung, Updates und Verwaltung verantwortlich ist. Ohne klare Eigentümerschaft entstehen Chaos und ineffiziente Prozesse.
Wissensaustausch: Gemeinsames Verständnis statt Einzelwissen
Jedes Team muss wissen, wie Tools genutzt und gepflegt werden. Neue Programmiersprachen oder Systeme erfordern Zeit, Refactoring und kontinuierliche Pflege. Tools müssen aufeinander abgestimmt eingesetzt werden, sonst entstehen Fehler und Verzögerungen.
KI wird es nicht richten
Diese Meinung ist zwar bei vielen Unternehmen beliebt, die den Kampf gegen die Komplexität verloren haben, aber sie ist falsch. Wenn man dem Chaos noch KI hinzufügt, fügt man letztlich nur eine weitere Ebene der Komplexität hinzu, über die man noch weniger Kontrolle hat. Wenn eure Komplexität einen Punkt erreicht hat, an dem kein menschliches Team mehr die Chance hat, die Vorgänge zu verstehen, sitzt ihr auf einer tickenden Zeitbombe.
Wir schätzen den Einsatz von KI-Tools in meiner täglichen Arbeit sehr und empfehlen, sie zu nutzen, um Komplexität in den Griff zu bekommen und sie zu reduzieren, anstatt sie blindlings zu erhöhen.
Wie wir fokussiert bleiben
Bevor ein neues Tool eingeführt wird, fragen wir:
- Brauchen wir es wirklich?
- Wie hoch sind die Gesamtkosten – inklusive Wartung und Lernaufwand?
- Können wir bestehende Tools effektiv nutzen?
- Welchen tatsächlichen Nutzen bringt das Tool?
Neue Tools starten wir stets mit einem MVP statt einem POC. So erkennen wir schnell, ob das Tool wirklich nötig ist.
Wir hören auf, 9.999 Kicks zu trainieren – und konzentrieren uns auf die, die den Unterschied machen.
