Es gibt eine Metapher aus dem Mannschaftssport, die ich seit Jahren benutze, um zu beschreiben, wie ich führe: Playing Captain. Der Spieler, der auch die Armbinde trägt. Nicht der Manager in der Kabine, nicht der reine Individual Contributor, der Eckbälle schindet — die Person, die die Linie setzt und sie dann mit dem Team läuft.
Ich weiß, dass “ich benutze eine Sportmetapher” in einem Blog-Post eine mild peinliche Sache ist zuzugeben. Ich steh dazu. Es ist die akkurateste Rahmung, die ich gefunden habe.
Was das wirklich bedeutet
Playing Captain ist eine spezifische Leadership-Haltung. Es ist nicht “ich bin ein Tech Lead, der an manchen Architecture-Meetings teilnimmt.” Es ist nicht “ich bin VP of Engineering und schreibe ein bisschen Code, um relevant zu bleiben.” Es ist etwas, das näher dran ist an: Ich bin noch bedeutsam in der Codebase. Ich treffe Architekturentscheidungen nicht aus einem Dokument auf Armeslänge, sondern aus demselben Callstack, den das Team debuggt. Ich payre, reviewe, schreibe nicht triviale Features und fange Design-Probleme ab, bevor sie zu Migrations- Bedauern werden.
Gleichzeitig mache ich die Lead-Arbeit: die Roadmap formen, Blocker ausräumen, die Engineers um mich herum wachsen lassen, die cross-Team-Gespräche führen.
Das Ziel — und das klingt idealistisch, aber ich habe es funktionieren sehen — ist, dass das Team autonom ausführen kann, weil die Architektur sauber und gut kommuniziert ist, nicht weil ich in jedem Meeting bin und Entscheidungen genehmige. Playing Captain ist, wie man beide Failure-Modes vermeidet: den abwesenden Tech Lead, der nicht weiß, warum der Service langsam ist, und den hands-on Engineer, der niemand anderen eine Entscheidung treffen lässt.
Wie das bei 12 Leuten vs. 3 aussieht
Bei AFAQ war ich CTO eines 12-köpfigen Teams. Klein genug, dass ich Produktionscode unter Deadline schrieb, groß genug, dass ich Leute vor Komplexität schützen musste, Roadmap besitzen musste und einem Board gegenüber Meinungen haben musste, über die ich Updates liefern musste. Playing Captain in dieser Größe bedeutet: du bist in den meisten Räumen wirklich die seniorste technische Stimme, und du nutzt das, um schnell voranzukommen — du triffst den harten Call beim Datenbankschema, weil auf Konsens zu warten langsamer ist als gelegentlich falsch zu liegen und es zu fixen.
Bei Bytro war ich Lead Developer bei einem Multi-Squad-Modernisierungs-Effort. Andere Textur. Das Team hatte bereits Senior Engineers; meine Aufgabe war nicht, der schnellste Coder zu sein, sondern die Architekturvision über Squads hinweg zu besitzen, die parallel bewegten und sonst vier inkompatible Abstraktionen für dasselbe Domain-Konzept erstellt hätten. Ich blieb im Code, damit ich wusste, welche Abstraktionen hielten und welche kurz vor dem Kollabieren waren. Das kann man nicht von einem Confluence-Dokument aus tun.
Bei auxmoney hatte die Credit-Assessment-Plattform genug Komplexität — und genug Velocity — dass hands-on sein keine Nostalgie für Individual Contribution war, sondern der einzige Weg, nützliche technische Guidance geben zu können. Man riecht ein Latency-Problem an der falschen Schicht, wenn man denselben Request-Pfad verfolgt hat, den das Team verfolgt. Man riecht es nicht von einem Jira-Board aus.
Das Gegenargument, stahlgepanzert
“Engineering Manager sollten aufhören zu coden” ist echter Rat, von echten Leuten, die echten Schaden gesehen haben. Ich habe das Muster gesehen, das er beschreibt: der Senior Engineer, der befördert wurde und jetzt jedes Design-Review blockiert, weil er sich immer noch als bester Coder im Raum sieht. Der die interessanten Tickets nimmt. Der jeden Code-Review zu seinen ästhetischen Präferenzen macht, und niemand fühlt sich für die Codebase verantwortlich außer ihm.
Das ist nicht Playing Captain. Das ist Playing Captain schlecht.
Der Failure-Mode ist real. Das Heilmittel ist nicht, aufzuhören zu coden; das Heilmittel ist, im Dienst des Teams zu coden. Das beängstigende Ticket nehmen, das alle meiden, weil der Blast-Radius groß ist — nicht das spaßige, weil man etwas shippen will. Architektonisch reviewen, nicht stilistisch. Pairen, um Wissen zu transferieren, nicht um sich beim Helfen zuzuschauen.
Der “hör auf zu coden”-Rat ist auch auf eine spezifische Team-Form abgestimmt — normalerweise eine große Org, in der dein Leverage People-Density, Prozess und Delegation-Chains sind. Bei 5–15 Engineers, besonders in einem Startup oder einem Modernisierungs-Projekt, ist das die falsche Form. Du optimierst nicht für Prozess; du optimierst für architektonische Kohärenz und Velocity. Technische Glaubwürdigkeit ist kein Nice-to-have für einen Playing Captain — es ist das gesamte Fundament.
Wann Playing Captain die falsche Entscheidung ist
Ich habe lange genug als Playing Captain gehandelt, um zu wissen, wann es falsch ist.
Wenn du bei 80 Engineers und wachsend bist, beginnt Playing Captain schlecht zu compoundieren. Das Team braucht dich ganztags in den cross-funktionalen Räumen; jede Stunde im Code-Review ist eine Stunde nicht bei den organisatorischen Problemen, die schneller compoundieren als technische. Du hast Leute, die die Architekturvision halten können — vielleicht brauchen sie mehr Richtungssetzung von dir, keine weiteren Pair-Programming-Sessions.
Es ist auch falsch, wenn du es nutzt, um die Teile der Führung zu vermeiden, die du unangenehm findest. Ich habe mich dabei ertappt, nach einem harten technischen Problem zu greifen als Verdrängungsaktivität, wenn es ein Performance-Gespräch gab, das ich vor mir herschob. Das ist kein Playing Captain. Das ist Code als Kuscheldecke benutzen. Der Captain muss trotzdem die harte zwischenmenschliche Arbeit tun; der Code ist keine Entschuldigung.
Was es richtig macht
Was Playing Captain richtig macht, ist die Feedback-Loop. Wenn du in der Codebase bist, weißt du, wenn die Architektur driftet, bevor das Team es dir sagt. Du weißt, welcher Engineer zu viel Komplexität im Kopf trägt, weil du die PRs gesehen hast, die er rausgibt. Du weißt, wenn eine Service-Grenze falsch ist, weil du auf beiden Seiten der Abstraktion warst.
Management-only-Tech-Leadership hat ein Latency-Problem. Du bekommst Informationen gefiltert durch Meetings, Retros und Leute, die (korrekt) nicht jede Kleinigkeit zu dir bringen wollen. Wenn etwas als Problem oberflächt, war es schon Wochen lang ein Problem.
Playing Captain komprimiert diese Latency. Das Feedback aus dem Code erreicht dich schnell, weil du den Code liest. Du kannst früh korrigieren, was bedeutet, dass du nicht dramatisch korrigieren musst.
Ich habe das über vier Unternehmen, drei verschiedene Tech-Stacks und Team-Größen von 4 bis 30 praktiziert. Es ist keine universelle Theorie der Tech-Leadership. Es ist die Theorie, die für mich funktioniert hat, und die Form der Teams, bei denen ich am nützlichsten war. Die Armbinde kommt mit Verantwortung. Die Stiefel bleiben an.