**Same title. Same line on the job description template. Completely different Tuesday. \ A recruiter reaches out about a role: Capacity TPM. You know the shape of the job — allocate compute, manage growth, keep things running for whatever's live. You've done it before. You take the call.

Then you start, and the job description turns out to have lied by omission. It never said whether "capacity" means a hardware supply chain or an API call.

Two Ways to Own Capacity

Zoom out, and every company running AI or web-scale infrastructure has made one of two bets:

• Own the hardware. Buy the servers and GPUs. Build data centers, or lease space in someone else's. Own the power contracts, the cooling, the supply chain, and the multi-year lead time on the next generation of chips.
• Rent the infrastructure. Let AWS, Google Cloud, or Azure own the hardware, the power, and the supply chain. Pay for what you use. Scale up and down with an API call.

Both bets are defensible. Both scale to hundreds of millions of users. But they produce almost opposite organizations — and opposite jobs for whoever has "Capacity TPM" on their badge.

The Hardware Model: Capacity as a Supply Chain

Companies that own their infrastructure — Meta and Google are the clearest public examples — treat capacity as a physical-world problem with a software layer on top.

Meta's own engineering blog describes systems called Global Reservations and Regional Fluidity: software that solves capacity placement as a literal assignment problem, using a solver to decide which physical machines go to which data center region, accounting for disaster-readiness buffers, latency constraints, and hardware refresh cycles. That's not a metaphor for a spreadsheet — it's mixed-integer optimization running against a fleet spread across a growing list of global regions.

Meta's public job postings for Data Center Capacity Engineer roles describe the position as coordinating across capacity and performance engineers, data scientists, optimization engineers, supply chain, logistics, finance, data center construction, facility operations, security, network engineering, hardware engineering, and systems tooling teams — for a single capacity decision. Meta's capacity and infrastructure supply chain organizations are publicly described as managing billions of dollars of investment a year.

Google runs a comparable model: it owns its data centers, builds its own TPUs alongside third-party GPUs, and uses internal systems to abstract physical machines into a centrally managed, fungible pool rather than letting individual teams order their own hardware.

In this model, a "capacity request" isn't a form. It's a multi-quarter forecast that has to account for chip lead times measured in months, power availability at a specific site, and an actual truck delivering an actual rack. Getting it wrong doesn't mean a slow API response. It means a training cluster that doesn't exist yet, for a model that was supposed to ship this year.

That's why these organizations run capacity functions in the hundreds, sometimes low thousands. It isn't bloat. It's a manufacturing and logistics operation that happens to produce compute instead of cars.

The Cloud Model: Capacity as a Line Item

Now take a company that decided, deliberately, not to run its own data centers.

Netflix is the canonical example, and its own long-standing public reasoning is straightforward: the physical infrastructure work that has to happen but creates no competitive advantage — what AWS and Netflix have both called "undifferentiated heavy lifting" — belongs to a cloud provider, not to Netflix engineering. Netflix runs across multiple AWS regions using thousands of auto-scaling groups, combining predictive pre-scaling with reactive auto-scaling to absorb traffic surges automatically.

Pinterest tells a similar story from a different starting point. It was built on AWS from 2010 and has never operated its own data center. Its most recent public infrastructure news is a multibillion-dollar, multiyear AWS commitment for more compute — not more buildings.

In this model, "we need more capacity" is a sentence, not a supply chain event. A team requests a quota increase or a bump in reserved capacity, and infrastructure that would take a hardware refresh cycle at a company like Meta shows up in minutes. The team that would otherwise run the hardware supply chain mostly doesn't need to exist — AWS already built and staffed that function, and spread its cost across every customer on the platform.

That doesn't mean nobody thinks about capacity at a cloud-native company. It means the thinking moves: from procurement and disaster-readiness buffers to cost visibility, reserved-instance strategy, and knowing which team's usage spike is about to blow the monthly cloud bill. It's real work. It's just a different kind of real work, done by a much smaller group of people.

Same Title, Different Org Chart

Here's where it gets interesting for anyone holding the title Capacity TPM.

At a hardware-heavy company, you're one node in an org chart full of cross-functional partners: facility operations, hardware engineering, supply chain, finance, construction. Your job is coordination across a physical operation. You need to be fluent in rack power budgets and chip lead times, not just a Gantt chart.

At a cloud-native company, your cross-functional partners are more likely to be finance, platform engineering, and the product teams actually consuming capacity. Your job looks closer to FinOps with a systems-thinking layer on top: reading usage trends, catching cost anomalies, negotiating internal quota, occasionally escalating to a cloud provider's account team. The hardware supply chain isn't your problem, because it isn't your company's hardware.

Neither job is easier than the other. They're just not the same job. A hardware-model Capacity TPM dropped into a cloud-native team will go looking for a supply chain that doesn't exist. A cloud-native Capacity TPM dropped into a hardware-heavy team will hand in a capacity plan with no lead-time buffer — and watch it break in Q3.

What This Means If You're Hiring, or Being Hired

The industry hasn't caught up to this split. Job boards list "Capacity TPM" or "Capacity Planning TPM" as if it's one role with one skill set. It isn't. It's at least two roles that happen to share a title:

• One is closer to a supply chain and operations discipline, with software as the coordination layer.
• The other is closer to a financial operations discipline, with rented infrastructure as the substrate.
  

If you're interviewing for either, ask the question that actually matters before you ask about scope, team size, or tooling: does this company own its servers, or rent them? Almost everything else about the job — how big the team is, who you'll spend your day with, what "urgent" means, how many quarters out you're forced to plan — follows from that one answer.

The title on the offer letter won't tell you that. The org chart will.

Vimal Dhupar is a Senior Technical Program Manager specializing in AI infrastructure and recommendation systems at scale. She has led large-scale AI capacity and infrastructure programs across major technology companies. Find her on LinkedIn.