What does a group Tech Lead actually do?
It’s been about ten months since I officially took on the role of Group Tech Lead, and I’ve begun to understand the bigger picture of what it entails and what my responsibilities are. It’s worth noting that the role definition varies greatly between companies and individuals. In this blog post, I’ll share my own experiences and insights on what it means to be a Group Tech Lead, and what I believe to be the best way to approach this role.
At Melio, we have a Team Lead and Tech Lead for each team, and a Group Lead and Group Tech Lead for each group, which typically consists of 3–4 teams.
From the very beginning of my career as an engineer, I’ve always dreamed of eventually becoming an architect. I thought that entailed being the person who makes all the important decisions and who others come to for answers to their biggest problems. But, as it turns out, that is not entirely true. Being at a high technical leading level doesn’t mean that all important decisions have to go through one person who knows everything. Instead, it means learning to delegate important decisions and building a strong team around you. This is a challenging skill to develop, and it’s something that a software engineer usually isn’t required to learn.
Of course, being a strong engineer is still essential and as a Group Tech Lead, I’m frequently invited to technical design sessions and other decision-making meetings where I need to bring value, stay current with technology, and understand the different options available. But as the company grows, it’s important to remember that my role is not only to make smart decisions but also to empower the people around me to make decisions even when I’m not available. This means trusting them and being aware that they might take a different approach than I would, but as long as it solves the problem and meets the requirements at hand, we can learn from it together.
If you’re considering becoming a tech lead, you’ve probably heard this phrase a million times and are probably tired of hearing it–but it’s true: this position is not for everyone. There are many advantages to being a highly skilled engineer. You can work on whatever you want, write code for most of the day (which is my number one hobby), and good companies know how to compensate these individuals. I am not saying that I don’t love my current role; it’s quite the opposite. However, it’s a completely different role from that of an engineer. I probably write code about 20% of the time, if not less (I still write code on the weekends because, as I said, it’s my hobby).
Here is the type of work you would typically find me engaged in:
👨🎨 Creating a visionary high-level architecture plan
What will the architecture look like one year from now? How about two years? A company needs an engineering vision. This typically involves a document accompanied by high-level diagrams. It’s worth breaking it down into different phases with specific dates so it becomes actionable.
Examples: Moving to microservices, experimenting with serverless architecture, supporting multiple regions, specifying bounded contexts, etc.
Promoting the visionary high-level architecture plan
It’s not sufficient to simply create the documents. It’s also crucial to share them with others, seek feedback, improve upon them, and present them to the entire R&D team to ensure everyone is on the same page.
🙇🏽 Participating in tech design sessions
I don’t require anyone to invite me. If someone decides to, I am grateful that they did and will be present, listen very carefully, and in most cases will raise concerns once other participants are done asking questions. I might even schedule a separate session with the presenters. By letting others speak first, there’s a good chance someone will ask my question. And if there’s no time left? That’s great, now I can ask the question in a less formal setting.
🦸♀️ Empowering
Identifying the right individuals who have the potential to lead the company and figuring out how I can assist them in reaching their full potential is one of my main responsibilities. For example, have they given a presentation to the entire company before? If not, I can help them prepare and deliver one. Have they ever led a project from start to finish with complete ownership? If not, I can guide them through the process. Have they ever created a diagram for the entire organization to refer to? If not, I can help them create one.
💁♀️ Delegating
This is an area where I have plenty of room for improvement — identifying individuals who excel in specific areas and delegating tasks and responsibilities to them. It’s easy for me to give the right answer or to resolve an issue, but it’s much harder to find the people who will be the future experts in a specific domain and delegate to them while helping bring them up to speed. This not only requires technical knowledge but also leadership, mentoring, and coaching skills. It’s a continuous process of identifying and developing talents within the team and empowering them to take on more responsibilities.
👩🏽💻 Writing code
When I write code, I strive to add value by discovering new tools or patterns that have not been used before.
It’s important to stay engaged with the code to have the context of what engineers are working with and to experience pain points. This way, when giving architectural advice, it doesn’t seem disconnected. Ideas, when implemented, often look different than when first conceptualized
👨🏻💻 Code reviews
I wish I could review more pull requests (PRs). I try to prioritize the ones that I think are important or where I can add value. But, it’s important to note that trying to review every single PR can be overwhelming and counterproductive. In the past, I’ve seen tech leads act as gatekeepers and it ends up creating a bottleneck for the entire team. This does not benefit the company; in fact, it harms it.
I trust the engineers I work with and I believe that if they make a mistake they will fix it and learn from it. Having to review all PRs is like getting into a “zero bugs” race when in reality, bugs are a natural part of the learning process– just like I have learned from my own mistakes. So, I trust my teammates and focus on being supportive and helpful in the PRs that I do review. It’s all about striking a balance between quality control and empowering the team.
📃 Internal communication (APIs and documentation)
How do other teams communicate with ours? Do we find that the same requests keep coming up? Do some people seem to receive most of the questions?
I’ve found that better APIs and better documentation can help improve communication. I believe that working on this is crucial for helping other teams communicate more effectively with our group. It’s important to make sure that the information they need is easily accessible, and that they know who to reach out to if they have any questions. It’s also important to keep track of the most frequent requests and questions to see if there are any patterns or areas where we can improve communication.
🫢 Code smells
Searching for code smells is a task that never ends for engineers. It’s an ongoing process to keep the system maintainable. Everyone must take part in this effort to ensure the codebase remains in good shape.
🗺️ Missing diagrams
Same as code smells, there is a “missing diagram smell” when people start getting lost in a certain area, or alternatively, it takes a very long time for new people to learn that area.
I found that this is normally a sign of a missing architecture diagram that would speed up the learning curve and also serves as a good basis for discussions.
🤖 Missing software component smell
A deficient software component can be recognized by sections that perform inadequately, resulting in an increase in daily workload. This can be due to an implementation that frequently requires manual intervention, false positive errors, redundant logic, overly complex domains, and others.
Examples of missing components are a supporting service, a code-generating package, or a missing entity model. The incorporation of software components can simplify the development process and improve the overall development experience.
As someone with a thorough understanding of our system, I have the ability to identify incidents, assess their impact, and determine the time needed to construct relevant components.
🏛️ Participating in important architectural projects
I am involved in the planning and execution of large-scale projects that have a major impact on the company’s technological infrastructure and direction. I work closely with other leads and engineers to ensure that the projects run successfully.
I am typically involved in 3–4 projects simultaneously, in addition to the one that I am working on fully hands-on.
It is important for me to have at least one project in which I am fully hands-on so that I can stay in the code details, and experience the deployment life cycle.
Being involved in these projects doesn’t mean I lead them. Quite the opposite. This is the place where I can give others the opportunity to lead, while trying to assist with whatever I can.
🧑🏻🏫 Internal lectures
Conducting presentations and talks on important topics that could help the company improve technologically is also a key aspect of my role. Keeping the team updated on the latest technologies and industry trends, and discussing their implications for the company is crucial for continuous improvement and progress.
☕️ Coffee breaks and chit-chat with my colleagues
Taking coffee breaks with team members is extremely important. Even though I am not a team or group leader, I find it crucial to take the time to have casual conversations with my colleagues. Strong communication is key to effective teamwork and good communication begins with simple conversations. It allows me to get to know my colleagues on a more personal level, understand their perspective, and build trust. It also helps me keep an open line of communication and identify any potential issues or obstacles before they become a problem.
🕴️ Promoting myself For the benefit of the company
Writing tech blogs and speaking at conferences not only helps boost the company’s brand but also attracts top talent to the company and expands your professional network. Plus, it’s a fun way to share your knowledge and experience with others in the industry.
👩🏼💼 Interviewing
Interviews can be time-consuming, but at the end of the day, the process is crucial as it allows you to select the individuals who will be working closely with you.
This decision is incredibly impactful as the people you choose to work with will have a direct impact on the success of the company. It’s important to take the time to thoroughly evaluate candidates, their qualifications, and their fit with the company culture.
🤵🏻♂️ Attending important meetings
I only attend a meeting for which I fully understand the purpose and where I believe I can add value. When I do attend, I make sure to take notes and review them afterwards. This helps me stay focused during the meeting and retain important information. It also allows me to follow up on any action items or decisions made during the meeting.
👨⚕️ Randomly helping people
As an employee with domain knowledge, I try to assist as much as I can when asked for help — whether it’s in designing, bug investigation, or in more formal settings where my opinion is valued.
And here too, my goal is to delegate as much as possible and empower others to take on more responsibilities. This allows me to share my knowledge and experience while also helping others to grow and develop in their roles.
What I do not do:
Block PRs from being merged
Block those PRs? No way! If I were to do that, it would mean that the responsibility for the code falls on me, and not on the person who wrote it. And that’s just not empowering. Everyone should own their code all the way to the finish line — production.
Code styling
This may not be a major topic, but it’s important to me. When it comes to code styling, I believe it’s best left to the engineers who care about it. As a Group Technical Lead, my focus should be on larger issues and projects. Code styling is a task that can easily be taken on by an engineer who is passionate about it. Let’s enable our team members to take ownership of their code, including its appearance.
Solicit opinions
Even if I were a manager, I don’t believe that telling people what to do is ever a good approach. My goal is to work with smart and caring people who don’t need me to tell them what to do. It doesn’t feel good when people boss you around; it feels like they think they know better.
Instead of requesting something specific when reviewing a pull request or attending a meeting, I prefer to raise a question by outlining the potential issue I have in mind and solicit opinions. Often, I am pleasantly surprised by the responses and discover perspectives or insights that I had not previously considered.
Be proactive
It is essential to understand that even with the best planning and execution, unexpected challenges will inevitably arise. Rather than placing blame on specific individuals, it’s important to identify the underlying circumstances that contributed to the situation. Leaders should remain calm and take a proactive approach to find solutions that will benefit the team as a whole.
I would not be able to successfully execute any project without consistently building trust, which is the most central aspect of my work.
All strategies and actions are futile without it. I have observed individuals with impressive titles come and go with minimal impact, as they were unable to establish or maintain trust.
Trust is not something that can be gained overnight. It’s earned by showing genuine care for those you wish to gain trust from, being receptive to their feedback and new ideas, and consistently maintaining this attitude on a daily basis.
I haven’t met anyone who managed to lead without creating a personal connection and building trust. At the end of the day, it all starts and ends with trust.
