Wie ich mein „WTF-Notizbuch“ führe (2021)
(simplermachines.com)- Wenn man Dinge, die einem direkt nach dem Einstieg in ein neues Team seltsam vorkommen, nicht sofort anspricht, sondern in einem WTF-Notizbuch sammelt, gewinnt man den nötigen Kontext, um Vertrauen als jemand aufzubauen, der dem Team hilft, statt nur zu meckern
- Festgehalten werden Signale, bei denen es im Teamablauf und technischen Flow hakt: wenn Retrospektiven ohne Maßnahmen enden, lokale Tests nicht möglich sind, das Build-Board rot ist oder kritische Aufgaben von einer einzigen Person abhängen
- Die Liste lichtet sich mit der Zeit durch stichhaltige Gründe, bereits laufende Korrekturen, eine niedrige Priorität im Team oder Punkte, die sich leicht beheben lassen
- Probleme, die auch nach einigen Wochen bleiben, werden mit Teammitgliedern, Team-Lead und Manager besprochen, um Ursachen und Vorgeschichte zu verstehen, und man löst zuerst gemeinsam die schon lange lästigen, aber vergleichsweise einfachen Probleme
- Wenn man nicht sofort Alarm schlägt, sondern erst Kontext und Prioritäten sammelt, kann auch ein neues Teammitglied Vertrauen bewahren und sich den Ruf als Problemlöser erarbeiten
So nutze ich ein WTF-Notizbuch
- Der Ruf, den ich im Team haben möchte, ist: „die Person, die mir hilft, meine Probleme zu lösen“ und „die Person, die Dinge zu Ende bringt, die mir wichtig sind“
- Jedes Mal, wenn ich in ein neues Team komme, schreibe ich auf eine neue Seite meines Bullet Journals
WTF - [Team Name]und notiere alles, was mir seltsam vorkommt - Wenn mir etwas auffällt, das ich ändern möchte, halte ich es zusätzlich als eigene Aufgabe fest
- In den ersten zwei Wochen konzentriere ich mich nur aufs Notieren
- Ich sage nicht sofort alles, was das Team meiner Meinung nach falsch macht
- Ich kippe in der Retrospektive keine lange Liste von Dingen aus, die geändert werden müssten
- Ich beobachte, höre zu und schreibe auf, was sich tiefgehend seltsam anfühlt
- Diese Methode hilft dabei, Veränderungen im Team anzustoßen und sich gleichzeitig selbst zu steuern, ohne wie jemand zu wirken, der nur klagt
Seltsame Signale, auf die ich in neuen Teams achte
- In einem neuen Team gibt es immer Dinge, bei denen man denkt: „wtf“
- Typische Beispiele sind:
- Das Team spricht in der Retrospektive eine Stunde lang über ein ernstes Problem und endet ohne Action Items
- Tests laufen lokal nicht, und es wirkt, als würde es niemanden kümmern
- Große Teile des Build-Boards sind ständig rot
- Wichtige und zeitkritische Aufgaben können nur von einer einzigen Person erledigt werden
- Das Team investiert viel Zeit in ein Feature, aber niemand weiß so recht, warum es wichtig ist oder wie es den Kund:innen hilft
Punkte, die von der Liste verschwinden
- Wenn die Liste groß genug geworden ist, beginne ich, die Punkte einzeln zu streichen
- Dafür gibt es meist vier Gründe:
- Es gibt tatsächlich gute Gründe
- Das Team arbeitet bereits an einer Lösung
- Das Team hält das Problem nicht für wichtig
- Es ist wirklich leicht zu beheben
- Auch das Problem, dass lokale Tests nicht laufen, muss je nach Kontext kein großes Problem sein
- Es kann ein bekanntes Thema sein, an dessen Lösung bereits gearbeitet wird
- Vielleicht erledigt das Team alle Arbeiten in virtuellen Maschinen und kann diese per Chat-Befehl leicht provisionieren
- Wenn das Continuous-Integration-System gut aufgestellt ist und kleine Änderungen häufig ausgerollt werden, muss das Fehlen lokaler Tests mehrere Deployments pro Tag nicht zwangsläufig blockieren
- Bei manchen Punkten ist eine einfache Lösung direkt erkennbar
- Wenn man nur die richtige Stelle kennt, kann man die Dokumentation schreiben
- Mit dem richtigen Skript ist es vielleicht nur eine kleine Änderung
- Wenn ich eine einfache Lösung sehe, behebe ich das Problem sofort
Verbleibende Probleme gemeinsam mit dem Team angehen
- Wenn nach einigen Wochen noch immer seltsame und ungelöste Probleme übrig sind, beginne ich Gespräche mit Teammitgliedern, Team-Lead und Manager
- Die Fragen konzentrieren sich darauf, warum diese Dinge so sind und wie es dazu gekommen ist
- Das Ziel ist, Vertrauen als jemand aufzubauen, der ehrlich neugierig und empathisch ist, geduldig bleibt und die Fachkenntnis der Kolleg:innen respektiert
- Die Gründe, warum ein Problem weiterbesteht, lassen sich meist in einige Kategorien einteilen:
- Das Team hat es nicht bemerkt
- Das Team hat sich daran gewöhnt
- Das Problem ist noch relativ neu, und das vorherige Problem war viel schlimmer
- Niemand weiß, wie man es behebt
- Früher wurde versucht, es zu lösen, aber ohne Erfolg
- Die ersten paar Typen lassen sich oft schon allein durch Nachfragen direkt beheben
- Die andere Person behebt es sofort oder sucht gemeinsam nach einer Lösung
- Bei technischen Problemen schreibt man zusammen eine Story oder ein Ticket und arbeitet daran
- Bei Prozess- oder sozialen Problemen spricht man in der Retrospektive mit dem ganzen Team darüber
- An diesem Punkt ist es gut, ein oder zwei Probleme zu finden, die ein neues Teammitglied schon eine Weile nerven und für die es eine vergleichsweise einfache Lösung gibt
- Wenn man sie auf das Retro-Board bringt, sollte es nicht etwas sein, das nur einen selbst stört
- Im Teamgespräch nimmt man es als Action Item auf, bei dem etwas, das das Teammitglied vorgeschlagen hat, sofort ausprobiert werden kann
- Das Team beginnt zu spüren, dass das neue Mitglied bei der Lösung ihrer Probleme hilft
Schwierigere Probleme und Gespräche mit dem Manager
- Mit der Zeit kommt man zu zähen Problemen, die dem Team bekannt sind, die es aber aus Angst nicht angeht
- Solche Probleme gelten vielleicht als „nicht so schlimm“, obwohl niemand darüber sprechen möchte
- Es kann an fehlenden technischen Fähigkeiten liegen
- Im Kern kann ein komplexes zwischenmenschliches Problem stecken
- In dieser Phase gehe ich mit der Liste, die ich bisher erstellt habe, ins Gespräch mit dem Manager
- Was ich in den letzten Wochen beobachtet habe
- Dass es bei manchen Punkten Fortschritte gibt, andere aber länger dauern werden
- Ob mir etwas entgangen ist
- Auf welche Bereiche ich mich konzentrieren soll
- Es kann sein, dass der Manager dieselben Probleme ebenfalls bedenklich fand, aber nicht stark genug gedrängt hat, weil das Team nicht besonders darunter zu leiden schien
- Danach kann man die Sorgen des Managers und die Probleme gemeinsam strukturieren und über Fälle sprechen, die in der Vergangenheit gut funktioniert haben oder eben nicht
- Der Manager beginnt dann, einen als jemanden zu sehen, der gutes Urteilsvermögen hat und bei schwierigeren Problemen helfen kann
Warum ich es nicht sofort anspreche
- Der Ruf, den ich haben will, ist: „Nat hilft mir, meine Probleme zu lösen“ und „Nat bringt Dinge zu Ende, die mir wichtig sind“
- Dieser Ruf kann im nächsten Performance Review zu den gewünschten Ergebnissen führen und Jahre später in Empfehlungen münden
- Früher habe ich Probleme sofort angesprochen, sobald ich sie entdeckt habe
- Das führte zu dem Ruf, „immer zu meckern“ und „zu denken, dass wir nie etwas richtig machen“
- Die Leute hörten irgendwann nicht mehr zu, ich war persönlich frustriert, und beruflich war es ebenfalls ineffektiv
- Wenn ein neues Teammitglied viel Aufhebens um Dinge macht, die gar kein echtes Problem sind, vom Team nicht als Problem gesehen werden, bereits gelöst werden oder für die es eine einfache Lösung gibt, die anfangs nicht sichtbar war, schwindet Vertrauen schnell
- In Teams gibt es immer viele Probleme, die man verbessern könnte, aber nur ein Teil davon lässt sich tatsächlich lösen
- Die Reihenfolge, in der man Probleme entdeckt, ist nur selten die wirksamste Reihenfolge, um sie zu beheben
- Das WTF-Notizbuch hilft dabei, den Impuls „ich will das sofort beheben“ zwischenzuparken und zu warten, bis genug Kontext da ist, um zu entscheiden, womit man anfangen sollte
1 Kommentare
Meinungen auf Hacker News
Ich glaube, dieser Artikel betont eines nicht genug: Den Blick eines neuen Menschen gibt es nur einmal.
Der Grund, warum man die Gebrauchstauglichkeit eines Produkts schlecht beurteilen kann, ist, dass man bereits weiß, wie es funktioniert, und gegenüber Fehlern und Mängeln abgestumpft ist.
Ein neues Teammitglied ist noch nicht in diesem Zustand; daran, was es fragt, wo es hängen bleibt und wo es tatsächlich Hilfe braucht, kann ein Team viele Erkenntnisse gewinnen.
Wir sitzen mit Notizen daneben und sprechen mit den Nutzern, während sie das Produkt benutzen.
Egal wie viele Terabyte an Telemetriedaten man sammelt: Man versteht die Nutzung eines Produkts nicht so gut wie durch Gespräche mit echten Nutzern.
Die Tech-Branche sollte ihre Angst vor anderen Menschen ein Stück weit überwinden.
Das ist ähnlich wie bei einem erfahrenen Professor, der vergisst, dass Dinge, die er einem Anfänger erklären muss, schwierig sind.
Allerdings sind nicht alle gleichermaßen schlecht darin; es hängt stark davon ab, ob man genug Empathie und Interesse hat, sich in die Lage von Einsteigern zu versetzen.
Zwei Menschen, die unzählige Male die Bash-Shell benutzt haben, können völlig unterschiedlich gut verstehen, was für Anfänger seltsam und unintuitiv ist.
Mit frischem Blick zu sehen ist ebenfalls eine Fähigkeit, und man kann darin durch Übung besser werden, so wie man lernt, echtes Licht und echte Objekte zu betrachten und zu zeichnen.
Wenn man es nicht sofort ausspricht, sondern notiert, gewinnt man Zeit zu lernen, warum die Dinge so sind, wie sie sind, und die Landschaft der Organisation zu verstehen.
Wenn Dinge wie Accounts, Berechtigungen und Freigaben geklärt sind, kann man auf Grundlage dieser Liste aktiv werden.
Dann ist die Wahrscheinlichkeit größer, dass das Team einen nicht als „die Person, die ständig hervorspringt und WTF ruft“, sondern als jemanden wahrnimmt, der helfen will.
Bei einer Größe von 12–15 Personen funktionierte das sehr gut, aber ich weiß nicht, ob es in größerem Maßstab ebenfalls gut skaliert.
Etwas aufzuschreiben und abzuwarten ist unmittelbar und niedrigschwellig, und es gibt auch die kleine Belohnung, dass „die Liste länger geworden ist“; wenn man das systematisch übt, kann man es leicht wieder neu lernen.
Mir gefällt, dass die Phase des Wahrnehmens und Aufzeichnens weiterhin getrennt bleibt von der späteren Phase, in der man eine Karte erstellt, beobachtet, lernt und Menschen mit demselben Problembewusstsein zusammenbringt und anführt.
Ein Arbeitsjournal zu führen ist immer eine gute Idee, aber am Ton dieses Artikels stört mich etwas.
Ich möchte nicht mit jemandem arbeiten, der sich wie die Borg verhält oder einem Skript folgt, das aus „How to Win Friends and Influence People“ stammen könnte.
Wenn es so wirkt, als wolle mich jemand manipulieren, fällt es mir schwer, ihm zu vertrauen – zumindest ab dem Moment, in dem ich es bemerke.
Trotzdem sollte man sich nicht nur von dieser unmittelbaren Abwehrreaktion leiten lassen.
Auch ich habe Ziele dafür, wie Stakeholder mich erleben sollen, und das war als Verhaltensmaßstab ziemlich nützlich.
Selbst wenn man technisch gute Arbeit leistet, entstehen Probleme, wenn man die zwischenmenschliche Dimension ignoriert; welche Gerüchte kursieren, wie man wahrgenommen wird und wie die eigene Arbeit verpackt wird, ist tatsächlich wichtig.
„Man muss einfach nur gute Arbeit leisten“ lässt nicht verschwinden, dass meine Arbeit und der Eindruck, den ich bei anderen hinterlasse, wichtig sind.
„How to Win Friends and Influence People“ habe ich nie gelesen, aber den Artikel selbst fand ich ziemlich gut geschrieben.
Ob erfahrener Individual Contributor, neue Führungskraft oder Offizier: In den ersten 30 bis 90 Tagen sollte man ähnlich vorgehen, nichts verändern und versuchen zu verstehen, wie die Dinge laufen – und wichtiger noch, warum sie so laufen.
Daraus ergeben sich viele organisatorische Vorteile; kurz gesagt: So macht man es tatsächlich.
Engineers haben unter schlechten Managern gearbeitet, und auch wenn sie nicht genau erklären können, warum diese schlecht waren, haben sie oft ein Gespür dafür.
Dieses Gefühl von „schlechtem Manager“ entsteht oft daraus, dass jemand taktisch keine gute Führung beherrscht; und wie Engineering ist auch Führung eine erlernbare Fähigkeit.
Das Problem ist, dass es nicht viele Orte gibt, die das bewusst lehren, wie etwa das Militär oder Trainings für Top-Führungskräfte.
Wenn man unter einem guten Manager arbeiten möchte, will man eigentlich unter einer guten Führungskraft arbeiten; Leadership ist eine taktische Fähigkeit, ähnlich wie effizienten C++-Code zu schreiben.
Es geht darum, Menschen so zu koordinieren und zu führen, dass sie Ziele erreichen, die größer sind als die Summe dessen, was die Teammitglieder einzeln leisten könnten – aus manchen Blickwinkeln kann sich das wie Manipulation anfühlen.
Trotzdem ist jemand, der das Team vor externem Unsinn schützt, nötige Ressourcen beschafft, öffentlich lobt und privat kritisiert, Richtung gibt, ohne übermäßig mikrozumanagen, Leistung anerkennt und belohnt und Untererfüllung nicht durchgehen lässt, normalerweise die Art Führungskraft, die Engineers mögen.
Umgekehrt wird ein charismatischer politischer Spieler mit MBA-Hintergrund und ohne technisches Verständnis, der solche Techniken aus schlechten Gründen einsetzt, zu jemandem, mit dem man nicht arbeiten möchte.
Auch Menschen, die aus technischen Rollen ins Management aufgestiegen sind, aber nicht akzeptieren können, dass Management eine andere Fähigkeit ist als technische Kompetenz, werden häufig abgelehnt.
Damit es in der gesamten Branche letztlich mehr kompetente Führungskräfte gibt, müssen Texte wie dieser Leadership nicht als vages angeborenes Gespür behandeln, sondern als erklärbare Taktik dafür, wie man es macht.
Sich den Ruf zu erarbeiten, „Nat löst meine Probleme“, ist gut für Empfehlungen, kann aber für die Karriere gefährlich sein
Ich habe das 20 Jahre lang in verschiedenen Abteilungen so erlebt: Jedes Mal wollte man mich als Problemlöser festhalten, aber nicht als Beförderungskandidaten ins Spiel bringen
Ein Kollege, der nach 40 Berufsjahren in Rente ging, war ebenfalls jemand, der jedes Problem lösen konnte, und deutlich fähiger als die Manager, wurde aber nie befördert
Er war der Trumpf im Ärmel aller, bekam aber kaum Anerkennung; dass er Probleme löste, galt als „selbstverständlich“, und belohnt wurde es nicht
Für andere auf derselben Stufe galten viel niedrigere Maßstäbe, und selbst in der letzten Leistungsbeurteilung sagte der Manager: „Ich bewerte nicht im Vergleich zu Kollegen, sondern nach der Leistung gegenüber den Zielen“
Da mir ein anderer Manager dasselbe gesagt hat, war das kein Zufall
Vor allem stand mein Manager immer hinter mir, wenn er Anfragen abblockte, die nicht von ihm kamen
Wenn jemand, den ich nicht kannte, mich um etwas nicht Triviales bat und ich keine Zeit oder kein Interesse hatte, konnte ich sagen: „Ich habe im Moment keine Zeit, mir das anzusehen. Wenn es Priorität bekommen soll, sprechen Sie bitte mit meinem Manager“, und in 99 von 100 Fällen ging es nie bis zum Manager
Der größte Vorteil, in der Abteilung oder im ganzen Unternehmen die Anlaufstelle zu sein, ist, dass sich Bekannte und ein Netzwerk ansammeln
Wenn man außerhalb des Teams Informationen braucht oder für eine wichtige Sache durch Bürokratie hindurchmuss, wirkt das wie eine kleine Superkraft
Außerdem entsteht ein Netzwerk, das man bei neuen Chancen kontaktieren kann; alle Jobs, die ich in 15 Jahren in der Privatwirtschaft bekommen habe, kamen auf diese Weise zustande
Allerdings kann man sagen, dass einer der beiden Ansätze den Beförderungsprozess gut übersteht und der andere nicht
Das ist nicht einfach, aber Grenzen zu setzen ist eine wichtige Fähigkeit
Der Teil „Als ich Probleme sofort angesprochen habe, sobald ich sie sah, bekam Nat den Ruf, sich ständig zu beschweren und zu glauben, alles, was wir tun, sei falsch“ sollte weit oben im Artikel stehen
Diese Art von Selbstwahrnehmung ist eine echte Fähigkeit, die es zu lernen lohnt
Der ehemalige Astronaut Chris Hadfield sagt in seinem Buch ebenfalls, dass er bei neuen Missionen und Teams ähnlich vorging
Zuerst in den Beobachtungsmodus wechseln, lernen, ob die WTF-Momente tatsächlich berechtigt sind, und das auf eine Weise tun, die neue Teammitglieder nicht nervt
Lohnt sich zu lesen
Wenn man lange an derselben Stelle arbeitet, schafft er einen Ort, an dem man das Rauschen herausfiltern kann, sodass es zumindest nicht unverarbeitet im Kopf hängen bleibt
Es geht nicht nur darum zu beurteilen, ob ein Problem berechtigt ist, sondern auch darum, zu lernen, manche Dinge loszulassen
Es wäre gut zu wissen, welches Buch das ist
Wenn ich in eine bereits bestehende Situation komme, bin ich im Allgemeinen so vorgegangen
In der ersten Woche sehe ich mir alles an und notiere Fragen und Beobachtungen
Nicht nur „WTF“-Momente, sondern auch Dinge, die gut funktionieren, und Dinge, die mir wie wirklich gute Ideen vorkommen
Erst danach gehe ich die Notizen durch, priorisiere sie und steige in die Diskussion ein
Das wirkt wie ein Prinzip, das gut zu Chestertons Zaun passt
Die Geschichte geht so: Zu jemandem, der einen Zaun entfernen will, sagt man: „Wenn du seinen Zweck nicht kennst, kann ich dich ihn nicht entfernen lassen. Geh und denk darüber nach; erst wenn du mir sagen kannst, dass du seinen Zweck verstanden hast, darfst du ihn beseitigen“
Klarer gesagt heißt das: Selbst wenn etwas merkwürdig wirkt, ist es besser anzunehmen, dass die Leute vor einem klug waren und es einen Grund dafür gab
Dieser Grund kann inzwischen veraltet sein, aber wenn man ihn nicht berücksichtigt, wiederholt man denselben Fehler
Nicht nur eine Liste der Dinge zu führen, die man reparieren möchte, ist eine gute Idee; wenn man sie eine Weile liegen lässt, versteht man auch, warum manche Dinge so sind, wie sie sind
Oft wurde etwas in Eile gebaut oder es gab Fehler, aber manchmal existiert tatsächlich verborgene Komplexität, die man nicht sofort versteht, wenn man nur eine Codezeile betrachtet
Ersteres ist ein offensichtlicher Fehlschlag, Letzteres löst sich meist, wenn man lange genug in die Umgebung eintaucht
Trotzdem ist es nützlich, beides aufzuschreiben
Erst diese Woche habe ich zwei Kollegen erzählt, dass ich auf meinem Computer eine „How the F“-Datei habe
Sie ist nicht exakt dasselbe wie das, was der Autor beschreibt, aber sehr ähnlich: Wenn ich in ein neues Team komme, schreibe ich jedes Mal alles auf, bei dem ich denke: „Wie ging das noch mal?“
Ich bringe es nicht wie im Original zu meinem Manager, aber es gibt mir eine Perspektive darauf, was die Stolpersteine im Team und im Unternehmen sind und wie ich sie mit der Zeit angehen kann
Ich lebe so, dass ich alle Ideen, die mir einfallen, in eine Liste schreibe
Ohne besondere Reihenfolge; ich hänge sie einfach fortlaufend an Papier oder eine Textdatei an
Ideen tauchen nicht zuverlässig dann auf, wenn man sie braucht, sondern den ganzen Tag über, während man andere Dinge tut; wenn ich sie nicht aufschreibe, erinnere zumindest ich mich nicht daran
Wenn dann tatsächlich etwas zu tun ist, kann ich sie eine nach der anderen abhaken, muss nicht überlegen, was als Nächstes dran ist, und weil die Ideen nicht ausgehen, wird ein ziemlich großer Produktivitätsschub möglich
Es klingt eher nach dem Organisieren einer persönlichen To-do-Liste, während es im Original darum geht, wie man sich in einem Team einlebt und kommuniziert
Das Leben ist zu kurz, um Notizen zu organisieren; ich finde, man sollte einfach alles aufschreiben und sich auf umgekehrte Sortierung und Suche verlassen
Ironischerweise weiß ich, dass ich eine Schatzkammer erstaunlicher Ideen habe, aber in diesem Alter kümmert es mich nicht mehr genug, sie umzusetzen, wie ich es in meinen Zwanzigern getan hätte