Some thoughts on being a Tech Lead

After being promoted to Tech Lead by my supervisor, I felt a bit conflicted. There wasn’t an official title upgrade, nor was there a corresponding elevation in rank—just a simple declaration of, "Hey, from now on, you are the Tech Lead," along with a slight salary increase.

However, for me, it’s a great opportunity to try something new, and I’d like to record some of my thoughts here.

The Difference Between Tech Lead and Team Lead

In terms of definition, I tend to lean more towards the term Tech Lead rather than Team Lead.

To me, they represent different meanings: one focuses purely on technical leadership and development, while the other leans more towards management and team guidance. My current role is more aligned with the former. (Of course, definitions can vary from person to person; I’m just sharing my perspective.)

From the early stages of development, I was always an engineer who enjoyed diving deep into coding. I didn’t disregard understanding specifications; rather, I preferred to tackle issues from an architectural standpoint rather than resolving interpersonal conflicts.

This is also 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 enhance the team’s development speed.

Why do I say this? Let's say you can implement features quickly, with good quality and few bugs; but do your teammates understand what this feature is about? Can they keep up with your pace? Are they approaching coding with similar mindsets?

If the answer to these questions is no, you are likely to encounter various spec mismatches, unexpected bugs, and slowdowns caused by others’ code during the later stages of development, ultimately leading to a bottleneck in QA.

Differences from Before

The most apparent change is that meetings have increased. Previously, discussions were limited to developers and the Engineering Manager, but as Tech Lead, I now have to collaborate with various departments and project members. The ratio of English and Japanese spoken used to be about 70:30; now it’s completely reversed. Thankfully, this company doesn’t place much emphasis on honorifics; otherwise, I would find it quite challenging.

Moreover, the expectations from everyone have understandably risen. If there are any unclear specifications, I’m the first person they turn to, so I need to have a deeper grasp of the specifications compared to other developers. I also need to anticipate potential problems and propose solutions. Additionally, the time I can dedicate to coding has noticeably decreased, but it hasn’t reduced significantly. In fact, I still find myself writing the most code, which is not a good sign. I should be spending more time figuring out how to improve overall processes and team dynamics instead of just coding.

Finding Problems Before They Arise is More Important Than Solving Them

I’ve realized that discovering problems is often more crucial than solving them. Within this team, I’ve identified several potential issues:

• Team members lack experience in handling complex scenarios.
• There is a lack of focus on overall processes and code quality.
• Team members do not fully follow (or understand) specifications and may not communicate potential scenarios with the Planner.

For example, during the development phase, I sensed that one team member was fixated on certain minor implementation details. While this can be a good thing, if it takes two months to produce nothing and delays the timeline, it becomes a serious issue. Additionally, the lack of focus on quality and overall processes meant that members relied on each other’s Code Reviews to catch errors, leading to an increasing number of issues reported during QA, leaving the entire development team overwhelmed.

Honestly, I felt quite disappointed during that period, but it also prompted a lot of self-reflection.

• There’s no heroism in development; don’t expect team members to change overnight.
• Instead of just focusing on code quality (which is important), it’s vital to clarify the root causes of issues first.

The problems mentioned above significantly increased the cost of fixing bugs in the later stages of development. Due to tight timelines, everyone was under considerable stress, which further necessitated more time investment, resulting in a significant drop in overall quality. Thus, the adage about early detection and treatment should be adhered to as a guiding principle.

Prioritizing Team Members Leaving on Time as a Rule

One thing I genuinely wish to achieve is to help team members leave on time. I want them to feel free to explore their ideas on the project, but I feel like I still have a long way to go to reach this ideal.

Keeping Track of Team Members' Progress is Crucial

I may have been promoted to Tech Lead due to my visibility and proactivity during the first quarter, which caught my supervisor’s attention, or perhaps because of my experience in handling technical and business scenarios better than other team members.

However, if I’m the only one skilled in that area, it’s of little use; I’ll just end up overwhelmed. It’s equally important to ensure that other members understand the significance of business scenarios and their requirements.

If there are things this team can’t achieve without you, then it’s not an ideal team.

