- In einem Umfeld, in dem Experten aus vielen Fachbereichen zusammenkommen, übernimmt die Führungskraft weniger die Rolle, technische Details bis ins Letzte zu kennen, sondern vielmehr, Probleme zu verbinden und die Richtung der Lösung vorzugeben
- Bei Leadership sind nicht bloß technische Kenntnisse entscheidend, sondern vor allem Übersetzungsfähigkeit und soziale Kompetenz; außerdem gilt es, Konflikte zu moderieren und gemeinsame Ziele zu betonen
- Entscheidend ist nicht die Tiefe der jeweiligen Spezialisierung, sondern das eigentliche Problem und die Lösungsrichtung klar zu definieren und dafür zu sorgen, dass Diskussionen in die Anforderungen der Nutzer und in Ergebnisse münden
- Effektive Führungskräfte tun nicht so, als wüssten sie alles, sondern haben den Mut, „Ich weiß es nicht“ zu sagen, und schaffen einen Rahmen, in dem Experten eigenverantwortlich beitragen können
- Der wahre Wert einer Führungskraft liegt in der Übersetzung von Perspektiven, dem Vermitteln des Problemkontexts und dem Schaffen von Räumen für Zusammenarbeit; genau das ist ein Schlüsselfaktor für Spitzenleistungen
Eine aktuelle Erkenntnis
- In einem Besprechungsraum arbeite ich mit erfahrenen Entwicklern und dem Produktteam aus verschiedenen Fachgebieten zusammen
- Ich habe in keiner einzelnen Technologie die höchste Expertise, übernehme aber die Rolle des Lead Developers
- Meine Rolle als Führungskraft unter Experten besteht nicht darin, alle Antworten zu kennen, sondern darin, Antworten zu finden und miteinander zu verknüpfen
Technical Leadership
- Führung bedeutet weniger Tiefe im technischen Wissen als vielmehr, als effektiver Übersetzer die Kommunikation zwischen Teams zu ermöglichen
- Ob es um die Zeitplanung des Backend-Teams oder die Anforderungen des Produktteams geht: Entscheidend ist, die jeweiligen Perspektiven zu dolmetschen und so Zusammenarbeit im Team zu ermöglichen
Leading is a Social Skill
- Technische Glaubwürdigkeit allein reicht nicht aus; echte Produktivität entsteht durch soziale Kompetenz
- Man muss Diskussionen zwischen Entwicklern lesen können und einschätzen, wann man einen Streit moderieren oder das Gespräch voranbringen sollte
- Effektive Kommunikation entsteht nicht nur durch Dokumente, sondern durch aktive Gespräche
Leading is Remembering the Goal
- Je mehr Expertise vorhanden ist, desto eher neigen Menschen dazu, sich in technische Details zu vertiefen; Führung muss jedoch den Fokus auf das Gesamtziel behalten
- Wichtig ist nicht nur die technische Diskussion, sondern die Rolle, das grundlegende Problem der User Experience und das geschäftliche Ziel klar zu definieren
- Wird das eigentliche Problem nicht klar eingegrenzt, können Teammitglieder je nach ihrer jeweiligen Analyseweise das wahre Thema aus dem Blick verlieren
- Die Führungskraft trägt die Verantwortung, das Problem so zu übersetzen, dass das Team es richtig versteht und auf dasselbe Ziel blickt
Leading is Saying "I Don't Know"
- Statt so zu tun, als kenne man jede Antwort, schafft die Haltung „Ich weiß es nicht, lasst es uns gemeinsam herausfinden“ Vertrauen und eine offene Kultur
- Diese Haltung erlaubt Experten Fragen und Diskussionen und gibt ihnen Raum, ihre Fähigkeiten einzubringen
- Die Führungskraft gibt Fachexperten Entscheidungsbefugnis und Stimme und weist der Diskussion eine produktive Richtung
- Wenn zwei Experten bei der Umsetzung unterschiedliche Ansichten haben, besteht die Rolle der Führungskraft nicht darin, die „richtige“ Antwort auszuwählen, sondern einen Rahmen zu bieten, der Trade-offs und Auswirkungen auf Nutzer sichtbar macht
The Translation Challenge
- Führungskräfte müssen die Sprache von Entwicklern, Produktteams und Management je nach Situation übersetzen können
- Entwickler: "Wenn der Authentifizierungsservice keinen geeigneten Circuit Breaker hat, kann es unter Last zu kaskadierenden Ausfällen kommen"
- Produktteam: "Wenn es Probleme mit dem Login-System gibt, kann das die gesamte App beeinträchtigen; deshalb brauchen wir einen Schutzmechanismus, und der Zeitplan verlängert sich um eine Woche"
- Management: "In diesem Sprint priorisieren wir Systemstabilität, um das Geschäftsrisiko zu senken"
- Man muss von Experten nicht verlangen, auch noch die Sprache anderer Abteilungen zu lernen; die Führungskraft sollte die Lücke als Brücke schließen
Beyond "Because, that's why!"
- Entscheidungen nach dem Muster „Ich bin der Lead, also machen wir es so“ beschädigen Vertrauen und die Kultur der Zusammenarbeit und senken die Produktivität des Teams
- Wichtig ist, das Team als Erwachsene zu behandeln und Gründe und Kontext von Entscheidungen klar zu erklären
- "Wir wählen einen konservativen Ansatz, weil die Kosten eines Fehlers hoch sind; später können wir iterativ verbessern"
- "Es mag sich wie zusätzliche Arbeit anfühlen, passt aber zu unseren Architekturzielen und hilft bei der Entwicklung der nächsten Features"
- "Das ist vielleicht nicht die eleganteste Lösung, aber wir können sie innerhalb des Zeitplans mit gutem Gewissen ausrollen"
- Je mehr man die eigene Expertengeste loslässt, desto eher kann man echte Leadership zeigen
Welchen Wert Führung dem Team liefern sollte
- Eine klare Problemdefinition
- Eine ausreichende Erklärung des Entscheidungskontexts
- Übersetzung unterschiedlicher Perspektiven zwischen Teams
- Schutz vor unnötiger Komplexität
- Ein Umfeld schaffen für die besten Ergebnisse
Fazit
- Technische Führung in einer Expertenorganisation geht über Anweisung und Kontrolle hinaus und fokussiert sich auf Verbindung und Kontextvermittlung
- Die Führungskraft ist nicht der Musiker, der jedes Instrument selbst spielt, sondern eher der Dirigent, der dem Orchester hilft, gemeinsam ein Stück zu vollenden
- Das ist eine sehr viel interessantere Herausforderung, als einfach nur die klügste Person im Raum zu sein
4 Kommentare
Andersherum betrachtet denke ich, dass man in einem Umfeld ohne Experten letztlich selbst zum Experten werden muss.
Natürlich denke ich auch darüber nach, neben technischer Führung andere Formen von Leadership zu übernehmen, aber wenn man auf Teammitglieder trifft, mit denen der Austausch nicht gut funktioniert, ist selbst das in der Realität schwer umzusetzen – es scheint also je nach Situation unterschiedlich zu sein.
Eine großartige Perspektive.
So sollte ich arbeiten.
Hacker-News-Kommentare
Als Teamleiter versuche ich, Entscheidungen nach dem Muster „Ich bin der Lead, und so machen wir es“ möglichst zu vermeiden, betone aber, dass man dieses Mittel bei Bedarf ohne Zögern einsetzen sollte. Ich nehme mir Zeit, alle Meinungen anzuhören und sorgfältig zu entscheiden, habe aber erkannt, dass ich als Lead Ordnung herstellen muss, wenn das Team in endlosen Debatten über unwesentliche Details feststeckt. Ich denke dann an Steve Jobs’ Spruch: „Wenn du alle glücklich machen willst, werde nicht Anführer, sondern verkaufe Eis.“ Wichtig ist, danach unbedingt wieder Vertrauen aufzubauen und dem Team zu erklären, warum man so handeln musste
Ich habe diese Lektion ebenfalls auf die harte Tour gelernt. Als ich zum ersten Mal Manager wurde, glaubte ich naiv, ich könne immer einen Konsens herstellen und das Team würde sich dann von selbst zusammenfinden. In großartigen Teams funktionierte das anfangs, aber später arbeitete ich mit Engineers, die nur an den Methoden ihres anderen Teams aus den letzten 25 Jahren festhielten, und verschwendete zu viel Zeit damit, auf einen Konsens zu warten. Am Ende wurde mir klar, dass der Moment kommt, in dem der Lead die Richtung vorgeben und eine Entscheidung treffen muss, nachdem alle ihre Position ausreichend dargestellt haben
Meiner Erfahrung nach habe ich in den letzten Jahren bei einem F50 in einer ähnlichen Situation gearbeitet. In einem Bereich mit drei Schlüsselpersonen wussten nur wir, dass Option A zwar oberflächlich gut aussah, in Wirklichkeit aber viele Probleme hatte. Trotz Erklärungen konnten wir das Team nicht überzeugen, also ignorierten wir am Ende die Abstimmung, sprachen mit unserem Vorgesetzten und konnten so die richtige Entscheidung treffen. Dabei wurde mir deutlich, dass ein Projekt immer wieder Probleme und Verzögerungen bekommt, wenn man nicht der Richtung folgt, die die Person bevorzugt, die das Ergebnis tatsächlich direkt tragen muss (Option C), sondern der Mehrheitsmeinung (Option A). Entscheidend ist, dass die Personen, die Verantwortung und Konsequenzen direkt tragen, kein Popularitätsvotum brauchen, sondern ein „Vetorecht“, damit ein Projekt vorankommt. In großen Projekten sollten mehrere Leads je nach Domäne Entscheidungen treffen, und nur bei einem Patt sollte die Führungskraft eine klare Entscheidung fällen. Wenn ein Lead Entscheidungen vermeidet, äußern am Ende alle nur Unzufriedenheit, und die Moral im Team leidet massiv — eine äußerst frustrierende Erfahrung
Ich musste auch an die Episode denken, in der Steve Jobs sein Team in einen Raum sperrte und so lange diskutieren ließ, bis eine gemeinsame Vision gefunden war. Alle in dieselbe Richtung zu bringen, ist schwierig, aber wenn das misslingt, leidet die Umsetzungsfähigkeit stark. Gleichzeitig führt das Ignorieren von Meinungen dazu, dass sich Teammitglieder übergangen fühlen; selbst wenn das Ergebnis wichtig ist, ist das auf Dauer kein tragfähiger Weg
Ich fand den Punkt eindrücklich, dass „allen eine Stimme geben“ und „allen ein Vetorecht geben“ völlig unterschiedliche Dinge sind. Als Lead festgefahrene Situationen aufzulösen, ist meiner Meinung nach eine essenzielle Aufgabe. Wenn allerdings bei jedem Thema der Lead entscheiden muss, ist das ein Zeichen für Probleme im Management, in der Motivation oder dafür, dass das Team die Strategie nicht versteht
Ich bevorzuge die Formulierung: „Wenn du direkt dafür verantwortlich wärst, welche Entscheidung würdest du treffen? Sag sie mir dann.“ Die Aufgabe eines Leads ist nicht immer, selbst die Entscheidung zu treffen, sondern sicherzustellen, dass überhaupt eine Entscheidung zustande kommt
Ich denke, ich habe in diesem Bereich etwas Erfahrung. Früher wurde ich zum Leiter eines Projekts ernannt, das bereits dreimal gescheitert war, und arbeitete dabei mit sechs der besten Engineers aus verschiedenen Teams. Alle hatten klare Meinungen und gute Gründe dafür, aber in Anlehnung an „Störe deinen Feind nicht, wenn er gerade einen Fehler macht“ versuchte ich die Haltung einzunehmen: „Störe deinen Freund nicht, wenn er etwas Großartiges macht.“ Nach dem Motto: „Wenn es nicht dein Bereich ist, dann baue etwas anderes, in dem du gut bist.“ Wir verteilten die Rollen ganz natürlich, beeinflussten uns gegenseitig auf sanfte Weise und akzeptierten bei weniger wichtigen Teilen auch Unvollkommenheit. Am Ende war es ein Erfolg, und ich bin sehr stolz darauf, dass daraus in einem Team voller talentierter Leute eine Struktur entstand, in der man voneinander lernte und sich nur auf die Punkte konzentrierte, die wirklich eine echte Diskussion brauchten
Ich glaube, deine Erfahrung ähnelt dem Führungsstil, den man Servant Leadership(passender Wiki-Link) nennt. Das ist auch eine Art von Leadership, die ich sehr schätze
Ich denke, es braucht als Lead echtes Vertrauen, Zurückhaltung und Selbstsicherheit, um großartige Engineers ohne übermäßige Eingriffe selbstbestimmt ihre Ideen entfalten zu lassen
Jedes Mal, wenn das Produktteam ein „einfaches“ Feature anfragt, denke ich sofort daran, dass dafür mindestens drei Teams gebraucht werden und jeweils ihre Microservices aktualisieren müssen. In solchen Momenten hasse ich moderne Websysteme manchmal wirklich
Das Problem ist hier, glaube ich, weniger das moderne Web an sich, sondern eher eine Architektur, bei der selbst ein „einfaches“ Feature von Abhängigkeiten über drei Microservices hinweg verteilt ist. Letztlich ist ein gescheitertes Systemdesign die größere Ursache
Dann würde mich interessieren, was die Alternative wäre
Meiner Erfahrung nach sollte man Aussagen wie „Ich bin der Lead“ vermeiden, weil sie wie mangelndes Selbstvertrauen wirken können. Stattdessen sollte man, nachdem man alle Informationen gesammelt und eine Entscheidung getroffen hat, selbstbewusst sagen können: „Also, wir machen es jetzt so“ oder „Ich möchte, dass wir es so umsetzen“
Im Kern geht es nicht um Missverständnisse, sondern um mangelndes gegenseitiges Vertrauen. Wenn ein Team sagt, eine Aufgabe dauere zwei Wochen, denkt ein anderes Team vielleicht, das sei an einem Tag erledigt, und vertraut dieser Einschätzung nicht. Wenn genug Vertrauen da wäre, könnte man akzeptieren, dass das andere Team schlicht mehr Fachkenntnis hat. In der Praxis entsteht aber oft der Verdacht, dass eine Aufwandsschätzung nicht den tatsächlichen Arbeitsaufwand widerspiegelt, sondern nur zusätzlichen Puffer schaffen soll. In solchen Fällen helfen ausreichende Erklärungen und nachvollziehbare Begründungen dabei, Vertrauen aufzubauen
Ich wurde vor etwa einem Jahr zum Lead Developer befördert. Ich war verwirrt darüber, was genau meine Rolle und Verantwortung sind, aber es beruhigt mich zu sehen, dass ich offenbar mit ähnlichen Gedanken gearbeitet habe wie im Originalbeitrag. Vor ein paar Tagen stieß ich auf einen Artikel darüber, „wie man Tutorials aus der Perspektive von Nicht-Entwicklern liest“, und konnte mich damit identifizieren; es fühlt sich an, als wäre ich auf dem richtigen Weg
Ich habe selbst drei Fälle erlebt, in denen ein Lead in einem produktnahen Softwareentwicklungsteam auf autoritäre Weise geführt hat, und jedes Mal war das Ergebnis nicht gut. Nachdem ich ein paar Mal selbst ein Team geleitet habe, wurde mir klar, dass meine Rolle nicht die eines „Kommandeurs“ ist, sondern die eines „Hubs und Vermittlers“. Wenn es Konflikte zwischen Teammitgliedern gibt, helfe ich dabei, sie zu lösen; wenn Fragen auftauchen, nehme ich Unsicherheit; wenn Ideen aufkommen, bewerte ich Umsetzbarkeit und Wert; und wenn Ressourcen nötig sind, helfe ich dabei, die richtigen Personen zu finden. Wenn Probleme entstehen, übernehme ich Verantwortung und motiviere das Team, sie zu lösen. Es hat mehr als zehn Jahre gedauert, all das zu lernen. Ich bin nicht der Beste, und mein Name ist den meisten Menschen nicht bekannt, aber wenn ich als „Teil“ des Teams arbeite, sind die Ergebnisse besser und es gehen weniger Talente verloren. Und ich finde es als Lead wirklich wichtig sagen zu können: „Ich weiß es auch nicht genau, aber lass uns die Antwort gemeinsam finden.“ Das erlaubt Expertinnen und Experten, Unsicherheit zuzulassen, ohne defensiv zu werden, und gibt ihnen das Gefühl, nicht allein zu sein. Wer sich durch frühere Führungskräfte ausgeschlossen oder wie ein austauschbares Teil gefühlt hat, dem wünsche ich Trost. Und wenn ein Lead sein Team langfristig gut führen will, sollte er Menschen nicht wie Maschinen behandeln, sondern sich wirklich umeinander kümmern
Ich bin beeindruckt, dass der Autor den Audioinhalt des Artikels selbst eingesprochen hat
Jemand sagt, er möge den Satz „It's because that's why“, und empfiehlt für Interessierte an diesem Themenfeld die Bücher von Vanessa Van Edwards, weil sie sehr dabei geholfen hätten zu lernen, wie man je nach Situation Wärme und Kompetenz signalisiert. Eine einzelne Person kann kaum alle Antworten haben, aber es habe viele positive Erfahrungen damit gegeben
Beim Treffen von Entscheidungen geht es, so mein Eindruck, um mehr als nur darum, „sicherzustellen, dass eine Entscheidung getroffen wird“ — aber auch nicht um weniger. Erstens würde ich, wenn möglich, empfehlen, andere die Entscheidung selbst treffen zu lassen. Aus Apples Zeit wird die Anekdote über Jean-Louis Gassee erzählt, der Managern, die einen Streit zu ihm brachten, oft eine Entscheidung präsentierte, die beide Seiten nicht mochten; daraufhin fanden sie meist selbst eine Alternative, auf die sie sich einigen konnten. Zweitens ist es notwendig, dafür zu sorgen, dass alle Beteiligten die Entscheidung wirklich mittragen — und man selbst zuerst. Für Manager, die sich stark nach dem Wind richten, sei das enorm schwierig. Als Vergleich wird angeführt, dass Jurastudierende immer vorsichtig und analytisch denken, Anwälte aber entschlossen argumentieren und die Haltung entwickeln müssen, andere zu überzeugen. Da Konsens nicht immer ideal zustande kommt, wurde außerdem der Tipp geteilt, konkrete Bezugspunkte wie Kunden oder Ergebnisziele zu setzen, um Entscheidungen voranzutreiben und ihre Umsetzung zu ermöglichen