What’s a Tech Lead?

First of all, let’s clarify something: In many companies, what they call a Tech Lead is what is actually a TLM (Tech Lead Manager), meaning a Tech Lead who also has management responsibilities, especially in people management. In this article, I will focus specifically on the responsibilities of a Tech Lead. If you want to know the responsibilities of a manager, I describe them here.

Let’s start with the obvious; a Tech Lead is not a manager. And let’s continue with the first thing people confuse with that phrase, this doesn’t mean they don’t have responsibilities regarding the career development of others. In reality, this should apply — or should be applied — to any senior.

Yes, it’s a technical person. But its responsibility is not solely focused on programming; on the contrary, its areas are technical direction (breadth knowledge e.g., testing, CI/CD, observability, etc.), understanding the company’s needs, understanding the product (especially the part/area they are responsible for), and leadership (accountability, backbone, delivery…).

The impact of a tech lead is expected to go beyond the individual scope, although this could be said of anyone working in a team, there is a big difference. In a tech lead, their main focus is the team, the group, the area, and the company. That is, beyond programming or designing, the most important work is strategic. Reviewing that everything that comes out of the team (and even the area in some companies) makes sense from all perspectives:

1. Solves the real problem. That is, it solves what is really important, what affects clients, what is pressing right now, etc.
2. Its design fits within the technical strategy (imagine building a component in Rust and on-premise when everything else is done in Ruby and cloud).
3. It takes into account its maintenance: operability, monitoring, alerts.

Communication

Additionally, a Tech Lead is an excellent communicator. They write well, especially technical documents. They have the ability to speak in public, to present ideas to different audiences, for example, in the company’s All Hands.

They are able to speak with different stakeholders, and different roles within the company such as Directors, CEO, CTO, VPs, managers, engineers, etc.

Pushback

Another key aspect of a Tech Lead is that they should not be afraid to push back, to give their opinion, to push for what they think is right (they understand perfectly the needs of the company and that is what they use to prioritize at all times).

Accountability

A person who not only has ownership, it’s able to take a problem and carry it/lead it to the end, but also makes others accountable for the same.

They have no problem asking uncomfortable questions to make sure they are going in the right direction, to uncover unknowns, they are not uncomfortable challenging others’ ideas if they believe they are not good, if they do not address the real problem, or to fully understand the problem.

Backbone

A Tech Lead must have strong opinions, must have determination, push for their ideas with arguments, and must make decisions. That is, they are expected to have opinions, to have conviction in them, and to push hard. Not to give in to please the group, not to be swayed by Group Thinking. But they also have to know how to Disagree and Commit.

Big Picture

They also have to have the ability to see things with a layer of abstraction, that is, they are able to see the forest not only the tree. They don’t get lost in the details that lead you to solve a problem that is not really important, or that lead you to solve just a part of the problem but do not get you out of the hole you are in. An example I already mentioned in a newsletter: programming something from scratch in a new language because it’s faster when the real problem we had was how to scale horizontally..

Seniority

In the literature on tech leads, even in the famous book The Manager’s Path, it is mentioned that you don’t have to be the best engineer to be a tech lead, but I think this is confusing. Yes, it is important to understand that this role does not have to be performed by the most senior person or the best programmer. But they must have a fairly broad knowledge and some seniority in many areas of software development. Even being an expert in some of them is more than recommended.

Many articles explain that Tech Leads are T-Shape engineers, that is, engineers who delve deeply into one area and then have some knowledge of many others. However, in my opinion, and in the current moment where teams rarely touch only a very specific part like backend or frontend. A Tech Lead is more like an M-Shape engineer. They don’t need to have a deep knowledge of all areas (to the point of being an expert) but certainly, it’s not enough to have superficial knowledge. For example, it is expected to have good judgment in architecture, system design, monitoring, CI/CD, etc.

Product/Domain Knowledge

