How would the self-service CI/CD platform design change if the organization had 1,000 teams instead of 100?

It's not just more capacity — several assumptions that hold reasonably well at 100 teams break down at 1,000: a single central platform team providing support no longer scales as a support model at all (requiring a federated/tiered support structure instead), self-service tooling that was "good enough" with light-touch guidance now needs to be genuinely self-explanatory with near-zero human involvement for the common case, and centralized infrastructure (a single shared CI orchestration layer, a single secrets management instance) needs genuine horizontal scalability and multi-tenancy isolation that matters much less at smaller scale.

Each assumption below scales roughly linearly with team count up to a point, then breaks down structurally rather than gracefully degrading — the redesign has to anticipate that break point rather than just adding capacity to the existing design.

• Support model must scale without requiring proportionally more central platform-team headcount.
• Self-service tooling must handle the long tail of edge cases without individual human intervention for most of them.
• Shared infrastructure must scale horizontally and provide real tenant isolation, since failures/noisy-neighbor effects affect proportionally more teams at this scale.

Support model shifts from centralized to federated/tiered: at 100 teams, a central platform team fielding support requests directly is workable, if not ideal. At 1,000 teams, this doesn't scale linearly — the answer isn't 10x the platform team's headcount, it's restructuring support itself: a tiered model where common issues are resolved via excellent self-service documentation and automated diagnostics (tier 1, zero human involvement), moderately complex issues route to designated "platform champions" embedded within larger team groups or business units (tier 2, distributed expertise rather than centralized), and only genuinely novel platform-level issues reach the central platform team (tier 3) — fundamentally changing the support architecture, not just its capacity.

Self-service tooling needs to handle the long tail, not just the common case: at 100 teams, a golden path covering 80% of cases well, with the remaining 20% getting some manual platform-team help, is a reasonable trade-off — 20 teams needing occasional help is manageable. At 1,000 teams, that same 20% is 200 teams — the tooling needs to either genuinely cover a much larger share of the long tail through better self-service (more configuration flexibility within the golden path, better error messages, self-diagnosing tooling) or accept that the tiered support model above absorbs what tooling still can't.

Shared infrastructure needs genuine horizontal scalability and multi-tenancy: a single CI orchestration system, secrets manager, or artifact registry that "just about" handles 100 teams' load might not scale linearly to 1,000 teams' load — this requires actually validating and architecting for horizontal scalability (sharding, load distribution) rather than assuming a system that worked at smaller scale will simply continue working with more capacity added. Tenant isolation (one team's usage spike or misconfiguration not degrading service for others) also matters proportionally more, since a shared-infrastructure incident now affects a much larger blast radius of teams.

Golden path standardization becomes both more valuable and harder to achieve: at greater scale, the cost of NOT standardizing (1,000 teams each doing things slightly differently) compounds enormously, making a strong golden path more valuable than ever — but achieving genuine adoption across 1,000 teams, each with their own history, constraints, and inertia, is also a much harder organizational (not just technical) challenge than doing so across 100.

A federated support model distributes expertise but risks inconsistent quality across different "platform champions," requiring investment in training and shared standards to keep quality consistent — a real cost the centralized model at smaller scale doesn't have. Building for genuine horizontal scalability and multi-tenancy from the start is more upfront engineering investment than assuming a simpler architecture will "probably scale," but retrofitting scalability into infrastructure already serving 1,000 teams is a much higher-risk, harder migration than building it in from the start.

• Scaling from 100 to 1,000 teams isn't just "more capacity" — it requires structural changes to the support model, tooling depth, and infrastructure architecture.
• Centralized support doesn't scale linearly; a federated/tiered model (self-service, distributed champions, central team for genuinely novel issues) is needed at this scale.
• Self-service tooling needs to cover much more of the long tail, since the same percentage of edge cases represents a much larger absolute number of teams.
• Shared infrastructure needs genuine horizontal scalability and tenant isolation, since a shared-infrastructure incident's blast radius scales with team count.

• Team Topologies: Platform Teams
• Google SRE Book: Introduction