Becoming a Tech Lead for the first time

I recently spent 3 months as the tech lead of a development team on GOV.UK. This was the first time I had taken on the tech lead role, so I had a lot to learn and, as a frontend developer leading what turned out to be a mostly backend development team, it definitely had its challenges. I’ve tried to condense down everything I learnt during this time, both as a reference point for myself and to hopefully help other new tech leads.

Can a frontend developer be the tech lead of a primarily backend team?

It’s true that you’ll encounter situations more frequently where you don’t have all the information you need to understand or answer questions. I quickly had to learn how to say “I don’t know, but I’ll try and find out” or “I don’t know, but [name] has a lot of experience with this”. And that’s ok. You’re not any less of a tech lead if you direct questions to other people. In fact, you’re empowering them to share their knowledge, debate and make decisions as a team.

The other pain-point is when frontend work comes up, and you’re the only frontend developer in the team. As tech lead, I normally found my Monday and Tuesday were packed with meetings. Once I’d done all the other admin I had to do, I actually only had approximately 2 days free for coding (and that’s if nothing else came up). If you’re the only frontend dev available, this might become a bottleneck. If you can see that frontend work is coming up, make sure you raise this concern - you may be able to get help from another frontend developer. At the very least, when you're planning the work, you need to factor in the extra time it will take. You should also see if other developers in your team are happy to give it a go - if they’re interested in learning, it could be a really great opportunity for them.

No doubt it’s easier for a frontend developer to lead on frontend work! But if you’re willing to take on the challenge, it’s a really rewarding experience - I’ve learnt more over the last 3 months, both technically and in terms of leadership skills, than I have in any other quarter at GDS.

Suggestions for new tech leads

Become comfortable with the idea of not knowing everything

There’s a common misconception that being a tech lead means that you need to have the answer to everything. This fuels the assumption that only senior developers can take on the role and means that other developers miss out on valuable learning opportunities. If we consider the qualities we like to see in our leaders, one comes up more often than not: we want to see that they’re human. Nobody can know the answer to everything and, if all our leaders pretended to, we’d put off new people from trying.

As a tech lead, you want to role-model these qualities and show that it’s perfectly normal to not have all the answers, but as a first time tech lead this can make you feel vulnerable. Here are some approaches to take when you’re asked a question you can’t answer:

• Ask for more time. Some people need more time to think. If this is the case for you, be upfront about it. It can be tempting to blurt out the first answer that comes to mind, but this isn’t always correct and can lead to mis-communication. Instead, try saying something like “I can’t answer that right now, but give me 30 minutes and I’ll get back to you”.

• Share the knowledge. You might not know the answer, but another developer might. If you have the time, sit down with them and work through it together. This way, they’re avoiding becoming the single point of failure by sharing their knowledge, and you get the benefit of having the information for next time.

• Direct them to someone else. While it’s ideal to pair and share knowledge, it’s not always possible for various reasons. It doesn’t make sense to increase your own workload and stress levels when there’s a developer who already has the knowledge and experience to answer the question.

• Buddy up: If you’ve identified a large knowledge gap, first: that’s nothing to be ashamed of! In the case of being a frontend developer leading a backend team, that’s likely (and probably expected) to be the case. You might find it easier to ask one of the developers in the team if they’d be happy to ‘buddy up’, e.g: be on-hand to help with the queries you know you won’t be able to answer. It can sometimes be easier to formally pick someone in this way so other team members know who to go to when you’re not around.

Find your own style

The quarterly cycle at GDS means I’ve had the benefit of experiencing many different styles of tech leadership as I’ve moved between teams. A lot of the work at the beginning is finding your own style. Are there particular features you want to see rolled out? Are you more of a people person, keeping on top of team health? Are you keen to give developers the learning and leadership opportunities they’re seeking? It’s important that a tech lead considers all of these, but the weighting placed on each of them is up to you and what works best for the developers you're working with.

Don’t measure your success on how often you code

As a developer, you’re probably used to judging your level of achievement each day by the lines of code you’ve written and reviewed, the features you’ve successfully implemented, or the number of bugs fixed.

As a tech lead, there will be an adjustment period in un-learning this behaviour. Remember: just because you’re writing less code, doesn’t mean you’re not doing a good job. A tech lead has a lot of ‘behind-the-scenes’ work:

• You will be attending more meetings. A tech lead acts as a bridge between product and development. As a result, you’ll spend more time answering questions, providing clarifications, planning and scoping out work.
• Organising developers and development work. Keeping an eye on team capacity and the status of work. If a piece of work is hanging round for a long time, your help may be needed to unblock it.
• Reviewing and deploying code, particularly for new / junior developers.
• Communicating with other development teams. Making sure others are aware of the changes you're making and vice versa.

Remember: all of the above counts as work! Try not to view it as a ‘distraction’ from coding - as a tech lead, this is all part of your day-to-day now.

Know when to ask for help

Being a tech lead for the first time is challenging and it’s understandable that you may need some guidance. If you feel like you’re struggling, try and identify what you’re struggling with. Perhaps you don’t understand what is expected of you, or your workload is becoming unmanageable? Identifying the problem(s) will give you a better idea of who to talk to about it.

If you don’t understand what is expected of you:

• Talk to the product people in your team. Make it clear that this is the first time you have taken on the role and you need some guidance on what they need from you.
• Talk to the developers in your team. What do they feel like they need from you as a tech lead? What would be most helpful to them? If you know they have leadership experience, try asking for tips.

If your workload is becoming unmanageable:

• Talk to the project or delivery manager. It could be that the team has become so big that you need more than one tech lead to coordinate the developers and/or streams of work.
• Delegate some tasks to another developer who has shown an interest in taking on more leadership responsibilities.

Generally:

• Talk to your colleagues who are or have previously been tech leads. They can share their own experiences, what they’ve learnt in the role, and should be able to give you some advice.
• If you don’t know anyone else who has been a tech lead, try setting up a community for tech leads in your company. Have regular meetings where you discuss what you’ve all learnt. This could be a great forum for getting impartial advice on specific problems.
• Ask for feedback. When you feel like you’re doing a bad job, asking for feedback is probably the last thing you feel like doing. But remember that you’re often your own worst critic! You’re likely to be pleasantly surprised at the feedback you receive, and you can learn from the improvements that people suggest.