There’s a metaphor from team sports that I’ve been using for years to describe how I lead: Playing Captain. The player who also wears the armband. Not the manager in the dugout, not the pure individual contributor grinding corners — the person who sets the line and then runs it with the team.
I’m aware that “I use a sports metaphor” is a mildly embarrassing thing to confess in a blog post. I’m owning it. It’s the most accurate framing I’ve found.
What it actually means
Playing Captain is a specific leadership posture. It’s not “I’m a tech lead who attends some architecture meetings.” It’s not “I’m a VP of Engineering who writes a little code to stay relevant.” It’s something closer to: I am still meaningfully in the codebase. I’m making architectural decisions not from a doc at arm’s length but from the same callstack the team is debugging. I’m pairing, reviewing, writing non-trivial features, and catching design problems before they become migration regrets.
At the same time, I’m doing the lead work: shaping the roadmap, clearing blockers, growing the engineers around me, running the cross-team conversations.
The goal — and this is the part that sounds idealistic but I’ve seen it work — is that the team can execute autonomously because the architecture is clean and well-communicated, not because I’m in every meeting approving decisions. Playing Captain is how you avoid both failure modes: the absentee tech lead who doesn’t know why the service is slow, and the hands-on engineer who won’t let anyone else make a call.
What this looks like at 12 people vs. 3
At AFAQ I was CTO of a 12-person team. That’s small enough that I was writing production code on a deadline, large enough that I had people to protect from complexity, roadmap to own, and a board that wanted updates I had to have opinions about. Playing Captain at that size means you’re genuinely the most senior technical voice in most rooms, and you use that to go fast — you make the hard call on the database schema because waiting for consensus is slower than being occasionally wrong and fixing it.
At Bytro I was Lead Developer on a multi-squad modernisation effort. Different texture. The team already had senior engineers; my job wasn’t to be the fastest coder, it was to own the architectural vision across squads that were moving in parallel and could otherwise create four incompatible abstractions for the same domain concept. I stayed in the code so I knew which abstractions were holding and which were about to collapse. You can’t do that from a Confluence doc.
At auxmoney the credit-assessment platform had enough complexity — and enough velocity — that being hands-on wasn’t nostalgia for individual contribution, it was the only way I could give useful technical guidance. You can smell a latency problem at the wrong layer when you’ve been tracing the same request path the team is tracing. You cannot smell it from a Jira board.
The counter-argument, steelmanned
“Engineering managers should stop coding” is real advice, from real people who’ve seen real damage. I’ve seen the pattern it’s describing: the senior engineer who got promoted and now blocks every design review because they still think of themselves as the best coder in the room. Who takes the interesting tickets. Who makes every code review about their aesthetic preferences and nobody feels ownership of the codebase except them.
That’s not Playing Captain. That’s Playing Captain badly.
The failure mode is real. The cure isn’t to stop coding; the cure is to code in service of the team. Pull the scary ticket that everyone’s avoiding because the blast radius is large, not the fun ticket because you want to ship something. Review architecturally, not stylistically. Pair to transfer knowledge, not to watch yourself be helpful.
The “stop coding” advice is also tuned for a specific team shape — usually a large org where your leverage is people-density, process, and delegation chains. At 5-15 engineers, especially in a startup or a modernisation project, that’s the wrong shape. You’re not optimising for process; you’re optimising for architectural coherence and velocity. Technical credibility isn’t a nice-to-have for a Playing Captain — it’s the entire foundation.
When Playing Captain is the wrong call
I’ve been a Playing Captain long enough to know when it’s wrong.
If you’re at 80 engineers and growing, Playing Captain starts to compound badly. The team needs you in the cross-functional rooms full time; every hour in a code review is an hour not spent on the organisational problems that compound faster than technical ones. You have people who can hold the architectural vision — maybe they need more direction-setting from you, not more pair-programming sessions.
It’s also wrong if you’re using it to avoid the parts of leadership you find uncomfortable. I’ve caught myself reaching for a hard technical problem as a displacement activity when there was a performance conversation I was dragging my feet on. That’s not Playing Captain. That’s using code as a comfort blanket. The captain still has to do the hard interpersonal work; the code isn’t an excuse.
The thing it gets right
What Playing Captain gets right is the feedback loop. When you’re in the codebase, you know when the architecture is drifting before the team tells you. You know which engineer is carrying too much complexity in their head because you’ve seen the PR they’re putting out. You know when a service boundary is wrong because you’ve been on both sides of the abstraction.
Management-only tech leadership has a latency problem. You’re getting information filtered through meetings, retros, and people who (correctly) don’t want to bring you every small thing. By the time something surfaces as a problem, it’s been a problem for weeks.
Playing Captain compresses that latency. The feedback from the code reaches you fast because you’re reading the code. You can course-correct early, which means you don’t have to course-correct dramatically.
I’ve practiced this across four companies, three different tech stacks, and team sizes from 4 to 30. It’s not a universal theory of tech leadership. It’s the theory that’s worked for me, and the shape of teams I’ve been most useful on. The armband comes with responsibility. The boots stay on.