Tech Lead Rules #1 — Diving Deep into the Trenches

We often say we should listen to the voices on the ground because they are the ones actually doing the work, and the same goes for software development.

However, becoming a Tech Lead requires more than just understanding the code itself; more importantly, you must have a comprehensive understanding of the entire project. Here are a few areas I consider crucial.

Introduction

A year ago, I wrote “Some Reflections on Becoming a Tech Lead.” Over the past year, I’ve learned a lot, and recently I also published “Setting Up a Server at the Company Wasn’t as Simple as I Thought.” This article serves as a set of personal notes, organizing what I believe are the essential qualities and knowledge required to be a Tech Lead. I hope it can also help readers who are wondering what a Tech Lead should actually be doing.

What Frameworks and Technologies Are Used in the Project

Taking the front end as an example:

• Are frontend frameworks being used? What are their new versions and features?
• Does it support SSR?
• How are APIs integrated? GraphQL, RESTful API, or gRPC?
• Having a basic understanding of the backend programming languages and architecture.

Software engineers assigned to be Tech Leads are usually those who can reliably complete assigned tasks, help solve project issues, and keep track of team progress—at the very least, it means their coding ability is not a major concern. Since they contribute to the project as an IC (Individual Contributor), this part is generally well-covered.

As for why you need to understand the backend programming languages and architecture: aside from designers, API integration is what frontend developers work most closely with. Understanding the problems the backend faces under its current architecture might help you discuss better solutions together, and you might even be able to help them solve their issues.

What Important Business Logic Exists in the Project

In financial services, critical business logic includes how deductions are executed, when they occur, how users are authenticated, how personal data should be stored, and so forth. For the front end, these often seem like things the backend should handle, but understanding the underlying mechanisms prepares you for future requirements.

When displaying large monetary amounts, is BigInt used to prevent overflow? Is floating-point arithmetic handled with proper care during currency conversions? Is decimal rounding handled on the front end or the back end? Are there strict requirements for time handling (must be standard server time, users cannot arbitrarily tamper with it, etc.)? These are all extremely important aspects of projects involving financial services.

While understanding business logic, developers usually also need domain knowledge in this area, and in financial services, you even need a basic awareness of relevant legal regulations.

How the Project Is Deployed

Although not directly related to feature development itself, knowing how code is deployed is immensely helpful for driving various process improvements.

Suppose the current project uses Docker: first, the project is packaged into an image, then uploaded to the company’s private Docker Hub, and finally, the deployment machine pulls and executes it.

There are many details worth paying attention to here: Who performs the image upload? Where are tokens configured? Does the deployment machine’s ACL allow access to Docker Hub? How are tokens passed? While these fall well outside the typical frontend wheelhouse, the deeper your understanding, the better equipped you are to push for what you want to achieve. For instance, if you want to spin up a new machine to introduce SSR, already knowing the deployment pipeline lets you quickly figure out how to write the deployment scripts, foresee where you might hit a wall, and address potential issues in advance.

Additionally, you can observe deployment times to optimize the workflow. For example, if dependencies are reinstalled every time the image builds, prolonging deployment time, you can try extracting the common parts into a separate base image to cut down on installation time and speed up overall deployments.

The Entire Flow from Request Sent to Server Received

• Does it pass through a load balancer?
• How many machines are there in the production environment, and what are their respective specs?
• Which region are the machines deployed in?
• Are static files hosted on the server or a CDN?
• Is there a reverse proxy (Nginx or Envoy)?
  • Are there specific rewrite/redirect rules you need to be aware of?
• Which port is the server running on?

Understanding the History

Sometimes, when looking at bad code, the voice inside your head screams: “Why was it written this way? WHY???” Aside from the genuinely careless “I just don’t care” kind of bad code, I’ve recently learned to appreciate the history behind it. Sometimes it was due to an extremely tight deadline; sometimes the business requirements were truly bizarre and clashed with the existing architecture; sometimes it was a trade-off made during architectural evolution. Once you look at it through a historical lens, you might actually end up admiring it.

Understanding the Needs of Various Stakeholders

When conflicts arise in a project, beyond poor communication, it’s often because people don’t know what the other side truly cares about. For instance, a project’s timeline gets squeezed inexplicably tight. The developers are under immense pressure to rush, thinking the PM simply wants to cut development time for no good reason. But in reality, the project is tied to new regulatory policies and must be released before the deadline to avoid hefty fines for non-compliance.

Things like this aren’t always deliberately concealed; sometimes the information just wasn’t broadcast to the whole department, or someone forgot to relay it along the chain.

I think a crucial mindset here is to believe that the other party’s problem is a real problem. It might seem foolish or unreasonable from a developer’s perspective, but if you approach it with the assumption that “everyone wants to make this project better,” the outcome will likely be completely different. (Unless someone is genuinely trying to cause trouble.)

Another point is to speak up whenever you have questions. Everyone agrees that asking questions is fine, even “dumb” questions, but many software engineers have strong egos and worry that asking will make them look incompetent. So even while seething inside, they quietly finish building the feature. In moments like these, a single question or a bit of clarification can often defuse a crisis (and if it can’t… well, you probably know what to do).

Conclusion

These things are important not just because you’re a Tech Lead and therefore “supposed” to know them; they help you effectively leverage existing resources to solve problems whenever you face a new project, new requirements, or team bottlenecks.

For new requirements or improvements, development speed and quality often hinge on your understanding of the existing architecture. Suppose a new requirement asks for image uploads with thumbnail generation. If a similar module already exists in another feature, you might only need to tweak the existing functionality. But if the Tech Lead is unaware of it, the team could end up wasting far more time and resources reinventing the wheel.

The team will also frequently discuss technical decisions or implementation details for specific requirements with the Tech Lead, and everything mentioned above provides great material to help you offer sound insights. Only by diving deep into the architecture, understanding the struggles developers face, and clarifying everyone’s needs can you keep new requirements and solutions grounded in reality rather than wishful thinking.

Postscript

Reflecting on my article “Some Reflections on Becoming a Tech Lead” from a year ago, I find that I don’t care quite as much about whether I get a raise anymore (though I still care a bit). Part of this is because I’m relatively content with my current role, working style, and day-to-day responsibilities; another part is realizing that everyone has their own way of working, and as long as I do my part well with a clear conscience, that’s enough.

I might still vent a bit on Twitter privately, but I still want to maximize team productivity as much as possible and continue improving our development processes and projects.