Differences Between Lead Roles and How to Find Your Right Path

🎁 Notion Template: Decide Your Career Path included!

---

This week’s newsletter is sponsored by Astronomer.

Learn how to orchestrate LLMs & Agents with Airflow

Anyone can vibe code a wrapper around the latest LLM or agent. But to build applications your competitor can’t ship in a day takes orchestration.

Download the complete guide to GenAI orchestration with practical guidance and code examples.

• Explore patterns like event-driven execution and multi-agent workflows.

• Discover new Airflow 3 features from human-in-the-loop operators to the AI SDK.

• Best practices to keep in mind when building your pipelines.

Thanks to Astronomer for sponsoring this newsletter. Let’s get back to this week’s thought!

---

Intro

There are many different lead roles available in the engineering industry, and to make it even more interesting, a specific lead role may mean something different depending on the company.

Here’s an example: the role of a Lead Engineer at some companies includes people management, while in others, the focus is purely technical, with people management handled by a Team Lead or Engineering Manager.

So, whenever you are applying for roles, it’s really important to find out the real expectations and responsibilities. If you assume you know, you are probably assuming wrong.

To help you get a broader perspective of the lead roles and what the most common responsibilities and expectations associated with the roles are, today’s article will help you with that.

At the end of the article, I am also sharing my specific recommendation of what particular career path might be the right fit based on what things you are good at and what things energize you versus not.

Especially if you are wondering what is going to be your next step in your career, this is a must-read article for you!

Let’s start.

There Are 4 Main Lead Roles Available in Our Industry

As mentioned in the Intro of the article, there are many different titles associated with lead roles, but all of the 4 titles fall into these 4 categories:

• Tech Lead

• Team Lead

• Engineering Manager

• Architect

The biggest differentiators between them is the focus on people versus technical direction.

With roles such as Team Lead and Engineering Manager, you are also directly managing your people, and with roles such as Tech Lead or Architect, you don’t have direct reports, therefore you need to influence others without authority.

To be fair, with this article, I am particularly focusing on the Lead roles, which are close to what a Senior Software Engineer might take as a next step.

That’s the reason I am leaving out the roles such as Director, VP, CTO, or similar, as those roles are the next steps after already being in a Lead role.

Now, let’s start with the first category: Tech Lead. This is usually where engineers get their first experience leading a project and owning its outcomes.

Tech Lead

The Tech Lead role is typically the first leadership role that Software Engineers move into. When you become a Senior Software Engineer, you normally start owning projects, and that’s where you already start doing some of the responsibilities of a Tech Lead.

A Tech Lead is someone who is responsible for the technical implementation of the specific project. They create a technical specification, collaborate with a product manager on the planning of the project, and manage expectations of the project with the stakeholders.

Normally, they also estimate the effort that is going to be needed and provide the specific timeline, and also what the specific iterations of deliverables are going to be.

Tech Leads are the go-to people for the tech side of the project, and they are responsible for ensuring everything goes well. It’s a totally different role than the role of a Software Engineer, you do a lot less coding, and you act as a multiplier for others.

Unblocking and helping others to progress and move forward with their tasks is what becomes very important.

Some companies may use the Tech Lead as a direct title, but mostly the Tech Lead role is used to define the role of a certain individual.

For me, personally, I am an advocate of doing a Tech Lead rotation in the engineering team, I believe it’s a good way to share knowledge across the team and give an opportunity to people to grow.

Titles that are mostly associated with this role:

• Lead Engineer

This is how a lot of companies name the role of a Tech Lead, especially in smaller companies. The definition and responsibilities are practically the same for the role as what we mentioned above.

In bigger companies, there is normally a career ladder defined, which doesn’t include the Lead Engineer role, but rather focuses on Staff and Principal Engineer titles, after the Senior role in the IC ladder.

• Staff Engineer

In a lot of teams, the Staff Engineer of the team is also the Tech Lead of the team, so the Tech Lead role is automatically associated with the title. But being the tech lead is just one of the archetypes of a Staff Engineer, and, important to mention, it’s the most common one.

The other 3 archetypes, based on Will Larson and the book Staff Engineer, are:

1. Architect: Similar to the responsibilities of an Architect role.

2. Solver: Dives into the organization’s most complex, high-risk problems. Technically, a very competent engineer.

3. Right Hand: Handles org-scale issues at business/tech/people intersections with the borrowed authority from VP/CTO.

Team Lead

The difference between the Team Lead and a Tech Lead is that the Team Lead is normally the first role in the management path, which also includes people management and having direct reports, while as a Tech Lead, you don’t.

Of course, this varies across different companies, and in some companies, a Team Lead doesn’t have direct reports and engineers report directly to the Engineering Manager.

The main responsibilities of a Team Lead include facilitating meetings like daily meetings, retrospectives, sprint planning, etc., while at the same time also having 1:1 meetings with the team members, providing coaching and mentoring, giving feedback, and delegating work.

I like to view this role as doing what’s best for the team. I like to say that as a Team Lead, you either do what the team needs or you hire to fill this gap.

If the team lacks technical seniority, you need to fill this gap, and if the team is drowning in tasks, you focus on better prioritization, stakeholder management, or help with finishing the tasks. It’s certainly a role for good generalists.

A similar role to the Team Lead is the Tech Lead Manager role, just the expectation is that you are doing both the role of a manager of the team and also being a Tech Lead at the same time.

However, what works best in my opinion is to have these two roles separate, and as I mentioned before, I like to do a rotation of Tech Leads and not have just 1 fixed Tech Lead per team.

Engineering Manager

The Engineering Manager role is the step above the Team Lead role in the management path. In some companies, the EM role might mean the same thing as a Team Lead role, so that means that you lead 1 team, but for me, it means that you lead 3 or more teams, and Team Leads are reporting directly to you.

