- Ein Artikel über das Konzept des „gefährlichen Rats (dangerous advice)“, der für erfahrene Senior Engineers nützlich sein kann, unerfahrenen Engineers jedoch schadet
- Dinge wie Zugriffsrechte auf Produktions-SQL sind „scharfe Werkzeuge (sharp tools)“
- Konkrete Beispiele für gefährlichen Rat sind, die eigenen Arbeitsprioritäten selbst festzulegen, manchmal absichtlich gegen Unternehmensregeln zu verstoßen und auch bei Unsicherheit eine klare Position einzunehmen
- Die meisten Karriere-Ratschläge sind Fälschungen, die zur Haftungsvermeidung oder Eindruckssteuerung geschrieben werden; um in der Praxis Dinge zu schaffen, ist Verhalten außerhalb der offiziellen Regeln nötig
- Manager haben eine strukturelle Grenze, weil sie solchen Rat wegen des Risikos für sie selbst nicht direkt geben können
- Gefährlicher Rat hat einen High-Risk-/High-Reward-Charakter, und entscheidend ist, den illegiblen Bereich zu verstehen, der jenseits der offiziellen Regeln einer Organisation liegt
Die Metapher von „scharfen Werkzeugen“ und „gefährlichem Rat“
- „Sharp tools“ sind Werkzeuge wie ssh, kubectl oder eine Produktions-SQL-Konsole mit Lese-/Schreibzugriff, die je nach Kompetenz enorm hilfreich sein oder großen Schaden anrichten können
- „Gefährlicher Rat“ hat dieselbe Eigenschaft und lässt sich nur mit Fähigkeiten und Urteilsvermögen richtig nutzen
- Der falschen Person gefährlichen Rat zu geben, ist so, als würde man der falschen Person Zugriff auf Produktions-SQL geben
Konkrete Beispiele für gefährlichen Rat
- Selbst entscheiden, woran man arbeitet
- Manchmal absichtlich gegen die schriftlich festgehaltenen Unternehmensregeln verstoßen
- Auch bei Unsicherheit eine klare Position einnehmen
- Sich selbst ein Stück weit als „grifter“ begreifen
- Alle Aktivitäten, die nichts mit dem Shipping zu tun haben, bewusst vermeiden
Warum die meisten Karriere-Ratschläge falsch sind
- Gute Engineers sehnen sich nach gefährlichem Rat, aus demselben Grund, aus dem sie scharfe Werkzeuge wollen
- Die meisten Karriere-Ratschläge werden mit dem Ziel der liability avoidance oder um people zu impressen geschrieben
- Wer tatsächlich Dinge umsetzen will, wird solche riskanten Verhaltensweisen am Ende ohnehin wählen, weil sie offensichtlich hilfreich sind
- Die Situation, in der jeder weiß, dass es offiziell nicht so läuft, aber niemand es ausspricht, erzeugt ein tiefes Gefühl der Entfremdung
- In der Junior-Zeit waren es wenige Kolleg:innen, die inoffiziell offen gesprochen haben, die wirklich geholfen haben
Warum Manager strukturell keinen gefährlichen Rat geben können
- Wenn ein Manager rät, Unternehmensrichtlinien zu ignorieren, und ein Engineer das schlecht umsetzt (z. B. indem er öffentlich in Slack postet, der Manager habe es erlaubt), trägt der Manager den größeren Schaden
- Die Führung in Tech-Unternehmen neigt dazu, Engineers als „useful idiots“ zu sehen, und erwartet von Managern professionelles Verhalten
- Viele Manager würden solchen Rat gern geben und bewerten es sehr positiv, wenn Engineers von sich aus so handeln
- Für Manager ist es äußerst frustrierend, starke Engineers zu führen, die viel effektiver wären, wenn sie strategischer und weniger an ihre Stellenbeschreibung gebunden an die Arbeit herangingen
Das Wesen gefährlichen Rats: High Risk, High Reward
- Um gefährlichem Rat zu folgen, braucht es Mut
- Wegen seines High-Risk-/High-Reward-Charakters ist er für starke Engineers überproportional nützlich und für schwächere Engineers schädlich
- Wer sich damit nicht wohlfühlt, sollte ihm niemals folgen; wenn man aber ohnehin schon so arbeitet und sich wegen langfristiger Fehler Sorgen macht, ist das wahrscheinlich nicht der Fall
Reaktionen auf Hacker News und die illegiblen Elemente von Organisationen
- Auf Hacker News mischten sich sehr positive und sehr negative Reaktionen
- Der zentrale Fehler der negativen Kommentare ist die Sichtweise, eine Organisation sei im Wesentlichen eine Menge kodifizierter Regeln und der Hauptmodus der Zusammenarbeit in Organisationen sei formal und strukturiert
- Das ist derselbe Fehler der übermäßigen Priorisierung von Legibility, den James C. Scott in Seeing Like a State beschreibt
- Jede Community hat illegible, aber tragende (load-bearing illegible) Bestandteile
- Der Kernpunkt dieses Artikels und des gesamten Blogs ist, über diesen illegiblen Teil der eigenen Arbeit sorgfältig nachzudenken
Noch keine Kommentare.