Leading a team without losing your hands

The cliché is that when you become a lead you stop coding. I disagreed with that when I took the role, and two years in I still do. But the way I code changed completely — and figuring out how it changed was the actual work.

Code the thin slices

I don't pick up feature tickets anymore. I pick up the scaffolding: a new auth module, the first version of a background job runner, the service that glues two teams' work together. These are the places where a bad pattern costs a year of cleanup.

The rule I follow: any piece of code that five other engineers will copy in the next month is mine to write. Whatever I write becomes the template, and templates compound. If I write it correctly — clean interfaces, sensible error handling, a test that demonstrates intent — the team absorbs that standard without a policy meeting.

Reviews are a teaching surface

Every PR I review is a chance to explain a decision in writing. I try to keep comments short and link to the reasoning, not just the fix. "Extract this into a service" is less useful than "extract this into a service — logic in controllers becomes hard to test and impossible to reuse when the second caller arrives."

I have one rule: if I leave the same comment for the third time, I write a short internal doc instead and link to it from the review. That converts a repeated correction into a durable standard. Three months in, I'm not the one catching it anymore.

1:1s that actually do something

Most 1:1s are status updates in disguise. The engineer talks about what they finished and what's next. The lead nods. Thirty minutes gone. I stopped running status-update 1:1s after the first quarter — I get that from stand-up and the ticket board.

What I ask instead: what's the one thing slowing you down that I could fix today? What are you not learning that you want to be learning? Is there anything in the codebase you'd be embarrassed to show an outsider? That last question is worth the whole meeting. Engineers know where the skeletons are. They rarely get asked.

Delegation without abandonment

The failure mode I see most in new leads is the pendulum: they either hold everything (can't let go) or drop everything on the team without context (disappeared into meetings). Both feel bad to the team, for opposite reasons.

My version of healthy delegation has three parts: clear outcome, clear constraints, and a defined check-in point. "Build the export feature. It needs to handle 100K rows without timing out. Show me a design doc by Thursday before you write code." The engineer owns the problem. I own the context and the unblock.

• Outcome, not process: define what done looks like, not how to get there.
• Constraints up front: performance requirements, timeline, API compatibility — things the engineer will hit mid-implementation if not told early.
• One check-in before the halfway point: catch mis-direction before it becomes sunk cost.
• Don't re-delegate your feedback: if you told the engineer to build it, review their design yourself.

Keeping your own technical depth

This is the one most leads lose without noticing. You stop writing code, then you stop reading code closely, then your architecture opinions become increasingly detached from what the codebase actually is. Six months later you're making decisions based on what you remember, not what exists.

I protect three things: I read every non-trivial PR, even the ones I'm not formally reviewing. I write the first version of any new service or module. And I keep one small self-contained ticket in every sprint that I ship myself. It takes 4–6 hours a week, but it keeps the signal alive. One concrete thing I shipped during this period while staying out of the feature work was cutting our telehealth API response times by 40% — that's the kind of work that's high leverage and contained enough to not pull you into a feature dependency.

Managing up while shipping down

The lead sits between the team and everyone above it. That means translating in both directions. When I talk to product or exec, I translate technical complexity into business risk: "This refactor isn't optional, it's three months away from being a two-week outage." When I talk to the team, I translate business pressure into focus: "This quarter the one thing that matters is the performance work, not the feature backlog."

Most engineers in lead roles over-explain technical detail upward and under-explain business context downward. The team doesn't need the full OKR deck. They need to know why the order of work matters right now.

When to stop coding entirely

There are two legitimate reasons to step back from the keyboard. One: when you're in a period of high people management load — a hiring push, a performance conversation, a team restructure. Trying to deliver code commitments during a hiring sprint splits your attention in a way that hurts both.

Two: when the codebase has grown to the point where your time has higher leverage in architecture review than in writing. A principal-level engineer whose reviews unblock four engineers delivers more than one who ships one feature themselves.

But I push back on the idea that this is the natural endpoint for all leads. Plenty of senior engineers stay hands-on for their whole career. The right level of coding depends on the team's needs, not an org chart assumption.

FAQ: Engineering leadership

Building a team or stepping into a lead role?

If you're growing an engineering team or moving into a first lead role and want a sounding board — I work with early-stage and scale-up engineering teams on architecture, hiring, and team structure.