I believe in this principle, which I experienced at my previous company (where I was not a Tech Lead). When everyone shares similar values, technical skills, and personalities, collaboration becomes much smoother, regardless of experience or position gaps. There’s no need for extensive Scrum meetings or various discussions; everyone submits results on time or even ahead of schedule.

Of course, such teams are rare. Most of the time, I rely on inquiries during Daily Meetings to help team members identify areas that need design work. This is one of the most direct factors influencing Sprint output and a good way to resolve issues.

However, this requires me to not only keep track of my own development progress but also to be very familiar with the overall architecture and specifications to identify potential problems.

Understanding One’s Strengths and Weaknesses

I’m not very good at preaching or changing individuals, nor do I possess a naturally gregarious personality. Therefore, when I want members to accomplish certain tasks, my tone often comes across as a bit intense.

I can’t tolerate anyone slacking off and hindering the team's progress. Since becoming the Lead, I’ve started to track each member’s progress and noticed that one member’s Pull Requests and Code Reviews were significantly fewer than those of others (by more than double). I tried various methods, including pointing out errors during Code Reviews, highlighting details on Slack, and following up on unresponsive Pull Requests, but if the individual shows no improvement, there’s not much authority I have to enforce change.

Identifying Blocker Indicators

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

• Complex Pull Requests with significant changes: These are likely to be the primary triggers for QA issues, so ensuring both testing success and a shared understanding among developers is crucial.
• The number of tasks before the Sprint ends: Many developers might not pay particular attention to this. If they have numerous Working In Progress tasks, it’s worth asking about their progress. Frequent occurrences of this indicate someone on the team is overloaded.
• Excessive or inappropriate refactoring: We should avoid inappropriate or excessive refactoring, as damaging the existing architecture may exacerbate QA issues rather than mitigate them.
• Using metrics to evaluate team efficiency: Time spent on Code Reviews, the number of Pull Requests, and the time taken from developing a feature to merging and deploying it are all relevant.
• If a team member is stuck on a particular issue without any inquiries, they’re likely struggling without signaling for help.

There are many more factors to delve into, but here I’m only highlighting a few that I think are particularly important.

Conclusion

Honestly, I still feel a bit lost. On one hand, the developers I’ve encountered here seem less enthusiastic about technology compared to my previous colleagues; often, they just aim to complete tasks without paying much attention to development processes or other improvements, which is quite frustrating. My supervisor believes I should help them and be more understanding of cultural differences.

But if someone is unwilling to change and engages in behaviors that affect team output and motivation, why should I be the one held accountable rather than them? Shouldn’t my performance review be spared from this? Or is it acceptable to use cultural differences to justify not working?

On the other hand, I don’t have the direct authority to adjust manpower or resources; at most, I can escalate issues to upper management. This development cycle has been not only tight but also plagued by unfamiliar experiences and slow personnel adjustments, leaving little time to address what truly needs handling. I feel powerless to effect any change.

Becoming a Tech Lead has undoubtedly broadened my perspective. Previously, I had little interaction with non-engineers, but now I find myself frequently negotiating with Planners and discussing various spec details almost daily. For some reason, Tokyo residents speak Japanese at twice the speed, which has significantly improved my language skills and taught me a lot of business-related Japanese.

Often, simply thinking about specifications from the company’s perspective can resolve many issues. When negotiating, if I focus on solving their problems, the deadlock on both sides tends to ease.

Ultimately, it comes down to the people.

Update (06/15/2020)

After the article was published, my supervisor reached out for a chat to address some of the questions I raised. Surprisingly, this article received quite a bit of feedback, perhaps because many people resonate with similar experiences. I want to emphasize that this piece is ultimately just a summary of personal reflections, and my views may be biased due to differing perspectives.

Additionally, I’d like to thank Twitter user @brucesu for recommending the article “breaking the senior developer ceiling,” which aligns with my views. If one wishes to climb higher, sometimes coding isn't the necessity; instead, it’s about focusing on delivering higher value and trying to see things from the company’s angle.

That said, I believe there are still many areas where I lack technical refinement and maturity. Therefore, at this stage, I still want to prioritize technical skills and advance toward architectural aspects.