Leading a Team Without Losing Touch With the Code

Somewhere between managing two engineers and managing ten, I stopped being able to review every pull request and still ship anything myself. That transition is uncomfortable if you got into leadership because you liked building things, and nobody warns you it's coming until you're already underwater on both fronts.

Here's what's actually worked for me, running a team of 7-10 engineers while staying close enough to the codebase to make real architecture calls — not just approve other people's.

Pick one or two systems to stay hands-on in

I can't be deep in every part of the platform anymore, and pretending otherwise just means I'm shallow everywhere. Instead, I stay genuinely hands-on in the parts of the system where bad decisions are expensive to reverse — our GraphQL schema and the multi-tenant data layer, in our case. I write code there, not just review it. Everywhere else, I trust the team and show up in design discussions instead of diffs.

Use code review as a leadership tool, not a gate

Early on, I treated review as quality control: catch the bug, approve, move on. It's more useful as a teaching and alignment tool. If I leave the same comment on three different PRs from three different engineers, that's not three code problems — it's one documentation problem, and the fix is a shared convention or a linter rule, not more comments.

Protect deep work — including your own

A team of this size generates a constant stream of Slack questions, unblocking requests, and "got a minute?" meetings. Left unmanaged, that fills 100% of a lead's day and 0% of it is architecture work. I block recurring focus time on my calendar the same way I'd protect it for a senior engineer, and I've had to get comfortable saying "let's take this async" more often than feels natural.

Delegate the decision, not just the task

The failure mode I see most in new leads is delegating tasks while keeping every decision. That doesn't scale, and it stunts the people you're delegating to. When I hand off a feature, I try to hand off the tradeoff along with it — "here's the constraint, here's what I'd optimize for, you own the how." It's slower the first few times. It's the only thing that actually reduces my load over time.

The honest tradeoff

I'm not going to pretend this is fully solved. I ship meaningfully less code than I did four years ago, and some days that itch doesn't go away. What's changed is where the leverage is — a good architecture decision or a well-run 1:1 now moves the platform further than an extra pull request from me would. That's the trade you're making when you take on a team, and it's worth being honest with yourself about it before you're three engineers deep and wondering where your afternoons went.