Skip to main content

Enterprise Federation in Product Companies

Google, Amazon, Microsoft​

The Different Starting Conditions​

Product companies have fundamentally different constraints from IT services firms:

  • They own the outcome — no external client to override internal standards
  • Projects are long-lived — products run for years or decades, not 18-month engagements
  • Internal teams are the customers — the "client" of the core is other internal engineering teams
  • Engineering culture is the leverage — top-tier engineering talent can enforce quality through culture, not just process

This means product companies can operate with stronger mandates and longer time horizons — and they invest accordingly.

Google: The Monorepo + Platform Team Model​

The Core Architecture​

Google famously runs the world's largest monorepo — billions of lines of code in a single repository. This is the physical manifestation of their federation model: everything is visible to everyone, and shared libraries live alongside the code that consumes them.

How Federation Works at Google​

  • Foundational libraries (logging, testing, RPC, storage) are owned by dedicated platform teams with full-time engineers
  • Consistency is enforced by tooling — Google's internal build system (Blaze, open-sourced as Bazel) enforces dependency rules and prevents circular dependencies
  • Code review culture — any engineer can review any code; shared components get reviewed by their owners before merge
  • Style guides and linters are mandatory, not advisory

The SRE Model as Federation​

Google's Site Reliability Engineering (SRE) model is itself a form of federation: a central SRE team owns the reliability standards, tooling, and on-call practices. Product teams must meet the SRE team's standards before their service gets SRE support. This is federation by quality gate.

Key Insight​

Google's federation works because the monorepo makes the dependency graph visible and the build system enforces the rules automatically. Humans don't govern compliance — the tools do.

Amazon: The Two-Pizza Team + Service Ownership Model​

The Core Architecture​

Amazon famously decomposed into two-pizza teams — small, autonomous teams that each own a service end-to-end (build it, run it, own it). This seems anti-federation, but it's actually a sophisticated federation model.

How Federation Works at Amazon​

  • Shared services are internal products — AWS itself started as Amazon's internal infrastructure, productized and sold externally. S3, EC2, SQS were built to solve Amazon's own problems first.
  • APIs as the contract — Bezos famously mandated that all internal teams expose their capabilities through service interfaces (APIs), and all communication must go through those interfaces. This IS the federation contract.
  • Builder Tools org — Amazon has a central engineering tools organization that owns CI/CD, code review tooling, security scanning, and deployment infrastructure. Teams must use these but are free to build on top.
  • The "Working Backwards" process — even the product development process is federated through a shared methodology (PR/FAQ documents before any project begins)

Key Insight​

Amazon's federation is interface-first, not implementation-first. The core mandates HOW teams expose their capabilities (APIs with defined contracts), not what technology they use internally. This maximizes autonomy while ensuring interoperability.

Microsoft: The DevDiv + Platform Engineering Model​

The Evolution​

Microsoft had one of the most dramatic federation transformations of any company. Pre-Nadella, Microsoft operated as a collection of competing silos (Windows, Office, Server) with minimal federation. Post-Nadella, the shift to "One Microsoft" and cloud-first was a federation exercise at enterprise scale.

How Federation Works at Microsoft​

  • Developer Division (DevDiv) owns the internal engineering platform — Visual Studio, Azure DevOps, GitHub (acquired), and the internal engineering systems. This is the core platform team at Microsoft scale.
  • Azure as the internal cloud — Microsoft mandated that all internal products run on Azure. The cloud platform IS the federation layer for infrastructure.
  • Engineering System standards — Microsoft publishes internal engineering standards (coding guidelines, security requirements, accessibility standards) that all product teams must follow
  • Inner Source — Microsoft operates a formal inner-source program where engineers can contribute to any internal repository, governed by the owning team

The "Ship It" Cultural Shift​

Nadella's cultural change included a federation of engineering practices: moving from annual releases to continuous delivery, mandating telemetry on all products, and requiring every team to eat their own dogfood. These are federation policies at the cultural level.

Key Insight​

Microsoft's federation succeeded when it shifted from org-chart-based silos to outcome-based shared platforms. Azure didn't just become the cloud; it became the shared operating assumption for all of Microsoft.

Patterns Unique to Product Companies​

1. The Platform as External Product​

All three companies took internal platforms and turned them into external products:

  • Google → Google Cloud, Kubernetes, Bazel
  • Amazon → AWS (the entire thing)
  • Microsoft → Azure, GitHub, VS Code

This commercial pressure creates a virtuous cycle: the better the internal platform, the better the product.

2. Engineering Culture as Federation Enforcement​

In product companies, peer pressure from senior engineers enforces standards more effectively than any policy document. A code review from a Google principal engineer carries more weight than a governance checklist.

3. The "Paved Road" Metaphor​

All three use some version of this: the core team builds a paved road — a well-lit, well-maintained path that makes it easy to do the right thing. Teams can go off-road, but they own that decision entirely.

4. Dogfooding as Quality Signal​

Internal teams using their own platforms creates a powerful feedback loop. When an internal Google engineer hits a pain point in GCP, it gets fixed. This doesn't exist in IT services (the firm doesn't live in the product it builds for clients).

What Product Companies Get Wrong Too​

  • Platform arrogance — assuming internal developers will love the platform because it's Google-built; adoption still requires empathy and product thinking
  • The greenfield trap — even Google and Amazon have internal legacy that can't easily adopt the latest platform patterns
  • Scaling governance — at 100,000+ engineers, even the best governance models develop antibodies and workarounds
  • "Not Invented Here" at scale — large teams in product companies also reinvent wheels, just at a higher engineering quality level