Wie hands-on bleibst du als Führungskraft?

Bleib technisch genug, um gute Entscheidungen zu treffen und Designs glaubwürdig zu reviewen, ohne dich selbst auf den kritischen Pfad zu setzen. In der Praxis heißt das Pull Requests lesen, an Design Reviews teilnehmen, gelegentlich kleine nicht dringende Arbeit übernehmen und in Incidents als Koordinator statt als Held dazuzustoßen. Die Teamgröße bestimmt das Maß: Bei fünf Direktberichten kannst du ein bisschen coden, bei fünfzehn solltest du es nicht.

Meine Regel ist, dass ich technisch genug bleibe, um eine Meinung zu haben, und nie Arbeit übernehme, die jemanden blockiert. Also lese ich an den meisten Tagen Pull Requests, bin in Design Reviews aktiv und nehme Dinge, die wirklich nicht dringend sind: Tooling, ein flaky Test, Dokumentation, Arbeit, die eine Woche liegen bleiben kann, wenn mein Kalender explodiert. Was ich nicht mache, ist ein Feature auf dem kritischen Pfad zu übernehmen, denn die Woche, die schiefgeht, ist immer die Woche mit drei Interviews und einem Reorg-Gespräch, und dann bin ich der Flaschenhals und habe meinem Team obendrein beigebracht, meinen Zusagen nicht zu trauen. Mit sechs Direktberichten schreibe ich vermutlich ein paar Stunden pro Woche Code. Als ich eine Gruppe von sechzehn Leuten über zwei Teams geführt habe, habe ich fast keinen geschrieben und bin stattdessen über Designdokumente und Incident Reviews scharf geblieben. In Incidents komme ich als Koordinator und Schutzschild dazu, nicht als tippende Person, denn das ist der schnellste Weg, die eigentlichen Experten auf mich warten zu lassen.