This is a series of stories talking about my journey in Shopee as a software engineer leader. For more details and motivation, you can check here.
After becoming senior developers for a while, you have been granted the team lead role by your manager. What wonderful news! Now you have some subordinates who can order and don’t need to do the miscellaneous tasks anymore.
However, things did not go as you expected. A few months later, you have felt exhausted already. The delegation did not make your life better but even worse. Previously, one task you can finish directly within one day on your own. But after delegation, you found you need to spend few hours listing down the instructions to the members, and they will spend few days doing it. During this period, they would ask you questions from time to time. The worse part was that the outcome was not the same as what you expected, so you may need to pick up their slack from time to time. You convinced yourself this was just an investment, and it would get better. But it didn’t. There was always something different from your expectation. You were angry and frustrated, especially when you were doing a code review and fixing up the process your member missed.
The worst, you wrote less and less code and spent more time reviewing and joining the discussion. You did not get any self-achievement, and you felt you did nothing to contribute to the world. You felt lost because it seems like you were not a developer where you were proud of previously.
This is the story that happens on many developers who was an excellent individual contributor (IC). Of course, this also happened to me two years ago when I was assigned to a team lead role. I was quite struggled at that time and felt depressed and almost burned out at that time.
To tell people you are not alone, and I have the same experience as you, I wrote two articles to share how I dealt with such feelings, how I found a way out, and how my mindset changes along with my learning journey of being a team lead.
From 1 member to 1 team
In the 2019 summer, I become a team leader of the order accounting team. As I started at a single-person team, I did not feel any difference before and after the team forming. I knew I needed to do more was (1) delegation (2) initiate more ideas and improvements.
Although I have the experience of mentoring 6 people, I did not have a clear idea about how to delegate. Once I started to do it, the frustration came back constantly, as I mentioned above. Therefore, I kept letting my hand dirty and handling things myself. I kept checking whether the progress and result aligned with my expectation for the things I delegated. If there was an issue, I will stand in front to help the members as I thought a leader should “protect” their members. Subsequently, I was pretty exhausted because I was still doing the tasks except for the coding part.
First step: building processes
Until 2020 summer, our team members grew to 8 people. I could not hands-on everything by myself anymore. I started to think about the scalability of a team. The obvious way was to write down my experience to save time to do knowledge transfer. I would not say this, but thanks for the WFH policy. I also found that recording the sharing and knowledge transferring process was an excellent idea. I hosted many sharing in early 2020, and all of the sharings have been recorded. Until now, we still record every sharing and discussion that is worth spreading or review again.
One of the learning points from writing documents was that I did not think about consolidating my knowledge in a structured way, but now I need to do this. For example, previously, we wrote the tech design in freestyle which was not good for other members to follow. Therefore, I need to consolidate my experience and provide a tech design template for my team members. These documents also noted down my methodologies for approaching a problem.
The other thing I tried to do is improving my communication skills. As the person needs to facilitate more and executing less, communicating was a crucial skill. Initially, I thought I only need to improve my English skills, so I found an English tutor and had an English lesson twice a week. Surprisingly, the most inspiring part was not learning English itself but communication skills. My teacher told me that my more significant problem was that I said things bottom-up, but typically people understand things in a top-down way. I needed to throw out the big idea or objective first, then talking about the details later. This method sounded easy but was quite challenging for me. This was not only about how you consolidated your ideas but also summarizing people’s ideas. Not everybody talked structurally, and you need to think fast to organize them to reply to people in a structured way to improve communication efficiency. This is a critical skill during 1–1s to observe people’s ideas behind their sentences.
Got lost
Until the end of 2020 Q3, I led a team based on my gut feeling. I tried to build a good culture and happy environments for the team, like creating MAGA sessions, establishing round tables, being transparent, upholding members. All things looked going well, except I felt lost in my mind.
The main reason was that I could not find any self-achievement from doing all of this. When you were a developer, your feedback cycle was quite short; you write some code and make the system work directly. Now you deal with people: guide them, teach them, and think about how to help them. But none of any outcome can reveal in a short time. You don’t even know the decision you made was correct or not. The more you want to control, the higher quality you want to maintain, the more stressful and frustrating you feel. Furthermore, planning the future, facilitation, delegation, those boring and miscellaneous things were still my work. I felt super busy every day, and I could not escape from such a situation. I did not feel any achievement and contribution to the world as well. Previously, I could write code to unleash such unhappiness, but now I could not do that anymore due to the accumulated backlogs.
Turning points
In October 2020, I realized that I should find a way out. I asked my manager about the external resources, and he suggested I read Managing Path[1]. The book articulates the transition along with the engineering management career ladder. It is a quite good book, but it seemed not really helpful for me at that time somehow.
I also tried to ask my friend, a (not engineering) manager, to share how she managed people. I got some points but did not feel much difference from the talks. I thought I might still need to find a person who has a similar experience to me. I discussed with engineer friends from the other company, but none shared a similar experience or are in the same role as me.
Talking to my engineering manager friend
One day, it turned out one of my friends has become an engineering manager at Instagram. I was thrilled and sent him a message immediately to have a catchup. This is the first time I felt somebody shared the same feeling with me after becoming a leader. We have the same struggle about zero achievement and hard to push people to follow our instructions. Besides, I also got some important points from his experience.
- He said he also did not want to be the manager in the very beginning. We were proud of having an engineering spirit, we contribute to great codes, and we don’t like to deal with people. There is a typical stereotype where a person becoming a manager is the person who doesn’t enjoy coding, and we don’t want us to be in that position. However, somehow he got promoted to be manager one day, and he realized that he could actually define himself for this manager role. He felt self-achievement for doing things that he wanted when he was a junior developer. The rationale behind this was because he thought his past managers did not provide sufficient support to him, and he didn’t want his members felt the same way.
- The second thing is related to giving the wrong guidance to the member. He agreed that we all wanted to be good leaders, provided the “correct” instruction to the member, and help them not to go in the “wrong” direction. But one lesson learned from him was that we did not need to worry about giving the wrong suggestion or doing the wrong thing. Humans are not like a program that you write a bug, and the system will crash entirely. They will fix it by themselves and learn from their mistakes. Our responsibility is not preventing our members from failing but providing a comfortable space to fail.
These ideas change my mindset largely. As a leader, you need to tolerate people doing things wrong and accept people not following your road. This is pretty hard because you need to prepare yourself for possibly bearing the bad consequence. That is the true support to your member, not just protect them from doing the wrong things.
Until now, you may have a question why I did not talk to my manager about these topics? Actually, we have had discussed all of them. I have got lots of input from my managers, but it doesn’t really work for me. That was why I wanted to seek other external stimulations to get more insights.
I want to pause the story here since it is too long for an article XD. You can continue reading my journey by clicking the article below.
[1] Fournier, Camille. The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change. O’Reilly Media, 2017.
