As Engineering Teams get smaller, is the Technical Program Manager the missing piece?

Do you remember what a "normal" software team looked like?

A product manager, an engineering manager, a designer, and six or seven engineers. Weekly planning meetings, a backlog to groom, a sprint to run. For most of the last decade, that was just... how teams worked. It was the water we all swam in.

That was my daily life as an software engineer and then an engineering manager for most of my career. That shape was so familiar it felt like a law of nature rather than a design choice.

I recently came across an article on the LeadDev website that argued that traditional team shape is breaking apart - and fast. AI is reshaping the traditional team structure that engineering managers are used to, and the engineering manager (EM) role itself is splitting into two very different futures. One stays close to the code. The other expands outward across multiple teams, with ratios that would have seemed absurd five years ago.

It's a well-argued piece and I agree with most of it. But reading it, I kept thinking: there's a third role sitting right in the middle of this split that barely gets a mention.

The Technical Program Manager (aka a TPM).

I've spent time on both sides of the engineering/management divide. I've been an engineering manager, and I'm an IC now. And one thing that experience teaches you is that the messiest, most overlooked part of any org isn't the people management or the code - it's the space between teams. The dependencies. The cross-functional delivery risks. The "who owns this?" conversations that stall projects for weeks.

That's exactly the space that gets wider as teams shrink.

I know what you're thinking - aren't we just adding extra headcount? Not quite. A single TPM can serve across four or five of those small teams simultaneously, handling the cross-cutting work that would otherwise fragment across every Engineering Manager and tech lead in the building. It's not a new layer. It's a better shape.

That LeadDev article is really describing one thing: small, fast-moving, AI-augmented teams. Tech leads that are head down in the code. Wide-span engineering managers that are spread thin across five or six of those teams. Who's looking at the whole picture? Who's tracking that Team A's output is the input for Team B's Q3 milestone? Who's in the room when the product roadmap and the engineering capacity don't line up?

That work doesn't disappear just because management layers do. If anything, it gets harder.

A good TPM doesn't typically manage teams and doesn't write production code - but they hold the connective tissue of a programme together. They ask the questions that fall between job descriptions. They translate between engineering constraints and business timelines. They're technical enough to smell risk early and organised enough to do something about it.

In a world where your Engineering Manager is managing multiple engineers across multiple teams, the last thing they have time for is running a cross-team dependency log or facilitating a technical risk review. That's not a criticism - it's just scope. Something has to give.

The Technical Program Manager (TPM) fills that gap.

So why isn't this already the obvious answer? Partly because the TPM role itself is poorly understood. Ask ten people what a TPM does and you'll get ten different answers - some companies use the title for someone close to project management, others for a semi-technical lead, others barely use it at all. It's a role that's been historically inconsistent, which makes it easy to overlook when org charts get redrawn. But that inconsistency is also an opportunity - as the Engineering Manager role fractures, companies will need to define this connective-tissue work somehow, and the TPM title is sitting right there, half-formed and ready to be shaped into something more central.

What's interesting is that the skills which make a great TPM are almost the opposite of what each fork of the Engineering Manager role is optimising for. The Tech Lead path doubles down on technical depth. The wide-span Engineering Manager path doubles down on people skills and influence. The Technical Program Manager has to hold both - enough technical credibility to challenge engineering estimates, enough interpersonal range to keep a dozen stakeholders aligned.

If you're currently an Engineering Manager wondering which way to lean as your org flattens, it might be worth asking yourself: which part of the job do you actually find energising? The 1:1s and the career conversations, or the delivery and the cross-team puzzles? Because that second category - that's Technical Program Manager territory, and it might be a better fit than either fork.

And if you're an IC watching all of this from the sidelines, wondering where the growth paths go from here - don't sleep on it. The role is less visible than Engineering Manager and less glamorous than staff engineer, but in a flatter org running lots of small teams, it might just be the most useful person in the building. 🙂