Engineering Manager vs Tech Lead: Who Does What?

2026-07-16 · 7 min read · Tools & Productivity

In many engineering teams, the split between Engineering Manager and Tech Lead is either undefined, argued about constantly, or handled by one exhausted person doing both jobs at once. This creates problems that look like people problems but are really role problems.

Getting the distinction right — and communicating it clearly — is one of the highest-leverage structural decisions an EM can make.

The Short Version

The Engineering Manager owns the people and the process. They're responsible for team health, individual development, hiring, performance, and ensuring the team has what it needs to deliver.

The Tech Lead owns the technical direction. They're responsible for architecture decisions, code quality, technical standards, and guiding the team through complex engineering challenges.

These are genuinely different jobs. When they're blurred, both suffer.

What the EM Is Responsible For

The EM's scope is everything that makes the team function as a team of humans:

• Career development: knowing each person's goals, creating growth opportunities, writing strong promo cases. See how to write impact stories and performance reviews.
• 1:1s and psychological safety: building the relationships that make feedback work. The EM is the person engineers come to when something is wrong — with the work, with each other, or with the company.
• Hiring and team composition: deciding what roles to hire for, running the hiring process, onboarding new engineers well.
• Removing organisational blockers: the EM fights battles the team shouldn't have to fight — cross-team dependencies, resourcing conversations, scope negotiations with product.
• Process and rituals: sprint cadence, team ceremonies, how work gets tracked and communicated.

What the EM is not primarily responsible for: deciding how the system is architected, which libraries to use, or whether a particular technical trade-off is the right one. They can have opinions. They shouldn't be the decision-maker.

What the Tech Lead Is Responsible For

The Tech Lead's scope is everything that shapes how the team builds:

• Technical direction: leading architectural decisions, reviewing RFCs, ensuring technical consistency across the codebase.
• Code quality: setting standards for review, raising the bar on what gets merged, identifying and addressing technical debt.
• Cross-team technical coordination: the Tech Lead is the point of contact for technical questions from other teams, not the EM.
• Mentoring technical growth: pairing with engineers on hard problems, giving feedback on technical approach, identifying skill gaps and helping close them.
• Risk identification: seeing technical problems before they become production incidents or delivery failures.

What the Tech Lead is not primarily responsible for: the career progression of their peers (that's the EM's job), decisions about who gets promoted, or managing interpersonal conflict.

The Overlap Zone

The two roles share some territory, and that's fine — as long as it's explicit:

Prioritisation: The EM owns the process; the Tech Lead provides technical input on what's feasible, what's risky, and what's underestimated. Both voices matter. Neither should override the other without conversation.

Incident response: The Tech Lead typically leads the technical response. The EM handles stakeholder communication, team support, and the post-mortem process.

Hiring: The EM owns the process and the final decision. The Tech Lead owns the technical assessment — the take-home review, the system design conversation, the evaluation of code quality.

Team culture: Both shape it. The EM through how they manage. The Tech Lead through how they code and collaborate.

When One Person Does Both

In small teams (4 engineers or fewer), it's common for one person to hold both roles, usually the most senior engineer who was promoted. This can work temporarily. It almost always breaks down past a certain scale because the two roles pull in different directions.

The EM role demands interruption-heavy availability — people need you, problems need addressing, meetings need attending. The Tech Lead role demands uninterrupted depth — hard technical problems require sustained focus. Trying to do both simultaneously means doing both poorly.

Signs you've outgrown the combined role:

• The EM/TL is always in back-to-back meetings and the code quality is slipping
• Engineers can't get technical guidance quickly because the TL is in management mode
• The EM/TL is burning out and can't articulate why
• Junior engineers don't know whose door to knock on for which kind of problem

When this happens, the right move is to split the roles — either by hiring, or by identifying a senior engineer on the team who can take on the TL function.

How to Split Them Clearly

If you're making the transition from combined to split roles, the most important step is a public clarification of who owns what. Ambiguity is the enemy.

Have an explicit conversation with the Tech Lead (or the person taking on that role) that covers:

• Which decisions they own outright (no need to consult the EM)
• Which decisions they lead but the EM is informed on
• Which decisions they provide input on but the EM owns
• What happens when they disagree

Document it. Share it with the team. A written RACI for the most common decision types is worth the 30 minutes it takes to produce.

The Most Common Failure Mode

The most common failure mode isn't confusion about the role boundary — it's the EM and Tech Lead not communicating with each other regularly enough for the split to work.

They need at minimum a weekly sync. Not to report status to each other, but to share what each is seeing: the EM shares morale signals and people concerns, the Tech Lead shares technical risks and quality concerns. Each informs the other's decisions without collapsing the distinction.

The EM-TL relationship is one of the most important in an engineering team. When it works, the team has both clear technical direction and strong people support. When it doesn't, engineers feel it — they're caught between mixed signals or forced to choose whose guidance to follow.

Get this relationship right and most other team problems become easier to solve.

Track your team's delivery, health, and individual development alongside GitHub metrics in one place. Try Emtricks free for 30 days — no credit card required.