Dec 4, 2020
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
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.
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?
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.
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.
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 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.
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.
