Vom „Techie“ zum Tech Lead: Meine fünf größten Fehler

Als junger, ehrgeiziger Entwickler, der von seinem Talent überzeugt war, wollte ich unbedingt Tech Lead werden. Dieses Ziel habe ich in weniger als vier Jahren erreicht. In den darauffolgenden zwei Jahren haben mich die mit der Teamleitung verbundenen Erfahrungen und die tatsächlichen Gegebenheiten jedoch vollkommen frustriert. Ich zog mich dann für mehrere Jahre in die Sicherheit der Technologie zurück und mied jede Möglichkeit, mehr Verantwortung zu übernehmen.

Im Laufe der Zeit habe ich die Ursachen meiner Fehler erkannt und schließlich wieder genug Selbstvertrauen gesammelt, um neue Führungschancen ergreifen und mich zum Teamleiter entwickeln zu können. Und dank der richtigen Unterstützung während der letzten zwei Jahre bin ich in meiner Rolle als Head of Technology bei ThoughtWorks gewachsen. Bei meiner Tätigkeit als Coach und Mentor für andere Tech Leads merkte ich, dass einige meiner Fehler auch anderen aus der Technologiebranche unterlaufen, wenn sie eine Führungsrolle übernehmen.

Ich möchte darüber sprechen, welche Fehler ich gemacht und was ich aus ihnen gelernt habe, damit andere davon profitieren können.

Fehler Nr. 1: Ich war der Meinung, dass mein fachliches Können mich zu einer Führungsrolle berechtigte

In meiner ersten Position als Tech Lead stellte ich einen talentierten jungen Mitarbeiter ein, der gerade seinen Abschluss gemacht hatte. Wir haben sehr gut zusammengearbeitet und uns gegenseitig zu neuen Ideen und Fähigkeiten inspiriert. Nach ein paar Monaten wurde mir klar, dass meine Mitarbeiter trotz ihrer Unerfahrenheit technisch kompetenter waren als ich. Als Tech Lead hatte ich das Gefühl, ich müsste mich am besten auskennen. Jedes Mal, wenn meine Mitarbeiter ihr Können unter Beweis stellten (vor allem bei meinen Vorgesetzten), hatte ich die Befürchtung, dass man sie als geeigneter für die Rolle betrachten könnte. So litt die anfangs tolle Arbeitsbeziehung unter dem Konkurrenzgefühl und dem Misstrauen, das ich aufgebaut hatte. Ich betrachtete meine Mitarbeiter nicht mehr als Kollegen (oder sogar mögliche Nachfolger), sondern als Bedrohung.

Die fachlichen Fähigkeiten einer Person sind oft entscheidend bei deren Auswahl als Führungskraft. Sie sind wohl auch der Faktor, der am besten sichtbar ist. Mein erster Fehler: Ich setzte diese Fähigkeiten mit dem Anspruch gleich, eine Führungskraft zu sein.



In meinem Fall führte das zu hinderlichem Wettbewerbsverhalten. Dass ich so unsicher war, ließ sich zu einem großen Teil auf meine Umgebung und meinen vermeintlichen Führungsanspruch zurückführen. Selbst wenn ein Mensch noch so bescheiden und kompetent ist, kann dieser Fehler das sogenannte Hochstaplersyndrom verschärfen. Das wiederum kann dazu führen, dass der Teamleiter andere Teammitglieder als wertvoller wahrnimmt, seine Beiträge für das Team unterschätzt und seinen eigenen Wert nicht anerkennt. In so einem Fall werden Führungskräfte unentschlossen und meiden Entscheidungen, anstatt denen zu vertrauen, deren Fähigkeiten sie eigentlich kennen.

Dieser Fehler verhindert, dass geeignete Personen sich für eine Führungsrolle ins Spiel bringen, weil sie glauben, dass der Kollege mit den besten fachlichen Fähigkeiten die Rolle übernehmen sollte.

Fehler Nr. 2: Ich konzentrierte mich auf die Technologie, anstatt meine Kompetenzen auszubauen

In meiner ersten Führungsrolle war ich sehr aufgeregt. Ich hatte es mit einem ganz neuen Team und einem Greenfield-Projekt zu tun. Ich führte neue Technologien und Methoden ein: Modultests, ORM, kontinuierliche Integration, Paarprogrammierung, optimistische Quelltextkontrolle, NAnt-Build-Dateien. Wenn ich in einem Blogartikel von einer spannenden neuen Idee gelesen hatte, integrierte ich sie in unsere Prozesse und Tools.

Die Auswahl der Tools und der Technologien fiel in den Bereich Iteration Zero. Als Nächstes ging es ans Tagesgeschäft. Management, Umgang mit Stakeholdern, Repräsentieren meines Teams bei Meetings, Leistungsbeurteilungen, Rekrutierung, Budgetverwaltung usw. Und auch wenn ich über SVN, NUnit, CruiseControl und C# genug wusste, hatte ich von den übrigen Dingen keine Ahnung.

Bald nervten mich die Tätigkeiten, die ich nicht verstand oder die mir schwerfielen. Doch anstatt meine Wissenslücken zu füllen, konzentrierte ich mich verstärkt auf das, was ich kontrollieren konnte: die Technologie. Das machte das Hochstaplersyndrom bei mir nur noch schlimmer – besonders dann, wenn andere Manager in einem Meeting ganz gelassen erzählten, wie sie die Kompetenzen ihrer Teams stärkten, indem sie Schulungen organisierten oder Geschäftsszenarien beispielsweise für Investments, neue Teammitglieder oder Notfallwiederherstellungen entwickelten.

Wie schon erwähnt, reicht technische Kompetenz allein nicht aus, um eine Führungsrolle übernehmen zu können. Neben den technischen Fähigkeiten sind noch viele weitere Stärken gefordert: Eine Führungskraft muss beeinflussen und überzeugen, sie muss coachen, Prozesse verstehen und ein vertrauensvoller Berater sein, mit komplexen Themen umgehen und strategisch denken (und noch vieles mehr). Diese Kompetenzen sind weniger offensichtlich und werden vermutlich im Laufe eines Arbeitstages oder einer Arbeitswoche in verschiedenen Abstufungen gefordert.

Neue Führungskräfte müssen sich bewusst werden, wie wichtig diese Kompetenzen sind und dass sie selbst sich in vielen Bereichen breit aufstellen müssen. Ansonsten besteht das Risiko, dass sie sich ihrer sichtbarsten Stärke, der Technologie, zuwenden und sich nur auf die Vertiefung ihres Wissens in diesem Bereich konzentrieren.

Eine weitere Falle ist, dass es für Menschen in IT-Berufen relativ einfach ist, neue technische Kompetenzen zu erwerben. Wir sind es gewohnt, uns neue technische Fähigkeiten anzueignen: Wir wissen, welche Formeln wir anwenden, welche Blogs und welche Stack-Overflow-Posts wir lesen, welchen Vordenkern wir folgen, an welchen Konferenzen wir teilnehmen und welche Bücher wir lesen müssen. Eine halbwegs brauchbare Einführung mit einem „Hello World“-Beispiel, und mit ein wenig Übung beherrschen wir schon bald eine neue Technologie.

Andere Kompetenzen lassen sich aber nicht auf diese Weise erlernen.
 
Wir wissen nicht, wem wir auf Twitter folgen sollen, damit wir lernen, Entscheidungen „richtig“ zu vermitteln, Teams zu organisieren oder Stakeholder zu managen.

Daher ist es so aufwendig, sich in neue Bereiche vorzuarbeiten, die man für eine Führungsrolle braucht. Weil viele dieser Bereiche recht neu sind, fühlen sich Führungskräfte allein gelassen und sind verunsichert. Es kann auch passieren, dass sie falsche Prioritäten setzen und eher neue technische Kompetenzen entwickeln, weil diese schnell und einfach zu erlernen sind und einen offensichtlichen Nutzen bieten, anstatt fachfremde Kompetenzen auszubauen, die sie sich erst mühsam aneignen müssen, ohne in ihnen einen sichtbaren Wert zu erkennen.

