Balancing Coding and Leading

leadership (8) , software-engineering (18) , tech-lead (3)

This post is part of my Tech Lead Series, a collection of practical advice for engineers stepping into leadership roles.

Every new tech lead faces the same question: how much should I code?

Code too much and you’re not leading. You become a bottleneck. Your team doesn’t grow because you’re doing all the interesting work. Code too little and you lose touch. Your technical opinions carry less weight because you don’t understand the daily reality of the codebase any more.

Most tech leads swing between these extremes before finding their balance. One month they haven’t merged a PR in weeks. A few months earlier, they were writing 80% of the team’s code. Neither state works.

There’s no universal answer, but there are principles that help.

Why this is hard

The problem is that both extremes feel productive.

When you’re coding, you’re shipping. You can see the PRs, count the commits, point to the features. It feels like work because it is work. And you’re probably faster than most of your team, so there’s a constant temptation to just do things yourself.

When you’re leading, the output is invisible. A good 1:1 doesn’t show up in Jira. Unblocking someone doesn’t get its own PR. The work that makes teams function doesn’t look like work.

So you default to what’s measurable, which means you keep coding and neglect the leadership work that only you can do.

The right amount of code

There’s no magic percentage. It depends on your team size, their experience level, the complexity of the work, and what else is demanding your time.

But here are some guidelines:

You should write enough code to stay credible. Technical leadership requires technical credibility. If you haven’t touched the codebase in months, your architecture opinions carry less weight. You need to understand the daily reality of working in this system.

You shouldn’t write so much code that you become a bottleneck. If the team waits for your PRs, if you’re on the critical path for every feature, if nothing ships when you’re on holiday, you’re writing too much. Remember: the goal is to make yourself less necessary over time.

You shouldn’t take the most interesting problems. It’s tempting to grab the gnarly technical challenges. But those are growth opportunities for your team. Your job is to give those away, not hoard them.

For most tech leads on teams of 4-8 engineers, something like 30-50% coding time is realistic. Less than that and you lose touch. More than that and you’re not doing the other parts of the job.

What to work on

The type of code matters as much as the amount.

Good tech lead coding looks like:

  • Prototypes and spikes that inform team decisions
  • Infrastructure and tooling that multiplies everyone’s output
  • Pairing with team members on complex problems
  • Code reviews that teach, not just approve
  • Fixing urgent production issues alongside the team

Bad tech lead coding looks like:

  • Taking all the high-profile features
  • Rewriting code your team wrote because you’d do it differently
  • Working on isolated tasks that don’t involve the team
  • Doing easy tickets to feel productive

Aim for coding that makes the team better, not coding that makes you feel busy.

Protecting leadership time

The leadership work is easier to skip because it doesn’t have deadlines. Nobody notices if you cancel a 1:1. The architecture discussion can wait until next week. The coaching conversation you’ve been meaning to have can always happen tomorrow.

But these things compound. Skip enough 1:1s and you lose touch with your team. Delay enough architecture discussions and you end up with a mess. Avoid enough coaching conversations and people stop growing.

Some tactics that help:

  • Block your calendar for leadership work: 1:1s, thinking time, documentation. Treat these blocks as seriously as meetings with stakeholders.

  • Batch your coding. Context switching between code and meetings destroys output for both. Cluster coding time into longer blocks rather than scattered hours.

  • Make commitments visible. If you’ve told someone you’ll review their RFC or pair with them on a problem, put it in the calendar. Invisible commitments get dropped.

  • Audit your week. Every few weeks, look at where your time actually went. Compare it to where you think it should go. The gap is usually larger than you expect.

When the balance shifts

The right ratio isn’t static. It changes based on circumstances.

More coding when:

  • You’re new to the team and need to build context
  • There’s a critical deadline and all hands are needed
  • The team is small and there’s genuinely more work than people
  • You’re prototyping something that needs your specific skills

Less coding when:

  • The team is struggling with direction or morale
  • There are interpersonal issues that need attention
  • You’re onboarding new team members
  • Strategic planning requires your focus
  • You’ve noticed you’re becoming a bottleneck

The balance should flex. The mistake is letting it drift without noticing.

The uncomfortable truth

You will never feel like you’re getting this right.

When you’re coding, you’ll worry you’re neglecting leadership. When you’re leading, you’ll feel guilty about not contributing code. There’s no state where both halves of the job feel satisfied.

This is normal. The discomfort is the job. You’re not trying to eliminate the tension. You’re trying to manage it, to make conscious choices about where your time goes rather than letting it happen to you.

Some weeks you’ll code more. Some weeks you’ll code less. What matters is that you’re choosing based on what the team needs, not what feels comfortable.

Published on .