Staying Hands-On as a Technical Lead: Why I Still Write Code

When I moved from SDE-II to Technical Lead, the most common advice I got was some version of "step back from the code." I understand where it comes from — a lead who hoards the interesting work starves the team. But stepping back entirely is how technical leaders lose the thing that made them useful: accurate judgment about what the system can and cannot do.

Three years into leading teams, I still write and review production code every week. This is not nostalgia. It's a deliberate operating mode, and it has rules.

Why judgment decays faster than you think

Architecture decisions are only as good as your mental model of the codebase, and that model rots quickly. A lead who hasn't touched the deployment pipeline in six months will confidently estimate a change at two days that actually takes two weeks — because they're estimating against the codebase as it existed when they last worked in it.

Every technical debt conversation, every build-vs-buy call, every "can we ship this by Friday" answer depends on a current model. Reading code keeps the model alive; writing code stress-tests it. When I personally hit the flaky test suite or the slow local setup, I don't need a retro to tell me developer experience is degrading.

What I take, and what I never take

The failure mode of the hands-on lead is well documented: they take the critical-path work, become the bottleneck, and block the team twice — once by being too busy to unblock others, and again by absorbing the work that would have grown someone else. The fix isn't to stop coding. It's to be disciplined about which code you take.

• ▸I take: spikes and proofs-of-concept that de-risk a decision before the team commits to it.
• ▸I take: unglamorous infrastructure work — CI speedups, dependency upgrades, flaky test hunts — that nobody is incentivized to pick up but everyone benefits from.
• ▸I take: the first implementation of a new pattern (a new service template, an auth flow), so the reference example is deliberate rather than accidental.
• ▸I never take: critical-path feature work with a deadline. If I'm the reason a release slips, the model has failed.
• ▸I never take: work that would be a growth opportunity for someone on the team. The interesting migration goes to the engineer who's ready to stretch, with me reviewing.

Code review is the highest-leverage hour of my day

If I could only keep one hands-on activity, it would be review. A thoughtful review teaches the author, keeps my model of the codebase current, and sets standards without a single meeting. I structure reviews in two passes: first pass for design — does this change belong here, does it create a coupling we'll regret — and second pass for correctness. Design feedback delivered after someone has polished the details is demoralizing and expensive, so it comes first, quickly, sometimes on the draft PR.

The goal of a lead's code review is not to catch bugs. It's to transmit judgment — so that next quarter, the review wouldn't have been necessary.

The calendar mechanics

None of this survives contact with a meeting-heavy calendar unless it's defended structurally. What works for me: coding time lives in two protected half-day blocks per week, meetings cluster on the other days, and I treat interruptions to those blocks the way I'd treat interrupting an engineer mid-task — allowed for incidents, not for status. I also stopped measuring my coding contribution in tickets closed. The measure is whether the team ships faster and the architecture holds. Code is the input; those are the outputs.

Takeaways

• ▸Hands-on time is how a lead keeps estimates and architecture calls honest — treat it as a job requirement, not an indulgence.
• ▸Choose work off the critical path: spikes, infrastructure, reference implementations.
• ▸Protect review time above coding time — it compounds across the whole team.
• ▸If you become the bottleneck, you've taken the wrong work, not too much work.