5 guests 5 episodes 3,210 words

The Platform Paradox: When Shared Infrastructure Is Leverage — and When It's a Tax

Should platform and infra teams be embedded inside product teams, or run as independent service providers — and when do they become bottlenecks?

Camille Fournier wrote the book on platform engineering and will tell you, without much prompting, that most platform teams are exactly as bad as their internal customers say they are. Upasna Gautam runs CNN's core content platform with editors pulling her into breaking-news pivots at all hours. Bret Taylor ran Facebook's platform and mobile orgs and had to be told by Sheryl Sandberg that he was failing the job because he kept retreating into the parts he personally enjoyed. In different ways, all three defend the idea that a standalone platform team can work.

Then there is Geoff Charles at Ramp, whose published org-design playbook centers on one contrarian rule: embed platform teams inside product teams for as long as possible, because pure platform teams drift too far from the business to prioritize well. Behind all of them is Jackie Bavaro, whose framing cuts across the debate — platform teams, she argues, are where PMs discover they have no real strategy. The question of embedding is downstream of a more embarrassing one: do you actually know what the platform is trying to win?

Should platform and infrastructure teams be embedded inside the product teams they serve — staying close to business context at the cost of some duplication — or run as independent, horizontal service providers that own shared foundations but risk drifting into bottlenecks that product teams learn to route around?

The 3 Positions

1 / 3

Standalone Platforms Work — If You Pay the Full Product Tax

Camille Fournier · Upasna Gautam · Bret Taylor

Camille Fournier — Ran platform engineering at Two Sigma and engineering orgs at Goldman Sachs and JP Morgan; co-author of Platform Engineering and author of The Manager's Path.

Fournier offers the least romantic defense of standalone platform teams you can find. She is unusually candid that most of them are dysfunctional in exactly the ways product managers complain about — slow, tone-deaf, funded on infinite runway, happy to force feature compromises to justify adoption of internal systems. She wrote the book to name that pathology and argue it is fixable, but only if leaders stop treating platform as infrastructure-plus-DevOps and start treating it as a product discipline.

"I'm very sympathetic to anybody who feels that way because part of the reason that I wrote this book, I co-wrote it with a friend, Ian Nolan, is that so many platform teams are guilty of all the things that he's complaining about, that my friend was complaining about, that they don't listen, they're not delivering effectively, they're not explaining their value to the company."
Camille Fournier
▶ 00:55:08

The fix is structural. Platform teams need actual software engineers — not just SREs running blueprint scripts — because the output is supposed to be a cohesive internal product, not a grab bag of cloud hygiene. They need PMs, outcome goals, and a theory of leverage. Without that, platform teams drift into technology-for-its-own-sake work.

"I'm a very strong believer that platform engineering has to involve software engineering. If you don't have any software engineers on your platform team and you only have more operations systems engineers, DevOps, SRE... I think you're kind of missing the picture. Platform engineering is not just maintaining cloud infrastructure and doing small scripts or blueprints or enablement projects for other teams, because that doesn't really create a cohesive and coherent platform. It doesn't create products and frankly you need to be ... platforms are products, ultimately."
Camille Fournier
▶ 00:58:17

Her advice to product teams stuck with a bad platform team is telling: if it has no PM, product-manage it from the outside. The workaround betrays the real point — standalone only works when the standalone team behaves like a product.

"One of the challenges is that people create these platform teams and think that they can be sort of divorced from having an impact focus because it's like, 'Well, you just got to run the infrastructure and make sure it works.' And it's like, 'No, you actually do still have to do ... you've got to take a lot of the best practices of product.'"
Camille Fournier
▶ 01:01:29

Upasna Gautam — Senior PM leading CNN Digital's core content platform, rebuilding the CMS used by every journalist and editor while onboarding the global editorial staff.

Gautam's team is a textbook standalone platform team — horizontal, shared, foundational. What makes her case interesting is that her stakeholders are not abstract internal engineers. They are editors and journalists on deadline, operationally embedded in her product development process whether she asked for it or not.

"On my team, the core platform team, our stakeholders and our customers, like I mentioned, are journalists and are editors. Which presents a really unique dynamic, and it's one that I love. We have direct access to our customers at all times of day, for better or for worse, and they're embedded into our product development process."
Upasna Gautam
▶ 00:16:21

