Imperfect #15: Team Lead vs EM vs Tech Lead
The meaning of each entry-level leadership position is subject to much debate. Having had them all myself, I’ll share what they mean to me and who I give them to these days.
TL;DR:
Tech Leads are the best programmers/system designers and often support Engineering Managers
Team Leads are aspiring managers who take care of all aspects of small teams (up to 5 people)
Engineering Managers are responsible for teams on the larger side (6 to 10 people). They provide technical validation and direction but focus more on business alignment and people management.
Read on for more details.
Tech Lead
These are individual contributors who have achieved high status for their technical knowledge and contributions. They normally know the most about software in and around their span of control, and are regarded as the most credible voice in technical discussions. They are typically the most tenured or experienced members of their teams. They are responsible for the quality of technical decisions in the team, while keeping business needs in mind. Code is part of the job, but much of their time goes towards multiplying the value of others - by pair programming, writing, reviewing code, designing systems, etc.
Tech Leads play a big role in hiring, making sure the bar stays high. They might not design the hiring process but they’re usually brought in to assess candidates. Mentoring other developers is also extremely important, which they can achieve formally or as part of the daily activities of code review, design sessions, etc.
While the archetype of the Genius Asshole is very common, I find the most effective tech leads to be kind people who listen carefully and communicate eloquently.
Tech Leadership is often just a role, not a title, with influence rather than authority. The best tech leads, in my opinion, step into the role without realising it.
Team Lead
They are hybrids between a tech lead and a manager. A Team Lead is much like the technical co-founder of a five-person startup: focused on organising the development effort, managing a few stakeholders, and keeping tabs on how well their team mates are doing. They write code much of the time, but also invest strongly in code reviews, design efforts, and other activities that help others work at their best. That includes regular and structured check-ins with team mates, as well as frequent interactions with stakeholders. Team Leads must partner well with their Product and Design counterparts, which requires a pragmatic approach to development decisions, deep customer understanding, and good knowledge of the business domain.
Many people ease into the role, as their tenure, experience or charisma makes others look to them for leadership. But the role is more formal than Tech Lead, as it comes with a certain amount of authority and ability to make decisions. Team mates normally report to the Team Lead in practice, even if on paper they might report to the Lead’s line manager.
Because of the many responsibilities, the person in this role isn’t expected to excel in all aspects and usually needs significant support from their manager. It works best for small teams of up to 4-5 people. It’s a good stepping stone towards management, giving people with leadership qualities a chance to explore the non-technical side of the job before fully committing to the change.
I’m not sure there’s a correlation between the desire to lead and the ability to do so. I prefer to promote someone who’s indicated some desire to do it rather than someone who doesn’t want to. I am careful about people who are too eager to lead, as a drive for status is the wrong motivator in my opinion. I like to see spontaneous initiative. People who naturally step in to fill voids, help organise things, and generally pick up the slack when no one else does, tend to do well in leadership long term.
Engineering Manager
It’s all in the name. An Engineering Manager is a former Engineer who manages Engineers. After the stepping stone of Team Lead, EM is the first full role of the Management career track, and brings many changes.
EMs are partners to Product Managers (or Owners, depending on company terminology and org chart). In the Who / What / Why of software development, PMs bring the Who and the Why, EMs bring the implied How, and both collaborate on the What. They need a solid understanding of the software in and around their span of control, in order to validate the feasibility and requirements of initiatives as early as possible.
Engineering Managers need to deeply understand the business and have a solid vision of how their team can provide value. It’s very common for EMs to sit back while PMs do all the business work, but that is a wasted opportunity. Again, they should be partners to their PMs and discuss the roadmap often.
Technical credibility is very important. They must keep their team’s decisions pragmatic. A good EM is a voice of reason, helping to strike the correct balance between technical perfection and on-time delivery of value. To be that person, they must be able to command respect for their technical chops. An EM who is completely disengaged from technical work will struggle to see eye to eye with their developers and lose the ability to steer the ship. It’s for that reason that Big Tech places a lot of emphasis on technical skills when interviewing for management positions.
As fully empowered Managers, they can and should be able to handle the financial and business side of the job. In many companies, HR and Finance are responsible for extending job offers and negotiating salaries but a good EM must be in on it too. That is because they’re the first person that their reports go to when they need a raise, for example.
Management comes with responsibility, authority, and often some degree of power. Being a Manager opens doors that are closed to mere Leads, often in the shape of Manager-only activities such as meetings, off-sites, training, slack channels, etc. It usually grants access to people in other functions of the company which are useful to Engineering, including HR, Finance, IT, Sales, Marketing, Operations, etc. An effective manager cultivates relationships with those people, which in turn makes it a lot easier to get things done. Ways to cultivate those relationships can be as simple as grabbing coffee from time to time. Knowing people can open up opportunities to add value that would otherwise go undetected. This is good for the company and obviously good for the manager and team who gets it done.
All of that relationship building, budget planning, job offer extending, performance reviewing, and general seeing to the many daily needs of a growing team of 6 to 12 people while keeping stakeholders happy and PMs sane, means less time for technical work. For that reason, many EMs let their technical skills rust. This is ok in the beginning, but I advise new managers to think of their technical skills like a cooldown timer. Yes, they need to focus on the business and people side, but that timer needs resetting every now and then before they fall too far behind.
One thing that helps is having a Tech Lead in place. That person can take care of the practical aspects of purely technical leadership, while the EM can focus on keeping the team happy, engaged and productive. By being a sparring partner to the EM, they can in turn help keep them engaged with the technical side for a relatively small time cost.
Conclusion
The distinctions between Tech Lead, Team Lead, and Engineering Manager can be hard to explain. But they can be simplified.
Small teams of up to 5 people have Leads. They’re usually high initiative people, who combine strong technical skills with some aptitude for people and stakeholder management. The Team Lead role is a good stepping stone towards the management path.
Bigger teams benefit from specialisation. An Engineering Manager who is ultimately responsible for the team’s deliveries, contributing by making sure the conditions for success are met. And a Tech Lead who can influence and own technical decisions, as well as keep the hiring bar high, performance calibration consistent, and juniors mentored.
There’s a lot of nuance to this of course. Larger, more established companies have different dynamics than smaller startups. Fast growth companies need different solutions than stagnating or contracting organisations. But I find this mental model easy to adapt to different situations.
Hope you find it useful. If you strongly agree or disagree, let me know!
Thanks for reading and enjoy the weekend ☀️