Tech Lead Guideline 1 — Dive into the grassroots level.

We often say that we need to listen to the voices of frontline staff, because they are the ones truly getting the job done, and the same applies to development.

However, becoming a Tech Lead requires not only an understanding of the code itself but also a comprehensive understanding of the entire project. Below are a few key areas that I believe are very important.

Introduction

A year ago, I wrote about “Some Thoughts on Becoming a Tech Lead”. Over the past year, I've learned many things, and recently I published an article titled “Setting up a Server at the Company Is Not as Simple as I Thought”. This article serves as a summary of what I think a Tech Lead should possess, acting as a personal note. I hope it can also help readers who are struggling with what a Tech Lead should do.

Frameworks and Technologies Used in the Project

Taking the frontend as an example:

• Is there a frontend framework being used, and what are its new features and versions?
• Is there support for SSR?
• How are APIs connected—GraphQL, RESTful API, or gRPC?
• Have a basic understanding of the programming languages and architecture used in the backend.

Typically, software engineers who are appointed as Tech Leads are expected to complete assigned tasks successfully, assist the project in solving problems, and keep track of team progress—this at least implies that they have no significant issues with coding. Since they are contributing as Individual Contributors (ICs) in the project, there shouldn't be any major problems in this regard.

As for why it’s important to understand the programming languages and architecture used in the backend, it's because the API integration, aside from design, closely collaborates with the frontend. Understanding the problems encountered in the existing architecture can help facilitate discussions with the backend team to arrive at more suitable solutions, or even help resolve issues on their side.

Important Business Logic in the Project

In financial services, some critical business logic includes how to process deductions, when to do it, how to verify user identities, and how personal data should be stored, among others. For the frontend, these are often tasks that should be handled by the backend. However, understanding the underlying mechanisms is essential for preparing for future requirements.

When handling larger amounts, are BigInts used to avoid overflow? Is there sufficient attention to floating-point issues during currency conversion? Is the handling of rounding decimals done on the frontend or backend? Are there strict requirements for time handling (e.g., must adhere to standard time, users cannot arbitrarily adjust it)? These are all crucial aspects of projects involving financial services.

In addition to understanding business logic, developers usually need some domain knowledge in this area, and in financial services, they may even need to be aware of relevant legal considerations.

How the Project Is Deployed

Although this may not be directly related to project development itself, knowing how the code is deployed is quite helpful for driving various process improvements.

Assuming the current project uses Docker, first, the project is packaged into an image, which is then uploaded to the company's private Docker hub, and the deployment machines will then pull and execute it.

There are many points to note here: Who executes the upload of the image? Where is the token set? Can the deployment machines' ACL access the Docker hub? How is the token transmitted? Although these aspects may extend beyond the frontend's responsibilities, the deeper your understanding, the more effectively you can push for the changes you want. For instance, if you want to set up a new machine to implement SSR, knowing the deployment process in advance allows you to quickly understand how to write the scripts and identify potential hurdles to address them beforehand.

Additionally, you can observe deployment times to improve processes. For instance, if every image requires re-installing dependencies, which extends the deployment time, you could try packaging common parts separately to reduce installation time, thus speeding up the overall deployment process.

The Entire Process from Request to Server Reception

• Will it go through a load balancer?
• How many machines are in the production environment, and what are their specs?
• Where are the machines deployed?
• Are static files stored on the machines or on a CDN?
• Is there a reverse proxy (nginx or envoy)?
  • Are there specific rewrite/redirect rules that need to be understood?
• On which port is the server running?

Understanding History

Sometimes, when I see poorly written code, I can't help but shout internally: “Why was it written this way? WHY???” Putting aside the "I just suck" kind of bad code, I've recently learned to understand the history behind it. Sometimes it's due to tight deadlines, other times it’s because of bizarre business requirements that conflict with the existing structure, or due to trade-offs made during architectural evolution. When you consider it from a historical perspective, you might even find it admirable at times.

Understanding Diverse Needs

When conflicts arise in a project, aside from communication breakdowns, it often happens because parties are unaware of each other's concerns. For example, if a project timeline is inexplicably tightened, developers may feel immense pressure to meet deadlines, believing that it's just the PM wanting to cut down development time. However, the reality might be that the project relates to new regulatory requirements that must be completed before the new rules come into effect, or else the company risks being fined for non-compliance.

These situations often aren't deliberately hidden; it might just be that not everyone is informed, or communication was simply forgotten along the way.

I believe a crucial point here is to believe that the issues others face are indeed issues. A problem that seems trivial or unreasonable from a developer's perspective might make sense when viewed through the lens of “everyone wants this project to succeed.” The resulting outcomes would likely be entirely different (unless someone is truly out to create trouble).

Another important point is to raise issues when they arise. Everyone should feel free to ask questions, even seemingly dumb ones. However, many software engineers may have stronger pride and fear that asking questions will lead to embarrassment, so they silently complete their tasks even when frustrated. Often, a single question or a bit more clarification can resolve a crisis (if not, then... well, you should know how to handle it).

Conclusion

The importance of these matters lies not just in the fact that, as a Tech Lead, you should understand them. These insights can help you effectively utilize existing resources to solve problems when faced with new projects, new requirements, or bottlenecks within the team.

For new requirements or improvements, the speed and quality of development often depend on understanding the existing architecture. Today, there might be a new requirement to upload images and generate thumbnails. If there’s a similar module already in a certain feature, only modifications to existing functionality are needed. However, if the Tech Lead is unaware of this, the consequence could be spending more time and resources.

Teams also frequently discuss various technical decisions or implementations of specific requirements with their Tech Lead. The aforementioned points provide valuable material to formulate insights. Only by truly delving into the architecture and understanding the challenges developers face, as well as clarifying each other's needs, can new requirements or solutions avoid becoming mere flights of fancy.

Postscript

In the article “Some Thoughts on Becoming a Tech Lead” written a year ago, I realized that I no longer care as much about salary increases (though I still do care). On one hand, I am satisfied with my current position and work style; on the other, I’ve come to realize that everyone has their own work style, and as long as I do my job well, I can feel content.

I might still complain a bit on Twitter privately, but I still aim to improve the team’s productivity as much as possible and continue enhancing the existing development processes and projects.