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:

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:

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.

Engineering leader at Bloomberg. All opinions are my own.