Die meisten technischen Probleme sind Menschenprobleme

• In Unternehmen mit großer technischer Schuld entstehen Ineffizienzen durch duplizierten Code und veraltete Frameworks
• Während eines Projekts wirken Vertrauensverlust beim Management und Widerstand gegen Veränderungen in der Organisation als zentrale Hindernisse
• Die eigentlichen Ursachen technischer Schuld sind menschliche Faktoren wie unklare Anforderungen, unrealistische Zeitpläne, die Bevorzugung veralteter Technologien, kurzfristige Reaktionen des Managements und persönlicher Stolz
• Für den Projekterfolg sind nicht nur technische Ergebnisse, sondern auch Wahrnehmungsmanagement und Kommunikation entscheidend
• Engineer:innen brauchen neben technischem Können auch die Fähigkeit zur Zusammenarbeit in der Organisation und zum Austarieren zwischenmenschlicher Beziehungen

---

Technische Schuld und das Problem duplizierten Codes

• In einem Unternehmen, in dem ich früher gearbeitet habe, gab es mit Millionen Codezeilen, fehlenden Unit-Tests und der Nutzung von über 10 Jahre alten Frameworks erhebliche technische Schuld
  • Um ein nur für Windows vorgesehenes Modul unter Linux auszuführen, wurden Hunderttausende Codezeilen per Copy-and-Paste übernommen
  • Dadurch entstanden zwei Codebasen, sodass neue Funktionen und Bugfixes jeweils separat umgesetzt werden mussten
• Eine solche Situation führt zu einer nicht wartbaren Struktur und langfristig zu immer größeren Abweichungen zwischen den Codebasen

Technische Schuld durch Menschenprobleme

• Projekte zum Abbau technischer Schuld lassen sich dem Management nur schwer vermitteln, und weil sich funktional kaum etwas ändert, fehlt am Ende oft ein sichtbares Ergebnis
  • Das Projekt verzögerte sich, wodurch das Vertrauen des Managements verloren ging
• Das Wesen des Problems ist nicht Technik, sondern die Haltung der Menschen und die Organisationskultur
  • Viele Entwickler:innen leisten Veränderungen Widerstand und verharren in alten Vorgehensweisen
  • Die Code-Struktur spiegelt den Charakter und die Veränderungsbereitschaft ihrer Autor:innen wider
• Technische Schuld entsteht aus unklaren Anforderungen, unrealistischen Zusagen, der Wahl veralteter Technologien, Abbruchentscheidungen des Managements und persönlichem Stolz
  • Je stärker ein Team dazu neigt, Veränderungen auszuweichen, desto stärker zeigt auch der Code Merkmale der Veränderungsabwehr
• Mehrere Entwickler arbeiteten seit Jahren unverändert auf dieselbe Weise, und es fiel sogar der Satz: „Ich will nichts Neues lernen.“
• In einem solchen Umfeld wächst die Schuld schneller, als man aufräumen kann; deshalb muss man, bevor man sie abbaut, zunächst verhindern, dass noch mehr davon entsteht
  • Wie bei Triage (Priorisierung) in der Notaufnahme braucht es zuerst die Phase, in der man „die Blutung stoppt“

Die Lücke zwischen idealer Welt und Realität

• Es gibt kaum eine ideale Umgebung, in der sich Engineering-Probleme losgelöst von Politik oder organisatorischem Kontext lösen lassen
  • An den meisten Projekten sind nichttechnische Stakeholder beteiligt
  • Die Haltung „Vertraut uns einfach, wir kümmern uns darum“ funktioniert nicht
• Das Management der Wahrnehmung von Ergebnissen ist genauso wichtig wie die Ergebnisse selbst
  • Nichttechnische Personen verstehen die Notwendigkeit des Abbaus technischer Schuld nicht intuitiv; deshalb muss man sie mit quantifizierbarem und geschäftlichem Nutzen erklären
  • Wenn Führungskräfte keinen Engineering-Hintergrund haben, müssen sichtbare Kennzahlen und Effekte präsentiert werden
• Letztlich ist es genauso wichtig, dass ein Team produktiv wirkt, wie dass es tatsächlich produktiv ist

Fähigkeiten, die Senior Engineers brauchen

• Ab dem Senior-Level sind abteilungsübergreifende Zusammenarbeit und das Austarieren zwischenmenschlicher Beziehungen unverzichtbar
  • In der Informatikausbildung lernt man nicht den Umgang mit Menschen wie Persönlichkeit, Stolz und Beziehungsmanagement
• Selbst Engineer:innen mit herausragenden technischen Fähigkeiten können an Problemen scheitern, die groß angelegte organisatorische Veränderungen erfordern
  • Die persönliche Produktivität ist hoch, aber der organisatorische Einfluss bleibt begrenzt
• Die Rolle des „Heads up coder“ ist wichtig
  • Jemand, der tiefes technisches Know-how behält und zugleich Projektrisiken früh erkennt und das Team steuern kann
  • Statt allein schnell wie ein einzelner Core zu arbeiten, übernimmt diese Person die Rolle, das gesamte Team effizient zu führen
  • Anders als ein rein technisch orientierter Engineer kann sie sich mit dem organisatorischen Kontext und Risiken gemeinsam bewegen und diese mitlesen

Zusammenfassung

• Hinter technischen Problemen stehen immer Menschen
  • Die meisten technischen Probleme laufen letztlich auf Menschen, Kultur und Kommunikation hinaus
• Technische Schuld ist kein Code-Problem, sondern das Ergebnis organisationaler Verhaltensmuster und Kultur
  • Für den Abbau technischer Schuld müssen die Bereitschaft zu organisatorischer Veränderung und das Verständnis der Führung vorausgehen
• Und auf den größeren Bühnen der späteren Karriere warten Probleme, die sich nicht allein durch technische Exzellenz lösen lassen
  • Ein wirklicher Senior Engineer ist eine ausgewogene Führungspersönlichkeit, die Technik und Menschenverständnis zugleich beherrscht