Why I Still Write Code as a Technical Leader (And Why You Should Too)

The Meeting Trap Is Real

There's a pattern I've watched play out multiple times. A strong developer gets promoted to tech lead or engineering manager. Suddenly their calendar fills up with standups, planning sessions, one-on-ones, stakeholder updates, roadmap reviews. Within six months, they haven't written a single line of production code. Within a year, they can't meaningfully review a pull request anymore.

They've become a meeting machine. And the worst part? They often don't realize it's happening until it's too late.

I made a conscious decision early on that this wasn't going to be me.

Why Coding Keeps You Grounded

When I'm reviewing architecture decisions with my team, I need to know what's actually feasible. Not theoretically feasible. Actually feasible, given our codebase, our dependencies, our deployment setup, and our timeline.

The only way to have that knowledge is to stay in the code.

Last month, a developer on my team proposed migrating our authentication system to a new library. On paper, it looked like a two-day task. Because I'd been working in that part of the codebase recently, I knew about three edge cases that would turn it into a two-week task. We scoped it properly, planned for the edge cases, and it went smoothly. If I'd been disconnected from the code, I would have approved the two-day estimate, and we would have blown the sprint.

This happens constantly. Small technical details that completely change the calculus of a decision. You only catch them if you're close enough to the code to see them.

Earning Respect Through Execution

I'll be blunt about this. Engineers don't respect leaders who can't do the work. They just don't. You can have all the right management frameworks, run perfect standups, and give great feedback in one-on-ones. But if your team knows you couldn't ship a feature yourself, there's a ceiling on their trust.

When I jump in to help debug a production issue at 11pm, that builds more credibility than any amount of process improvement. When I write a clean, well-tested implementation of a tricky feature, my code review feedback carries more weight because the team knows I'm not just theorizing.

This isn't about ego. It's about effectiveness. A technical leader who codes has more influence over technical outcomes. Period.

Knowing When to Code and When to Lead

That said, I'm not arguing that tech leads should be the top contributor on every sprint. That would be a different kind of failure. If you're doing all the coding yourself, you're not growing your team.

Here's how I think about it:

• Code when it's high-risk or high-ambiguity. New integrations, unfamiliar APIs, security-sensitive features. These are where my experience adds the most value as an individual contributor.
• Delegate when it's a growth opportunity. If a junior developer could learn from building a feature, let them build it. Review carefully, provide guidance, but let them do the work.
• Never code what someone else could code better. I have team members who are stronger than me in specific areas. Frontend performance, for example. I'm not going to write that code just to prove I can. That's insecurity, not leadership.
• Protect your coding time. I block out Tuesday and Wednesday mornings for deep technical work. No meetings. No Slack. Just code. If I don't protect this time, it evaporates.

My Actual Weekly Balance

Here's roughly how my time breaks down:

• 30% coding. Writing production features, building prototypes, doing code reviews. This is non-negotiable.
• 25% technical planning. Architecture discussions, sprint planning, backlog grooming. Making sure we're building the right things the right way.
• 20% people management. One-on-ones, mentoring, hiring conversations, performance feedback.
• 15% client and stakeholder communication. Requirement discussions, demos, status updates.
• 10% operational work. Deployments, monitoring, incident response, documentation.

Some weeks skew heavily toward one category. During a production incident, coding might be 60% of my week. During planning for a new project, client communication might dominate. But over a month, these percentages hold pretty steady.

The Skills That Transfer Both Ways

Here's something people miss: coding and leading aren't separate skills that compete for time. They reinforce each other.

Writing code makes me a better leader. I understand my team's challenges because I face the same challenges. I can estimate timelines accurately. I can spot when someone is stuck before they tell me, because I recognize the patterns.

Leading makes me a better coder. Managing multiple workstreams taught me to write simpler, more maintainable code because I know someone else will need to understand it. Client conversations gave me a stronger sense of what actually matters in a product, so I make better technical tradeoffs.

The Uncomfortable Truth

Some organizations want their engineering managers to stop coding entirely. "Focus on the people," they say. "Your job is to remove blockers, not write code."

I understand that philosophy. I just disagree with it.

The best technical leaders I've worked with all share one trait: they can still build. They might not be writing code 8 hours a day, but they're dangerous enough to ship something real when it matters. They can prototype an idea in an afternoon. They can diagnose a production issue without waiting for someone else to look at it.

That's the kind of leader I want to be, and the kind I'd want to work for. Stay technical. Your team will thank you.