These could feasibly be the same thing, or wildly different, depending on the organization.
For me, Tech Lead is easier to define:
Senior technical team member.
~30% of their time is still spent writing code.
The remaining ~70% is eliminating technical blockers, setting and evolving tech strategy, working with product owners and project managers to define and deliver the product vision as well as empowering, growing and onboarding their team members.
I like to think of the role as a Software Developer who lightly manages the team, from within the team.
A Team Lead (in a big business, traditional sort of sense) may differ in that they:
Aren't necessarily a technical team member (or may be post-technical in the sense that they haven't written code in a good long while).
Manage the team from the outside.
Concern themselves more with budgets and timelines than technical outcomes.
May be more involved in HR activities, like approving leave, reviewing salaries etc.
Neither of these lists are exhaustive in terms of responsibility, and the venn diagram of what role has what responsibility will vary from business to business.
What I will say is: Whether this is two roles, or one role serving both functions, all of the above is necessary for a team to perform well.
My ultimate bugbear is "Tech Leads" who don't work within a team and don't write code, issuing orders from their weird, architect-y, tower. This can lead to a disconnect between tech strategy and implementation that will derail any team and/or product.
My second ultimate bugbear is "Tech Leads" who refuse to consider business context when making technical decisions, and are only interested in writing code. This leads to building "cool" technologies that don't serve their stated purpose.
This aligns closely with what I have in mind. I love your term "bugbear" - both are definitely in my bugbear list also.
The "architect-y" tower reminds me of leaders who insist on having things done in specific ways without knowing what exactly the impact of what they're asking for.
The 2nd one is crucial since majority of software is written for business purposes and therefore, really needs consideration and to not do so would actually create technical debt and cost the business $$$ in the long term.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
These could feasibly be the same thing, or wildly different, depending on the organization.
For me, Tech Lead is easier to define:
I like to think of the role as a Software Developer who lightly manages the team, from within the team.
A Team Lead (in a big business, traditional sort of sense) may differ in that they:
Neither of these lists are exhaustive in terms of responsibility, and the venn diagram of what role has what responsibility will vary from business to business.
What I will say is: Whether this is two roles, or one role serving both functions, all of the above is necessary for a team to perform well.
My ultimate bugbear is "Tech Leads" who don't work within a team and don't write code, issuing orders from their weird, architect-y, tower. This can lead to a disconnect between tech strategy and implementation that will derail any team and/or product.
My second ultimate bugbear is "Tech Leads" who refuse to consider business context when making technical decisions, and are only interested in writing code. This leads to building "cool" technologies that don't serve their stated purpose.
What a great answer!
This aligns closely with what I have in mind. I love your term "bugbear" - both are definitely in my bugbear list also.
The "architect-y" tower reminds me of leaders who insist on having things done in specific ways without knowing what exactly the impact of what they're asking for.
The 2nd one is crucial since majority of software is written for business purposes and therefore, really needs consideration and to not do so would actually create technical debt and cost the business $$$ in the long term.