TCP #96: When Centralized Platforms Win and When Federated Wins
Most organizations miss the pattern and apply one model everywhere.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
Your leadership asks whether the platform team should own everything or whether product teams should own their own infrastructure.
You pick one. You apply it everywhere. You create problems.
Centralized teams become bottlenecks.
Federated teams create chaos.
Both outcomes stem from the same mistake.
The question is not centralized or federated. The question is centralized on what and federated on what.
The Platform Ownership Decision: Centralized or Federated
Platform teams face a structural decision. Centralize ownership in a dedicated platform team or federate ownership across product teams.
Centralized means one team owns infrastructure, tooling, and standards. They build. They maintain. They operate. Product teams consume.
Federated means product teams own their platforms. They choose tools. They manage infrastructure. They set standards. The platform team provides templates and guidance.
Most organizations treat this as ideology. They centralize everything or federate everything. Both approaches fail.
The decision is contextual, not philosophical.
When Centralized Platform Ownership Wins: Four Scenarios
Centralized ownership wins in four scenarios.
First, early organizational maturity.
Organizations with 10 to 50 engineers lack the headcount to distribute platform work. A central team builds shared infrastructure. The central team moves faster than distributed efforts. Standards emerge. The organization scales.
Attempting federation at this stage fragments the effort. Three teams build three CI/CD pipelines. None reaches production quality.
Second, infrastructure domains.
Core infrastructure requires deep expertise and consistent operation.
Kubernetes clusters. Networking. Identity and access management. Database platforms. These systems demand specialized knowledge. Failure modes carry organization-wide impact.
Centralizing infrastructure creates expertise concentration.
The platform team develops operational excellence. Product teams consume stable primitives without managing complexity.
Third, high compliance and risk domains.
Security controls. Audit frameworks. Data protection. Regulatory requirements demand consistency. Inconsistency creates liability.
Centralized teams enforce standards uniformly. They implement controls once. They collect evidence systematically. Product teams build features within compliant boundaries.
Fourth, low team platform maturity.
Teams without platform engineering experience make poor infrastructure decisions. They optimize locally. They ignore operational concerns.
Centralized teams provide the expertise that product teams lack. They encode best practices. They prevent common failures. Product teams move faster by consuming mature platforms.
When Federated Platform Ownership Wins: Four Conditions
Federated ownership wins under different conditions.
First, scaled organizational maturity.
Organizations with 200+ engineers encounter coordination bottlenecks. The central platform team becomes a constraint. Request queues grow. Product velocity suffers.
Federation distributes platform work. Product teams own their tooling. They make decisions locally. Throughput increases.
Second, product and tooling domains.
Observability tools. Deployment pipelines. Testing frameworks. Service configurations. These systems require product context. Generic solutions miss requirements.
Product teams understand their needs. They know which metrics matter. They know deployment risk tolerance. Local ownership produces better outcomes.
Centralized teams lack context. They build generic solutions. Product teams work around the platform.
Third, lower risk domains.
Feature flags. Logging libraries. Development tooling. Internal dashboards. These systems carry a limited blast radius. Failure affects one team, not the organization.
Federation enables experimentation. Teams try new approaches. They learn faster. Innovation increases.
Fourth, high team platform maturity.
Teams with platform engineering capability make good infrastructure decisions. They understand tradeoffs. They operate reliably.
Federation leverages distributed expertise. Teams solve their problems. They share solutions. Platform capabilities compound.
The Mistake: Treating Platform Structure as Ideology
Most organizations choose a centralized or federated philosophy.
Startups read about platform engineering. They create a platform team. The team centralizes everything. Deployment pipelines. Logging. Monitoring. Testing. The team becomes a bottleneck. Product velocity collapses.
Scaled companies read about DevOps. They federate everything. Infrastructure. Security. Compliance. Teams fragment effort. Duplication explodes. The organization fails audits.
Both mistakes stem from the same error. Treating organizational design as ideology instead of an engineering decision.
The centralized ideology believes consistency requires central control. The federated ideology believes speed requires distributed ownership. Both are partially correct and globally wrong.
Consistency matters for some domains. Security. Compliance. Core infrastructure. Speed matters for other domains. Tooling. Configuration. Product features.
High-performing organizations vary the model by domain. They centralize infrastructure. They federate tooling. They centralize compliance. They federate observability. The boundaries are defined by risk, maturity, and capability.
How to Decide: Four-Dimensional Platform Ownership Framework
Evaluate each platform area across four dimensions.
Organizational maturity: How many engineers? Under 50 favors centralization. Over 200 favors federation. Between 50 and 200 requires mixed approaches.
Domain type: Is this core infrastructure or product tooling? Infrastructure centralizes. Tooling federates. Hybrid systems require judgment.
Risk profile: What happens if this fails? Organization-wide impact centralizes. Team-level impact federates. Compliance requirements centralize.
Team capability: Do product teams have platform expertise? Low capability centralizes. High-capability federates. Capability varies by team and domain.
Apply all four dimensions. Security with high compliance and low team maturity centralizes regardless of organization size. Deployment pipelines in a scaled organization with high team capability federate regardless of risk.
The decision is not centralized versus federated. The decision is centralize what and federate what.
Start with a centralized infrastructure.
Add federation as teams mature and the organization scales.
Move high-risk domains toward centralization.
Move low-risk domains toward federation.
Revisit quarterly as conditions change.
Platform architecture follows organizational architecture. Design both intentionally.
Whenever you’re ready, there are 2 ways I can help you:
Free guides and helpful resources: https://thecloudplaybook.gumroad.com/
Get certified as an AWS AI Practitioner in 2026. Sign up today to elevate your cloud skills. (link)
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
This framework nails it. I've watched our org swing from full centralization to total federation and back, and th ereal issue wasn't the choice itself but treating it like an either/or. The risk profile dimension is especially on point becuase compliance stuff genuinely needs central control while dev tooling can move way faster when teams own their stack.