After being promoted to Tech Lead by my supervisor, I have mixed feelings. There is no corresponding promotion in terms of job level or an actual title. I was simply told, "Hey, from now on, you are the Tech Lead," and given a slight salary increase.

However, for me, it is a good opportunity to try something new, so I would like to share some thoughts here.

Difference between Tech Lead and Team Lead

In terms of definitions, I prefer the term Tech Lead over Team Lead.

To me, these two roles have slightly different meanings. Tech Lead focuses on technical leadership and development, while Team Lead leans more towards management and leading a team. My current role aligns more with the former (of course, these definitions may vary for different individuals).

Since the early stages of my development career, I have always been an engineer who enjoys coding. It's not that I ignore specifications or other aspects, but I prefer to tackle problems from an architectural perspective rather than dealing with interpersonal matters.

This is actually one of my biggest weaknesses and an area I need to improve. Even if I can code quickly on my own, it doesn't have much impact if I don't improve the overall development speed of the team.

Why do I say this? Let's assume you can deliver features quickly, with good quality and few bugs. But do your team members understand what that feature is for? Can they keep up with your pace? Do they approach coding with a similar mindset?

If these questions are not addressed, you are likely to encounter various issues in the later stages of development, such as deviations from specifications, bugs that were not considered initially, and being slowed down by other team members' code. Ultimately, the entire development process will get stuck at the QA stage.

Differences from before

The most obvious difference is that there are more meetings now. Previously, I only needed to discuss with other developers and the Engineering Manager internally. But after becoming a Tech Lead, I have to collaborate with various departments and people from different projects. Previously, the ratio of English to Japanese used to be around 7:3, but now it has completely flipped. Fortunately, this company doesn't pay too much attention to honorific language, otherwise it would be quite challenging.

Another difference is that people's expectations of me have naturally increased. Whenever there are unclear specifications or specs, the first person they turn to is me. So, I need to have a deeper understanding of the specifications and anticipate potential issues to provide solutions.

Additionally, the time spent on writing code has noticeably decreased. However, in reality, it hasn't decreased by much. In fact, I still end up writing the most code, especially when it comes to extracting data. This is actually a bad signal. I should be spending more time thinking about how to improve the overall process and team collaboration, rather than writing code.

Identifying problems in advance is more important than solving them

I have realized that identifying problems is more important than solving them. In this team, I have noticed several underlying issues:

• Team members lack experience in handling complex scenarios.
• Insufficient focus on the overall process and code quality.
• Incomplete understanding of (or failure to communicate) specifications and potential scenarios with the planner.

For example, during the development phase, I vaguely sensed that one team member insisted on certain minor implementation details. While this can be a good thing, if after two months there is still no progress and it leads to project delays, then it becomes a major issue. Another issue is the lack of emphasis on quality and the overall process. Relying solely on other team members' code reviews to catch errors results in an increasing number of issues reported during QA, making the entire development team extremely busy.

To be honest, I was disappointed during that period, but it also made me reflect on many things.

• There is no room for heroism in development; don't expect team members to change overnight.
• Before focusing on code quality (which is important), clarify the root causes of problems.

The aforementioned problems increased the cost of bug fixing in the later stages of development. Due to time constraints, everyone's emotions were tense, and more time had to be invested, resulting in a significant decrease in overall quality. Therefore, the saying "early detection is better than solving problems" should be treated as a motto to follow.

Prioritizing team members leaving on time as the first rule

One thing I really want to achieve is allowing other team members to leave on time and have the freedom to explore things in the project. However, I feel that I am still far from achieving this ideal.

It is important to keep track of team members' progress

The reason I was promoted to Tech Lead might be because I caught my supervisor's attention through my active participation and enthusiasm in the first quarter. It could also be because I have more experience in handling technical and business scenarios compared to other team members.

However, if I am the only one who excels, it won't be of much use. I would end up being overwhelmed while others remain unaware of the importance of business scenarios and requirements.

If there are tasks that cannot be accomplished without you in the team, then it is not an ideal team.

