Verbessern Sie Ihre technischen Fähigkeiten als Teamleiter

Ihre derzeitige Tätigkeit umfasst zwei unterschiedliche Aspekte mit jeweils eigenen Verantwortlichkeiten: den technischen und den leitenden Aspekt. Beide Aspekte sind wichtig – wenn Sie versuchen, einen davon zu ignorieren, werden Sie Probleme verursachen. Ein Teamleiter, der sich nur auf den leitenden Aspekt seiner Tätigkeit konzentriert, wird Schwierigkeiten haben, die Arbeit seines Teams zu verstehen. Das Gegenteil ist vielleicht sogar noch schlimmer: Wer sich nur auf die technischen Aspekte konzentriert, könnte die Stabilität des gesamten Teams gefährden. Dieses Problem betrifft viele Menschen in Führungspositionen.

Und obwohl sich dieser Artikel darauf konzentriert, wie man dieses Problem aus der Perspektive eines Softwareentwicklers angehen kann, sollte man beachten, dass das Problem selbst nicht nur in der IT-Branche auftritt, sondern in vielen verschiedenen Berufen zu finden ist.

Es liegt also auf der Hand, dass der Schlüssel zum Erfolg darin liegt, diese beiden Aspekte in Einklang zu bringen. Ihr Verhältnis wird sich im Laufe der Zeit je nach Prioritäten (und einigen anderen Faktoren) ändern, daher müssen Sie flexibel bleiben und darauf achten, wie Sie Ihre Zeit verbringen. Da sich die Softwareentwicklung als Branche jedoch ständig verändert und weiterentwickelt, müssen Sie dennoch mit der Technologie in Kontakt bleiben. Sie sollten sich nicht vollständig aus dem Prozess der Softwareentwicklung zurückziehen, aber sobald Sie Teamleiter werden, haben Sie weniger Zeit dafür. Genau aus diesem Grund müssen Sie sich eine technische Denkweise bewahren.

Beachten Sie, dass eine technische Denkweise etwas anderes ist als nur das Programmieren. Das Programmieren ist nur ein Teil der Gleichung – eine der Aktivitäten, die Ihnen dabei helfen, eine technische Denkweise beizubehalten. Es stehen Ihnen mehrere andere Tools zur Verfügung, und wir werden Ihnen im Folgenden einige Vorschläge mit Beschreibungen unterbreiten.

Schreiben Sie etwas Code

Beginnen wir mit dem naheliegendsten Ansatz. Wie bereits erwähnt, werden Sie aufgrund der Art Ihrer Arbeit viel weniger Code schreiben, aber Sie sollten trotzdem etwas Code schreiben. Aus diesem Grund muss sich die Art der Aufgaben, an denen Sie arbeiten, ändern. Sie sollten nicht an den kritischsten und interessantesten Aufgaben arbeiten. Überlassen Sie diese Ihren Teammitgliedern (es sei denn, es gibt keine andere Möglichkeit). Ihre anderen Aufgaben können (und werden) Ihnen im Weg stehen, wenn Sie anfangen, an etwas Komplexem zu arbeiten. Und wenn es sich dabei auch noch um eine Aufgabe mit hoher Priorität handelt, wird die Situation noch schlimmer. Ganz zu schweigen davon, dass Sie Ihren Teammitgliedern die Aufmerksamkeit und Lernmöglichkeiten stehlen, indem Sie sich die interessantesten Aufgaben aussuchen.

Die Lösung hierfür besteht darin, an kleineren, nicht kritischen Aufgaben zu arbeiten (und dies regelmässig zu tun). Dies hat mehrere positive Auswirkungen: Ihre Fähigkeiten werden nicht nachlassen, und Ihr Team wird sehen, dass Sie sich nicht vor der Arbeit scheuen (was sehr wichtig ist).

Code-Reviews

Neben dem Schreiben von Code kann das Lesen des Codes anderer Leute eine weitere gute Möglichkeit sein, „in Form zu bleiben“. Code-Review bedeutet nicht nur, Feedback zur Arbeit anderer zu geben, sondern auch zu lernen, wie andere arbeiten. Durch die Teilnahme an Code-Reviews lernen Sie neue Vorgehensweisen kennen (z. B. verschiedene Ansätze zur Lösung bestimmter Probleme), die Verwendung neuer Sprachfunktionen, Bibliotheken oder Frameworks.

