Why We Don't Hire Project Managers (And What a TPM Does Instead)

The PM-Shaped Hole That Isn't Actually There

Most engineering teams default to hiring a Project Manager somewhere between hire #4 and hire #8. The reasoning is intuitive: things are getting hard to track, sprints are slipping, the CTO is in too many meetings, the founders cannot see status. Hire someone whose job is to fix that.

We have shipped 50+ products over 8 years, most of them in fintech, regtech, healthtech, and other regulated verticals. For most of those years, we ran the traditional model — engineering teams with embedded Project Managers, the way most agencies still operate. As AI tooling matured and our team structure shifted toward lean three-person teams, we deliberately evolved away from that role. The Project Manager role does not exist on our current delivery teams, and every time a client has asked us to add one back — usually because their internal process required it — the result has been the same: more meetings, slower decisions, the same shipping pace.

This post is about what we hire instead, why the distinction matters, and what coordination actually looks like in a lean three-person team.

TPM vs PM: The Role Confusion That Costs Founders Money

The most expensive mistake non-technical founders make in early team design is confusing two adjacent roles:

Project Manager (PM). Coordinates execution. Owns the schedule, dependencies, status reporting, meeting cadence, sprint mechanics. Translates between technical work and stakeholder visibility. Their core artifact is the project plan — a Gantt chart, a roadmap, a status document. They typically do not write code, do not own the spec, do not make architectural calls. Their job is to make a multi-person system run on time.

Technical Product Manager (TPM). Owns the product. Decides what gets built, why, in what sequence, with what trade-offs. Writes the spec. Talks to users and stakeholders. Reads code well enough to validate that what shipped matches what was specified. Often writes small things themselves — scripts, prototypes, bug fixes. Their core artifact is the spec plus the priority order. They are closer to a "CTO who happens to also be the product lead" than to anything in the project-management lineage.

These roles are not synonymous, but most job postings, recruiting platforms, and HR systems treat them as adjacent or interchangeable. They are not. A PM cannot do a TPM's job because they cannot read the code, write the spec from first principles, or make trade-offs without translation. A TPM cannot do a PM's job — but in a lean team, the PM job mostly does not need doing.

What Our TPM Actually Does

Concrete, not abstract:

• Owns the spec. Writes it, refines it, defends it under pressure from customer feedback. Knows what is in scope, what is deferred, what was rejected and why.
• Owns the priority order. Decides which feature ships next based on customer urgency, technical risk, compliance dependencies, and what the Developer can credibly deliver this sprint.
• Talks to users. Customer-discovery calls, beta-feedback sessions, stakeholder updates. The TPM is the team's primary interface to humans who use or pay for the product.
• Reads the implementation. Reviews pull requests at the architectural level — does the data model match the spec, does the API shape make sense for downstream use, does the UX of the new feature actually solve the problem we described.
• Writes occasionally. Quick scripts, data extracts, small prototypes, the occasional bug fix in a part of the code they understand. Not a full developer, but technical enough to ship things that do not require a Developer's time.
• Makes the trade-off calls. When a feature would take three weeks to do right and one week to do well-enough, the TPM decides which version we are shipping based on what the customer actually needs.

The thing this list does not include: running standups, maintaining a Jira board, writing weekly status reports, scheduling cross-team syncs. Some of that work happens informally (a 10-minute morning sync, a Linear ticket, a Slack update). Most of it does not need to happen at all because the team is small enough that nobody is out of the loop.

What a PM Would Add (And Subtract)

Imagine we added a Project Manager to a 3-person Productera team — the typical TPM, Developer, QA setup. What changes?

They would add: formal sprint planning meetings, retrospectives, a maintained Jira/Linear board with effort estimates and burndown charts, weekly status reports, dependency tracking across upstream/downstream work, scheduled syncs with the customer's PM, formal RAID logs.

They would subtract: the speed of decision-making. Every decision that previously took a five-minute conversation now goes through a process. Trade-offs that the TPM and Developer used to make in the moment now need PM visibility. The customer's PM now has someone to meet with weekly, which means an hour a week of meeting time gets created on both sides.

For most products at most stages, the subtraction is bigger than the addition. The team was already shipping. The customer was already informed. The decisions were already getting made. Adding a layer of coordination overhead to a team that was not suffering from coordination problems creates the problems the new role is supposedly there to solve.

"But Who Tracks Timelines and Dependencies?"

The most common pushback when we explain this to a new client. The honest answer:

• Timelines live in the spec and the sprint plan. The TPM owns the spec; the Developer owns the sprint plan. Both update in real time as reality shifts.
• Dependencies are usually internal to a 3-person team — the Developer waits on the TPM's spec, the QA waits on the Developer's implementation. These do not need a tracking system; they are visible because the team shares context.
• External dependencies (the customer's API team needs to ship a webhook, the third-party provider needs to enable a sandbox) get tracked in a shared doc and surfaced in weekly check-ins. No PM required.
• Status lives in a brief weekly note from the TPM to the customer or stakeholder. Five paragraphs. What shipped, what is shipping next, what is blocked, what we need from you.

What you lose by not having a PM: nothing meaningful for a small team.

What you gain: the meeting time that would have gone to coordination is now going into shipping.

When You Actually Do Need a Project Manager

The honest carve-out. Not all teams should run without a PM. The role earns its keep when:

• Three or more parallel engineering pods are working against shared deadlines and need their work synchronized.
• Regulatory or contractual deliverables require formal status reporting on a fixed schedule (financial services audit prep, government contracts, large enterprise SOWs).
• Many external stakeholders — customers, regulators, partners, internal departments — each need separate communication and reporting.
• The TPM is genuinely overloaded with stakeholder management to the point where spec quality is suffering. (At which point the answer might be a second TPM, not a PM — depends on the work.)

If you fit any of these, a PM is real value. If you do not, the role creates more meetings than it saves.

What This Looks Like for a Client Engagement

When a new client engages us for a lean fintech build or a regtech platform, the team they get is a TPM, a senior Developer, and a QA engineer. The client's stakeholders meet weekly with the TPM. Status updates go out as part of that meeting. Spec changes get worked into the next sprint by the TPM and Developer in real time. The QA flags issues that need re-prioritization through the same channel.

If the client requires a formal Project Manager on their side — for their own internal reporting reasons — we work with theirs. We do not duplicate the role on our side because there is no work for it to do.

The result the client sees: production-grade software shipping in weeks rather than the months a traditional 6-to-8 person agency engagement would take. Same scope. Less overhead. Faster decisions. The savings come from both the reduced headcount and the reduced coordination tax — and the latter is bigger than the former.

The Test for Your Own Team

If you are running a team of 4-8 engineers and have a Project Manager, try this: list everything the PM did this week. For each item, ask whether the team would have shipped less, slower, or worse without it. Be honest.

Most engineering organizations that run this audit discover that 60-80% of the PM's work is making the rest of the meetings work. Take the meetings out (the ones the PM is required to run, attend, and report on) and most of the PM's work disappears with them.

That is not a critique of any individual PM — many are excellent at the job. It is a critique of a default team structure that adds the role without asking whether the role is solving a problem the team actually has.

For lean teams shipping with senior engineers and a real TPM, the answer is usually no.

Related reading: The 3-Person Engineering Team That Outships Your 8-Person Squad · You're Outsourcing the Wrong Roles · How to Hire Fintech Developers

Related glossary terms: Code Review · CI/CD