Remaining Technical as an Engineering Leader

Remaining technical is essential

Let’s begin by acknowledging that engineering leadership is a technical role. You are responsible for supporting software engineers who do technical work, for helping to shape the team’s technical vision, and for making strategic technical decisions. To remain credible and viable as an engineering leader it is essential that you remain technical.

  • 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?

For many, remaining technical is synonymous with continuing to write code, and indeed, writing code does help, but the key choice is now what code to write. When you move from a maker’s schedule to a manager’s schedule, the large blocks of time required for deep work, like writing code, become harder to find. Furthermore, when they do appear, the chance of being interrupted remains high. As such, it is generally not possible — nor advisable — to commit to delivering work that is on the critical path of your team’s projects. Attempting to play the roles of software engineer and team leader simultaneously is a recipe for overwork and burnout. The dilemma then is working out how to remain technical as your opportunities for coding become increasingly limited, and the range of coding tasks realistically available to you is narrower compared to when you were in a software engineering role.

Photo by Chris Ried on Unsplash

Remaining technical away from the critical path

Writing code is one of the ways to remain technical, but is not (and shouldn’t be) the only way. Here are some activities available to you that help you remain technical:

  • 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.

Other factors to consider

What does the team need?
If you’re leading a very small team, or there’s a deadline fast-approaching that requires all hands on deck, your ability to contribute technically and write code might not just be valued, but be required. It’s important to ask yourself: what does the team need from me — is coding the best way I can support my team at the moment? Sometimes the answer can be, yes.

--

--

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
Mark Wood

Mark Wood

Engineering leader at Bloomberg. All opinions are my own.