Subscribe now

The team had been building for eight months. Four tools shipped, two more in review. The platform lead was proud, and rightly so. The work was good. The code was clean. The internal docs were better than most external ones I’ve seen.

Nobody was using any of it.

Not because the tools were bad. Because the team had built them in the wrong sequence. They’d gone straight to System without doing Roadmap. They’d solved the problems they assumed product engineers had, rather than the ones product engineers were actually bleeding on that quarter. When adoption flatlined, they interpreted it as a distribution problem and wrote more documentation. It wasn’t a distribution problem. It was a sequencing problem, and no amount of docs fixes that.

I’ve seen this pattern more times than I can count. Teams that ship consistently but compound nothing. Teams that build in circles because they never established what “done” looks like for a platform problem. Teams that arrive at ecosystem thinking without the trust to back it up. The tools are real. The adoption isn’t. The platform exists on paper but not in behavior.

The RSE Framework is my attempt to name what’s actually happening. To give platform teams a sequential operating model that prevents the most common failure modes before they have a chance to take root.

I've also put together a free slide deck covering the full framework. Useful if you want something to reference or share with your team.

Download it here

Platform teams don’t fail by building badly.

They fail by building out of order. That’s a harder problem to diagnose, because the output looks like progress. Tools ship. PRs merge. Demos happen. The team is busy. And yet six months later, the platform’s adoption curve is flat, the roadmap feels like a guessing game, and the engineering leader who funded the team is quietly asking whether it’s working.

This isn’t a resource problem. The teams I’ve seen fail had engineers, often good ones. It wasn’t a technology problem either. The tooling choices were reasonable. It was an ordering problem. They’d skipped a stage they didn’t know they were supposed to do, or rushed through it, and the consequences arrived six months later looking like something else entirely.

The default mental model for a platform team is wrong. Most people think of it as “a team that builds internal tools.” That framing is accurate but incomplete. It describes the output without describing the operating model. Without an operating model, the team optimizes locally, solving whatever’s loudest this sprint, instead of compounding leverage across time.

What’s missing is a theory of sequencing. What do you do first, what does it unlock, and what happens when you skip it? That question doesn’t have an obvious answer when you’re standing at the beginning. Most teams discover the answer the hard way, in retrospect, after the adoption plateau or the reorg.

RSE is my answer to that question. It’s not a methodology with ceremonies. It’s a three-stage progression: Roadmap, System, Ecosystem. Each stage builds the foundation the next one depends on. Skipping a stage produces a predictable, nameable failure mode.

Before R, S, or E: The Two-Audience Discipline

Before explaining any of the three stages, there’s a meta-principle that threads through all of them. It’s the lens that RSE gets read through, and ignoring it is one of the fastest ways to build a platform team that’s technically productive and organizationally invisible.

Engineers are the customer. Leaders are the investor.

Engineers use the tools daily. Their adoption is the only real measure of whether the platform exists. If they route around you, nothing else matters. Not the docs, not the roadmap, not the OKRs.

Engineering leaders fund the team, defend its scope in headcount conversations, and decide whether it survives the next reorg. They don’t use the tools. They need to see the return.

Build only for engineers and you lose your funding. Build only for leaders and you lose your users. Both have to hold simultaneously, at every stage.

This split isn’t a communications strategy. It’s an architectural constraint. In Roadmap, problems are sourced from engineers (they feel the pain) but ranked in language leaders understand: hours recovered, incidents avoided, headcount-equivalent leverage. In System, tools are built for engineer ergonomics, but every one tracks a metric legible to someone writing a budget defense. In Ecosystem, adoption rate proves the customer hypothesis while cost-of-replacement proves the investor thesis.

What Skipping Stages Produces

The naive approach to platform team strategy is to start building whatever’s loudest. A product engineer complains about service scaffolding, so you build a scaffold starter. Another team mentions inconsistent observability, so you write a shared logging library. Each decision feels reasonable in isolation. The team is responding to real pain. But the sequencing is emergent and reactive rather than deliberate and compounding.

When I talk about “skipping a stage,” I don’t mean ignoring it entirely. I mean doing it incompletely, implicitly, or in the wrong order. The result is always one of three recognizable failure modes. These aren’t hypotheticals. They’re patterns I’ve seen play out at real teams, and the failure mode names itself once you know what to look for.

The interesting thing about these failure modes is that they’re each invisible from inside the team experiencing them. Roadmap-less building looks like thoroughness. System-less shipping looks like productivity. Ecosystem-less platforming looks like vision. They only become legible as failure modes in retrospect, or from the outside.

RSE: The Operating Model

Each stage has a clear purpose and an extractable principle. The stages are sequential. Each one builds the foundation the next depends on. But they’re not linear in the sprint-by-sprint sense. You’ll revisit Roadmap when your team grows or your org reorgs. You’ll refine System as adoption data comes in. The sequence is about what earns what, not about time boxes.

R: Roadmap

A ranked list of problems with explicit exit conditions. Not a list of tools.

That distinction sounds minor and is not. Most platform team “roadmaps” are actually lists of things someone wants to build. A proper Roadmap is a prioritized list of things that are wrong: problems, friction points, failure modes, each with a clear definition of what “solved” looks like. The tool that solves the problem comes later. The problem comes first.

You can’t build a system for problems you haven’t named. The Roadmap stage is where you earn the right to start building.

R.01: Problem Discovery

Pain surveys over whiteboards. The instinct, especially for strong engineers, is to synthesize the solution space, to think about what a well-run platform team should build and work backwards. That produces plausible-sounding roadmaps that nobody asked for.

The correct starting point is talking to product engineers about what cost them time last sprint. Not what they think a platform team should build, but what specifically made their work harder than it should have been. The questions the team isn’t asking are often the problems the platform should solve. What’s too painful to even put on a ticket? What do engineers work around rather than fix?

R.02: Prioritization

Once you have the problem list, you rank it:

How often does this problem occur, how bad is each occurrence, and how many teams does it affect? Multiply those three scores. The top three problems are your P0s. Everything else is a distraction until those ship.

Prioritization is also where the Two-Audience discipline shows up most directly. Engineers feel the pain in ways that map naturally to frequency and severity. Blast radius is the investor framing: it’s what makes the problem legible at a headcount conversation. A problem that affects eight teams is a different budget conversation than a problem that affects one. The ranking must be defensible to both audiences.

R.03: Scope Definition

The charter. Five sections: mission, scope, non-scope, SRE boundary contract, KPIs. If you can’t write it in two pages, the team doesn’t exist yet. It’s a group of engineers with overlapping tickets and a shared Slack channel.

The non-scope section is as important as the scope section. Without an explicit boundary, platform teams accumulate operational burden. A charter with a clear non-scope makes “no” a policy decision rather than a personal one. That’s the only way to hold the boundary when leadership is watching.

The SRE boundary contract deserves specific attention. The line between backend platform engineering and infrastructure/SRE is genuinely blurry, and without a written agreement it becomes a source of chronic territorial friction. Which pager rotation does a given tool live in? Who owns the SLA? Who handles migrations? Write it down.

R.04: Sequencing

Which problems unlock the next ones. Solve scaffolding before observability, because observability rides on scaffolding. Solve config before feature flags, because flags depend on config. The dependency graph of your problems is as real as the dependency graph of your code. It determines what order operations have to happen in.

R.05: Success Criteria

Define what “solved” looks like before you start. If you don’t define done before you begin, done becomes “the tool shipped,” and that’s not the same thing.

Success criteria live at two levels: customer-facing (adoption rate per eligible service, steps removed, time-to-production for a new consumer) and investor-facing (developer hours recovered per quarter, incidents avoided, headcount-equivalent leverage). Both sets need to be defined upfront, tracked explicitly, and reported on. A tool ships against both or it doesn’t ship.

A roadmap isn’t a list of tools. It’s a ranked list of problems with explicit exit conditions, defensible to the engineers bleeding on them and to the people writing the checks.

S: System

The execution playbook that turns named problems into tools that compound rather than one-offs that decay.

Most teams fail here. Not by shipping badly, but by shipping without a system. Each tool is built from scratch in terms of quality bar, distribution strategy, documentation approach, and versioning discipline. The tenth tool has no more adoption momentum than the first. Nothing compounds because nothing was designed to compound.

The System stage is about building each tool so that the next one is easier to build, easier to adopt, and harder to replace.

A tool that ships once is a feature. A tool that gets adopted, versioned, documented, and depended on is a platform asset. The System is what turns the first into the second.

S.01: Compile-Time First

Bias toward libraries, starters, and annotations over runtime services. Every new internal runtime service is a new on-call rotation, a new SLA, a new blast radius. When that service has an incident at 2am, it’s your team’s pager. Compile-time dependencies fail gracefully. Runtime ones page you.

Runtime services are sometimes necessary. But they should be last resorts, not defaults. If the same problem can be solved at compile time, solve it there.

S.02: The Wrapper Test

Before any tool ships, it has to clear three questions. Does it lower implementation time, as in hours genuinely saved per service? Does it improve developer experience, meaning steps removed, errors prevented at compile time, defaults that actually work? Does it provide an operational benefit the engineer couldn’t get themselves, like observability wired in, retries handled, idempotency enforced by default?

A wrapper that does what the underlying library already does isn’t a platform asset. It’s tax with your team’s name on it.

S.03: Documentation as First-Class

A tool isn’t done when the code merges. It’s done when an engineer who’s never seen it can go from “I need this” to “it’s in production” without messaging the platform team.

That means a working quickstart that runs end-to-end in under ten minutes, a failure-mode reference that answers the three questions engineers ask most often, and versioned docs with visible deprecation timelines. Undocumented tools don’t get adopted. They get tolerated until something better appears.

S.04: Paved Road, Not Mandate

The default path has to be the easiest path. If using the platform tool is harder than rolling their own, product teams roll their own. Mandates fail against friction. Friction beats mandates every time. The goal is to make the right thing the path of least resistance, the thing a new engineer does without being told to.

S.05: Distribution Mechanics

Adoption isn’t a launch problem. The most effective strategy: embed with one product team per sprint. Solve their specific, named pain. Let them become advocates. When that engineer talks to another team about how they solved the problem, it carries infinitely more weight than anything the platform team announces internally. Internal announcement emails don’t move adoption. Respected product engineers do.

S.06: Versioning and Migration Discipline

Plan v2 before v1 launches. The deprecation path is part of the initial design, not an afterthought. Platform team credibility is built on how it handles upgrades, not how it handles launches. A migration that’s smooth and well-communicated earns more goodwill than a polished launch. A painful migration destroys the credibility that a dozen launches built up.

S.07: Observability of the Platform Itself

Your tools need their own metrics. Adoption rate per eligible service. Error rate per consumer. Developer time saved, measured and reported. You can’t compound what you can’t measure, and you can’t defend a platform budget on vibes.

S.08: The Reactive/Planned Split

Protect planned work from reactive support. A standard split worth defending: 60% planned tooling, 30% reactive support, 10% tech debt. Without this split, reactive work eats everything and the roadmap becomes fiction. This is a leadership-level decision, not a sprint negotiation. If it’s left to the team to self-enforce, reactive work wins by default.

A tool that ships once is a feature. A tool that gets adopted, versioned, documented, and depended on is a platform asset. The System is what turns the first into the second.

E: Ecosystem

Individual tools are replaceable. An ecosystem is not.

The Ecosystem stage is where a team that ships good tools becomes a team that is infrastructure. It’s the phase where the platform stops being a service product teams use and starts being the environment they work inside. That shift doesn’t happen by accident. It happens because the System stage was executed with compounding as a design goal.

An ecosystem isn’t tools that coexist. It’s tools that make each other more valuable, to the point where leaving the ecosystem costs more than building inside it.

E.01: Interoperability by Default

Every tool in the ecosystem speaks to every other one. The starter ships with logging, tracing, metrics, auth, and feature flags wired in. Pulling one piece means losing all of them, intentionally. Standalone tools don’t compound. Interoperable tools do.

E.02: Shared Primitives

One auth model. One config system. One error taxonomy. One observability schema. Product engineers learn it once and it applies everywhere. The primitives are what make the ecosystem feel like a single product instead of a collection of utilities with inconsistent interfaces, and what makes onboarding fast at scale.

E.03: The Golden Path

A single documented sequence from “I have an idea” to “I’m in production with audit logging, idempotency, and dashboards.” The default is mandatory. The escape hatch is opt-in but supported.

The golden path is a contract, not a cage. Every tool on the path ships with documented extension points: interfaces to implement, hooks to override, config to swap. No tool is allowed to be a black box. A team with a legitimate edge case can get off the path, but they do it explicitly and they lose the platform team’s SLA in doing so. Anything outside the golden path is a one-off the platform team doesn’t owe support to.

E.04: Compounding Surface Area

Every new tool that integrates with existing ones makes the existing ones more valuable. The third tool in an ecosystem is worth more than the first three standalone tools combined. Compounding is the design goal, not feature breadth, not tool count.

The metric that proves this to leadership: not “we shipped six tools this quarter” but “adding the sixth tool increased average daily active usage of the first five.” That’s compounding.

E.05: Cultural Lock-In

When senior engineers refuse to onboard at companies without an internal platform like yours, you’ve won. The ecosystem isn’t the tools. It’s the expectation engineers have about how their work should feel. That expectation is the most durable moat a platform team can build, and it can’t be copied by writing a single tool.

Cultural lock-in isn’t manipulative. It’s the natural result of building tools engineers genuinely prefer. The lock-in is just the cost-benefit math coming out in the platform’s favor consistently enough that it becomes the default assumption.

E.06: External Boundary

What the ecosystem deliberately does not cover. Product logic stays with product teams. The ecosystem owns the layer underneath, not the layer above. Without an enforced boundary, the platform becomes a dumping ground for everything nobody else wants, and it dies under the weight of work it never should have owned.

An ecosystem isn’t tools that coexist. It’s tools that make each other more valuable, to the point where leaving the ecosystem costs more than building inside it.

The Sequencing Is Not Optional

I want to be explicit about what I’m arguing here, because RSE can be read as three helpful categories that you can mix and match. That reading is wrong.

The sequencing matters. You cannot do System well without Roadmap, because System executed without Roadmap is system-less shipping and you won’t know it until adoption flatlines. You cannot do Ecosystem well without System, because Ecosystem without System is architecture astronautics and the org will reorganize before you earn the trust to back it up.

R before S before E is a constraint, not a preference.

The legitimate objection is: “We’re already in S or E, does this framework help us at all?” It does, but differently.

If you’re in System without having done Roadmap properly, the immediate move is a discovery pass. Not to restart, but to validate that what you’re currently building maps to the problems product engineers are actually experiencing. Run the pain survey. Check the frequency x severity x blast radius ranking against your current tool priorities. If they’re misaligned, adjust.

If you’re in Ecosystem without System discipline, meaning you’re designing for interoperability and shared primitives but the tools themselves don’t pass the Wrapper Test, pull back. The ecosystem design is aspirationally correct but operationally premature. Earn System credibility first. Then the ecosystem becomes achievable rather than theoretical.

Most backend platform teams aren’t building the wrong things. They’re building in the wrong order. Roadmap before System, System before Ecosystem. The sequencing is the strategy.

The Maturity Arc as a Field Diagnosis

Once you have the RSE model, you can use it to diagnose where any platform team is, including your own, and what’s blocking them from moving to the next stage.

Most fifty-engineer organizations are stuck in R. They know the problems exist. They can name them. They haven’t ranked them, chartered the team to own them, or defined what “solved” looks like. The team is busy, the roadmap exists, and nothing is compounding.

Most organizations between eighty and one hundred fifty engineers have an S but no E. They ship tools. The tools work. Adoption is partial: teams close to the platform team use the tools, teams furthest away roll their own. Each tool stands alone. Removing the platform would cost a week of refactoring, not a quarter. The investment is real but not yet irreversible.

The teams that reach E are the ones that became reference architectures. The ones where senior engineers talk about “how we do things here” with a specificity and coherence that reveals an underlying system. The ones where a new service scaffolds in ten minutes and ships with audit logging, idempotency, and dashboards wired in, because that’s just how things work here.

The Question Only Your Context Can Answer

The extractable principle from RSE is simple enough to write on a whiteboard:

Roadmap earns the right to build. System earns the right to compound. Ecosystem earns the right to become infrastructure.

