Our industry is infamous for confusing terms. Roles in software development are a good example. Titles like Architect, Tech Lead, Team Lead and Engineering Manager provide endless confusion. In this article, we’ll explore the definition of the Tech Lead role.
The Short: A Tech Lead is a software engineer responsible for leading a team and alignment of the technical direction.
The Long: A Tech Lead is a software engineer responsible for leading a team and alignment of the technical direction. Providing a strong technical direction involves establishing a technical vision, resolving technical disagreements and managing the technical quality of team deliverables. Effective technical leadership ensures the team uses appropriate engineering practices (such as CD or automated testing), invests in continual improvements to tooling or technical debt, and that the system evolves to meet its changing needs and environment.
Sometimes team leadership is shared but rarely technical leadership. A Tech Lead may co-lead a team with other roles like a Product Manager or Engineering Manager/Team Lead. Where a Product Manager focuses on the “What“, the Tech Lead focuses on the “How.” Where the Engineering Manager/Team Lead focuses on “People and Team Growth“, the Tech Lead focuses on “Technical Growth” of team members and the system. The unique focus for the Tech Lead is leading the technical direction and quality for the team. They may also have added responsibilities depending on the specific team.
In the above example, a team may have a Product Manager, an Engineering Manager and a Tech Lead. Leadership is shared between the three roles but each provides a different focus. In this situation, the Tech Lead focuses more on technical topics. They will be more involved in architecture discussions and decisions. They will observe and manage the quality of the codebase as it evolves and the technical growth of the team.
In the above example, a team may have only a Product Manager and a Tech Lead. In this situation, the Tech Lead inherits the Engineering Manager responsibilities. They additionally focus on people development (e.g. feedback or career conversations) and building a high performing team. This model works well with small teams or less complex systems. As a team grows in size or system grows in complexity, the Tech Lead has less time to focus on both areas. A Tech Lead in this context implicitly prioritises one focus area over another. From my personal experience, they usually prioritise technical topics to the detriment of people or team topics.
What holds true regardless of team composition is the Tech Lead’s technical leadership. An effective Tech Lead establishes a technical vision with the team. They work with the team to update and evolve it and turn it into reality. Tech Lead’s must keep involved with code to make informed decisions, identify technical risks and to maintain trust with developers. In my presentation, “The Geek’s Guide to Leading Teams“, I suggest an ideal minimum of 30% time with code.
Not just a team lead
Early in my career, I worked on a team that had both a Tech Lead and a Team Lead. The Team Lead didn’t have a strong architectural background. They would certainly write code, but they added value to the team in a different way. They focused very much on people development. The Team Lead had 1-to-1s with people focused on feedback and career development. They actively organised activities to build psychological safety and foster trust. The Team Lead would meet with stakeholders outside of the team keeping a good information flow, or to remove blockers.
Where the Team Lead focused on team issues, the Tech Lead focused on technical topics affecting more than one developer. The Tech Lead mediated technical debates. They participated in building solutions for performance optimisations. They lead discussions on decisions that might constrain or broaden future architectural choices. They, too, met with external stakeholders but focused on technical topics. They met with infrastructure people to understand network or hardware changes. They met with other Tech Leads to ensure our system fit in with the broader company ecosystem. They met with product people to ensure our architecture supported future work.
More hands-on than an Engineering Manager
Like a Tech Lead, our industry has no common definition for the Engineering Manager. You’ll find this title varies across companies and will vary even in the same company. Some Engineering Managers are like Tech Leads, but there are many who are very different. For example, many don’t write code day-to-day. Instead they focus on:
- Maintaining a productive working environment for development teams
- Acquiring appropriate budget for development to support business goals
- Representing the technology perspective on a management or board level
- Establishing and/or co-ordinating programmes of work (delivered through development)
- Recruiting and retention to meet team or IT headcount
An Engineering Manager may sit at a team level but they also sit at a team of teams level. Many Engineering Managers may not have a development background. They may, instead, have been a Project Manager, QA or other role still involved in software.
A good Architect looks like a Tech Lead
The Architect role ensures the overall application architecture fits the business context, both now and in the future. In some organisations, Architects work with the team to establish and validate the architectural vision. Architects also look at finding the right balance of standardisation. A suitable amount of standardisation supports productivity. Too much standardisation kills innovation.
Some organisations have the “Ivory Tower Architect” who swoops in to consult, standardise and document. They float from team-to-team, start new software projects, and rarely follow up to see the result of their initial architectural vision. This is not what a Tech Lead looks like.
An effective Architect looks like a good Tech Lead. They understand what their team goals are and establish an appropriate architectural vision. They work with the team to adjust this as the team learns more about the problem and technology chosen to solve it.
What are the core skills of a Tech Lead?
Although the scope of a Tech Lead varies, the required skills do not. A Tech Lead needs to build a set of balanced skills in the following areas:
- Development – A Tech Lead must have a background as a developer. They need to know how to write code and what good quality code looks like. They should be able to help their team with any technical challenges they have, even when they are not necessarily the expert.
- Architecture – Development is only one part of building a working system. Tech Leads must have a broader understanding of how software fits into the overall system. They need a good understanding about how software will be deployed, managed and operated in a production environment.
- Leadership – An effective Tech Lead needs to have strong leadership skills, even when they are not accountable for line management. Leadership skills like coaching, influencing and delegation are keys to success.
What’s a Tech Lead again?
A Tech Lead is a software engineer responsible for leading a team and alignment of the technical direction. They may co-lead a team with other roles like a Product Manager or a Team Lead or Engineering Manager. But the Tech Lead has a unique focus on the technical aspects, or the “How.” An effective Tech Lead blends strong leadership skills, architecture skills and development skills. They steer their team towards a common technical vision. They are accountable for the quality of the technical deliverables for the team.
If you want to know more the Tech Lead role:
- Get a copy of “Talking with Tech Leads“, a book sharing real life experiences from over 35 Tech Leads around the world via Leanpub or Amazon.
- Sign up for Level Up, a curated newsletter for leaders in tech.
- Register for a training course at the Tech Lead Academy to grow your technical leadership skills.
21 thoughts on “The Definition of a Tech Lead”
Thank you so much for writing.🤩
Can you give examples of day to day work done by tech leads?
Hi Said. Thanks for your comment. What a Tech Lead does will differ from team to team and day-to-day, but some of what a Tech Lead does includes writing code, resolving technical conflicts in the team, building bridges and agreements with other teams (e.g. API contracts, etc), helping team members with technical challenges, finding ways to improve the team environment. This list isn’t meant to be exhaustive but shares some concrete examples.
Thank you for sharing this information. I am new at the role (Tech Lead). So, I am learning how to be a good at this by watching your performances at conferences and reading your articles. I even have applied for a job in N26 🙂 Let’s see the results!
Again, thanks. Really helpful!
Glad it’s been very helpful
thanks for this info. Especially the images showing the relationship between Tech lead, Engineering lead and Product Manager. It is very useful!
Thank you. As George EP Box once said, “All models are wrong, but some are useful.” I hope these remain useful 😉
Hi Patrick, great article!!
In your experiences, do Tech Leads respond to (and later become one) Engineering Managers? Or their roles belong to separate careers and have a separate leadership?
Thanks for your comment. Our industry is very inconsistent in this sense, and your experience will depend on the companies you look for. A helpful article to understand this difference is 5 Engineering Manager Archetypes. You’ll notice one of these is the Tech Lead Engineering Manager.
I got a promotion to tech lead and I need to change my mind (or combine) leadership and technical skill. This article will help me a lot. Thanks!!!
You’re welcome! Congratulations and I wish you all the best in your new role.
Thanks for the description of the function. I’ve encoutered some issue to explain to my HR direction the difference between Architect & Tech Lead. this sounds clear to me now.
I’m glad the article has helped you. I appreciate the comment
Interessting write! So, according to the above other role names would be Staff Engineer or Lead Developer? I would’ve considered the role of a Tech Lead close to the architect, but being responsible and accountable of the overall technical aspects, issues and alignment of serveral engineering/product teams.
I’ve definitely worked with people who have a Lead Developer title and their responsibilities look like a Tech Lead. Staff Engineer is a newer (more popular in the US/US-centric companies) and one of the archetypes sometimes overlaps (but not always).
Yeah, I guess the size of the company matters here. Bigger companies usally tend to introduce more roles with fancy names.
At the end it’s important someone feels responsible for the topics you described, understands the overlapping and where to draw the lines.
Your text is very clear for me. Congrats!
This text is very illuminating from a practical perspective.
I’m attempting to study the transition from a developer to a more leadership oriented role in an academic context and I’m attempting to use the perspective of someone who is transitioning into a tech lead role.
I’ve previously read your book ‘Talking with Tech Leads’ and scoured through academic sources that make mention of the role.
Your materials are illuminating from a practical perspective, but they aren’t peer reviewed and as such they can only be used in a limited capacity.
I was wondering, as you seem to have been engaged with this topic for over half a decade, if you happen to have some leads for finding more academic sources that make direct mention of the role? For instance this blog post is likely mostly based on personal experience–but do you happen to know of any academic sources you could attach to it? For instance your book Talking with Tech Leads has been referenced in academic sources of which I think I’ve gone through most.
For now my experience is that academic sources that deal with the role do not exists in abundance–rather there are only a handful. I’ve defaulted to finding academic literature that defines relationships between roles in order to define the role by what it is like and what it isn’t.
Thanks for your comment and reading the material I’ve shared. You’re right in that the material I have published is not published in accordance to a specific academic research method. Although my writing is technically peer-reviewed by other industry people, it may not come appear like this from your perspective, so feel free to use these materials in whatever way you might find useful.
I am unaware of any formal academic studies that also study this role, but feel free to contact me if you do find any.
All the best