The team owns a multi-year replatforming project — the kind of work embedded teams almost never get to protect — and survives that mandate precisely because of direct line of sight to users.

"Since my team is a core platform team, our main responsibility is to A, build our newer, faster, more flexible content management platform to replace our legacy one, and B, onboard our entire editorial staff to it."
Upasna Gautam
▶ 00:16:50

"It happens all the time, right? That is the nature of breaking news. I mean, you have to be ready to pivot at the drop of a hat. I had a big working session planned with my users to do research with them... and breaking news breaks, and it takes so much time and effort to gather a team of editors across the globe to do a user testing session. And when breaking news happens, they have to prioritize that over everything."
Upasna Gautam
▶ 00:00:00

Her implicit argument reframes the debate: embedding versus standalone is the wrong axis. The binding constraint is distance from the pain the platform is supposed to remove. If your users are in your process, the reporting line barely matters.

Bret Taylor — Co-creator of Google Maps and the Facebook Like button, former CTO of Facebook, co-founder and CEO of Sierra, current board chair of OpenAI. Ran Facebook's mobile and platform groups at peak scale.

Taylor's contribution is not about org design — it is about the posture required to lead platform work. When Facebook reorganized and he went from a small CTO team to more than a thousand people running mobile and platform, he kept gravitating toward the parts he personally enjoyed: product details, architectural decisions, partner presentations he could edit himself. Sandberg caught him at it.

"I was trying to conform the job to the things I thought I liked to do. So, I was spending a lot of my time on some product and technology things that I was passionate about, thinking I'm the boss. I should focus on what I want to focus on instead of thinking about, okay, I'm running the mobile and platform teams at Facebook. What's the most important thing to do today to make our mobile and developer platform successful?"
Bret Taylor
▶ 00:17:30

Platform teams serve other teams, so the scoreboard is always someone else's. Leaders who need it to be their own either push the platform toward customer-facing work or drift into infrastructure-as-hobby.

"Our developer platform had a lot of partners and when there was an issue there and I'd spend time on partnerships and it worked and our platform became healthier, the partner became more successful. I took pride in that success and then I just started being better at my job."
Bret Taylor
▶ 00:18:03

"The actual act of engineering or product design or all the things I thought I liked, what I really liked is impact."
Bret Taylor
▶ 00:18:49

His story cuts both ways. Standalone platform teams fail when leaders cannot take joy in someone else's success. Embedded teams fail with the same leaders — the dysfunction just hides inside a product team.

When This Applies

when you are early, velocity is the dominant constraint, and the platform has one clear first customer. Ramp's payments platform inside Bill Pay and its data-science platform inside the risk team.

Embed as Long as Possible — Pure Platforms Are a Trap You Hit Too Early

Geoff Charles

Geoff Charles — VP of Product at Ramp, which reportedly reached $100M ARR in two years with ~50 people. His teardown with Lenny, How Ramp builds product, is one of the most-read pieces in the Lenny's Newsletter canon.

Charles has turned Ramp's org design into a velocity machine, and his most contrarian claim is that pure platform teams are a trap fast companies fall into too early. Platform work exists to serve real product use cases; those decisions are dominated by product context, not infrastructure elegance. Separate the platform team from its customer and prioritization drifts, every dependency becomes a negotiation, and velocity collapses.

"Embed platform teams as long as possible. Pure platform teams are often too far removed from the business context to make the right prioritization decisions and move with velocity. So we try to keep platform teams embedded in core product teams for as long as we can."
Geoff CharlesHow Ramp builds product

Ramp operationalizes this with discipline. Platform work lives inside the product team with the most acute pull. Only after those embedded teams rack up a few wins does Ramp spin them out — to force the cross-team skill that building the first version never required.

"Our payments platform was embedded within our Bill Pay product because most of the new use cases were B2B payments. Our data-science platform was embedded within our risk team since most of our data-science needs were on underwriting. We spin teams out after they've had a few wins to force them to work across teams."
Geoff CharlesHow Ramp builds product

Two other choices make this viable: small teams (5–10 engineers) and flexible staffing across pods without reorgs. Embedding is a timing heuristic, not a permanent stance. The assumption underneath is that the bigger risk is premature abstraction, not duplicated work.

