Learnings from a month of being an Assistant Tech Lead!

Today is exactly a month since I was given the responsibility of co-leading a small team of software developers at Adacta Fintech to develop insurance solutions for our clients. It was intimidating at the beginning not just because I was taking this responsibility for the first time but also, it came at a time when the Tech Lead and the Product Manager were on vacation simultaneously and the senior developers in the team were moving to other opportunities in their career.

As they say, they never waste a crisis, I took this challenge as an opportunity to hone my skills as a Technical Lead. In this blog post, I will share some of the learnings and realizations I went through in this period:

** 1. Preparation is the key**

At first, it was intimidating to know that I needed to talk to different stakeholders such as Business Analysts, Product Manager, and Developers. Also provide estimations, write technical notes, organize sprints, and take care of JIRA tasks all at the same time instead of just being in my shell and programming. Thanks to my product manager and my senior lead, we were able to organize multiple sessions on how to handle the different responsibilities, how to articulate the business aspects of the project and find a correlation between the technical and the business sides of the project. While it is never enough, I did build some confidence over the course of these multiple sessions and I highly advise it for anyone aiming to transition into a Technical Lead role.

** 2. Imposter Syndrome is natural, accept it and be honest about it with your colleagues**

As Rahul Pandey points out in his talk, every time we are faced with a new challenge, the feeling of being lost is something that every engineer faces. The fact that I accepted it helped me immensely to become comfortable with the new position I was assigned to. One of the first things I would do at the start of the meeting is to let the other members know about my situation and this gave me more confidence to ask them questions if I felt I did not exactly understand something. As a developer, you could still get away with not exactly understanding the business implications of what you are doing as you can always fall back to your Tech lead to ask him in more detail but when you are the one leading the team, you no longer have that leverage as the rest of the team depends on you. In fact, I am glad people around me appreciated the fact that I was honest to them and they spent more time explaining things to me than they would have preferred to.

** 3. Communicating your vision to the team is super important**

As a lead, it is super important that your team becomes aligned with the vision you have for the product and your people. It not only helps the development move in a direction as per the needs of the business but also keeps your team members motivated and engaged. One of the first things I did when I took charge was to let the team know what development trajectory we needed to take to meet the business needs of the company. At the same time, I also let them know about my plans to further their learning and help them improve as a developer in the next month. This helped us to measure our progress at the end of the month and we got valuable suggestions on how to improve as a team.

** 4. Technical Debt exists, accept it, and do not fix it yourself**

I joined my current team when a substantial portion of the project was already built. As a developer, I used to be very aware of not introducing technical debt in my code. Now as a tech lead, I had to review other people's code and had the opportunity to dive deeper into the aspects of the code that I had not encountered. As a consequence, I encountered the technical debt in the code, I was tempted to go in and fix errors myself but that meant sometimes I was overworked and burnt-out. Realizing the approach was not feasible, I started with the process of continuous feedback having small calls with the members to let them know what better could have been done whenever I encountered any such issue. We also agreed with the team to not introduce any technical debt in a small part of the project to start with. I started to lead by example and asked members to review my code so they could follow some of my coding practices to avoid introducing technical debt.

** 5. Knowledge Transfer will reduce your work by many-fold and increase the efficiency of the team**

Coming from an open-source community, I have always been excited to share my knowledge and learn from other people as much as I can. Because most of the developers in the team were relatively new to the company, I was all of the sudden spending almost all my time answering the developer's queries and there was a pattern in the questions. So, I decided to aggressively organize knowledge transfer sessions not only from technical people in the team but also from the business people. We started to record the sessions and write notes not just for the present members of the team who were absent but potentially for the future members of the team. This helped us avoid single point of failure as all of us were partially aware of the part of the project that we were not working on. It also motivated members to dive deep into the development so they could present some of the work they were doing.

** 6. Do not burn yourself**

It is natural that I wanted to prove that I am fit for the new responsibilities that are assigned to me. As a consequence, I started to code and write emails to different stakeholders outside my work hours. While I could do it for the first few weeks but I started to burn out after some time. My suggestion is to accept that it’s exhausting and pace yourself. Chill, Watch movies, Play Cricket, Work out. Find what works for you. Get the steam out :-)

Let me know what you think about my blog, I am looking forward to your suggestions and comments.

See you next time till then keep laughing, spreading happiness and most importantly living this journey called life!!!!