New Role, New Team and New Challange

When I was promoted as a Team Lead, I had to take charge of one of the existing teams while also setting up two new smaller teams with a few members each.

Building a new team comes with its own challenges, but leading an already established team is a completely different experience. The existing team had a few senior members who had been there from the beginning. One of them strongly believed that he knew the product and the codebase better than me. Whenever I delegated tasks to him, he would not prioritize them. If I tried explaining the use cases, he would not listen. Over time, his output dropped significantly. I knew that before my manager noticed this issue, I had to address it. I have always believed that most conflicts can be solved through open discussion, so I invited him for a one-on-one meeting.

During that meeting, I understood his perspective and also gathered some feedback from him. I assured him that I would take his feedback seriously and that he would notice changes starting immediately. At the same time, I requested that he follow my instructions, not blindly, but with trust. This helped pause the conflict temporarily, but I knew I had to act quickly to resolve it permanently.

This is where my previous lesson from my gym master (A Lesson from My Gym Master) became valuable.

For the next feature, I asked him to take ownership. I requested that he prepare the case study, workflow and document. He covered all the basic scenarios and almost all the edge cases, but when I asked him about a few critical edge cases, he went completely blank. Instead of asking him to redo everything from scratch, I sat with him during the drafting process and encouraged him to ask questions whenever he needed guidance. As we discussed, we discovered even more edge cases and covered them thoroughly. By the end of the meeting, we had a complete feature case study and a strong design document.

When the feature was tested by QA, they found a few bugs, but there were no gaps or areas for improvement. He told me this was the first time QA did not send back improvement suggestions, which made him proud of his work.

Around the same time, he worked on a complex bug fix for support. During code review, I suggested a simpler and more efficient solution. Initially, he disagreed, but I asked him to test it anyway. Once he tried it, he saw it worked better and updated his code accordingly.

After a few incidents like these within the same week, I gained his respect. He started trusting me and following my guidance, not blindly, but with confidence.

Lesson for me: Just like my gym master, I did not focus on proving myself. I realized that respect does not come from demanding it, but from consistently showing competence and supporting others to succeed. By working alongside my teammate, guiding him when necessary, and coordinating with him to bring out his best, I allowed the results to speak for themselves. This approach eventually helped me earn his trust and respect, and reminded me that true leadership is about creating the right environment for people to recognize your value naturally while ensuring accountability and collaboration.