"One of the biggest values, I think, of software is how do you reuse the components that you've built to increase, again, velocity and impact. So why we were interested in bill payments as an expansion of our corporate card platform was we saw a bill as just an invoice to the company."
Geoff Charles
▶ 00:40:55

Ramp's corporate card platform became the seed of Bill Pay because the same people owned both — embedding made the reuse natural.

When This Applies

when it has racked up wins with its first customer and needs to earn a second — graduation forces the cross-team muscles the platform never had to develop. Ramp's explicit "spin out after a few wins" rule.

Platform Teams Are Where PMs Discover They Have No Real Strategy

Jackie Bavaro

Jackie Bavaro — Former head of product at Asana (first PM there); co-author of Cracking the PM Interview and Cracking the PM Career. Her three-part strategy framework — vision, strategic framework, strategic acts — is taught across the industry.

Bavaro's contribution comes from a formative failure. Her new head of product Alex Hood asked her to write a strategy for the platform team. She confidently handed one over. He told her it wasn't a strategy. That moment drove her three-part framework — and the crucible being a platform team is not a coincidence.

"A few years later we hire Alex Hood, our new head of product. And he's like, 'Can you create a strategy for the platform team?' And I was like, 'Great, here it is. We have it.' And he's like, 'That's not a strategy.' And I was like, 'What?'"
Jackie Bavaro
▶ 00:23:16

Her structural point: platform teams are uniquely bad at producing strategy. The surface area is enormous, customers are internal, and the obvious artifacts — vision decks, roadmaps, metrics dashboards — look strategic without being strategic. A team brain vision plus a capabilities list is a vision and a roadmap with a strategy-shaped hole in the middle.

This is also, she argues, why Principal and Partner PM roles cluster on platform teams. The business needs a single PM who can have director-level impact on a small, highly leveraged team, and problems of that shape tend to be platform or partnerships. But the roles are rare because most platform PMs can't articulate a real strategy and so never produce the impact.

"The reason a company would give you that high of a title is because they have a business need for PM who can have as much impact as a director, but with the team that's small enough that they can PM the whole team. And there's only a few problems out there like that. Platform type teams can fill that role a lot of the time."
Jackie Bavaro
▶ 00:18:38

"If you want to go down that route, it's probably going to be an infrastructure team or a new business unit, unlikely to be a user facing piece, because they probably want to build a large teams there with a lot of layers."
Lenny Rachitsky
▶ 00:20:50

Her implicit position on embedding is that reporting lines are a distraction. The binding constraint is whether the platform team can state what it is trying to win. If it can't, embedding gives it borrowed strategic clarity. If it can, it deserves independence.

When This Applies

when the work is a multi-year replatforming project that would be crushed under short-term product priorities, or when internal users are loud enough that distance-to-user is solved without formal embedding. CNN's CMS rebuild and global editorial onboarding.

Evidence from the Archive

Two Sigma

Camille Fournier wrote the book on platform engineering because most platform teams are guilty of exactly what their internal customers complain about

Her core move: platforms are products, which means they need PMs, software engineers, and outcome goals — not SRE V2 running on infinite funding

Camille Fournier · Engineering executive; co-author of Platform Engineering ▶ 00:58:17

Ramp

Ramp embedded its payments platform inside the Bill Pay product team and its data-science platform inside the risk team — only spinning them out after 'a few wins'

Geoff Charles argues pure platform teams are a trap: removed from product context, they lose prioritization discipline and collapse velocity

Geoff Charles · VP of Product at Ramp ▶ 00:40:55

CNN

Upasna Gautam runs CNN's CMS platform team with journalists physically embedded in the product process — research sessions get scrapped mid-flight when breaking news hits

Her counterexample: standalone platform teams aren't inherently bottlenecks; the failure mode is distance from users, not reporting lines

Upasna Gautam · Senior Product Manager, core content platform at CNN ▶ 00:16:21

Asana

Jackie Bavaro confidently handed her new head of product a platform strategy; he told her it wasn't one. That moment produced her three-part strategy framework

Her argument: platform teams are where PMs discover they have no real strategy — a roadmap plus a vision is a strategy-shaped hole

