5 Things No One Told Me Before I Became A Tech Lead

Interested in joining us?

Check out our current vacancies
5 Things No One Told Me Before I Became A Tech Lead featured image

At Rightmove each of our dev teams has a Technical Lead. Their responsibility in a nut shell is to drive technical decision making and mentor the individuals in the team. However it isn’t a role that involves any line management.

I’ve been a Tech Lead at Rightmove for close to 18 months now. For me it seemed like a natural progression as a developer who was, let’s say chatty in meetings… I was acutely aware of the unknown aspect of this role, and like any good developer I did my research, and got some advice from the existing Tech Leads at Rightmove. However, preparing for a shift into a new role is tricky, it is impossible to fully prepare someone for a new role.

This was my first ever leadership role and it came with quite a few new challenges. A lot of these challenges I did not anticipate and were skills I had to develop or improve along the way. Here are my top five:

Silence Is Golden

OK, you’re a Tech Lead now, we get it, you know stuff. Probably, the reason you’re a Tech Lead is because as a Developer you were the go-to person for answers. What you need to learn now is that just because you CAN answer a question, that doesn’t mean you should. One thing you don’t want to be is the single source of ideas and knowledge in your team. Each of your teammates needs to feel empowered to provide their own opinions and solutions.

You may find that some people need a little nudge to speak up. What’s worked for me in meetings is to ask questions to specific people rather than throwing a question out to the room. Rather than jumping on a question that you know the answer to, just say nothing and see what happens. Start learning to feel comfortable in uncomfortable silences.

The only exception to the above points is if the question that’s being asked is really not discoverable by anyone who isn’t you. Ultimately, you should never be considered a single point of failure. If you are, then you need to share more of that knowledge that lives in your head.

Multitask and Delegate!

I know this one sounds obvious however thinking something and experiencing it are two vastly different things.

Coming from a Developer background, I made the assumption that the multitasking aspects to being a Tech Lead would come naturally. I will hold my hands up and admit that I underestimated the jump in the number of tasks that a Tech Lead needs to do.

My instinct as a new Tech Lead was to take on ALL the responsibilities and technical challenges because you want to prove yourself in your new role. Fight the urge and DO NOT DROWN YOURSELF IN WORK. Chances are, you work with good people who are eager to take on more responsibility. Take the opportunity to delegate and lighten the load a little bit.

If you’re naturally good at spinning plates then awesome, if not then I’d recommend researching some multitasking techniques and find out what works best for you. I love to do lists and use two separate todo list for work. I use one daily todo list for tasks that I either want to start or finish today, and a longer term work to do list for tasks I’m hoping to pick up within a week or two.

Learn How To Run A Good Meeting

Something I was warned about before I became Tech Lead was that that my meeting invites would shoot up exponentially, which it did. What no one told me is that some of the meetings you go to will be teeeeeeerible. Im really not hating on meetings, I think they can be really valuable and it is definitely a great feeling to leave a meeting with a solution to a problem that’s been blocking your progress. I will also add that this is not strictly advice for Tech Leads and can apply to anyone really. It’s just now your responsibility as a Tech Lead to avoid some of these missteps.

I’ve been in meetings where i’ve come out more confused than when I walked in. If you’re organising the meeting, make sure you come in with a real solid objective that you’re looking to achieve at the end of the meeting. And make sure to vocalise this to the rest of the people in the meeting. This ensures you’re all on the same page and working towards that goal.

I’ve had meetings overrun or end abruptly because we ran out of time. To avoid this, come in to the meeting with a rough plan of what you’re going to talk about. If there are multiple points you want to discuss then plan out how long you want each part to take. For example, if I had a 30 min meeting, I might start off with defining some kind of technical problem I was having, which includes drawing a diagram of some sort. I want this stage to take 10 mins so we can then use the other 20 to discuss proposed solutions. You should also get good at tactfully interrupting people who are getting off topic. It would be a shame if you ran out of time and had to book in another meeting because someone was waffling.

If you are ever in a meeting and see any of these warning signs, please give feedback to the person running the meeting. Without giving feedback openly they will never have the opportunity to improve.

People Will Take More Notice Of Your Opinions and Actions

When I was made Tech Lead in my team, almost overnight the number of questions I would get asked shot up. It felt a little strange at first, but despite being the exact same person with the exact same opinions as the me from a week ago, my opinions did inevitably carry more weight. This for the most part I view as a positive as it could give you an opportunity to solve the bigger cross team challenges within your organisation.

Although your influence in the team can manifest itself positively, it can also be a negative. If you’re great at presentations and knowledge sharing, you will end up encouraging your developers to do the same. Conversely, if you’re in a meeting and you fly off the handle because of a disagreement with your manager, don’t be surprised if the other developers follow suit.

Balancing Your Own Learnings With Others

One of the things I love about being a developer is how much there is to learn. Before I became a Tech Lead one of my main objectives every day was to learn something new, regardless of if it was technical, business knowledge or a soft skill.

What I noticed when I became a Tech Lead was that nowadays my main objective is to make the team as good as it can be. If there is an opportunity to learn something new, I sometimes feel as though it’s much more valuable for the developers in my team to have that experience instead of me. I do believe that continuing to learn new tools and techniques is a part of a Tech Lead’s responsibilities. However I think what’s more important is that you have a responsibility to your team who are looking to you for opportunities to learn and guidance on how to progress with their careers. This ultimately is up to you to strike the right balance between what’s beneficial for you as an individual and what’s beneficial to the team.


Hopefully this guide has given you some insight into the Tech Lead role and some challenges that I and other Tech Leads I’ve spoken to have faced. All in all it’s been a great learning experience becoming a Tech Lead and I’m sure I have a fair bit more to learn along the way.

Tony Ly author photo

Post written by

Engineering Manager at Rightmove. I enjoy finding better ways to solve problems, mentoring and in general being a stand up guy.

View all posts by Tony Ly
%d bloggers like this: