Platforms Are Products
When to start a platform team, who staffs it, and the impact metrics that keep it honest
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Fournier's operating model for internal platform teams, from her forthcoming O'Reilly book Platform Engineering. The central move is refusing the 'SRE V2' framing: a platform team is a product organisation, staffed with software engineers, systems/SRE specialists AND product managers, held to impact-based outcomes rather than 'we run the infrastructure'. She also gives concrete readiness signals for when a company should start one at all.
Origin
Camille Fournier, co-authored with Dean Nolan as the book Platform Engineering: A Guide for Technical, Product, and People Leaders (O'Reilly). Built on her time as Head of Platform Engineering at Two Sigma and building internal platforms at JP Morgan Chase and Goldman Sachs, and explicitly written because so many platform teams are guilty of the things their internal customers complain about.
Core principles
- 01Platforms are products. Build coherent offerings that make the company more productive, not a pile of scripts and enablement projects.
- 02Platform engineering must involve real software engineering — infra ops and small scripts alone don't produce a cohesive platform.
- 03You need product people. Engineers and engineering managers will do their best, but you cannot write the code or run the team and be the PM at the same time, at least not for long.
- 04The PM:engineer ratio on platform teams is legitimately higher — a lot of platform work is deeply technical scaling work that needs no product spec.
- 05Platform work is longer-running and more complex than typical agile product delivery. Adapt the practices; don't pretend the cadence is the same.
- 06The best platform offerings are usually harvested, not invented: an application team solves its own problem well, and the platform team assimilates it and makes it available to everyone.
- 07Migrations are unavoidable even if you never force them — your cloud provider will force them for you.
How to run it
- 1
Check the readiness signals before creating the team
Three triggers: roughly 50+ engineers; duplicated effort where the same kind of person on every team is solving the same kind of problem; or a core scaling issue (e.g. nobody can get code released without cross-team coordination) that needs a dedicated team.
Pro tip Below ~10 engineers, ad-hoc coordination is fine and correct — one person minding GitHub, a couple of people per team sharing the cloud databases.
Watch out Don't jump into a platform team early. This is for companies that have matured to where internal productivity and centralisation are worth real investment.
- 2
Staff all three disciplines
Software engineers (who will build actual products, not blueprints), systems/SRE specialists for the operational and scaling half of the work, and product managers who own discovery and impact framing.
Pro tip Some of the best PMs Fournier has ever worked with were platform PMs — platform is a high-leverage place to put a PM, because it makes the whole company faster.
Watch out Many companies refuse to 'waste headcount' on PMs for internal teams. The result is a room full of smart engineers who don't really know what to build and default to building whatever seems right.
- 3
Set impact-based, measurable outcomes
Replace 'we built this thing that seemed cool' and 'we adopted this technology everyone on the internet is talking about' with measurable contributions: are we reducing cycle time for engineering tasks, are we unblocking products that can't launch or scale, are we making meaningful cost reductions or efficiency gains.
Pro tip Take the best practices of product — OKRs, goal-setting, discovery — and adapt them to the internal world. They're different but still essential.
Watch out The seductive error is thinking a platform team can be divorced from impact focus because 'you just run the infrastructure'. You can't.
- 4
Harvest good solutions from application teams
Watch for individual application teams solving a problem well for themselves. Take that solution, generalize it, and make it available to more and more teams. This is where much of the best platform offering originates.
Pro tip This makes platform a 'past-one' discipline rather than a zero-to-one one — taking things over, stabilizing, scaling and evolving them.
Watch out If you want to be building brand-new stuff all the time, you probably won't be happy on a platform team.
- 5
Own the three unglamorous parts of the job
Longer, larger-scale project management that agile practices only partly cover; a constant stream of migrations, including ones your cloud provider forces on you; and stakeholder management, which is universally the least fun part of the job.
Pro tip Fournier is glad she has the stakeholder-management skill set even though nobody loves the work — for leaders it's a big part of the job, not an optional extra.
Watch out If you want to only do the fun tech problems, you may be fine as an IC but you will not be happy leading a platform team long-run.
In the wild
Fournier maps the territory: teams formerly called dev tools (CI/CD tooling), cloud infrastructure provisioning and tooling, semi-bespoke storage systems, and web/mobile framework support. She also names an in-between category — integration platforms like a single billing platform serving all product lines, which shares the multi-tenant scaling problems of infra teams while needing more real product discovery and business focus.
→ A definition that includes the blended cases most companies actually have, rather than the pure infra caricature.
A former colleague of Fournier's, working on customer-facing products, complained that platform teams are slow, push product teams to compromise on features to adopt their systems, and get infinite funding without ever showing ROI. Fournier's response is sympathy, not defence — she says so many platform teams are guilty of exactly these things, and that failing to explain their value to the company is part of why she wrote the book.
→ The complaint becomes the specification: measurable impact and product discipline are the answer to 'what is this team even for?'
Common mistakes
Building a platform team with no software engineers
A team of ops/systems engineers and SREs doing scripts, blueprints and enablement projects doesn't produce a cohesive, coherent platform. It produces infrastructure maintenance.
Refusing PM headcount for internal teams
Without product people, you get a room of smart engineers with no clear picture of what to build, so they build whatever they think is right — and the ROI question becomes unanswerable.
Starting a platform team too early
At 10 engineers the ad-hoc sharing is genuinely fine. Centralizing before there's duplicated effort or a real scaling bottleneck spends headcount on a problem you don't have.
Chasing technology because the internet is talking about it
Adopting a stack because it's fashionable — whether it came from a VC-funded startup or a big company whose context you don't share — is the exact opposite of asking what problems your engineers actually face.
Is it for you?
Best for
Engineering leaders at companies past ~50 engineers deciding whether and how to create a platform team, and PMs considering a platform role.
Not ideal for
Startups under ~10-50 engineers where ad-hoc coordination still works, and teams whose problem is customer-facing product-market fit rather than internal leverage.
From the transcript
“platforms are products ultimately”
“you want software Engineers you want systems Engineers you want product people”
“it tends to be like you have 50 plus Engineers I don't think this is the kind of thing that you start when you are…”
“are we reducing the cycle time for engineering tasks are we solving problems that are preventing products from launching”
From the episode
The things engineers are desperate for PMs to understand
Camille Fournier (author of “The Manager’s Path,” ex-CTO at