How I approach being a Senior Tech Lead

After 3 years of being a TL in tech companies, I wanted to share a few personal suggestions to who is new to this role.

I chose this time because now that my team is made of 10 engineers my responsibilities and ways of working are evolving. This team size is making my job all about management, leadership and designing aspects and little or nothing related to coding. Because of that, I wanted to pause a bit and share with you 9 points on how I approached being a TL so far.

• A TL is a role of high responsibility. To incentivize your team to trust you, you should: (a) Share credits with all your team when things succeed; (b) Be the first one who takes responsibility for failures.
• Be bold and opinionated: it’s great to always be available to every idea but also it’s okay to say no to someone’s request. If you are 100% certain that an idea is not good, you should feel ok to reject it and explain why. In most cases though it is better if you take some time to think about it. It’s also important for you to be bold and call out when something is not going well. Being the one who brings awareness of a problem will pay back in the long term to your team’s growth.
• Don’t hesitate to take ownership of product strategies, even if your team already has a PM. You should not completely defer the work to them, but you should at a minimum collaborate. Your collaboration with PMs and EMs is essential. Although boundaries among these three roles need to be set, there’s no strict rules on what these are. I personally believe these boundaries should be purposely vague. These three roles should be able to help each other and wear different hats whenever needed. Dynamics in teams vary but in theory none of these three roles should strictly prevail on the other. I strongly advocate for an active presence of TLs in product strategy decisions. TLs are the people who have better chances to know how systems work and how feasible certain ideas are. Not only that, they are the ones that might know from the inside what’s the right thing to do to improve their product. Make sure you take part in updating team projects at an organizational level. You should also encourage your team members to do the same, by consistently sharing updates and what are the project strategies.
• If needed, be ready to make decisions on your own first and then socialize the idea and seek approval later. It might lead to stagnation and slowness if a TL seeks for full consensus or waits for other people’s feedback every time a decision has to be made. If there’s no agreement, you should be that person that at the end can decide for everyone. You need to take that responsibility.
• Use words of encouragement and be ready to publicly celebrate your team’s success. At the same time, you should not shy away from providing growth feedback to your colleagues on their project. Most of the time, I believe that we should recognize success in front of others while giving growth feedback privately. Other times providing growth feedback in front of the whole team can be useful for the others so that they can avoid making similar mistakes.
• Expect your team members will look for your help when needed. At the same time, lead by example and be the first one who seeks help from others if you feel the team needs it.
• Don’t stress yourself in guaranteeing your ideas are always the best and you are never wrong. Being a TL means you might have more experience than others in the team, but it doesn’t mean you have to be the technically strongest on each specific domain. You should always focus on leveraging expertise to indicate benefits and risks, bring different perspectives, but when you are not perfectly confident of which option is best, leaving a decision to someone in your team might be the best action to take. Your role as a TL is also to increase trust and confidence in the team, not showing you are the one who is always right. Try to avoid creating a dependency towards you. If your team is always seeking approval from you, you are creating weakness. Ultimately, you want to let your team grow without creating a big knowledge and experience gap between you and your team
• Sometimes you need to be the first person to talk, sometimes you let others talk. The balance is important because: (a) It increases the level of confidence and maturity in your team; (b) You don’t let others think that you are the only one who knows everything
• Wear multiple hats and understand your audience: having a meeting with a software engineer is not the same as having one with a lawyer or a marketing team. The language and interests are completely different. You need to have chameleonic skills in order to take the best out of it. Try to understand what the audience is interested in. In my opinion, you should be part of those meetings. It’s not just “the PM’s (or EM’s) responsibility” — it’s also your business because it’ll help you understand the diversity of point of views.

I hope this was useful. And feel free to let me know your thoughts!