Fehler Nr. 3: Ich betrachtete mich weiterhin als einzelner Code-Produzent.

Nach ein paar Monaten in meiner ersten Teamleiterposition wurde ich zunehmend nervös. Ich hatte das Gefühl, vieles machen zu müssen, was sich nicht produktiv anfühlte. Ich verbrachte immer weniger Zeit mit (Paar-)Programmierung und saß stattdessen in Meetings, beantwortete E-Mails oder Fragen von Stakeholdern. Ich hatte das Gefühl, dass keines meiner Projekte Fortschritte machte. Also holte ich das, was ich wegen dieser vermeintlichen Ablenkungen nicht schaffte, in meiner Freizeit nach. Schnell war ich überarbeitet.

Bei meinem Wechsel zur Führungskraft hatte ich nicht erkannt, wie meine Verantwortlichkeiten und Erfolgskriterien als Code-Lieferant sich veränderten. Jedes Delivery Team verfolgt vor allem das Ziel, möglichst viele „Werte“ zu schaffen. Vor diesem Hintergrund gibt es im Team zwei Haupttätigkeiten: Die einen produzieren Werte, und die anderen steigern deren Wirkung. Eine besonders einfache, wenn auch bei Weitem nicht die einzige Möglichkeit hierfür ist, den Lieferanten (in diesem Fall den Entwicklern) so viel Zeit wie möglich für produktive Tätigkeiten (also das Schreiben von Code) zu geben. Die restlichen Teammitglieder – von PM über XD bis hin zu BA und QA – stellen sicher, dass der Workflow möglichst korrekt und reibungslos abläuft, dass er nicht blockiert wird und keine Ausfälle (z. B. aufgrund von Bugs) auftreten. Es ist ganz einfach: Um die Produktivität der Entwickler zu gewährleisten, beseitigt das Team um sie herum alle Hindernisse und Ablenkungen, damit die Entwickler sich ungestört auf das Schreiben des richtigen Codes konzentrieren und Werte schaffen können.

Wenn jemand aus dem Entwicklerteam zum Tech Lead wird, gehört er nicht mehr zu denen, die produzieren, sondern zu denen, die sich um die Wirkungssteigerung kümmern (einschließlich der Beseitigung von Hindernissen und Blockaden).

Ein Teamleiter, dem das nicht klar ist, gerät unter Stress, vor allem was das Zeitmanagement angeht. Er hat dann das Gefühl, nicht genug Zeit für (Paar-)Programmierung zu haben. Das kann sich dann darin äußern, dass er angesichts zu vieler Meetings frustriert ist oder sich wünscht, dass diese nur zu bestimmten Zeiten stattfinden (Zeitfenster für (Paar-)Programmierung usw.). Ich habe auch schon Extremfälle erlebt, bei denen alles abgelehnt wurde, was nicht rein technisch war, z. B. Gespräche mit Stakeholdern. Das alles ist darauf zurückzuführen, dass der Tech Lead sich selbst als direkter Produzent wahrnimmt und nicht als jemand, der die Wirkung anderer maximiert.



In meinem Fall war es sogar so, dass ich mich als das wichtigste Teammitglied betrachtet habe, das unverzichtbar ist. Ich habe das oft auch bei anderen beobachtet, insbesondere in kleineren Teams, in denen der Teamleiter über deutlich mehr Qualifikationen verfügt als die übrigen Mitglieder. Wenn der Tech Lead neben dem üblichen Lieferdruck auch noch aufgrund der zusätzlichen Verantwortung unter Druck gerät, hat er unter Umständen das Gefühl, dass die Produktivität des Teams erheblich leidet, wenn er sich aus der Programmierung zurückzieht.