Skip a stage and you skip what that stage earns. The failure mode that follows isn’t punishment. It’s just physics. Systems that skip foundations don’t compound; they accumulate.

Look at your current platform work and ask honestly: which stage are you actually in, and which stage do you think you’re in? If those are the same answer, you’re ahead of most. If there’s a gap between them, that gap is the thing worth fixing before you build anything else.

What would change about your team’s next sprint if you took the RSE sequencing seriously, not as a framework to understand, but as a constraint to build inside?

The decision already made

The same hour, spent four times, in front of the same audience, looks like four hours of productivity.

Sprint review, Friday afternoon:

1. Squad 1 demos a wrapper around the HTTP client to standardize timeouts. Clean work, well-named, ships next sprint.

2. Squad 2 demos a slightly different wrapper, same client library, same problem space, different defaults around retries.

3. Squad 4 demos an audit-logging helper that almost matches the format the platform-adjacent squad rolled out last quarter.

4. Squad 6 isn’t demoing platform work at all. They’re shipping a feature, on time, on the back of three engineers who built their own version of the same scaffolding two sprints ago.

The work is real. The work ships. It just ships four times.

Subscribe now

The EM running the review nods through all four demos. He’s been the EM for fourteen months. He has not yet noticed that three of the four demos are the same demo.

Neither has anyone in the room. The squad leads aren’t withholding it; they genuinely don’t know what the other squads built. There is no forum where they would have found out.

This is the hidden platform team. It’s called “senior engineers doing repetitive work.”

Nobody in that room would call this a platform investment. It is one.

The decision to not have a platform team has already been made. It was made invisibly, the moment the third senior engineer reached for a problem the first two had already solved. Nobody voted on it. Nobody costed it. It is already on the books. The only thing missing is the line item. And what I’ve seen, again and again, is that the line item never gets added until someone names what’s there.

Where the velocity went

Your headcount has doubled. Your velocity hasn’t. You are hunting for the explanation in the wrong places.

There are several candidates for that gap, and the honest version of this issue acknowledges all of them up front. Sprint planning discipline. Feature-side technical debt. On-call fatigue. Communication overhead from team growth. Hiring quality. Most engineering orgs at this scale have several of these problems running simultaneously, and none of them are wrong. None of them are the only answer either. This issue is about one specific structural cost that almost always sits inside the velocity drop, often unnamed, and almost never on a budget line.

The cost has a shape. Above a certain size — roughly the band where you have four or more product squads — the unnamed cross-cutting work stops being amortized and starts being multiplied. Each squad solves the same coordination problem in isolation, with subtly different conventions, on subtly different timelines. The HTTP client. The retry policy. The audit log shape. The error response envelope. The structured-logging fields. The tracing headers. Six squads, six versions, all roughly correct, none identical.

You’re three years past your last platform conversation. Your headcount has doubled. Your velocity hasn’t. When someone proposes a platform team, the answer in the room is some version of “we’re not big enough yet, and we don’t want to add overhead.” Your senior engineers nod. They’re the ones absorbing the cost.

The redistributed model has a real defense. It deserves to be taken seriously before it gets dismantled.

The defense worth taking seriously

Here is the position to beat. Distribute cross-cutting work across the product squads. Engineers closest to the problem solve it. Don’t form a platform team until the cooperation model is visibly broken. Anything else is premature optimization.

A smart engineer reaches for that position for four good reasons.

It is defensible by experience. Below a certain scale — somewhere in the 20-engineer band — cooperation works without formal coordination, and forming a platform team there creates a ticket queue and makes the rest of the org passive. The right answer at that scale is not to build a platform team. Anyone who has watched a too-early platform team form has seen this fail.

It is defensible economically. A dedicated platform team is real headcount. A redistributed model adds zero. From a CFO seat, “let the engineers self-organize” is the default that doesn’t require a budget conversation, and the default usually wins.

It is defensible ideologically. The position that platform teams fail when they become ticket-driven infrastructure providers is correct, and any engineer who has read this topic for two years has internalized it. The federated, distributed-ownership model has real virtues. Under a manageable number of services, informal coordination genuinely works.

It is defensible psychologically. “Everyone pitches in” is a culture statement most leaders are proud of. Naming the work as platform work feels like admitting the org isn’t lean anymore.

