Reflections on Becoming a Tech Lead

My feelings were somewhat mixed after my manager promoted me to Tech Lead. There was no corresponding bump in job level, nor an official new title—just a tap on the shoulder saying, “Hey, from now on you’re the Tech Lead,” along with a slight raise.

Still, it’s a great opportunity for me to try something new, so I’d like to jot down a few reflections here.

The Difference Between Tech Lead and Team Lead

In terms of definitions, I lean more toward “Tech Lead” rather than “Team Lead.”

To me, the two carry quite different meanings: one is purely technical and developmental leadership, while the other leans more toward people management and team building. My current role aligns more with the former. (Of course, definitions vary from person to person; this is just my own perspective.)

Ever since the early days of my career, I’ve always been the type of engineer who loves burying his head in code. It’s not that I ignore specs or requirements, but rather that compared to dealing with interpersonal issues, I much prefer tackling things directly at the architectural level.

This is also one of my biggest weaknesses and an area where I need to improve: even if you code fast on your own, it doesn’t mean much if you don’t elevate the development speed of the team as a whole.

Why do I say this? Suppose you build features quickly, with high quality and very few bugs. But do your teammates actually understand what the feature does? Can they keep up with your pace? Do they share a similar mindset when writing code?

If the answer to these questions is no, you are very likely to hit a wall in the mid-to-late stages of development—running into spec mismatches, an explosion of overlooked bugs, and being slowed down by other members’ code—ultimately leaving all development deadlocked in QA.

What’s Changed Compared to Before

The most noticeable difference is having way more meetings. Previously, discussions only happened among developers and the Engineering Manager. But after stepping up to Tech Lead, I started collaborating with people from various departments and projects. Before, my ratio of speaking English to Japanese was roughly 7:3; now it’s completely reversed. Luckily, this company isn’t too rigid about keigo (honorific speech), otherwise it would have felt exhausting.

Another thing is that people naturally hold higher expectations of you. Whenever any requirement or spec is unclear, you are the first person they turn to. Because of that, you need a deeper grasp of the specs than other developers, and you have to anticipate potential issues to provide solutions.

Additionally, my coding time has noticeably decreased—though not by that much. In fact, pull the commit data and I’m still the one writing the most code. This is actually a bad sign. I should be spending more time thinking about how to improve the overall process and team operations, rather than writing code myself.

Catching Issues Early Matters More Than Solving Them

I’ve realized that identifying problems is far more important than solving them. In this team, I spotted several potential issues:

• Team members had relatively little experience handling complex scenarios.
• A lack of attention to the overall workflow and code quality.
• Not fully adhering to (or understanding) the specs, and failing to communicate potential scenarios with the Planners.

For example, during the development phase, I noticed a teammate persistently obsessing over minute implementation details. While that isn’t inherently a bad thing, when two months pass without anything to show for it and deadlines get delayed, it becomes a major problem. Another issue was the disregard for quality and overall process; people relied on other members’ Code Reviews to catch mistakes, which later caused an influx of QA-reported bugs and left the entire dev team overwhelmed.

To be honest, I was very frustrated during that period, but it also prompted a lot of self-reflection:

• There is no room for heroics in development; don’t expect members to change overnight.
• Before stressing over code quality (which is still important, of course), get to the root of the problem first.

The issues mentioned above significantly drove up the cost of bug fixes in the later stages of development. Due to tight schedules, tensions ran high, people had to put in more hours, and overall quality plummeted. That’s why the adage “early detection, early cure” should really be treated as a guiding principle.

Rule #1: Making Sure the Team Leaves on Time

One thing I really hope to achieve is ensuring that team members can log off on time, while also having the freedom to experiment with what they want on the project. But I still feel quite far from reaching that ideal.

Keeping Track of Members’ Progress Is Crucial

Perhaps I was promoted to Tech Lead because my proactivity and engagement in Q1 caught my manager’s attention, or perhaps because I had more experience with technical and business scenarios than other members.

However, being capable on your own is pointless—you’ll just work yourself to death. You also need to ensure other members understand the importance and requirements of the business context.

If a team can’t function without you, it’s not an ideal team.

