Published 5th April 2019
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.
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.
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.
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.
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:
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.
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:
If your workload is becoming unmanageable: