PM vs EM vs TPM: Which Role Are You Actually Playing?
What PM, EM, and TPM actually do in software shops, and which mix of the three you are currently doing without realising it.
Table of contents
- When does the role question actually matter?
- What is the cost of leaving the role implicit?
- What does the role split look like at a 5-person team?
- What does the role split look like at 50+ people?
- What is the concrete role-definition template?
- What failure modes does role confusion create?
- When is the role distinction overkill?
- Where should you go from here?
The first conversation about who-does-what in a software project is almost always about job titles, and almost always confusing. A "Senior Engineer" is doing PM work. A "PM" is doing TPM work. An "EM" is being asked to estimate. This chapter splits the three roles cleanly so you can name what you are doing today and what you should delegate tomorrow.
When does the role question actually matter?
Three moments.
Project kickoff. Someone needs to own scope, schedule, and status. If three people each think the other person owns it, the project drifts for a month before anyone notices. Naming the role in the kickoff doc is the cheapest insurance.
Hiring. A job description that mixes EM and PM responsibilities is a recipe for a candidate mismatch and a frustrated hire. Hiring the right person starts with knowing which role you actually need.
Career conversations. "I want to grow" usually means one of: deeper individual contribution, more people management, or more scope coordination. The three correspond to different roles. Your manager cannot help unless you can name which.
What is the cost of leaving the role implicit?
Three failure modes.
Decisions stall. Two people both think "the other one will decide". Nothing happens for two weeks. By the time someone forces a decision, options have closed.
The wrong person owns the wrong thing. The EM ends up writing status reports because no PM exists; the PM ends up coding because no engineering capacity exists. Both do their second-best work and miss their first-best work entirely.
Stakeholders get conflicting signals. Sales asks the PM for an ETA, gets one. Sales asks the EM for an ETA, gets a different one. The customer hears both. Trust erodes.
What does the role split look like at a 5-person team?
flowchart TB
Lead[Tech Lead<br/>1 person] --> PM[PM duties:<br/>scope, schedule, status]
Lead --> EM[EM duties:<br/>1-on-1s, growth, hiring]
Lead --> TPM[TPM duties:<br/>cross-team comms]
Lead --> IC[IC duties:<br/>coding, design]
One person plays all four hats. The challenge is not to drop any of them: if the tech lead spends 100% of time coding, the PM hat falls and the project drifts. The mitigation is calendar discipline - block the morning for IC work, block one afternoon a week for 1-on-1s, write the status report Friday.
What does the role split look like at 50+ people?
flowchart TB
VP[VP Eng] --> EM1[EM<br/>Team A]
VP --> EM2[EM<br/>Team B]
VP --> EM3[EM<br/>Team C]
PMO[PM Lead] --> PM1[PM<br/>Project X]
PMO --> PM2[PM<br/>Project Y]
TPMO[TPM Lead] --> TPM1[TPM<br/>Initiative Z<br/>spans A B C]
EM1 -.partners with.-> PM1
EM2 -.partners with.-> PM2
EM3 -.partners with.-> TPM1
At 50+ engineers the roles split. Each EM owns one team's people (5-8 reports). Each PM owns one project's schedule (often spanning 1-2 teams). Each TPM owns a cross-team initiative (3+ teams or vendors). The roles partner explicitly: every project has both an EM (who provides engineers) and a PM (who runs schedule). The stakeholder chapter covers how the partnership communicates externally.
What is the concrete role-definition template?
A short markdown block that lives in the project's README.md or
kickoff doc:
## Roles
| Role | Person | Responsibility |
|-------------|--------------|--------------------------------------------------|
| Sponsor | {{ Name }} | Approves scope and budget, removes blockers |
| Tech Lead | {{ Name }} | Owns architecture, mentors engineers |
| PM | {{ Name }} | Owns schedule, status, scope changes |
| EM | {{ Name }} | Owns staffing, performance, attrition |
| TPM | {{ Name }} | Owns cross-team coordination (if 2+ teams) |
| Engineers | {{ Names }} | Build the thing |
| QA | {{ Name }} | Test plan, exit criteria |
| Designer | {{ Name }} | UX, design system compliance |
## Decision rights
- Scope changes: PM (with Sponsor approval if budget changes)
- Architecture: Tech Lead (with peer review for major changes)
- Hiring: EM (with team panel + sponsor)
- Vendor selection: PM (with Tech Lead input)
## Escalation path
Engineer -> Tech Lead -> EM -> VP Eng -> Sponsor
The decision-rights section is the part most teams skip and most projects get stuck on. Without it, every decision goes to the sponsor by default - which is slow and unscalable.
What failure modes does role confusion create?
Four classic ones:
- Two PMs, one project. A PM was hired without checking who was already running it. They pull in different directions for a quarter before someone notices. Mitigation: every project has exactly one accountable owner in the kickoff doc.
- EM doing PM work. A people-manager spends 60% of their time writing status reports because no PM exists. Their reports (1-on-1s) suffer; attrition rises. Mitigation: hire a PM or shed the project.
- TPM with no authority. A TPM is appointed to "coordinate" but has no budget, no decision rights, no reporting line over the teams. They send meeting invites that no one accepts. Mitigation: a TPM needs explicit authority backed by a senior sponsor.
- Tech lead avoiding the PM hat. A senior engineer who really wants to code keeps deferring scope decisions. The team starts asking the PM-of-an-adjacent-team for direction, and ownership drifts. Mitigation: explicit calendar block + checklist for PM duties weekly.
When is the role distinction overkill?
Two situations.
Two-person team. Two engineers building a side project do not need to formalise PM, EM, TPM. They need to ship.
Time-boxed prototype. A two-week spike has no schedule risk worth managing. The senior engineer makes calls; document the result.
The role split earns its complexity when the team grows past ~5 engineers, when the project crosses team boundaries, or when one person can no longer hold all the context in their head.
Where should you go from here?
Next chapter: estimation fundamentals - the first concrete artifact every PM owns. After that, risk and issue tracking covers how to keep the project safe once it is moving.