This is the first time that you move yourself completely out of the day-to-day operations, and your main focus becomes delegation, coaching, overall structure, and the success of teams, while focusing on strategy and hiring.

Some of the main responsibilities include roadmap planning together with other relevant people, setting KPIs (Key Performance Indicators), defining OKRs (Objectives and Key Results), being a good translator between business and tech, defining specific success metrics, tracking them, and focusing on improving, and of course, making sure that you hire the right people for your teams.

You normally have 1:1 meetings with your direct reports (Team Leads), with your manager, alignment meetings with the leadership team and peers, and I also like to do 1 alignment meeting together with all the Team Leads once a week to ensure that we are all moving in the right direction.

An interesting role that I wish to mention here is the Technical Program Manager (TPM). It’s a role that is not connected to the engineering track, but instead lives in the product track, so it shouldn’t be mixed with the Engineering Manager role.

The difference is that the TPM has no direct reports and is overseeing and coordinating multiple projects or products, but the EM role is leading teams, where Team Leads and other Engineers are reporting to them (directly or indirectly).

Architect

Like the Tech Lead, the Architect role usually has no direct reports and relies on influence rather than authority. Team Leads and Engineering Managers, on the other hand, have direct reports.

I normally introduce this role when the tech leads of the team can’t align on the architecture, and where inconsistencies of the implementations tend to happen across different teams.

That’s when I look to add a person focusing on ensuring that the teams are aligned and that we are all architecturally moving in the right direction. The main focus is understanding what the most important things are for the business and translating that into good, long-term technical decisions.

As an Architect, you work across different teams and work with them to ensure that they have everything they need to be successful. You design systems organization-wide, define technology standards and patterns to ensure scalability, security, and ease of integration.

What I like to say about this role is that you need to think in years and not in sprints. Making good long-term decisions is where your main focus should be.

There are many different variants of architects, and I’ve seen many titles across different companies. Here are the 4 that I believe are the most common (additionally to Software Architect):

• Solution Architect

A Solution Architect focuses particularly on solving a specific business problem by designing the right technical solution. That’s the difference to a Software Architect, where the emphasis is on a specific application or system, and its long-term success.

• System Architect

System Architects focus primarily on availability, latency, and scalability. Their work may span both software and infrastructure, with the focus on infrastructure.

• Enterprise Architect

An Enterprise Architect is working on the overall architecture of the systems in the organization. Rather than designing individual systems or solutions, this role defines how all systems across the organization fit together to support business strategy.

• Platform Architect

A Platform Architect designs shared services or platforms that enable teams (mostly product teams) to move faster. These platforms or services may include cloud infrastructure, internal developer platforms, data platforms, or integration layers.

Finding Your Path

If you don’t know yet which path might be right for you, you are definitely not alone! When I was a Senior Software Engineer, I was feeling stuck because I didn’t know what my next step was going to be. I was overthinking about my career path, and I didn’t know which particular skills I should focus on:

• “What is going to be that next step for me?”

• “Should I go into management, architecture, or should I grow as an IC?”

• “What particular skills should I be learning next?”

These questions were always on my mind, and my growth was stagnating because I wasn’t intentional about my growth, and I didn’t have defined goals.

So, it’s really important that you at least have some idea in which direction you wish to grow and on what particular skills to focus on.

Build Your Pros and Cons List to Help You With the Path Selection

To help you with the path selection, I highly recommend that you build a list of what things you are good at and what things energize you, versus not. That’ll show you which path would be the right one for you.

Here is the visual of the 3 main paths available:

And let me also share my recommendations next.

When to choose the IC path:

• You like to be involved in details

• Learning new concepts and patterns is what you like to do

• You like to be an expert in particular technologies that you work with

• You like to ensure that coding style guides and guidelines are up-to-date and well-defined across different teams

• You believe in mentoring others and helping them grow as engineers by providing them with technical support

When to choose the Management path:

• You like to communicate with different people regarding the requirements of a specific project

• You like to make sure that the team is aligned regarding stakeholder expectations and deliverables

• If you believe that you can contribute to the team’s success a lot more with non-technical skills like communication, alignment, accountability, help, and support, it’s certainly a good path for you

• You are one of the first people to speak up if something can be improved, and you are not afraid to take ownership and responsibility for projects

• You see yourself as a generalist rather than a specialist

• You are very focused on trying to improve the engineering process and seek potential improvements

When to choose the Architect path:

• You like to stay technical, but have a desire to focus on the big picture a lot more than the really fine details.

• You still need to be good at understanding the details and good practices, but your main focus is going to be to think about the codebase and architecture ahead of time.

• You enjoy defining blueprints and plans that are going to be successful long-term.

• You like to anticipate and talk about constraints and potential problems before implementing a solution.

Notion Template: Decide Your Career Path

Use this template to define a plan for your career. This will help you to clearly understand what you need to do and where you can improve.

Paid subscribers, you can get it here: 🎁 Products for paid subscribers.

Last words

The important message I want to share at the end of the article is the following:

Career paths are rarely linear.

If you have already decided to go a particular path (or you already are on that path), there is nothing wrong with switching to another path.

It’s quite common for people to be Engineering Managers, then be Staff Engineers, and they might try themselves as Architects or go back to the management path.

A lot of the skills and things you learn in any of the paths are well applicable to other paths, especially people skills, leadership, time management, good organization, and overall experience.

It’s quite unlikely that the path will be linear. I personally don’t know a lot of people who have decided to go a certain path and haven’t made adjustments over time.

Especially at the current time, where we are seeing a lot of the Lead roles getting closer together.

You got this!

---

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

---

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.