Fehler Nr. 4: Ich wollte alles wissen und steuern, anstatt Aufgaben abzugeben

In einem Meeting wollte ein Vorgesetzter etwas über einen Bug wissen. Weil ich noch nie in diesem Bereich der Anwendung gearbeitet hatte, konnte ich die Frage nicht so recht beantworten und wurde bei dem Versuch immer weniger überzeugend. Am Ende leitete ich mir eine Antwort her, weil ich nicht zugeben wollte, dass ich etwas nicht wusste. Andere Teams begannen dann, ihre Anwendungen entsprechend meiner Antwort anzupassen, und fanden schließlich nach jeder Menge vergeblicher Arbeit heraus, dass ich falsch gelegen hatte. Ich machte mangelndes Wissen für meinen Fehler verantwortlich und wollte so etwas in Zukunft vermeiden, indem ich am Anfang jedes Tages das Commit-Protokoll las.

Beim Lesen der Commits fiel mir ein Teil des Codes auf, der recht prozedural programmiert war, und ich fand, dass er objektorientierter geschrieben werden könnte. Gemeinsam mit dem Entwickler dachte ich über einen anderen Ansatz nach. Wir programmierten dann paarweise, und ich vertiefte mich mehrere Tage lang in diesen kleinen Codeabschnitt. Gleichzeitig arbeitete ein anderes Zweierteam an einer großen Architekturänderung. Die Freigabe führte zu einem Bug aufgrund einer falschen Annahme, die ich hätte entdecken müssen.

Ich sagte meinem Vorgesetzten die Wahrheit: dass ich mich zu sehr auf den Code konzentriert hatte, anstatt das andere Paar im Blick zu behalten. Mit der Rückmeldung, ich würde mir Gedanken über Unwichtiges machen, konnte ich jedoch nicht so recht umgehen. War es etwa nicht wichtig, objektorientiert zu programmieren? Die Antwort: Ich müsse Prioritäten setzen.

Beide Situationen machten deutlich, dass ich mich nicht um alles kümmern konnte. Kein Mensch kann das. Als Tech Lead musste ich Verantwortung abgeben und mich auf das Wesentliche konzentrieren. Manchmal bedeutete das, dass ich etwas nicht wusste oder dass etwas nicht genau so gemacht wurde, wie ich es gemacht hätte – oder auch, dass Dinge ganz und gar nicht optimal waren. Es war in Ordnung zu sagen „Ich weiß es nicht, ich muss das mit meinem Team abklären“, denn aus Versehen falsche Informationen zu verbreiten, richtete Schaden an. Es war auch in Ordnung, wenn etwas nicht ganz perfekt war, wie z. B. ein prozeduraler Codeabschnitt. Eine große Architekturänderung nicht im Blick zu haben, war hingegen nicht vertretbar.

Außerdem habe ich erkannt, dass beispielsweise Mentoring und Code-Reviews im Team viel effektiver sind, um die Codebasis langfristig zu verbessern, anstatt jede Kleinigkeit korrigieren zu wollen. 

Fehler Nr. 5: Ich konnte Signale nicht richtig deuten

Ich nahm an Projektmeetings teil und machte Verbesserungsvorschläge, aber als sich nichts änderte, wuchs meine Frustration. Meine Ideen wurden nicht umgesetzt. Wir sprachen darüber, im Team jede Story der Entwickler zu testen, aber nachdem wir es einmal ausprobiert hatten, gingen wir wieder dazu über, alles in Queues vor dem Produktivbetrieb zu erfassen. Wir einigten uns darauf, dass die Entwickler die Verantwortung für die Datenbank tragen sollten, und warteten dann doch wieder darauf, dass die Datenbankadministratoren Stored Procedures erstellen. Ich schulte Entwickler im Bereich TDD, aber nach nur einer Iteration gaben es alle wieder auf. Es wurde nur geredet, aber nichts passierte. Mit der Zeit wurde ich frustriert und entmutigt.



