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.
In the past few years, I have interviewed tens of developers entitled to a team lead. However, if you asked me the common part for those team leads, I don’t have answers. It is hard to define the role of a team leads properly. If you ask 10 team leads what their job is, you may get 9 distinct answers. Different companies have different requirements for being a team lead. Even in the same company, my leadership style is totally different from my neighbor team lead. So if I say I am a team lead with 13 developers. What does it mean?
To let people have more background about my story, I want to align with you about the imagination of my role first. Throughout this article, I will let you know my job, responsibility, and what the company expects me to do.
(As I just realized that the original articles are too long to read. I will split it into 2 stories.)
First of all, let me show you an example of my weekly schedule. The working hour for our company is 10 a.m. to 7 p.m. with 1.5 hours lunchtime from 12:30 p.m. to 2 p.m.
Generally speaking, I split my jobs into 4 categories: Project, Technologies, Team, People. One thing you may notice is that I do not have time slots for the technology category. I do not specifically reserve time for technology stuff (which I believe I should do so), and this just means I use the blank slot to do it rather than don’t do them. Another thing to say is that although it looks like there are a lot of unplanned time slots, they will normally be filled by the impromptu meetings after a week. Other than that, I may need to spend time doing lots of miscellaneous/administrative things. About the off-working hour time, it is usual to work overtime since I become a team lead. I usually used my off-work time to clear up backlogs for the action items collected from the daytime and prepare the materials for tomorrow.
Before elaborating on what I do for these things, let me give you more background knowledge about what my team does first. Our team is called the order accounting team, and our mission is to facilitate the money flow for an order. Here are the processes we facilitate (not exhaustive):
- When an order has been created, we need to calculate the commission fee and tax amount. This is the process of amount calculation.
- After the buyer received the goods, we will move to the clearing process, allocating the amount to the seller, Shopee, and third party. In this stage, we will finalize the amount going to transfer to the seller.
- The last mile is called a settlement, which will take the value from the clearing part and facilitate the actual money flow to payout to sellers.
Now you have some idea about our product is, so let me tell your more details about my team lead role here:
Product
First of all, the main task for a product team is to develop features to support Shopee’s business. As the most senior person in the team, my role here is more like a consultant, a facilitator, and a project manager.
Feature development
Whenever there is a new feature, our PM will host a meeting with us to discuss the feasibility of the business request. I join the discussion to provide insights from the technical point of view. Also, as the oldest person here, I give some background knowledge and legacy debt to the problem for the PM to reference. I usually will not accept the PM’s request directly but discuss the real issue they want to solve and provide a solution from my perspective.
After the PRD (product requirement document) has been finalized, I will delegate to the members to write the TD (Tech design) and do the actual development. During this process, I will help to review the TD, discuss with developers about the implementation details, split that tasks, remove the blockers that my members encountered, and push the project moving forward. Regarding who will do the code review, I have rarely done code review in the past half of the year. Most of the time, I will delegate to senior members or let other members do peer reviews.
Until now, I do fewer things mentioned above due to the growth of the team. Most of the time, I just let the senior members conduct the project. I will still join the discussion in some cases like the project scope is beyond our team, the project has high risks, or I want to collect information about how the members work. Instead of focusing on the project itself, I am more focused on coaching people to learn from their projects. I push people to reflect on the project they have worked on and think about the improvement points. Sometimes I also make them give an internal sharing about their work and the lesson they have learned.
Maintenance
Aside from the main tasks, maintaining features is as crucial as developing a new one. My role here is an issue coordinator, a potential issue observer, an improvement planner. Even I was an experienced firefighter before, and my duty now is more like coordinating the issue rather than solving the problem myself.
To make our system better and more stable, from time to time, I review our systems and find the potential issue and technical debts, trying to solve those problems earlier and prepare for the future. These include migrating old services to the new ones, eliminating technical debts, and also complete the non-functional requirements for our system (i.e., planning stress test, defining SLI/SLO for our system, build rate limiting, etc.) The ultimate goal for doing all of these is to ensure the quality of service that we can provide to the business and make developers’ lives better.
Plan for the future
Last but not least, I am the pioneer of the product. As the person fully understands our product and engineering system, my job is to help define our product’s future direction. For instance, my team maintains the lifecycle management of the refund entity. However, the refund is actually has nothing to do with our team’s scope. It was a kind of legacy decision. My job here is to discuss with other team leads, define what a refund is, and propose the strategies to move forward to the ultimate goal. This practice aims to set a clear product boundary that can reduce communication costs and prevent creating engineering debt in the future.
Technology
As a part of a product team, most of the technology decisions correlate with the product. Same as product, I am the solution consultant and an improvement planner. During the TD and development stage, I provide technical suggestions from my experience. Besides, I also need to plan for the future, including the old system deprecation/migration and the new system preparation plan.
To keep iterating our system, I need to initiate technical ideas from time to time. I am not necessary to be the person to come up with those ideas (and actually, I am not the person having the idea most of the time.) But I must be the person to consolidate them and convert the idea into real projects. The technical ideas can be creating a development tool for our team, building a reusable system like a progress bar system for a different system to use, or integrating with our in-house solution like an open tracking platform.
Aside from initiating the idea internally, I also need to discover new technologies to apply to our system. This is quite important because we can save lots of resources and time to rebuild the wheels if we can leverage the component provided by others. As the only person who has such visibility to the projects in all of Shopee, I must help filter and broadcast that information to the people to enhance our systems.
Even though I am still an engineering lead, I would like to confess that I did not cultivate my technical skills a lot last year. Instead, I focused on developing my leadership skills more and thinking about guiding people. And I think this is the thing I have a big room to improve.
As I mentioned above, this article is the first of a two-part series. The second article will continue to talk about the works for teams and people.