I believe in this principle, as I have experienced something similar in my previous company (although I was not a Tech Lead there). When everyone shares the same values, technical skills, and personalities, regardless of differences in experience or position, collaboration becomes smooth. There is no need for excessive Scrum meetings; everyone will deliver results on time or even ahead of schedule.

Of course, finding such a team is not easy. Therefore, most of the time, I try to ask questions during daily meetings to let them know what needs to be designed. This is one of the key factors that directly affects the output of the sprint and is a good way to solve problems.

However, this requires me to not only manage my own development progress but also have a deep understanding of the overall architecture and specifications in order to anticipate potential issues.

Understanding my strengths and weaknesses

I am not good at lecturing or changing people, nor am I someone who easily gets along with others. So, when I want team members to do certain things, my tone often sounds a bit aggressive.

I cannot tolerate someone slacking off and slowing down the team's progress. Since becoming a Lead, I have been tracking the progress of each team member. I noticed that one member's pull requests and code reviews were significantly fewer compared to others (more than twice as less). I have tried various methods, including actively pointing out mistakes during code reviews, discussing details on Slack, and inquiring about delayed pull requests. However, if the person does not improve, there is not much I can do as I don't have any authority.

Identifying blockers is crucial

For me, there are several indicators that require special attention:

• Pull requests that are complex and involve significant changes: These are likely to be the main triggers for QA issues, so it is important to ensure that tests pass and that developers have a shared understanding.
• The number of tasks remaining before the end of the sprint: Many developers don't pay much attention to this. If they have too many tasks in progress, it's worth asking about their progress. If this situation occurs frequently, it indicates that someone in the team is overloaded.
• Excessive or inappropriate refactoring: We should avoid inappropriate or excessive refactoring. If refactoring disrupts the existing architecture, it will increase QA issues rather than resolve them.
• Using indicators to evaluate team efficiency: Code review time, number of pull requests, how long does it take for a feature to go from development to merge and deployment?
• When a team member is stuck on a particular issue without seeking help. This often indicates that they are stuck but not signaling for assistance.

There are many more aspects to delve into, but here I have mentioned the ones I consider important.

Afterword

To be honest, I am still a bit confused. On one hand, the developers I have encountered here seem to be less enthusiastic about technology compared to my previous colleagues. Most of the time, they are focused on completing tasks without paying much attention to the development process or other improvements. This is quite frustrating for me. My supervisor also believes that I should help them and be more understanding of cultural differences.

But if someone is unwilling to change and does things that affect the team's output and motivation, why should I be blamed instead of them? Why should my performance evaluation suffer? Or is it justifiable to use cultural differences as an excuse to get away with slacking off?

On the other hand, I don't have the actual authority to make changes in terms of HR or resource adjustments. At most, I can only escalate the problems to higher management. This development cycle, which was already tight, combined with the unfamiliarity of experiences and slow adjustments in resources, left no time to address the actual issues. I am powerless to change anything.

Becoming a Tech Lead has indeed broadened my perspective. Previously, I had limited interactions with non-engineers, but now I have frequent negotiations and discussions with planners about various detailed specifications. I don't know why, but when speaking in Japanese, it's twice as fast for people in Tokyo, which has significantly improved my Japanese skills. Often, as long as I approach things from the company's perspective, many problems can be solved, and if I find ways to solve their problems during negotiations, the deadlock is not so severe.

Ah, in the end, people are the biggest challenge.

Update (2020/06/15)

After publishing this article, my supervisor proactively approached me for a chat and answered some of the questions I raised in the article. Surprisingly, this article received a lot of responses, perhaps because many people have had similar experiences and resonated with it. I would like to add that this article is ultimately a personal reflection and may be biased due to different perspectives.

I would also like to thank my Twitter friend @brucesu for recommending the article "breaking the senior developer ceiling." I agree with many points in the article. If you want to continue moving up, sometimes writing code is no longer necessary. Instead, focus on providing higher value and try to see things from the company's perspective.

However, I believe that I still have many areas of technical development and immaturity. Therefore, at this stage, I still want to focus more on technology and move towards the architectural level.