In the rooms where I’ve watched this argument made, it’s always made well. The defense is real. It is also wrong above the threshold, in a way the smart engineer reaching for it has not yet noticed.

The defense conflates internal coordination within a squad with coordination across squads. The federated model handles the first cleanly. It compounds cost on the second.

“Premature optimization” is the wrong frame past the threshold. Below the band, yes — building a platform team there is a textbook over-rotation. Past it, the redistributed work is no longer optimization. It is accumulated debt being repaid, in installments, by the most expensive engineers in the org.

The federated argument also assumes information symmetry the org no longer has. Once you cross the threshold, no senior engineer can hold the state of what every other squad has already built. Squad 4 doesn’t know Squad 2 wrote the audit-logging helper last quarter. They write it again. The cost is the second writing.

Which leaves the structural question the redistributed model can’t answer at this scale: who is responsible for the second writing of the same code? The squad? The senior engineer? The org? The model has no answer because the model has no owner — and the cost lands wherever the answer would have been.

Three approaches, and the pattern

Three approaches are on the table for an org at this scale. Each has a real case. Only one has a pattern that holds up over time.

Approach A: The redistributed model (status quo)

Cross-cutting work is distributed across product squads. There is no formal platform charter. The senior engineer who cares most absorbs the cost. The advantages are real: zero new headcount, no team-formation tax, no bottleneck risk by construction. The disadvantages are also real, and they are the ones leaders have most trouble seeing. Cross-cutting decisions get made N times — once per squad — and converge only by accident or by a single heroic refactor. Quality drift is structural. Onboarding compounds.

One caveat deserves to land cleanly. Some orgs do achieve high platform quality through a federated ownership model — open-source-style internal contribution, strong RFC culture, well-curated shared libraries. The federated path to high platform quality is real, and where it works it is beautiful. It also requires a level of internal-tooling cultural maturity most orgs at this scale do not have. The argument here is about the median org, not every possible org.

Approach B: The virtual platform team

A few senior engineers are designated to spend a fixed fraction of their time on shared infra. No dedicated team. No separate roadmap. No new headcount line. Preserves the “everyone pitches in” culture. Lower political friction.

This approach has one consistent failure mode and you can predict it from the structure alone. Priority collisions are guaranteed — and when feature deadlines slip, the platform allocation is the first thing dropped. There is no continuous improvement because there is no continuous owner. The allocation trends toward zero within two to three quarters under sustained feature pressure, because there is nobody whose performance review depends on defending the platform work. As a transitional state for one or two quarters while a real team is being scoped, the virtual model has a job. As a steady state, it does not.

Approach C: The funded MVP platform team

Two or three engineers, dedicated, with an explicit charter, a roadmap, and kill-criteria, treated as an internal product team. Explicit ownership. Continuous improvement. The cost is now a budget line you can manage.

The cost is real. So is the risk of doing this badly. A significant fraction of platform teams fail to deliver measurable productivity gains, and the failure mode is consistent: over-staffed, over-scoped, and trending toward becoming the ticket queue the model warns against.

Share

Then there is the pattern.

I’ve watched the redistributed model run for two years in orgs at this scale. The cost is consistent. It is several times what a funded MVP team would have cost, and the gap widens with each quarter the work stays unnamed. The redistributed cost isn’t proportional to headcount in the way most leaders intuitively expect — it compounds, because the second writing of the same code is the first installment of a longer payment plan, and the third writing is the second installment, and the cost arrives in disguise as slowed onboarding, missed deadlines, and senior-engineer attrition that nobody connects back to the source.

The gap is also widening, not narrowing, in the orgs I’ve watched recently. AI tooling amplifies whatever organizational system it inhabits. Where the platform foundation is intentional, AI compounds the gains. Where the foundation is fragmented, AI compounds the dysfunction — fragmented patterns get fragmented faster, drift accelerates, cleanup cost compounds.

The redistributed model was expensive two years ago. It is structurally more expensive now. It will be worse next year.

What I’d fund

So here is the position, no hedging.

Past the threshold where you have four or more product squads and the cross-cutting work is visibly fragmenting, fund a two-to-three-person platform team within two quarters. Not eight. Not zero. Two to three engineers, named charter, two-quarter prove-value runway, explicit kill-criteria.