Sie können jedoch auch die Arbeitsgewohnheiten Ihrer Teammitglieder und deren Herangehensweise an die Softwareentwicklung beobachten. Beispielsweise fällt Ihnen vielleicht auf, dass viele Pull-Anfragen umfangreich und komplex sind oder dass Ihre Teammitglieder wiederholt gegen Best Practices oder den Codierungsstil verstossen. Dann können Sie reagieren und gemeinsam mit Ihrem Team einige Anpassungen vornehmen.

Teilnahme an technischen Diskussionen

Es wird viele technische Diskussionen zwischen Ihren Teammitgliedern geben. Sie müssen wahrscheinlich nicht an jeder einzelnen davon teilnehmen, da Sie dafür einfach keine Zeit haben. Ausserdem möchten Sie Ihren Teammitgliedern vertrauen, damit sie viele Probleme selbst lösen können. Es gibt jedoch einige Diskussionen, an denen Sie teilnehmen sollten. Wenn Ihr Team beispielsweise einen neuen Dienst entwirft, grössere architektonische Änderungen vornimmt, versucht, schwerwiegende Leistungsprobleme zu beheben, oder irgendetwas tut, das Auswirkungen auf das gesamte System haben kann, sollten Sie sich beteiligen.

Manchmal müssen Sie vielleicht den Verlauf der Diskussion ändern, wenn das Team zu weit vom Thema abweicht, oder Sie sind die Person mit der grössten Erfahrung in dem jeweiligen Bereich und können sehr hilfreiches Feedback geben. Das Wichtigste ist jedoch, dass Sie beobachten, wie Ihr Team an die Gestaltung herangeht, und sich selbst an diesem Prozess beteiligen. Denken Sie daran, was wir am Anfang dieses Artikels gesagt haben: Sie sollten sich nicht aus dem Prozess der Softwareentwicklung zurückziehen. Technische Diskussionen sind ein wesentlicher Bestandteil dieses Prozesses – ignorieren Sie sie also nicht.

Dokumentation schreiben

Das Schreiben von Dokumentationen ist ein Teil des Softwareentwicklungsprozesses, der aus verschiedenen Gründen oft vernachlässigt wird (in der Regel, weil nicht genug Zeit dafür vorhanden ist). Eine gute Dokumentation kann Ihrem Team jedoch in vielerlei Hinsicht helfen; ebenso kann das Fehlen einer Dokumentation Ihrem Team schaden. Genau hier können Sie als Teamleiter, der mehrere Aufgaben sorgfältig unter einen Hut bringen muss, helfen (und gleichzeitig Ihre technische Denkweise beibehalten).

Da das Verfassen von Dokumentationen schnell ausser Kontrolle geraten kann, wenn Sie nicht vorsichtig sind, sollten Sie versuchen, das absolute Minimum zu ermitteln. Hier ist eine Liste mit Ideen:

• Fügen Sie eine kurze Beschreibung jedes Dienstes zu seinem entsprechenden Repository hinzu, zusammen mit einer Liste wichtiger Interaktionen/Anwendungsfälle oder Remote-Systeme, mit denen er kommuniziert.
• Erstellen Sie Handbücher für die Erstellung und Bereitstellung Ihrer Anwendungen (damit jeder im Team dies tun kann). Dokumentieren Sie alle Aktivitäten, die für Ihren Softwareentwicklungszyklus von entscheidender Bedeutung sind. Es gibt Dinge, die jeder im Team wissen sollte – machen Sie diese Dinge also sichtbar.
• Behandeln Sie die wichtigsten Konfigurationseinstellungen für jede Umgebung und geben Sie Anweisungen zum Zugriff auf wichtige Tools/Dienste.
• Erstellen Sie Dokumente, die beschreiben, was im Falle eines Vorfalls zu tun ist (z. B. wie man eine Datenbank aus einem Backup wiederherstellt).

Beim Verfassen der Dokumentation müssen Sie Recherchen durchführen oder mit Personen sprechen, die sich mit dem gewählten Thema auskennen (möglicherweise beides), wodurch Sie mit verschiedenen Arten von technischen Informationen in Berührung kommen.

