Die meisten technischen Probleme sind Menschenprobleme
(blog.joeschrag.com)- 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
2 Kommentare
Hacker-News-Meinung
Ich habe festgestellt, dass die meisten Probleme Kommunikationsprobleme sind
Ingenieure sind von der Produktvision oder den Kunden abgeschnitten, und das Produktteam behandelt die Ingenieure wie ein bloßes internes Outsourcing-Team
Vertrieb und CS verstehen nicht, welche Auswirkungen ihre Zusagen auf die Produkt-Roadmap haben
Am Ende sind Ziele und Erfolgsmetriken nicht aufeinander abgestimmt, und alle rudern in unterschiedliche Richtungen
Die Lösung ist nicht „bessere Leute“, sondern dafür zu sorgen, dass sich alle auf dasselbe Ziel konzentrieren und verstehen, wie ihre jeweilige Rolle mit dem Ganzen zusammenhängt
Dasselbe gilt für alte technische Schulden: Sie verschwinden nicht, wenn man sie ignoriert. Man muss die Kosten und Risiken, die diese Schulden dem Unternehmen verursachen, quantifizieren, sie gegen andere Ziele abwägen und einen Plan zu ihrer Tilgung aufstellen
Dabei sind die Nutzer direkt nebenan, man trifft sie persönlich, freundet sich mit ihnen an und lernt ihren Alltag und Kontext kennen
Es wird alle 3 Wochen automatisch geplant und läuft ohne separate Action Items. Jedes Mal sind die Leute überrascht, kleine Bugs werden behoben und es entstehen Verbindungen
Ich betreibe dafür einen automatischen Scheduler mit Anbindung an die Slack API, und der schwierigste Teil ist die Terminabstimmung und die Teilnahmebereitschaft
Das Management hört den Untergebenen nicht zu, und die Untergebenen konkurrieren darum, Aufmerksamkeit zu bekommen
Vor Kurzem wollte in unserer Abteilung ein Berater auf eine neue Plattform umstellen, niemand war einverstanden, aber stoppen ließ es sich nicht. Am Ende hört niemand zu
Auf die Frage „Warum machen wir das?“ kommt nur eine Antwort im Stil von „Vertrau mir einfach, Bruder“ zurück
Dieses Verhalten von PMs wird sich vermutlich nicht ändern. Deshalb übernehmen Ingenieure direkt Produktaufgaben und schließen so die Kommunikationslücke
Mir ist klar geworden, dass viele Menschen tatsächlich keinen Stolz auf ihre Arbeit empfinden
Für manche ist es einfach nur ein Gehalt
Gerade ältere Kollegen haben erlebt, wie Systeme zusammenbrechen, und wollen verhindern, dass so etwas noch einmal passiert
Bei jeder neuen Stelle versuche ich, innerhalb eines 90-Tage-Plans klare Leitlinien zu setzen, aber am Ende ist das Entscheidende das Team
Manche Teams lechzen nach Veränderung, andere behindern sie
Wenn Führungskräfte ahnungslos sind oder nur die schnellste und billigste Option wählen, wird es noch schwieriger
Das erinnert auch an Fälle wie den britischen Post-Office-Skandal, bei dem man intern von Problemen wusste, sie aber blockiert wurden
Früher war mehr als die Hälfte selbstständig, heute sind es nur noch rund 10 %
Was wir jetzt schaffen, ist nicht mehr „unseres“, sondern „das des Arbeitgebers“
Selbst wenn man härter arbeitet, wird man nicht belohnt, sondern bekommt eher noch mehr Arbeit aufgeladen
Am Ende werden Menschen wie Ressourcen behandelt und weggeworfen, wenn man sie nicht mehr braucht
In Krisen werden zuerst die Beschäftigten entlassen, während der CEO Millionen bekommt
In so einer Struktur zu erwarten, dass Mitarbeiter sich für das Unternehmen aufopfern, ist unmöglich
Wer weniger arbeitet, bekommt mehr Gehalt, und du kannst wegen einer Ersatzkraft zum halben Gehalt entlassen werden
Interviews werden immer komplizierter, Verdienste werden gestohlen, und die Inflation frisst die Gehälter auf
Am Ende wirkt die Frage „Warum ist der Stolz verschwunden?“ wie ein Rätsel, aber die Antwort ist eigentlich eindeutig
Aber Unternehmen wissen, dass die meisten Menschen nicht genau das tun können, was sie wollen, und konzentrieren sich stattdessen auf Prozesse und Workflows
Für den Einzelnen ist es am besten, das zu tun, was ihm gefällt, und dabei gut bezahlt zu werden
Wenn ein Entwickler sagt: „Ich will nichts Neues lernen“, ist das nicht unbedingt schlecht
Die Müdigkeit durch Frameworks, die sich wie im JavaScript-Ökosystem täglich ändern, ist etwas anderes als technische Stabilität auf Basis von Go oder LTS
Stabilität hilft auch der Produktagilität
Man muss vielleicht mit einem Senior Engineer verhandeln, der eine alte C++-Codebasis betreut, aber das einfach technische Schulden zu nennen, ist voreingenommen
Ob es sich um technische Schulden handelt, können nur der Lead IC, der für die Codebasis verantwortlich ist, und sein Manager beurteilen
In einem Interview menschliche Probleme anzusprechen ist ein guter Weg durchzufallen
Viele Interviewer halten nur technische Antworten für richtig und ignorieren menschliche Einsichten
Ich schätze so eine Perspektive sogar sehr, muss aber mit Kollegen darum ringen, sie zu überzeugen
Als ich sagte, dass je nach Message-Durchsatz Batch Processing ausreichen könnte, unterstellte er mir sofort, ich würde „Queues nicht verstehen“
Ich sagte, dass ich seit über 10 Jahren mit Datenprodukten im Petabyte-Maßstab arbeite, wurde aber abgelehnt, weil es nicht zu seinem Systemdesign passte
Jetzt arbeitet dieses Team am Ende daran, alle Microservices hinter einer einzigen API zusammenzufassen
Wenn ein Team diese Balance nicht versteht, muss man diesem Team auch nicht beitreten
Als Data Engineer in Big Tech sind die zwei schwierigsten Probleme für mich folgende
Erstens hat durch Conway’s Law jede Abteilung ihre eigene Toolchain und Datenphilosophie
Zweitens behauptet jedes Silo, nur sein eigener Ansatz sei richtig, will aber gleichzeitig die Daten der anderen
Standardisierung ist unmöglich, weil die Führungskräfte jeder Abteilung glauben, nur ihre Arbeitsweise sei die einzig richtige Lösung
Wenn man genau hinschaut, sind die meisten Ansätze zugleich richtig und falsch
Oberflächlich sieht es wie ein technisches Problem aus, aber am Ende ist es ein Menschenproblem
Änderungen an vorgelagerten Systemen werden nicht angekündigt, sodass man es erst merkt, wenn weiter unten ein Alarm losgeht
Es gibt so viele spontane Anforderungen, dass Sprints bedeutungslos werden, und dazu kommt jede Menge undokumentiertes Wissen
Diese Erfahrungen haben mich motiviert, tiefergehende Computer Science auf niedrigerer Ebene zu studieren
Um Veränderung voranzutreiben, muss man Netzwerke aufbauen, Menschen zusammenbringen und Veränderungen transparent kommunizieren
Aber für echte Veränderung braucht man die Unterstützung von Führungskräften auf höherer Ebene wie Directors oder VPs
AWS hat dafür einen Leitfaden zu organisatorischem Wandel veröffentlicht, und AWS Prescriptive Guidance ist ein hervorragender Blueprint
Es beginnt mit „Lass uns alle in einer Lösung zusammenführen“, zerfällt aber bald in getrennte Projekte pro Abteilung
Um das zu verhindern, braucht man eine Führungskraft mit starker Autorität
Besonders im öffentlichen Sektor ist es schwieriger, weil sich die Beteiligten oft gegenseitig nicht ausstehen können, während es im privaten Sektor wenigstens noch das gemeinsame Ziel des Arbeitsplatzerhalts gibt
Wie Jerry Weinberg in Secrets of Consulting sagte:
„Auch wenn es oberflächlich wie ein technisches Problem aussieht, ist es immer ein Menschenproblem“
Die Wurzel technischer Probleme liegt letztlich in menschlichen Entscheidungen, Kommunikation, Management und Kompetenz
Ich habe als Analyst an einem Systemaustauschprojekt gearbeitet
Das bestehende System verteilte Arbeit nach einem einfachen Round-Robin-Verfahren, das neue System verteilte fair unter Berücksichtigung der jeweiligen Arbeitslast
Einige Mitarbeiter manipulierten das System jedoch so, dass sie beschäftigt wirkten, wodurch am Ende die gewissenhaften Mitarbeiter noch mehr Arbeit übernehmen mussten
Wir erklärten klar, dass das eigentliche Problem nicht technisch, sondern fehlende Aufsicht war, wurden aber letztlich zu einer technischen Lösung gedrängt
Der menschlichen Natur nach dehnt sich Arbeit auf die verfügbare Zeit aus, und solche Fehlanreize muss man technisch kontrollieren
Wenn man Systeme für ideale Menschen entwirft, scheitert man
Schon seit The Psychology of Computer Programming (1971) betonte Jerry Weinberg das Prinzip:
„Auch wenn es wie ein technisches Problem aussieht, ist es immer ein Menschenproblem“
Seine Bücher sind auch heute noch lesenswert
Ich mag diese Haltung nicht, Menschen dafür zu kritisieren, dass sie „keinen Stolz auf ihre Arbeit“ haben
Die meisten Beschäftigten sind nicht Eigentümer ihrer Arbeit, Eigentümer ist das Unternehmen
Wenn das Unternehmen eine bestimmte Richtung erzwingt und Widerstand bestraft, warum sollte man dann kämpfen
Wir sind nur Zahnräder in der Maschine, und wenn man uns so behandelt, verhalten wir uns eben entsprechend
Die selbstbezogene Haltung des Autors wirkt auf mich unangenehm
Ich bin inzwischen ziemlich senior und arbeite direkt mit Finanzierungssponsoren und Anforderungsverantwortlichen zusammen
Sie fragen: „Mach das, was kostet es?“, und ich muss oft innerhalb von 18 Minuten eines 30-minütigen Meetings eine grobe Schätzung liefern
Sie verstehen die Technik nicht, aber die Sprache von Geld und Politik beherrschen sie perfekt
Manche Probleme habe ich mit einer einzigen Textnachricht gelöst, und das Budget dafür lag bei 6 Millionen Dollar
Andere Projekte gingen an ein anderes Team, das 35 Millionen Dollar verbrannte und scheiterte
Die Sponsoren mit Budgethoheit stellen meistens Politik über alles, und ihr Ziel ist „die nächste Position“
Wenn man sich ihre Karrieren ansieht, fragt man sich oft: „Wie sind sie nur dahin gekommen?“
Wenn Sie dazu mehr im Detail erfahren möchten, empfehle ich Ihnen, Peopleware zu lesen!