Der schlechteste Programmierer, den ich kenne
(dannorth.net)- Ein Consulting-Team bei einer Big Bank versuchte, individuelle Produktivität anhand von abgeschlossenen Storys/Story Points zu messen, und Tim Mackinnon erhielt bei dieser Kennzahl wiederholt 0 Punkte
- Der Grund für die 0 Punkte war nicht, dass er nicht arbeitete, sondern dass er keine Storys auf seinen eigenen Namen nahm und den Großteil des Tages mit Pair Programming verbrachte
- Weniger erfahrenen Entwicklern gab er nicht direkt die Antwort, sondern schuf durch sokratische Fragen Lernmomente; mit Seniors fand er aus unterschiedlichen Perspektiven gemeinsam bessere Lösungen
- Das Team arbeitete effektiver, produktiver und besser abgestimmt, wenn Tim dabei war, und der Manager schaffte die individuelle Produktivitätskennzahl schließlich stillschweigend ab, während Tim im Team blieb
- Eine Messung, die individuelle Beiträge isoliert betrachtet, kann Beiträge wie die von Tim auf 0 setzen; Produktivität sollte daher über Business Impact und den Flow auf Teamebene betrachtet werden
Der „0-Punkte-Programmierer“, den individuelle Kennzahlen hervorbrachten
- Ein Team der Big Bank führte individuelle Leistungskennzahlen ein, um individuelle Performance zu bewerten und Entwicklung zu fördern
- Der Manager vermied leicht manipulierbare Kennzahlen wie Codezeilen oder Bug-Zahlen und wählte stattdessen abgeschlossene Storys oder Story Points als Messgröße, weil sie Business Value repräsentieren sollten
- In einem Jira-ähnlichen Tool war jede Story einzelnen Personen zugeordnet, daher ließen sich individuelle Produktivitätskennzahlen leicht erstellen
- Tim Mackinnons Wert war nicht einfach niedrig, sondern lag jede Woche und in jeder Iteration buchstäblich bei 0 Punkten
- Der Manager meinte, man müsse Tim aus dem Team nehmen und durch jemanden ersetzen, der Storys tatsächlich „liefert“, doch der Team Lead lehnte das ab
Was Tim tatsächlich lieferte
- Tim übernahm keine Storys auf seinen eigenen Namen, sondern arbeitete stattdessen jeden Tag mit anderen Teammitgliedern im Pairing
- Wenn er mit weniger erfahrenen Entwicklern arbeitete, ließ er sie selbst am Steuer sitzen und führte sie behutsam zur Lösung
- Er zwang ihnen keine Antworten auf und drängte sie nicht
- Mit Fragen wie „what if“ und „how else“ sowie sokratischen Fragen schuf er Lernmomente
- Mit Senior-Entwicklern arbeitete er eher wie in gemeinsamer Kreation oder beim Sparring; sie wendeten unterschiedliche Weltbilder auf das Problem an und erzielten Ergebnisse, auf die man allein nur schwer gekommen wäre
- Tim lieferte nicht direkt Software, sondern entwickelte das Team, das Software liefert
- Das gesamte Team arbeitete effektiver und produktiver
- Es arbeitete besser abgestimmt und toleranter
- Auch die gemeinsame Arbeit machte mehr Freude
- Wenn der Manager vorbeikam, um das Team zu beobachten, arbeitete Tim immer mit jemand anderem an „dessen Arbeit“, und das Ergebnis war höhere Qualität und kürzere Time-to-Value
- Am Ende behielt das Team Tim und entschied sich statt individueller Produktivitätskennzahlen für Team-Verantwortlichkeit
- Es verfolgte und feierte den Business Impact, den es als leistungsstarke Einheit für die Organisation erzielte
Wohin man bei Produktivität schauen sollte
- Produktivitätsmessung an sich ist notwendig, und für Verantwortlichkeit ist messbarer Business Impact ideal
- eingesparte Beträge
- generierte Beträge
- geschützte Beträge
- Wenn direkter Business Impact schwer zu messen ist, können auch stellvertretende Business-Kennzahlen verwendet werden
- In komplexen adaptiven Systemen gerät bereits die Annahme ins Wanken, man könne den Beitrag einer einzelnen Person isoliert messen
- DORA-Metriken messen nicht den Beitrag einzelner Kolben, sondern die Funktionsweise des Arbeitssystems
- Sie können als Westrum-Kulturmetriken betrachtet werden
- Oder als Metriken dafür, wie technische Änderungen in die Produktion fließen
- Individuelle Kennzahlen können den tatsächlichen Beitrag von Menschen wie Tim auf 0 setzen; besser geeignet ist ein Blick auf Teamleistung und Flow auf Systemebene
1 Kommentare
Kommentare auf Hacker News
Vor etwa 20 Jahren arbeitete ich bei einem mittelgroßen Softwareunternehmen, das Desktop-Apps für Mac und Windows verkaufte. Das Team hatte größtenteils nur Mac-Erfahrung und lernte Windows gerade erst, daher hatte die Windows-Version viele Probleme.
Damals galt ich als Windows-Experte und wurde eingestellt, um diese Version zu verbessern und dem Team zu helfen, sich mit Windows-Programmierung vertraut zu machen.
Den ersten Teil des Tages verbrachte ich meist wie bei „Hausbesuchen“: Ich ging von Büro zu Büro, machte Pair Programming, untersuchte Bugs und diskutierte Best Practices für die Windows-API. Später fragte mich ein Kollege, „wie ich so großzügig mit meiner Zeit sein könne“.
Ein paar Monate später hieß es in meiner Beurteilung, meine „Produktivität entspreche nicht ganz den Erwartungen, insbesondere wenn man bedenke, dass die Produktivität des restlichen Teams zuletzt gestiegen sei“. Ich hatte gedacht, genau deshalb sei ich eingestellt worden.
Wissensaustausch ist der größte Nutzen, den man anderen Entwicklern bieten kann, aber Menschen, die diesen Weg wählen, werden viel zu wenig belohnt.
Ohne solche Entwickler wären wir der heutigen Softwarewelt nicht einmal nahegekommen, und auch wenn ihnen nicht direkt gedankt wird, sind sie eindeutig wertvoll.
Alle Reparaturen hatten dieselbe Priorität, unterschieden sich aber im Schwierigkeitsgrad. Nachdem ich einen Monat lang gelernt hatte und sonst niemand sie machen wollte, übernahm ich die Reparatur der Basisstationen. Das dauerte länger, war für den Betrieb aber viel wichtiger.
Bei der Monatsbesprechung wurde ein Kreisdiagramm zur Auslastung gezeigt, und ich sah deutlich schlechter aus als die erfahrenen Seniors.
Damals lernte ich, warum die Seniors sich nur die schnellen und einfachen Aufgaben herauspickten, und dass es interne Politik gibt. Rückblickend war es sogar ein Glück, so früh in meiner Karriere einen miserablen Chef erlebt zu haben.
Mein neuer Chef gab bei der ersten Beurteilung zu, dass er ursprünglich einen Performance Improvement Plan für mich geschrieben hatte, ihn aber verworfen hatte, nachdem wir in ein Open Office umgezogen waren und er gesehen hatte, wie die Leute Schlange standen, um mich um Hilfe zu bitten, und dass ich niemanden wegschickte.
Dass ich meinen Platz im Cubicle verloren hatte, war zwar etwas nervig, aber durch diese Erfahrung sah ich Open Offices positiver.
Natürlich arbeite ich inzwischen in keinem Büro mehr und habe nicht vor, jemals wieder etwas anzunehmen, das nicht remote ist.
Erst wenn man sich einen Ruf aufgebaut hat, kann man etwas verändern; davor ist es schwierig.
Zu viele Menschen optimieren für das „Team“ und werden wegen negativer Wahrnehmung weiter oben entlassen oder bei Beförderungen übergangen. Umgekehrt wird bei Leuten, die nach den aktuell wichtigen Maßstäben des Unternehmens einen guten Ruf haben, ziemlich lange auch schlechtes Verhalten toleriert.
Ob die Person sofort zu einem besseren Ort gewechselt ist, angefangen hat, weniger Zeit mit anderen zu teilen, um zu den Leistungskennzahlen des Unternehmens zu passen, oder ob sie jemanden, der im Organigramm hoch genug stand, tatsächlich davon überzeugt hat, dass sie genau für diese Rolle eingestellt worden war.
Das erinnert mich an eine Anekdote aus den Bell Labs.
Jemand berechnete anhand einer Kennzahl wie der Zahl der Patente, wer die produktivsten Mitarbeitenden waren, und stellte fest, dass viele von ihnen mit derselben Person zu Mittag aßen.
Diese Person selbst hatte keine besonders hohe individuelle Produktivität, stellte aber ständig tiefgehende und überzeugende Fragen und machte die Kolleginnen und Kollegen dadurch messbar produktiver.
Die Anwälte der Patentabteilung der Bell Labs versuchten, ein Organisationsprinzip zu finden, das erklärte, warum manche Menschen produktiver waren. Die einzige Gemeinsamkeit war, dass Mitarbeitende mit vielen Patenten häufig mit dem Elektroingenieur Harry Nyquist zu Mittag oder zum Frühstück gingen.
Nyquist gab ihnen keine konkreten Ideen; er brachte Menschen dazu, aus sich herauszugehen und nachzudenken, und stellte vor allem gute Fragen.
Gruppen von Menschen sind fragile Strukturen, und eine gute Teamatmosphäre sowie gute Fragen können die Lage unsichtbar verbessern.
Andernfalls ist es schwer, eine faire Bezahlung zu bekommen.
Ich glaube das nicht.
In einem Unternehmen, in dem ich mehrere Jahre gearbeitet habe, kam man auf die Liste für Leistungsverbesserung, wenn man keine 10 Punkte pro Woche schaffte – egal ob Junior oder Senior.
Ich war in mehreren Teams, und man konnte allein am Stresslevel der Entwickler sofort erkennen, wie ein Team Punkte maß.
Teams, die in guter Absicht Punkte messen wollten, waren gestresst, zeigten meist Anzeichen von Burnout und arbeiteten 60 Stunden pro Woche.
Teams dagegen, die das System wie ein Spiel behandelten und verstanden, dass es eine unmögliche Aufgabe war, vergaben für Tickets möglichst hohe Punkte oder zerlegten sie in kleine Tickets und sammelten so kontinuierlich Punkte; sie waren stressfrei und glücklich.
In so einer Umgebung war es eine Trottelstrategie, sich an die Regeln zu halten, und als ich schließlich kündigte, folgten mir innerhalb von vier Monaten alle sieben Senior Engineers des Unternehmens.
Ziel ist es, große, unsichere und riskante Stories in kontinuierlich und stressfrei erreichbare Stories aufzuteilen.
Das heißt nicht, dass dieser Arbeitsplatz gut klingt, aber die Entwickler, die das System „gespielt“ haben, scheinen sich im Großen und Ganzen so verhalten zu haben, wie Scrum es fördern will.
Allerdings ist es schreckliches Management, eine Mindestpunktzahl pro Woche zu erzwingen und damit das Aufblähen von Punkten zu provozieren.
Es hat aus denselben Leuten mehr Arbeit herausgeholt, als es ohne Druck der Fall gewesen wäre.
Ein früherer Chef sagte ganz offen, er würde „Leute einstellen und verheizen“, um ein Projekt fertigzubekommen, und plante damit, dass sie nur sechs Monate lang brauchbar arbeiten müssten.
Wenn jemand den Stress und die geringe Vergütung aushielt und blieb, war das aus Sicht des Unternehmens ein Bonus; ich selbst habe auch nicht lange durchgehalten.
Wenn man in der Woche nicht alles fertigbekam, wurde das Ticket als erledigt markiert und die verbleibende Arbeit als neuer Bug eröffnet.
„Sobald eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein.“
An manchen Orten war es wichtiger zu wissen, was ein Manager erwarten kann, als echte Produktivität in Richtung Ziel.
Wer gutgläubig geschätzt hat, nahm vielleicht an, dass auch das Management in guter Absicht handelt, aber viele Projekte werden als Wunschdenken geplant oder mit künstlich knappen Deadlines versehen, um Leute zu „motivieren“.
Dieser Stress hat möglicherweise außer der emotionalen Befriedigung des Managers kaum Wert geschaffen.
Wenn Nichttechniker die Leistung von Software Engineers bewerten, kann das zu drastischen Ergebnissen führen.
Mein Freund „Tommy“ war ein IT-Mitarbeiter mit hervorragenden Netzwerkkenntnissen, und nur wenige Wochen nach seinem Wechsel zu einem staatlichen Energieunternehmen musste er das Netzwerk bis hin zu allen Gebäuden der Zentrale mit moderner Ausrüstung komplett neu aufbauen.
Das Unternehmen wollte einen externen Dienstleister beauftragen, aber als Tommy die von der Finanzabteilung angesetzten Kosten sah, war er erstaunt und sagte, er könne es selbst erledigen, wenn er nur physische Hardware wie Router, Switches und Kabel sowie zwei Leute für die Verkabelung bekäme.
Er schloss die Arbeit innerhalb weniger Wochen für weniger als ein Zehntel des ursprünglichen Budgets ab, bekam dafür aber nur ein mündliches „Danke, gute Arbeit“ von seinem Chef.
IT-Fachkräfte in einer Zeit, in der altmodische Vorgesetzte den wahren Wert nicht verstehen, sind wirklich eine bittere Sache.
Später hätte Tommy als Contractor dazukommen und zusätzliche Vergütung bekommen können.
Ein wirklich hervorragender Entwickler, mit dem ich zusammengearbeitet habe, schrieb sowohl ausgezeichneten Code als auch furchtbaren Code, der sofort wieder ersetzt werden musste – und beides machte die Zusammenarbeit mit ihm gut.
Den Wert guten Codes muss man nicht erklären, und es ist gut möglich, dass wir seinen Code heute noch verwenden.
Aber er war auch in Notfällen herausragend.
Wenn ein Kunde komplett stillstand und wir möglicherweise schuld waren, tauchte er sofort auf, erfasste das Problem schnell und schrieb und installierte zügig schmutzigen Spaghetti-Code, der den Kunden wieder arbeitsfähig machte.
Es war augenschmerzhafter Code, den man weder einchecken noch refaktorisieren konnte, aber die unmittelbare Krise war abgewendet, während später jemand alles sauber reparieren musste.
Ich war von letzterer Fähigkeit sogar noch beeindruckter, vor allem weil sie selten ist, und er war einfach ein guter Mensch, den alle mochten.
Trotzdem erledige ich Dinge schnell, und mein eigenwilliger Code hat schon mehrfach den Tag gerettet, indem er Notfälle gelöst oder Ausschreibungen gewonnen hat.
Mit „perfektionistischen“ Entwicklern ist die Kommunikation schwierig; für sie scheint Code, der nicht ausreichend durchdesignt ist, wertlos zu sein, selbst wenn sie verstehen, dass Geschwindigkeit nötig ist.
Natürlich werden sie umgekehrt dasselbe über mich denken.
Inzwischen haben wir wöchentliche Meetings eingeführt, um das Problem abzumildern, und das funktioniert ziemlich gut.
Am schwierigsten ist es, wenn es zwar kein Notfall ist, der Zeitplan aber eng und die Spezifikation unklar ist: Dann muss man entscheiden, welche Art von Ansatz passt, und immerhin treffen wir diese Entscheidung gemeinsam.
Man kann sich das zwar selbst beibringen, aber die Art, häufige Probleme und Lösungen so auswendig zu lernen, dass man sie mechanisch heruntertippen kann, ist für mich wirklich quälend.
Solange einem das Unternehmen nicht gehört, wird man immer nach dem sichtbaren Wert beurteilt.
Wenn der Arbeitgeber deinen Wert nicht visuell wahrnehmen kann, ist es unwahrscheinlich, dass du dich dort halten kannst.
Ein vollständig meritokratisches Leistungssystem wäre zwar ideal, aber wenn jemand anders Einstellung oder Bewertung in der Hand hat, hängt Erfolg zu 100 % davon ab, wie diese Person dich sieht.
Diese Wahrnehmung entsteht aus dem äußeren Eindruck, unabhängig davon, ob tatsächlich Wert für das Unternehmen vorhanden ist oder nicht.
Hier geht es nicht um Programmierfähigkeiten oder tatsächlichen Wert, sondern um Einstellung und Bewertung; es gibt auch viele Menschen, die sehr produktiv sind und gleichzeitig ihr Reputationsmanagement gut beherrschen.
Persönlich möchte ich, dass die Seniors im Team wirklich schwierige Dinge tatsächlich erledigen.
Es ist gut, Juniors dabei zu helfen, ihre Arbeit zu machen, aber für schwierige und komplexe Aufgaben, die Juniors wegen fehlendem Wissen, fehlender Erfahrung und mangelnder zwischenmenschlicher Fähigkeiten nicht bewältigen können, braucht man weiterhin erfahrene Leute.
Kein Pair Programming kann das vollständig ersetzen.
Man sollte vermeiden, dass Features mit geringem Wert sehr gut umgesetzt werden, während wirkungsstarke, hoch priorisierte Arbeit nicht fertig wird, weil die erfahrensten Leute weniger erfahrenen Kolleginnen und Kollegen bei Dingen wie dem Schreiben von Unit Tests helfen.
Nur weil es einem Junior zugewiesen wurde, heißt das nicht automatisch, dass es ein einfaches Problem ist; wie sollte man Engineers sonst wachsen lassen?
Nicht alle Seniors sollten ihre Zeit mit Junior-Mentoring und Zusammenarbeit verbringen, aber wenn es in einem Team ein paar solcher Leute gibt, wirken sie als Kraftmultiplikatoren und nützen dem gesamten Team.
Selbst wenn man das bei der Einstellung nicht wusste: Wenn er eine nützliche Nischenrolle gefunden hatte, hätte das Unternehmen daraus eine offizielle Rolle machen sollen.
Er war ein Coach, und wenn man ihn für diese Rolle eingestellt hätte, wäre das in Ordnung gewesen; aber wenn man einen Coach gewollt hätte, hätte man vermutlich eigens einen eingestellt.
Schwierige Features können Juniors manchmal selbst mit unbegrenzter Zeit nicht fertigstellen, weil ihnen die Fähigkeiten noch fehlen und diese Fähigkeiten erst über Jahre entstehen.
Gelegentlich ist Hilfe von Seniors nötig, aber wenn der Senior dadurch selbst nichts mehr baut, ist das aus Sicht des Unternehmens wenig sinnvoll.
Schwierige Features sollte man jemandem geben, der ausreichend senior ist; wenn man Juniors entwickeln will, kann man ihnen die einfacheren Teile dieser Arbeit gemeinsam übertragen und den Senior erklären lassen, was er tut.
Tims Haltung, allen zu helfen, ist großartig, aber es ist auch seltsam, dass die anderen Programmierer so viel Hilfe brauchen, dass Tim überhaupt keine Zeit mehr hat, eigene Ergebnisse zu liefern.
Das Problem ist nicht Tim, sondern ein Management, das es in Ordnung findet, dass Fachleute ständig Hilfe brauchen und eine Struktur besteht, in der ein freiwilliger Helfer wie Tim jederzeit einspringt.
Wenn einer der Seniors sie von Anfang an ordentlich gebaut hätte, hätten Juniors sie auch ändern können sollen.
Wenn sie aber selbst dann, nachdem dieser Senior sie gebaut hat, wegen der Struktur schwierig und komplex ist, fragt man sich, warum man ihn Senior nennt.
Trotzdem kann die Arbeit aller Seniors nicht nur darin bestehen, Juniors zu helfen.
Heutzutage ist es schwer, so jemand zu sein.
Alles ist auf nach außen sichtbare Leistung ausgerichtet, daher werden solche Leute leicht zum Ziel von Kürzungen; ich habe das selbst erlebt.
Teamplayer, Mentoren und Softwarearchitekten werden zunehmend verdrängt, und Coder, die große Mengen Code ausspucken, nehmen ihren Platz ein.
Selbst wenn wegen technischer Schulden die Fähigkeit, Features zu liefern und zu warten, mit der Zeit abnimmt, mögen Manager Entwickler, die unabhängig von tatsächlich ausgelieferten Features oder Bug-Zahlen konstant mehr als 5000 Zeilen pro Woche schreiben.
Als Team Lead und Engineer, der komplexe Projekte geleitet hat, finde ich Menschen, die mehr als 2000 Zeilen Code pro Woche schreiben, beängstigend.
Das sind über 100.000 Zeilen Code im Jahr, und man muss die unnötige Komplexität bedenken.
Wahrscheinlich könnte man dieselbe Funktionalität in 10.000 Zeilen, mit weniger Bugs und in der Hälfte der Zeit implementieren; dann wären es aber nur 380 Zeilen pro Woche, und das würde dem Manager nicht gefallen.
Ich neige zu der Ansicht, dass Entwickler, die Tausende Zeilen produzieren, nicht tief genug über die langfristige Richtung des Projekts nachdenken, und ein Großteil dieses Codes fühlt sich eher wie Wegwerfcode an.
Google hat das bis zu einem gewissen Grad mit der Rolle des Tech Lead institutionalisiert, und von diesem Engineer wird erwartet, eher als Kraftmultiplikator und Mentor zu handeln denn als einzelner Contributor.
Es funktioniert nicht immer wie vorgesehen, vielleicht sogar nur selten, und ein TL kann sich in Personenkoordination, Planung und Kleinststreitigkeiten verlieren und nicht mehr als Engineer arbeiten.
Trotzdem ist die Idee der Rolle in Ordnung.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Die Idee, alles zu messen und sich nach den Zahlen zu richten, die man bekommen kann, gibt es seit dem 19. Jahrhundert.
Manager wiederholen seitdem dieselben Praktiken, und die Ergebnisse fallen auf dieselbe Weise ziemlich stabil aus.
Der Eigentümer eines Unternehmens, bei dem ich kurz gearbeitet habe, wollte den Webservice alle sechs Monate von Grund auf neu schreiben lassen, um den neuesten Webframeworks und Trends zu folgen.
Einen 5000-Zeilen-pro-Woche-Helden hätte er auf der Stelle eingestellt.
In Wartungsprojekten verbringe ich manchmal eine Woche, ohne allein auch nur eine Zeile zu schreiben, oder arbeite sogar eine ganze Woche daran, die Zahl der Codezeilen zu reduzieren.
Hervorragend.
Im Rudern gibt es ein Training namens seat racing, bei dem man Personen in verschiedenen Kombinationen auf die acht Plätze setzt und wieder herausnimmt, um die schnellste Kombination zu finden.
Individuelle Stärke ist ebenfalls eine Kennzahl, aber wer im Rennboot sitzt, entscheidet die Geschwindigkeit des Teams.
Am Ende kommt es selten vor, dass die schnellste Kombination einfach aus den acht stärksten Personen besteht; oft gibt es ein oder zwei „magische“ Menschen, die auf dem Papier nicht unbedingt besser wirken, aber jedes Boot schneller machen, in das man sie setzt.
Sie verbessern auf subtile Weise Balance, Rhythmus und Kraft der anderen.
Manche Coaches nehmen das nicht gern an und wehren sich dagegen, wodurch sie am Ende weniger gewinnen.
Softwareteams sind dem sehr ähnlich, und letztlich zählen Kombination und Ergebnis.
Wenn ich gebeten werde, „technische Führung“ zu coachen, sage ich immer, man solle Mitarbeitende vom Facilitator-Typ genau im Blick behalten.
Ihre Unterstützung macht andere Mitarbeitende produktiver und effektiver, und manche ziehen größere berufliche Zufriedenheit daraus, anderen zu helfen, Hervorragendes zu leisten, als selbst Erstaunliches zu vollbringen und den ganzen Ruhm einzuheimsen.
Solche Leute schneiden in Bewertungen oft schlecht ab, aber wenn man sie verliert, sinkt die Teamproduktivität netto.
Deshalb versuche ich, ein Werkzeug an die Hand zu geben, um zwischen Menschen zu unterscheiden, die tatsächlich nicht produktiv sind, und solchen, deren Produktivität sich im Erfolg anderer zeigt.
Es ist niemals gut, nur eine einzige Kennzahl zu messen und danach zu managen.
Denn diejenigen, die die Kennzahl gamen, „gewinnen“, und dieses Verhalten führt dann zu Beförderungen.
Ich habe das auch der Führung von Google gesagt, aber Laszlo meinte: „Das ist das System, das wir haben, und es ist nicht perfekt, aber damit werden wir arbeiten. Ob du innerhalb dieses Systems arbeiten willst oder nicht, ist deine Entscheidung.“
Schon dieses Meeting allein reichte aus, um zu erkennen, ob die obere Führungsebene eine bessere Engineering-Umgebung schaffen wollte oder nicht.
Viele neue Manager, besonders solche, die früher Individual-Contributor-Engineers waren, glauben, dass sowohl die Teammoral als auch der Output steigen, wenn man die „besten“ Mitglieder behält und die „schlechten“ gehen lässt.
Doch ihr Verständnis von „best“ basiert nicht auf Kriterien zur Führung von Menschen, sondern darauf, wie gut sie früher ihre eigene Arbeit gemacht haben.
Deshalb bevorzugen sie Menschen mit ähnlichen Fähigkeiten und Gewohnheiten wie sie selbst und werten Menschen mit anderen Fähigkeiten und Gewohnheiten ab.
Der Moment, in dem ihnen das klar wird und ihre Augen groß werden, ist immer interessant.
Die Nullzinspolitik hat Rollen wie Senior Directors vermehrt, die Jira-Boards verwalten und Aufgabenlisten bearbeiten, während es an Menschen mangelt, die die tatsächliche Arbeit erledigen können.
Ich widerspreche nicht der Idee, dass es Menschen geben kann, die die Produktivität anderer fördern, aber am Ende braucht es diese „anderen Menschen“, damit etwas fertig wird.
Andernfalls verfällt die Organisation.