Jackie Bavaro · Former head of product at Asana; co-author of Cracking the PM Career ▶ 00:23:16

Facebook

Sheryl Sandberg caught Bret Taylor editing a partner presentation instead of managing his team — the feedback that reframed his approach to running Facebook's platform org

Taylor's lesson: platform leaders fail when they optimize for their own interests rather than for the platform's scoreboard, which is always someone else's success

Bret Taylor · Former CTO of Facebook; co-founder of Sierra; chair of OpenAI board ▶ 00:17:30

The Synthesis

The embed-vs-standalone debate is actually a debate about three variables that get conflated, which is why the argument never resolves.

Distance From Pain

How many hops from your platform team to actual user pain?

The Full Product Tax

Have you paid for platform-as-product, or just platform-as-ops?

Spin Out After Wins

Has your platform earned its second customer yet?

Strategy Before Org Chart

Can your platform team articulate what it's trying to win?

Someone Else's Scoreboard

Can your platform leader take joy in a partner's success?

The real binding constraint isn't embedded-vs-standalone, it's distance from the problem the platform is supposed to remove. Gautam's CNN team is standalone but has journalists embedded in her process. Charles's Ramp pods are embedded in whichever product team has the most acute pull. Both solve the distance problem structurally — the reporting line barely matters.

Fournier's rule: standalone platforms only work when they behave like products — real PMs, software engineers (not just SRE and ops), outcome goals, a theory of leverage. Most dysfunctional platform teams skipped the product tax. If yours has no PM, product-manage it from the outside. The workaround itself proves the point.

Geoff Charles's timing heuristic: embed platform work inside the product team with the acute pull, then spin it out only after a few wins force it to work across teams. Ramp's payments platform grew inside Bill Pay; data science inside risk. Pure platform teams aren't wrong — they're just premature until the second customer arrives.

Jackie Bavaro's crucible: platform teams are where PMs discover they have no real strategy. The surface area is enormous, customers are internal, and vision decks plus roadmaps look strategic without being strategic. Embedding buys time for a missing strategy; it doesn't fix it. Interrogate strategic clarity before debating reporting lines.

Bret Taylor's Facebook lesson: platform work serves other teams, so the scoreboard is always someone else's. Leaders who need it to be their own drift into architecture-as-hobby or push the platform toward customer-facing work it shouldn't be doing. Sandberg had to name this failure mode for him directly. It hides equally well inside embedded and standalone teams.

Which Approach Fits You?

Answer 3 questions about your situation. We'll match you to the right approach.

Question 1

Where does your platform work have its center of gravity today?

Question 2

What does your platform team's composition look like?

Question 3

What is your biggest complaint about how platform work is going?

Notable Absences

The Bottom Line

The non-obvious insight: the embed-vs-standalone choice is a lagging indicator of whether you have solved three other problems. If your platform team has direct line of sight to user pain, a real strategy, and a clear theory of leverage, standalone works. If it has none of those, embedding buys time but does not fix it — the dysfunction compounds inside a product team that now has to carry it too.

*How Ramp builds product* is the canonical statement of the embedded side, and it reads best alongside *General management, functional, and hybrid models*, which documents how Coinbase and Intuit run standalone platform teams for shared services — AI modeling, identity, security — while keeping GM business units nimble. *How Figma builds product* shows the further end of the arc: horizontal platform teams sitting across vertical product teams, the exact shape Fournier defends and Charles warns against stepping into too early.

Sources

Camille Fournier — "The things engineers are desperate for PMs to understand | Camille Fournier (author of “The Manager’s Path,” ex-CTO at Rent the Runway)" — Lenny's Podcast, September 15, 2024
Upasna Gautam — "An inside look at how CNN builds product | Upasna Gautam" — Lenny's Podcast, February 23, 2023
Jackie Bavaro — "Jackie Bavaro on getting better at product strategy, what exactly is strategy, PM pitfalls to avoid, advancing your career, getting into management, and much more" — Lenny's Podcast, June 16, 2022
Bret Taylor — "He saved OpenAI, invented the “Like” button, and built Google Maps: Bret Taylor on the future of careers, coding, agents, and more" — Lenny's Podcast, July 31, 2025