- Heute bin ich zwar Engineering Manager, aber als ich noch als Software Engineer gearbeitet habe, arbeitete ich mehrere Tage an einer komplexen Funktion und stellte dann einen PR ein
- Das Feedback war bestimmt und kühl: „Overengineering. Zu kompliziert. Refaktorieren.“ Mehr als diesen kurzen Satz gab es nicht
- Ich war wütend, weil ich nur Kritik und kein einziges Lob bekam, doch die Episode mit diesem Manager war erst der Anfang
Ein Führungsstil ohne Rücksicht auf Gefühle
- Dieser Manager war anders als die Führungskräfte, die ich bis dahin gekannt hatte
- Er nahm einen nicht an die Hand und sprach auch keine sanften Worte
- Er hatte die folgenden Eigenschaften
- Unreife Ideen lehnte er sofort ab
- Er hasste Komplexität um der Komplexität willen
- Ihm waren nur sauberer, wartbarer und effizienter Code wichtig
- Auch in Retrospektiven redete er nicht um den heißen Brei herum, sondern sprach Probleme direkt an
- Zuerst hielt ich ihn für kalt und erbarmungslos, doch dahinter steckte eine andere Philosophie
Der Wendepunkt durch Feedback, das mein Ego erschütterte
- In einem Sprint Review präsentierte ich voller Selbstvertrauen eine Funktion, doch der Manager unterbrach mich und fragte
> „Das ist fragil. Was passiert unter Last? Wie sieht der Rollback-Plan aus?“
- Als ich nicht ordentlich antworten konnte, sagte der Manager:
> „Im Moment denkst du wie ein Coder. Du musst wie ein Engineer denken.“
- Zuerst machte mich das wütend, doch schließlich wurde mir klar, dass mein eigener Coding-Stil eher auf Cleverness als auf Resilienz ausgerichtet war
Die eigentliche Lektion: Dieser Manager griff mich nicht persönlich an
- Meine Denkweise veränderte sich grundlegend
- Statt „cleveren“ Codes schrieb ich leicht lesbaren Code
- Ich konzentrierte mich auf Design für den Ausfallfall
- Ich schrieb keinen Code für mich selbst, sondern Code für die Entwickler, die nach mir kommen
- Danach gingen die Code Reviews dieses Managers ohne großes Zögern durch
- Nicht der Manager hatte sich verändert, sondern ich war gewachsen
Der Einfluss auf meinen eigenen Führungsstil
- Als ich Engineering Manager wurde, musste ich oft an diese Erfahrung denken
- Ich wollte keine Führungskraft werden, die die Leute hassen, aber auch keine, die nur sanft ist
- Ich entwickelte meinen Stil auf folgende Weise
- Ich gebe direktes Feedback mit Kontext
- Ich betone systemisches Denken
- Ich halte hohe Standards aufrecht und gebe zugleich menschliches Feedback
- Engineers wollen gefordert werden, aber sie wollen nicht das Gefühl haben, ignoriert zu werden
Wann ein entschlossener Manager nötig ist
- Führung ist verwirrend, weil Ego, Deadlines und Druck darin miteinander verknüpft sind
- Ein entschlossener Manager räumt diese Verwirrung aus dem Weg, indem er
- einen dazu bringt, nicht in Funktionen, sondern in Skalierbarkeit zu denken
- einen dazu bringt, wartbaren statt cleveren Code zu schreiben
- einen dazu bringt, sich im Voraus auf Fehler und Ausnahmefälle vorzubereiten
- Ihm ist die Überlebensfähigkeit des Codes wichtiger als Gefühle
Wie man unter einem entschlossenen Manager überlebt und wächst
- Wenn man unter einer erdrückenden Führungskraft arbeitet, kann man so damit umgehen
- Nimm es nicht persönlich: Das Feedback bezieht sich auf den Code
- Frage nach dem Feedback „Warum?“: Die meisten entschlossenen Führungskräfte respektieren Neugier
- Denke selbst zuerst über mögliche Ausfallstellen nach: Du musst anfangen, wie dein Manager zu denken
- Wer selbst Führungskraft ist, sollte Folgendes umsetzen
- Hohe Standards setzen, aber erklären, warum sie wichtig sind
- Konkret statt vage Feedback geben
- Wachstum statt nur Erfolg feiern: Wenn ein Entwickler ein Problem vor dem Manager entdeckt, sollte man ihn loben
Das beste Geschenk eines abgelehnten Pull Request
- Anfangs war mein Stolz verletzt, doch rückblickend war dieser abgelehnte PR die größte Chance meines Lebens
- Er war der Auslöser dafür, Coding nicht als persönliches Projekt, sondern als Aufbau eines Systems zu sehen
- Ein entschlossener Manager sorgt nicht dafür, dass man sich gut fühlt, aber er lässt einen als Entwickler wachsen
- Wahres Wachstum beginnt nicht dann, wenn ein PR angenommen wird, sondern wenn er abgelehnt wird
22 Kommentare
Wenn es einen direkten Manager gibt, der keine Rücksicht auf Gefühle nimmt, und einen freundlichen Manager, der Rapport hält – welcher Typ Manager kann durch Feedback das Wachstum von Teammitgliedern fördern? Beim Lesen des vorherigen Beitrags kam mir diese Frage.
Ich denke, es ist ein Wahrscheinlichkeitsspiel. Menschen, die trotz extrem schlechter Chancen wachsen, gibt es überall. Ich finde, Manager sollten solche Menschen ausklammern und sich bemühen, die Gesamtwahrscheinlichkeit zu erhöhen. Ich denke, ein Manager, der handelt, weil er glaubt, dass seine Haltung auf ihre eigene Weise die Wahrscheinlichkeit erhöht, verdient Respekt. Solange er nicht einfach nur sein bisheriges Vorgehen beibehält, weil es eben geht.
Ich denke, dass diese Art von Feedback je nach Persönlichkeit, Kulturkreis und individuellen Unterschieden beim Hören unangenehm sein oder sogar wütend machen kann. Grundsätzlich scheint es jedoch sowohl für die eigene mentale Gesundheit als auch aus Wachstumsperspektive besser zu sein, mit der Haltung heranzugehen: „Diese Person will mich nicht absichtlich quälen.“ Wenn man in so eine Situation gerät, kann man sich beim Lesen dieses Textes vielleicht denken: „Vielleicht gilt das auch für diesen Manager?“ Ein guter Text.
Über
kind and directwird viel gesprochen, aber tatsächlich ist es viel schwieriger, direct zu sein, als kind.Ein Leader, der zwar nicht den gesamten Kontext liefert, aber es nicht einmal schafft, den Kontext zu vermitteln, dem die Mitarbeitenden folgen sollen, hat keinen Wert.
Es wirkt wie ein Beitrag eines hervorragenden Followers, der die eigene starke Leistung anderen zuschreibt.
Wenn ein Leader keinen Kontext vermittelt, braucht man diesen Leader nicht wirklich.
Er sollte dringend ersetzt werden.
Was sich gut anhört, ist nicht unbedingt auch gut. Ich denke auch, dass ein Code-Review, das nur aus den zwei Worten "Nasty Code" bestand, mir im Leben am meisten geholfen hat.
Nicht alle Entwickler sind gleich.
Ich habe darüber nachgedacht, was „systemisches Denken“ eigentlich bedeutet, und im Kontext des Artikels wirkt es auf mich wie eine Denkweise aus der Perspektive des Verhaltens einer Anwendung. Ich denke aber, dass das wirklich eine sehr wichtige Perspektive ist.
Ich kann das sehr gut nachvollziehen, weil ich erlebt habe, wie eine Codebase trotz bester Absichten völlig chaotisch wurde. Die Bedeutung der Fähigkeiten eines Managers ist wirklich enorm.
Dem stimme ich zu.
Die Implikation des Artikels wirkt auf mich weniger so, als wäre dieser Manager besonders hervorragend gewesen, sondern eher so, als hätte der Autor selbst gute Arbeit geleistet. (Vielleicht ist der Autor einfach der Typ Mensch, der unabhängig von der Art des Feedbacks wächst.)
Ich erinnere mich, einmal eine Studie gesehen zu haben, nach der sich das Verhalten beim Erhalt von negativem Feedback, dem es an Kontext mangelt, mit hoher Wahrscheinlichkeit entgegen der Erwartung verändert.
Man muss erkennen, dass Feedback zur eigenen Arbeit keine persönliche Kritik ist.
Es wäre vielleicht besser gewesen, wenn der Manager ein besserer Mensch gewesen wäre, aber ein Unternehmen ist keine Schule ... Wir sind Profis ... also müssen wir selbst lernen, mit Feedback umzugehen.
Man braucht auch den Mut, zu sagen, dass man etwas nicht weiß.
Sie scheinen eine deutlich andere Perspektive zu haben als ich. Vielleicht liegt es daran, dass meine Karriere noch nicht so weit fortgeschritten ist, aber ich habe oft erlebt, dass unklare Rückmeldungen und Feedback mit mehrdeutigen Bezügen eher das Gegenteil bewirken...
Die Rechtschreibung ist falsch.
„Man muss erkennen, dass es keine Kritik ist.“ -> Sie sollten schreiben: „Man muss erkennen, dass es keine Kritik ist.“
Sie wissen sicher, dass es keine persönliche Kritik ist, aber ich denke, dass Sie sich über meinen Hinweis geärgert haben, sobald Sie ihn gesehen haben. Manche nennen das Haarspalterei, aber letztlich sind Menschen wohl so, dass sie ähnliche Formulierungen unterschiedlich aufnehmen.
ps. Ich hatte Ihren Rechtschreibfehler auch nicht bemerkt, sondern erst gefunden, nachdem ich den Satz in eine Rechtschreibprüfung eingegeben hatte, weil ich ein Beispiel finden wollte.
Wenn man einen Rechtschreibfehler korrigiert, reicht es doch zu sagen: „Danke, das wusste ich nicht.“ Das scheint mir kein Grund zu sein, wütend zu werden. Zu glauben, dass andere dasselbe empfinden werden wie man selbst, ist meiner Meinung nach eine gefährliche Verallgemeinerung. Und außerdem heißt es nicht „getrennt schreiben“, sondern „zusammenschreiben“.
Ich denke, professionell zu sein bedeutet, auch stressige Situationen bewältigen zu können.
Damit will ich nicht rechtfertigen, andere unter Stress zu setzen. Wenn man professionell arbeitet, gibt es auch Momente, die einen wütend machen, aber ich denke, professionell zu sein bedeutet, damit klug umzugehen.
Ich bin wohl kein Rechtschreibexperte. Und die Community ist auch kein Unternehmen.
Ich stimme dem Kommentar wirklich zu. Ich denke, dass die Kompetenz und die Haltung der Person, die es angenommen hat, herausragend waren. Ich denke, dieser Manager hatte zwar eine klare Philosophie, wusste aber nicht, wie er einen guten Ansatz finden konnte, um seine Philosophie im Team zu verbreiten.
Wahrscheinlich ist genau das damit gemeint, wenn man etwas noch so vage hinwirft und das Gegenüber es trotzdem perfekt auffängt ... hehe
Ein wirklich guter Artikel. Das sollte ich mir wohl immer wieder ansehen, sowohl vor als auch nach dem Erstellen eines PR.
Um zu vermeiden, dass es wie ein persönlicher Angriff wirkt, scheint es wichtig zu sein, vorher eine gute Beziehung aufzubauen. (Vor allem im Kontext der koreanischen Gesellschaft.)
Ich persönlich achte auf die Verwendung des Subjekts. Es ist ja „dieser Code“, der overengineered ist, nicht „die andere Person“, die etwas falsch gemacht hat.
Das erinnert mich an den Artikel Was geht eigentlich im Kopf von Experten vor?. Wenn man Reviews wie „Das ist Over-Engineering. Zu komplex. Bitte refaktorieren.“ oder „Das ist verwundbar. Was passiert unter Last? Gibt es einen Rollback-Plan?“ bekommt, wäre es auch gut zu fragen, warum die Person das so sieht, welche Probleme sie erwartet und in welche Richtung sie Verbesserungen denkt. (Nicht dass der Autor das nicht getan hätte – ich habe nur darüber nachgedacht, wie man in solchen Situationen mehr Nutzen daraus ziehen könnte.)
Ein wirklich guter Text..