Becoming Tech Lead again

It’s been a while since my last post. During this time, I started working for another company as a regular software developer, not as a Tech Lead. Does that mean I need to close this blog and start a new one with a more fitting title? Just kidding, of course.

My goal is to become a Tech Lead again in my current team, and I believe that writing about the Tech Lead journey will be a good way to reflect on my progress. I also hope it will be educational and insightful for developers like you.

At the time of writing, I've been with this company for about 2.5 months, but this post summarizes my first month working towards becoming a Tech Lead.

Why do I want to be a Tech Lead?

This section explains my motivation for becoming a Tech Lead and highlights factors you could consider when planning your next career move in software development.

My motivation to become a Tech Lead stems from a combination of four key areas:

1. What I enjoy

   Feeling impactful and responsible for both the technical and people-management aspects of projects

2. What I excel at
   Recognizing patterns, analyzing problems, solving complex issues, and optimizing team workflows in software projects.

3. What I want to challenge myself in
   Selecting solutions that align with business goals and making architecture-level decisions that improve long-term scalability.

4. Compensation
   Typically, the more impactful a role is, the better the pay. More importantly, I believe I bring significant value to the companies I work with, and I want to be fairly compensated for that.

Note on #3: I purposefully titled this point "What I want to challenge myself in" rather than "What I want to develop" because challenges excite me more. This distinction is important when I revisit this post for career motivation or when making future decisions.

My Plan to Become a Tech Lead

In my previous job, I became a Tech Lead because I was the most experienced developer, with strong domain knowledge and expertise in software engineering. However, that’s not the case in my current team. This project is also far more demanding in terms of services performance compared to my previous projects.

This presents a new challenge for me, especially since I’d like to assume the Tech Lead role in a relatively short time. So, what's my plan?

Act Like a Tech Lead from Day One

I want to show that I have the skills and mindset required to be a Tech Lead. I also want my teammates to see what they can expect from me, both as a developer and a potential team leader (though I’m not sure they know about my ambition). This is stressful because it involves suggesting changes to people with far greater project knowledge and ingrained work habits. What helps me manage this stress is:

• Determination to reach my goal

• Confidence in my software engineering skills and belief that I can propose valuable ideas

• A history of failed attempts that have made these situations less intimidating

• Acknowledging that I might be wrong, which helps me communicate humbly and listen carefully

But what value can I bring from day one, when I have minimal domain knowledge? Fortunately, programming languages, solid engineering practices, and design patterns are fairly universal. So, I can review code and suggest improvements based on my general expertise.

That’s what I started with, and I received positive feedback for “suggesting a good improvement and bringing fresh energy to the project.” A strong start, I'd say! Code reviews are also a great way to understand team coding practices and what matters most during reviews.

(I was a bit nervous that someone might tell me to ease up on the comments, but no one did. Either my teammates are very patient, or my suggestions were actually valuable.)

Listen, Observe, Identify Problems, and Plan Solutions

My main goal during the first month was to observe the way of working, types of tasks, team dynamics, meet people, and understand the project’s challenges.

Meetings with teammates, the architect, and project managers didn’t provide as much insight as I had hoped. However, I learned about two key challenges:

1. Many bugs were being reported by users.

2. The team lacked initiative, heavily relying on the Tech Lead, who had been moved to another area. (Spoiler alert - that has improved really fast without anyone’s intervention)

In hindsight, it may have been too early to expect major findings. My ability to dig into issues relies on connecting dots, and I didn’t have enough knowledge at that point. However, the positive side is that I broke the ice with my teammates and other colleagues in the company.

Learning the Domain

Domain knowledge is crucial for speeding up feature implementation and problem-solving, so it’s an area I wanted to focus on. However, I must admit that I didn’t make as much progress as I had hoped.

I expected more thorough onboarding into the domain and services my team maintains, but that didn’t happen. In hindsight, I should have requested more detailed onboarding or taken proactive steps to learn on my own.

What I did manage to do was actively participate in feature refinement sessions. My approach in these meetings was to act as a full and equal team member, asking for explanations when I didn’t understand something. This might sound bold for someone new to the team, but I believed I could contribute once I understood the project better.

My questions and paraphrasing revealed that not everyone shared the same understanding of certain problems, and some key details were missed. So, I did manage to add value, even at this early stage.

I encourage anyone onboarding to a new project to adopt the mindset of “I deserve to understand,” as it’s a great way to gain domain knowledge. Many people are too afraid to ask for clarifications, but it’s essential.

Areas for Improvement and Future Plans

As I mentioned earlier, domain knowledge is essential, and I’m not satisfied with my progress in this area. Therefore, it will be my top priority over the coming months. In my previous projects, solving bugs proved to be one of the best ways to gain this knowledge, so that’s how I plan to achieve this goal.

Despite my initial disappointment with bug analysis, I plan to continue efforts to reduce the number of bugs in our project. I’ll organize a brainstorming session to explore strategies for achieving this goal.