4 Months as a Tech Lead

After 8 months joining a new company, I was promoted to Tech Lead in Aug 2025 at my $current_company. I am now leading a team that ships the company’s SaaS product.

When I first transferred into the team, there were only 2 engineers, 1 QA, and 1 Product Manager. The business grew so well and we’re planning a lot for next FY. Now, 4 months later, the team has grown to 3 backend engineers, 2 DevOps engineers, 2 QAs, and 1 Product Manager. As a first-time lead engineer, leading a cross-cutting squad, it was overwhelming at first to keep everything in my head.

Mandates#

In the beginning, I was given clear mandates to:

• Improve the quality of feature delivery
• Improve the speed of feature delivery
• Improve infra & product stability

Here’s how I tackle these problems:

Improve the quality of feature delivery#

Before I joined the team, they were steadily delivering features. But when they’re working on complex features, they’ve had to change their plans a couple of times during development. This situation is not ideal because it would extend the project timeline, and much of the development done would have to be redone.

What I did was, the team and I would gather and discuss the solution thoroughly, prepare a tech spec document, and get feedback from across the company before executing the plan. This way, we could uncover problems and pitfalls, pivot before spending time implementing the solution. There is no perfect solution, but as long as we are aware of the trade-offs we’re taking, we are good.

I personally spend a lot of time writing and reviewing the tech spec in the team. The clearer the tech spec, the smoother the project delivery is. Not to mention, I also spend a lot of time reviewing PRs.

“The problem is already solved when you start writing the code” - saw this somewhere in LinkedIn

I’m glad that my previous experience working with cloud, backend, distributed system, database, and (slight) frontend helps the team.

What’s changing: we’re writing a clear tech spec and task breakdown rather than a vague one.

Improve the speed of feature delivery#

In addition to the clear tech spec mentioned above, here are some of my efforts to improve feature delivery speed:

• Write scripts that solve everyday problems in the team.
• Encourage knowledge sharing and pair programming in the team.
• Clarify all of the issues in the team after the daily standup

Improve infra & product stability#

Before I joined the team, the infrastructure was not exceptionally stable. After talking to the team, we found out that the team’s practice wasn’t using the dev environment as much.

What’s changing: we adopted a shift-left mindset and use the dev (and soon, the ephemeral local/test environment) more effectively. The infrastructure is much more stable since then.

I’m also trying to encourage the team the mindset “You should be able to touch any part of your code”.

First time doing people management#

Throughout my career, I have had more than 8 managers. Some of them were great; some were not. From those experiences, and also from my readings, I have come up with my own guiding principles on managing people:

• Always listen more than talk. Create more opportunities for subordinates to raise issues and untangle problems within the team. They spend more time writing code and deploying to production, so it’s best to listen to their stories before something bad (incident) happens. An egoless leader who listens to the team members is the best kind, in my opinion.
• Care about individuals as people, not just as commodities. I was personally touched when my manager cared about my well-being, my growth, my health, and, to some extent, my family.
• Resolve conflicts & discuss the ugly parts together. I appreciate when my manager is transparent with me and discusses the difficult parts rather than making assumptions about me or, worse, talking about me behind my back.
• Give opportunities to the team members while guiding them. The more mistakes they make, the more mature they are. Of course, it has to be within a controlled perimeter. The level of attention required depends on their level.
• Blameless culture. In my opinion, punishing team members for mistakes will hinder honesty and discourage innovation. People will resort to the usual practice rather than try new things because they’re afraid they’ll get punished for ‘doing it differently’. Moreover, the team cannot learn from their mistakes, because everyone is scared and refuses to reveal too much.

What helped me get here#

• Be an active participant. If you’re on the receiving end, understand why it was decided that way. Question and challenge everything (respectfully) instead of just accepting it as it is.
• During my internship at Onapp, I was assigned to all teams across the company: Backend, API, and QA. From there, I’ve seen all sorts of works & and tech stacks used by each team. Similar to my experience at Seek, I was on the Frontend team, where I wrote React and Node.js, and on the Platform team, where I wrote Golang & worked with AWS.
• Books I recommend: The Staff Engineer’s Path by Tanya Riley taught me how to navigate the organization, and Software Engineering at Google taught me the mistakes & lessons they had at Google.

New challenges#

Now that the team members are so productive, we are encountering a bottleneck in testing & QA. As we hire more QAs, how do we keep everyone productive with our setup.

Other than that, I’m also trying to balance between managing up, managing down, and essentially stakeholders from all directions. This is new to me because, previously, as an Individual Contributor, I didn’t have to consider others.

Fin#

I really appreciate everyone who trust me ☺️