I firmly believe in this, and I experienced something similar at my previous company (where I wasn’t a Tech Lead). When everyone shares roughly the same values, technical capabilities, and personalities, collaboration runs seamlessly regardless of gaps in experience or seniority. You don’t even need strict Scrum or endless meetings; people deliver results on time, or even early.

Of course, such teams are rare gems. So, for the most part, I use Daily Standups to ask questions and guide them on what needs to be designed properly. This is one of the most direct factors impacting Sprint output, and an effective way to solve issues.

However, this requires me not only to stay on top of my own progress, but also to possess a deep understanding of the overall architecture and specifications so I can anticipate potential pitfalls.

Knowing Your Strengths and Weaknesses

I am terrible at lecturing people or trying to change who they are, nor do I have the kind of personality that easily mingles with everyone. So whenever I want members to do something, my tone often ends up sounding a bit too aggressive.

I cannot tolerate slacking off that slows down team progress. After becoming a Lead, I began tracking everyone’s progress and noticed that one member submitted significantly fewer Pull Requests and Code Reviews compared to the others (by more than half). I tried multiple approaches: pointing out errors proactively in Code Reviews, giving nudges on Slack about details, and following up on overdue, unanswered PRs. But if the person refuses to improve, the truth is I don’t hold the authority to do much about it.

Identifying Blocker Metrics

For me, there are several indicators that warrant close attention:

• Complex PRs with massive changes: These are prime hotspots for QA issues, so it’s critical to ensure tests pass and that developers share a common understanding.
• The number of tasks remaining near the end of a Sprint: Many developers don’t pay much attention to this. If they have too many tasks “In Progress,” check in on them. If this happens too frequently, it means someone on the team is overloaded.
• Excessive or inappropriate refactoring: We should avoid misguided or over-refactoring. If refactoring breaks the existing architecture, QA issues will increase rather than decrease, doing more harm than good.
• Using metrics to evaluate team efficiency: Code Review turnaround time, number of PRs, how long it takes a feature to go from development to merge and deploy.
• A team member being stuck on an issue for a prolonged period without asking questions: Often, they are blocked but failing to send out a distress signal.

There are many more if we dig deeper, but these are a few key points that come to mind.

Postscript

Truth be told, I’m still feeling a bit lost. On one hand, compared to my past colleagues, the developers I work with here aren’t as passionate about technology; a lot of the time, the goal is just getting the task done. They don’t particularly care about the development workflow or other improvements, which frustrates me deeply. Meanwhile, my manager thinks I should help them and be more understanding of cultural differences.

But if someone refuses to change and repeatedly harms team output and morale, why am I the one being held accountable instead of them? Why does my performance review have to suffer for it? Does “cultural differences” really excuse things all the way to skipping work without consequence?

On the other hand, I don’t have the actual authority to adjust staffing or resources; at most, I can only escalate issues upward. This project not only had a tight schedule, but combined with inexperience and sluggish staffing adjustments, the team barely had any time to do what we actually needed to do. I felt completely powerless to change anything.

Becoming a Tech Lead has certainly broadened my horizons. In the past, I had limited interactions with non-engineers, but now I negotiate and hash out spec details with Planners almost daily. People in Tokyo speak Japanese twice as fast for some reason, which rapidly improved my Japanese and taught me a ton of business vocabulary. Often, thinking about specs from the company’s perspective solves a lot of problems. And during negotiations, focusing on solving their pain points keeps gridlocks from getting too intense.

Sigh. In the end, the hardest problem is always people.

Update (2020/06/15)

After this post went live, my manager reached out to chat and cleared up some of the questions I raised. The post unexpectedly received quite a bit of feedback, perhaps because many people have had similar experiences and felt a resonance. One thing I want to add is that, at the end of the day, this post is just a summary of personal reflections and might carry biases from my own perspective.

Also, thanks to Twitter friend @brucesu for recommending the article “breaking the senior developer ceiling.” I strongly agree with the points made in the article: if you want to keep climbing higher, writing code isn’t always essential; instead, you need to focus on delivering higher-leverage value and try to see things more from the company’s viewpoint.

Even so, I believe there are still many technical areas where I lack polish and maturity. So at this stage, I still want to keep technology as my primary focus and push further into the architectural domain.