Wenn die Technologie jeden Tag und jede Minute bestimmt, stellt man sich auf die Feedbackschleifen und die vorhandenen Signale ein. Wir sind ein Teil der Story Wall: Unser Gehirn setzt Endorphine frei, wenn ein Build freigegeben wird oder eine Story in den Produktivbetrieb geht, und Cortisol, wenn der Build bricht oder eine Story im Entwicklungsstadium feststeckt. Wer aber eine Führungsrolle einnimmt, muss plötzlich auf ganz andere Signale achten.  

Dieser Verschiebung wird man sich zunächst schwer bewusst, zumal die täglichen Anforderungen im Prinzip gleich bleiben: Storys müssen weiterhin angefangen und geliefert werden, und der Code muss geschrieben werden. Die Signale, die ein neuer Teamleiter empfängt, sehen also nach wie vor technisch aus.  

Wenn wir eine Führungsposition übernehmen, müssen wir lernen, andere Signale zu erkennen und zu deuten. Wer die Richtung ändern will, muss andere beeinflussen. Wir müssen lernen zu erkennen, wer unsere Ideen versteht und ob diese Person überzeugt und unterstützend eingestellt oder eher skeptisch ist. Es gibt auch andere Signale: Teammitglieder, die zu viel Arbeit haben und Unterstützung benötigen und die neue Fähigkeiten oder Disziplinen aufgrund fehlender Tools nicht entwickeln können – oder aber Lücken in der Kommunikation, wegen derer das Team nicht weiß, was von ihm erwartet wird. Solche Signale sind oft schwer zu erkennen, weil sie von uns Menschen ausgesendet werden und wir Dinge häufig verstecken.
 
Außerdem sind die Signale mit Vorsicht zu behandeln: Nicht immer haben sie die Ursache, die man annimmt.

Herausragende Führungskräfte haben ein Gespür für all diese Signale. Sie können sie interpretieren und darauf reagieren. Das Ganze mag manchen wie Hokuspokus erscheinen, aber es gibt rationale Ansätze, die erlernbar sind – auch wenn sie nicht ganz so rational und greifbar sind wie die Technologie.

Meine technischen Wurzeln als Wachstumsgrundlage

Viele dieser Fehler hängen miteinander zusammen. Zum Beispiel ist es schwer, sich nicht weiterhin als Produzent zu sehen, wenn man der Meinung ist, dass man schon alleine aufgrund seiner technischen Fähigkeiten für eine Führungsposition bestimmt ist. Dadurch ist es schwieriger, andere Kompetenzen zu entwickeln. Durch die Art und Weise, wie diese Fehler zusammenwirkten, geriet ich in meiner Führungsrolle in eine Negativspirale.

Zur Führungskraft zu werden, bedeutet eine große Veränderung und kann beängstigend sein, und wenn wir Menschen bei einer Sache nicht weiterkommen, wenden wir uns unseren Stärken zu. Doch auch wenn die technische Kompetenz die Grundlage ist, müssen wir als Führungskräfte auch unsere anderen Stärken ausbauen. Das kann unsere Fähigkeit sein, mit Menschen zusammenzuarbeiten und zu kommunizieren oder andere zu überzeugen. Technische Kompetenzen lassen sich auch übertragen, z. B. die Fähigkeit, schnell zu lernen, sich Neues anzueignen, über komplexe Themen nachzudenken oder Probleme durch Abstrahieren in eine verständlichere Form zu bringen. Als ich mir meiner Stärken schließlich bewusst war, erkannte ich Möglichkeiten, mir neue Kompetenzen zu erschließen und neue spannende Bereiche des Lernens und der Entwicklung zu erkunden. 

Schließlich muss man sich klar machen, dass der Weg zur Führungsposition nicht unbedingt geradlinig verläuft.
 
Teams sollten ihren Mitarbeitern kleinere Entwicklungsmöglichkeiten bieten, damit sie ihre Fähigkeiten unabhängig von einer Führungsrolle ausbauen können.