Recherchieren

Als Teamleiter müssen Sie darauf achten, woran Ihr Team als Nächstes arbeiten wird, und entsprechend planen. Manchmal kann das bedeuten, dass Sie Recherchen durchführen müssen (zum Beispiel, um den besten Ansatz für die Entwicklung einer neuen Funktion zu finden).

Rechercheaufgaben sind einer meiner Lieblingsvorschläge auf dieser Liste. Sie bieten Ihnen das Beste aus beiden Welten. Einerseits arbeiten Sie an etwas Interessantem und nutzen Ihre technischen Fähigkeiten. Andererseits legen Sie auch den Grundstein für etwas, auf das sich Ihr Team bald konzentrieren muss. Sie können viele Formen und Ausprägungen annehmen: verschiedene Quellen lesen, die Integration mit der neuen API untersuchen, eine neue Bibliothek oder ein neues Framework ausprobieren oder einen neuen Dienst entwerfen.

Das bedeutet, dass es viele Möglichkeiten gibt, neue Technologien zu erlernen oder an etwas Interessantem zu arbeiten (das sich stark von den Aufgaben unterscheidet, mit denen sich Ihr Team normalerweise beschäftigt). Ausserdem könnte die Recherche nach ihrer Fertigstellung als guter Ausgangspunkt für eine technische Diskussion mit Ihrem Team dienen.

Beteiligung an der Systemüberwachung

Wenn Sie in einer Umgebung arbeiten, in der es eine Strategie für das Bereitschaftsmanagement gibt, könnte dies eine gute Option sein. Ja, Bereitschaftsdienst kann stressig sein – niemand wird gerne um 3 Uhr morgens wegen Produktionsproblemen geweckt. Das bedeutet auch, dass Sie sich mit den Tools vertraut machen müssen, die für die Überwachung, Protokollierung und Alarmierung verwendet werden. Wenn jedoch von den Ingenieuren in Ihrem Team erwartet wird, dass sie sich an der Bereitschaftsrotation beteiligen, müssen Sie einfach mitmachen, denn nichts zu tun, aber von Ihren Teammitgliedern zu erwarten, dass sie es tun, ist ein Zeichen für sehr schlechte Führung.

Wenn Sie jedoch über die Unannehmlichkeiten hinwegsehen, ist dies eine grossartige Gelegenheit, viel über das System und seine Funktionsweise zu lernen (denn sonst können Sie nicht bei der Lösung von Produktionsproblemen und Ausfällen helfen). Darüber hinaus haben Sie die Möglichkeit, an der Verbesserung der Überwachung, Alarmierung und allgemeinen Systemstabilität zu arbeiten – und Ihr Team wird davon erheblich profitieren. Dieser praxisorientierte Ansatz erfordert (wahrscheinlich), dass Sie sich mit dem Incident Management vertraut machen, was eine wichtige Fähigkeit für jede Führungskraft ist.

Fazit

Beachten Sie, dass Sie diese Liste als eine Liste von Ideen betrachten sollten – nicht als Gesetz, das in Stein gemeisselt oder mit Blut geschrieben ist. Es gibt auch andere Ansätze, die wir hier nicht behandelt haben; wir haben uns nur auf die gängigsten oder wirkungsvollsten konzentriert.

Wenn es darum geht, eine technische Denkweise beizubehalten, ist es wichtig zu verstehen, dass Ihnen mehrere Werkzeuge zur Verfügung stehen. Je nach Ihren Aufgaben und Ihrer verfügbaren Zeit können Sie möglicherweise an allen aufgeführten Aktivitäten teilnehmen, was natürlich grossartig ist. Oftmals wird Ihnen das jedoch nicht möglich sein – stattdessen müssen Sie den Ansatz wählen, der für Sie zu diesem Zeitpunkt am besten geeignet ist. Manchmal schreiben Sie Code, manchmal recherchieren Sie oder nehmen an der Systemüberwachung teil.

Unabhängig davon, wie viele Dinge Sie tun, ist es am wichtigsten, sich daran zu erinnern, dass Sie etwas tun und dabei konsequent sein müssen – denn all diese Dinge tragen zu einem Ziel bei: der Erweiterung Ihrer technischen Kenntnisse und Fähigkeiten.