The kill-criteria are what make the bet reversible. If, after two quarters, no measurable adoption metric has moved — golden-path uptake, onboarding-time delta, deduplication of named cross-cutting work — dissolve the team and revert to the federated model.

The two-engineer floor is small enough to make this reversible. Most platform teams that fail are over-staffed and politically irreversible by the third quarter. A two-person MVP can’t lock you in. The constraint is the feature.

On the threshold: I’m committing to the four-or-more-squads frame because that is the point where the redistributed cost first becomes irreversible, not the point where the argument is unambiguous. The argument gets unambiguous later, somewhere around eighty engineers. Below the band, the federated model genuinely works. Inside the band, leaders who wait for unambiguous evidence have already paid a year of redistributed cost they cannot recover.

The argument doesn’t survive serious scrutiny in the other direction. The redistributed cost runs several times the MVP team cost within a quarter at this scale, compounding.

The failure-rate caveat — that most platform teams don’t deliver measurable productivity gains — is real, and the answer is scope discipline, not don’t form the team. Most platform teams that fail are over-scoped, over-staffed, and become the ticket queue the model warns against. A two-or-three-person MVP cannot become a ticket queue. There isn’t enough team to absorb the requests. The constraint forces product discipline.

The political cost I’d accept: forming the team will hurt. Two of your most senior engineers will resist — the cross-cutting decisions are what they’re proudest of, and naming the work as platform work feels like a demotion of their most interesting problems. Their squads will complain. There will be a quarter of trust deficit while the new team finds its footing. Existing implementations will need migration paths, not just new patterns. None of this is free. The argument survives all of it.

I’ve watched this play out in other orgs at this scale, and the variable is never whether the redistributed cost is real. It’s only whether anyone says it out loud.

The pattern beyond platform

Zoom out from platform engineering. Every engineering org has work that does not fit on a sprint board. Cross-service consistency. Compliance review prep. Audit log standardization. Onboarding documentation. Retry semantics. Error response shape. The standard observability footprint. None of this work belongs to a single product squad. All of it gets done — by someone, at some cost — whether the work is named or not.

That is the principle this case reveals.

Unnamed work doesn’t disappear; it gets redistributed. And redistributed cost has a specific operational property: you can’t measure it, you can’t optimize it, and you can’t reduce it — because it isn’t on a budget line anyone is reading. The work shows up in slipped deadlines, in onboarding times that crept from a couple of weeks to several, in a senior engineer’s calendar that’s somehow always full of “infra cleanup” they didn’t plan for. Every one of those signals is the cost arriving in disguise. The signal is not “we need a platform team.” The signal is “nobody owns this, and the org has stopped noticing.”

This pattern repeats outside platform engineering. It is the structural shape of every “we don’t need a dedicated team for that, our engineers self-organize” answer past the threshold where it actually works. Security review past a certain scale. Data quality past a certain number of product domains. Internal documentation past a certain service count. Each one starts as a thing the smart engineers absorb out of professional pride. Each one stops being absorbable at a different threshold, and most leaders cross that threshold without noticing.

Every time I’ve watched an engineering leader try to read this signal, the misread is the same: accumulation gets misread as growth. The threshold is rarely respected because crossing it isn’t a discrete event — it is an accumulation. The leader who learns to read accumulation as cost, not as growth, is the one who saves their org six months of redistributed work.

The question worth carrying

Redistributed cost is still cost. You’re paying it. You’re just not seeing it on a budget line you can manage.

Here is the question worth carrying. Look at your last sprint review. How many of the things your senior engineers showed off were things three other senior engineers also did this quarter — and what is the time cost of that duplication? Don’t estimate. Actually count one example. The number you arrive at will be lower than the real number, and it will still be too big to ignore.

The harder question isn’t whether to fund the team. It is what to call the work once you’ve named it. “Platform” means several different things today, and most leadership conversations stall there — on the language, not the money.

For the EM reader without budget authority, there is a smaller version of the same conversation you can have this week without asking for headcount. Ask one senior engineer how many hours of their last sprint went to work no product squad asked for. Don’t push for a number. Just listen to the pause before they answer.