Introduction

I’ve been a Tech Lead for more than five years. During this time I’ve worked with different teams, business people and codebases, and I’ve learnt a lot along the way. I still don’t consider myself an expert, but I have learnt a few lessons that I wish I had understood earlier.

Being a Tech Lead isn’t only about knowing the most about the technology. In fact, the technical part is often not the hardest one. The difficult part is helping a group of people move in the same direction while keeping the software healthy and the business informed.

Communication is the most important skill

The first lesson is also the easiest to underestimate: communication matters more than most technical skills.

A Tech Lead communicates with developers, product managers, business people and sometimes customers. Each group has different concerns, and repeating the same technical explanation to everyone is not effective. Developers need enough context to make good implementation decisions. The business team needs to understand what is possible, what is risky and what is taking longer than expected and why.

My job is to understand what people need and help them reach a sensible decision. This requires listening carefully and asking questions before proposing a solution.

I also learnt to stay calm, especially when a discussion becomes difficult. There is no benefit in fighting with a colleague or reacting emotionally to pressure. A tense conversation can easily become personal, while the original problem remains unsolved. I try to focus on the facts, the data and the next actions. Being calm means having difficult conversations constructively, helping people understand my perspective while remaining open to rethinking my own process and communication.

Delegate and trust people

When I started leading, I sometimes thought that being responsible meant checking everything myself. This approach doesn’t scale and, more importantly, it sends a bad message to the team.

Delegating is not just distributing tasks. It means giving someone ownership and trusting them to make decisions. I still need to provide context, answer questions and review the result, but I shouldn’t control every small step.

Technical leadership depends on trust, and trust is built through repeated small actions. I try to do what I say I will do, admit when I don’t know something and give credit to the people who did the work.

I also try to be predictable. Colleagues should know that I will listen to their concerns, explain my decisions and raise a problem early instead of hiding it. I need to trust that developers will make a good-faith effort and ask for help when they need it.

This is especially important when working with the business team. They don’t need a promise that everything will be easy. They need an honest view of the situation so they can make decisions with the information available.

Take responsibility for the whole stack

A Tech Lead should have a broad view of the product: knowing enough about the frontend, backend, infrastructure, data and deployment process to understand how a decision affects the rest of the system.

I don’t wait for someone above me to tell me that a problem needs attention. If the build is slow, the deployment process is unreliable or an old dependency is creating risk, it is part of my responsibility to notice it and propose an improvement.

The same applies to best practices. The team needs sensible conventions around code reviews, testing, documentation, monitoring and security. These practices shouldn’t become bureaucracy, but ignoring them because there is always another feature to build creates a much bigger problem later, such as technical debt.

Being responsible for the technical direction also means making trade-offs visible. Sometimes the right decision is to move quickly with a temporary solution. Sometimes it is worth stopping to improve the foundation first. The important thing is to make the decision consciously and communicate its consequences.

Mentor with both standards and empathy

Mentoring other developers is one of the most rewarding parts of the role. It is also one of the easiest parts to get wrong.

I want the code and the decisions of the team to meet a high standard, so I can be strict about quality. But strictness without empathy quickly turns into discouragement. A code review should explain why something needs to change and help the other person improve.

People have different levels of experience, different ways of learning and different things happening in their lives. I can keep the technical expectation high while still being patient with the person learning how to meet it. The goal is for the other developer to need my help less often over time.

Estimates are imperfect

Estimating software delivery is almost impossible to do perfectly. Many many articles talk about this and all of them are worth reading. Requirements change, unknown technical problems appear and some tasks are simply more complicated than they looked at the beginning.

A rough estimate gives the business team something to plan around and forces the technical team to think about the work. I try to give an honest range instead of a fixed deadline, state the assumptions behind it and more important update it when those assumptions change. An estimation is mostly wrong by definition, but can be more and more precise when you are getting closer to the goal.

An estimate is a forecast based on what we know at that particular moment. As soon as you have more information, you should adapt the estimate accordingly.

Keep the business updated

One of the most useful habits I’ve developed is giving frequent updates. I don’t wait until a feature is completely finished before communicating.

An update can be simple: what has been completed, what I’m working on next and whether there are any risks or decisions needed. This gives the business team visibility and creates opportunities to correct the direction early.

People are generally more patient with delays when they understand what is happening. Silence creates uncertainty, and uncertainty is often interpreted as a lack of progress. Sharing progress early also makes feedback cheaper because a misunderstanding can be corrected before the feature is polished.

Conclusions

After five years, I think the role of a Tech Lead is mostly about creating the conditions for good work. That means communicating clearly, keeping calm under pressure, delegating instead of controlling, protecting the health of the whole stack and helping other developers grow.

The technical decisions still matter, of course. But a technically excellent decision that nobody understands or trusts won’t take the team very far. The best result is a team that can make good decisions together, deliver useful software and talk openly when something isn’t working.

That’s what I’m still trying to build, one conversation and one decision at a time, and most importantly, I’m enjoying it.