How I Balance Writing Code and Leading a Team at the Same Time

Staying technical as a tech lead is not about protecting your identity as a developer — it's about being a credible, useful leader. But doing it well requires real boundaries and deliberate choices.

The Tech Lead Who Stopped Coding

I've seen it happen. A capable developer gets promoted to tech lead. In the first month, they're still writing code. By month three, the meetings have expanded to fill the day, code review takes most of the remaining time, and actual implementation has become something they do on evenings. By month six, they've mostly stopped.

This is sometimes the right outcome — some lead roles genuinely require full-time coordination. But often it's not a choice; it's a drift. And the drift has real costs: the lead loses their sense of what the codebase actually looks like to work in, loses credibility with the team, and becomes a manager who talks about engineering instead of practicing it.

Why Staying Technical Matters

The most important reason isn't about status or identity. It's about information quality.

A tech lead who codes understands the real cost of decisions. When you say "this should be straightforward," you know from recent experience what "straightforward" actually means in this codebase. When you estimate effort, your estimate is grounded. When you're in an architectural discussion, your opinions about what's feasible and what's expensive are calibrated against reality.

A tech lead who doesn't code is making decisions based on increasingly stale intuitions. That gap between mental model and reality tends to show up in bad directions: underestimating complexity, overcommitting the team, designing systems that look clean on a diagram but are painful to implement.

Staying technical is a form of staying honest.

What I Actually Take On

The mistake I see tech leads make when trying to stay technical: taking on work that has hard deadlines or sits on the critical path.

If the team is blocked on something I'm implementing, I've made myself a bottleneck. My availability is less predictable than a developer's because my schedule fills with things I can't always control — urgent stakeholder conversations, impromptu decisions, someone needing to talk through a problem.

I deliberately choose work that:

• Is not blocking anyone else
• Can be interrupted and resumed without major cost
• I can hand off cleanly if something urgent comes up
• Gives me useful exposure to areas of the codebase I don't see in code review

This often looks like: exploratory technical investigations, internal tooling improvements, documentation with real code in it, or picking up a well-scoped low-priority ticket that's been sitting in the backlog.

Protect the Time Actually

The good intention without the structural protection is meaningless. I block time for coding on my calendar, the same way I block time for one-on-ones or planning sessions. Unblocked time fills with meetings by default in most engineering organizations.

The block doesn't have to be large — two to three hours twice a week can be enough to stay connected. The key is protecting it from the accumulation of thirty-minute requests that individually feel reasonable and collectively consume everything.

I communicate this to the people I work with: "I have deep work blocked from 9–12 on Tuesdays and Thursdays — for non-urgent things, after noon works better." Most people respect this. The ones who don't usually have genuinely urgent things.

Know When the Balance Needs to Shift

There are phases in a project where leadership demands outweigh technical contribution. A difficult planning cycle, an organizational change, an incident that requires sustained stakeholder management — these eat the calendar, and trying to hold on to coding time during them often means doing both things poorly.

The mistake is letting a temporary shift become permanent. I re-evaluate every few months: am I still writing code in a meaningful sense, or am I doing enough to tell myself I am while the reality is that I've mostly transitioned to management?

If the honest answer is the latter, that's worth examining deliberately. Maybe it's the right direction. Maybe the role has changed and the title should reflect that. Maybe the team has grown to the point where there's a real management need. But it should be a choice, not a drift.

The Benefit to the Team

A tech lead who stays technical has one advantage that's easy to underestimate: they model what engaged, practical engineering looks like.

When the lead is in the code, making choices, running into problems, updating their understanding — the team sees that this is something worth continuing to do at any level. That technical craft doesn't get abandoned as you get more senior; it evolves.

A lead who's fully out of the code sends a different implicit signal: that coding is something you graduate from. That leadership means leaving the actual work behind. In teams trying to maintain a culture of technical excellence, that signal is quietly corrosive.

The goal isn't to be both a full-time developer and a full-time lead — it's to stay close enough to the work that you're leading from inside it, not above it.