Tech leads can find it easy to fall into the trap of becoming too much of a manager, always worried about the process or attending meetings and never actually cutting code.

A recent article by Eliot Horowitz, the cofounder of MongoDB, argued that tech leads should code 30% of their time. It’s worth reading the article as Eliot has some helpful strategies for tech leads and engineering managers to boost their time spent coding.

Don’t go overboard

However, it’s often an easy trap to end up at the other end of the scale, as a team lead or an engineering manager who spends all their time coding, and very little of their time as a manager or leader.

This is particularly easy for early-hire developers who used to write large parts of the code base - as the team or the company grew, suddenly they had a promotion and found themselves a team lead or a manager. But even with these new responsibilities, the temptation is too great to just spend a lot of time in the ‘I’m only coding’ end of the scale.

Anti-patterns that you might be falling into are:

• dismissing your team’s opinions only to come back with a solution you just bashed out because you know the code-base better
• always picking up development stories to help the team ship more code
• writing code on weekends or at night
• blowing off meetings to just hack on stuff
• you’re the biggest committer in the code base
• you’re the only one in the team who understands large parts of the code base
• you’re not willing to try a different process because you can ship code faster than changing the process
• new projects usually start with you - you write the majority of the code, then bring on other members for maintenance or scaling

The danger here is that you’re not actually leading and shaping the team. You’re not actually leading the team, you’re just another developer. Consider some of the reasons that you’ve been tapped to become the lead:

• it gives you a chance to teach your team members
• it gives you time to consider architectural changes and implications of code changes
• it removes you as a blocker for new code/projects/refactors
• it gives your team members a chance to learn for themselves
• it increases the number of experts on the team (sharing your knowledge and experience is one of the most powerful things you can do as a leader)
• it allows your engineering team to bounce their ideas off you

Find a healthy balance - maybe it’s 1.5 days coding and 3.5 days coaching and leading. The ratio can change over time as well - as the team gets more experienced, things might change.

But the primary reason that you were hired/promoted for this role is to lead and teach the team. If it’s too hard to be a capital L leader, then be a coach.

Don’t drive and just write code yourself, but help out your team members. Pair with them and watch the code that they’re writing. Review the last architectural change that happened to your system and think about how it was handled. Is there something you can learn? Is there something you should be teaching the team?

As bad as it is to just be a manager, it’s just as bad to only be a developer. Great tech leads get the balance right.