Remaining Technical as an Engineering Leader

The question “how technically hands-on should I be as a team leader?” comes up frequently in my conversations with engineering leads. The short answer is: “definitely to some extent”, but for a more specific answer we need to consider context, your individual team makeup, and your goals as a leader.

Remaining technical is essential

Remaining technical means maintaining:

  • A sufficient depth of understanding of the systems your team owns
  • The ability to discuss technical concepts fluently
  • Sound technical judgement to be able to reason about trade-offs, and make good decisions

Should I be writing code?

Photo by Chris Ried on Unsplash

Remaining technical away from the critical path

  • Read code reviews — set time aside to read the code reviews your team is producing. This helps you maintain awareness of the areas of the code that are changing, spot technical debt, and keep an eye on quality by reviewing tests and reviewer comments. Note that I say read code reviews, rather than participate in code reviews — it’s not that you should never participate, but be aware that being a required reviewer makes you a bottleneck. Left unchecked, I’ve seen this result in all code reviews needing sign-off from the team lead, which can really slow the team down.
  • Participate in design discussions — understand how your systems are changing, ask thoughtful questions to help highlight trade-offs, and help guide the team to make sound technical decisions.
  • Read post-mortems — learn from the challenges other teams have faced, and bring this knowledge back to your team.
  • Invest in automation — look for opportunities to automate part of your team’s workflow. This type of work requires you to first understand the processes you have in place, forcing you to get closer to the day-to-day experience of the engineers of your team. It also typically involves writing some code, maybe a short script.
  • Investigate new technologies — the implementation languages and technologies that we use change over time. For example, your team might be thinking about trying out Docker for local builds, or planning to use Kafka in a future project. Take some time to follow tutorials, and build a working example that you can continue to hack on. This will help you develop a basic understanding of the concepts and terminology of the new domain, and give you a starting point to explore from in the future.
  • Pick up well-defined, well-scoped, lower-priority bug fixes or small features from your team’s backlog — the value of the bug or feature here is inherently low, but that’s not the point. These tasks give you a chance to use the same tools and processes as the team, to experience any pain points or friction first-hand, and to role-model high quality, well-tested pull-requests. It’s important to make it clear to the team why you’re picking up items like this, rather than something of higher priority from the top of the backlog.
  • Try pair programming, favouring the observer role — this is a great way to learn from your team, and means that you can leave at short notice if required.
  • Consume technical content — stay up to date with what is happening in the industry, read articles, watch videos, and attend meetups. Consuming is not the same as producing, but it helps keep your brain in a technical space, and encourages continuous learning.
  • Participate in recruitment — conducting interviews in which you ask technical questions, and assess the code of others, helps to keep your knowledge of computer science fundamentals fresh, and practice thinking algorithmically.

Some people might also suggest adding ‘Code in your personal time’ to this list. My view is that by all means do this if it’s something you enjoy and want to do, but don’t feel pressured, or force yourself to do it because of your role. It’s already too easy to take your work home with you as an engineering leader — I don’t recommend adding to this.

A common follow-up question after discussing the suggestions above is, “But won’t my coding abilities suffer if I’m not writing any serious, substantial code like I used to?”. The reality is yes, they likely will degrade to some degree — and that’s okay. You are no longer being valued primarily for your technical contributions as a software engineer — your role is now to support the team doing the work. If you choose to pendulum back into a more hands-on software engineering role in the future, it will take you some time to ramp up, but that is to be expected. It’s not realistic to think that, at any moment, someone could switch back to performing their previous job as well as they have ever done, having not done it for some time.

Other factors to consider

What does your manager/department/organisation expect and value?Expectations of how technical leaders should be can vary between organisations, departments, and even individual managers. Subcultures exist, and it’s important to be aware of them. It’s essential that you have a conversation with your manager to ensure you are aligned on these expectations.

To be successful in an engineering leadership role it’s important to remain technical. This can seem daunting given your schedule, and the need to be available and responsive to those you support. Fortunately, there are a number of ways of remaining technical that don’t require long periods of uninterrupted work. By taking on a mix of these activities, you can remain technical without blocking your team.

The hard part of all of this is striking the right balance of how you spend your time — being responsive to the needs of the team, while also remaining sufficiently technical to be effective. Sometimes these aspects will be in harmony, other times not. Sure, you can take that half-day to fix that long-standing bug that has been annoying you, but isn’t it more important to have that difficult feedback conversation you’ve been putting off? We’ve all been there. We know what we should do. Being a leader means making difficult decisions and prioritising the needs of the team over your own, but when you get the balance right, watching your team flourish is worth it.

Thanks to Melanie Harries for reading drafts of this.



Engineering leader at Bloomberg. All opinions are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store