# 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.