It is also expected that a Tech Lead has an excellent knowledge of the product, especially of their area. A TL frequently collaborates with product managers to understand customer needs and business priorities, as well as to help prioritize and coordinate initiatives. This is also essential to be able to make decisions when designs are proposed, proposals are reviewed, etc. Without knowing the business, it is difficult to push in the right direction. That’s why it’s vital to understand who your customers are, where the business is lagging, what strategy the company has, what OKRs, KPIs your area, team, etc. have.

That is, they must have total knowledge of the Problem space.

Programming

Obviously, a Tech Lead codes on a daily basis and has a good knowledge of the code base and architecture, but much of the day is spent on activities that some mistakenly consider Management. Many meetings, reviewing documents, technical proposals from others, product ideas, follow-up meetings, design meetings, architecture, initiatives.

What is their job in reviewing these proposals? Mostly to ensure that the solution is in line with the company’s technical strategy, that it solves the business problem, that it takes into account things like monitoring, alerting, observability, etc. And yes, sometimes there is also a lot of project management, making sure it is feasible, that it is phased, etc. Although this depends a lot on the company, in some companies, this is entirely the responsibility of the manager, project manager, or Technical Program Manager.

I would say that if your goal is to be 100% focused on programming, you will not enjoy this role. Because you cannot have tunnel vision on a feature, on a single problem, you have to be aware of what is happening within your area, your team, and be able to develop a strategic vision.

Politics

A good part of a TL’s work is influencing, and for that, they have to know the “politics” of the company to be able to move or unblock initiatives. What do I mean by politics? Knowing what message to give, to whom, where to present their proposals, knowing how to do buy-in.

Mentorship

I already said at the beginning that not being a manager does not mean you don’t have responsibilities in people’s careers. It is expected of a Tech Lead to help people grow, to improve by doing things like pairing, reviews, etc. The coaching part usually falls more on a manager and the mentoring more on the TL, but in the end, coaching is just another tool to help people solve problems on their own, so it is not unusual for a TL to also use it.

Quality and Speed

In many companies, a TL is also responsible for the team’s quality, meaning, ensuring that good practices are followed both in software development and at the architecture level. This doesn’t mean they decide how to implement things, but it is expected that they supervise and challenge, as mentioned above, to maintain good quality and speed. I intentionally included speed in the quality part because a TL is expected to design solutions that are not house of cards but also not over-engineered. This seems simple but is one of the most complicated things; one must understand very well the benefit obtained for the effort required. And to prioritize the company’s needs over what we feel like doing or what we think should be done to be well programmed/architected.

Now that the qualities have been mentioned, I’ll share an example of the responsibilities we expect from the people we consider TLs at Tinybird.

1. Leads conversations (with customers, with the team).
2. Able to successfully interact at senior and junior levels within the organization.
3. Communicates proactively.
4. Solves uncertainty (gathering info from any stakeholders, systems, docs, etc).
5. Develops an opinion of where the project should go.
6. Able to vary the direction of the project (or tactic or task) in smart ways to keep moving toward the objective.
7. Detail-oriented without ever losing a strong strategic perspective.
8. Has Backbone; Disagrees and Commits. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion.
9. Calm under the pressure of implementation and deadlines.
10. A strong listener with great skill at asking questions.
11. Adept at anticipating potential problems and addressing them early.
12. Resilient in order to recover from setbacks.
13. Consistent in how they respond to comparable situations.
14. Able to deliver. It’s able to take on any initiative small or complex from start to finish
15. Has a business sense — understands what we are trying to achieve as a company and keeps that in mind when making decisions
16. Instills a sense of urgency in the team

Finally, as you can see, a TL will spend a good part of their time reviewing or making technical proposals. So, this article that I wrote a few weeks ago is the perfect complement.

https://blog.get-merit.com/the-role-of-the-tech-lead/

The manager’s path

https://dev.to/thawkin3/lessons-from-a-tech-lead-roles-responsibilities-and-words-of-advice-ldj