Player-coach: leading a team without leaving the codebase

When I started leading delivery on high-visibility client platforms, the well-meaning advice was to “get out of the code.” I never fully did, and I think that made me a better lead, not a worse one. The trick is being deliberate about which keystrokes are yours.

Spend your keystrokes on the seams

The most useful code a lead writes is rarely a feature. It is the shared scaffolding: the base block, the data contract, the reusable component that decides how everyone else will build for the next three months. Get those right and half your future code reviews never need to happen.

So I write the seams and hand out the surfaces. I own the shape; the team owns the volume.

Review to teach, not to gatekeep

A review that only says “change this” trains people to wait for you. A review that says why trains them to not need you. I try to leave the reasoning, not just the verdict: “this’ll double-query on big pages, here’s the pattern that won’t”, so the next PR already has the fix baked in.

The goal is a team that gets more independent every sprint, not one that routes everything through my name.

Translate up so the team can build down

Half of leading was never technical: it was sitting in stakeholder meetings and turning “the program wants X” into scoped, buildable work before it reached anyone’s sprint. A developer handed a clear, de-risked task ships fast. A developer handed a vague ask ships the wrong thing twice.

Staying in the code is what made those translations honest, because I was estimating work I actually understood, because I was still doing some of it.

That is the whole balance: build the seams, review to teach, translate the ambiguity. You can lead a team and still be an engineer. I would argue you have to be.