Compare & Contrast: IT Services vs. Product Companies
Key Learnings for Enterprise Federation Design
Side-by-Side Comparison
| Dimension | IT Services (TCS, CTS, HCL, Accenture) | Product Companies (Google, Amazon, Microsoft) |
|---|---|---|
| Who is the "customer" of the core? | Internal delivery teams (but also their clients) | Internal engineering teams |
| Mandate strength | Soft — client can override | Hard — company owns the outcome |
| Project lifespan | 1–3 years (engagement-bound) | 3–10+ years (product lifecycle) |
| Primary federation mechanism | Practice / CoE / asset libraries | Platform team + tooling enforcement |
| Governance model | Review boards, advisory authority | Automated gates, peer review culture |
| Technology diversity | High (client-mandated stacks) | Low-medium (internal standards enforceable) |
| Innovation loop | Slow (client risk aversion) | Fast (own the risk, own the reward) |
| Core funding model | Cost center / overhead | Product / R&D investment |
| Success metric | Asset reuse count, cost savings | Developer experience, delivery velocity |
| Biggest challenge | Mandate authority | Scale and governance complexity |
The Core Paradox
Both models face the same paradox from opposite directions:
IT Services: Too much autonomy (client mandates, project diversity) makes federation hard to enforce
Product Companies: Too much central control (platform mandates) creates bottlenecks and resentment
The answer for both is the same: federation by value, not by force.
Teams adopt the core because it makes them faster and safer, not because they have to.
7 Transferable Learnings
Learning 1: Governance Lives in the Toolchain, Not Documents
Both models succeed when compliance is automated into CI/CD pipelines, not enforced through manual review boards. Policy documents are read once and forgotten; a failed pipeline build is impossible to ignore.
IT services implication: Invest in shared CI/CD templates with embedded governance checks before anything else.
Product company implication: Treat every new standard as incomplete until it has an automated check.
Learning 2: Core Teams Must Be Product Teams
The single biggest structural mistake in both models is staffing the core team like an IT operations team instead of a product team. Core teams need:
- A product manager (not just a technical architect)
- A roadmap with priorities driven by consumer feedback
- An adoption metric as the primary success measure
Learning 3: Inner Source is the Bridge
The healthiest federation models have a formal inner-source model — project teams can contribute to core components, with core team review. This:
- Reduces the bottleneck on the core team
- Builds project team ownership and trust in core components
- Surfaces real-world needs into the core roadmap
- Creates a talent pipeline into the core team
Both Google (monorepo + open contribution) and Accenture (Technology Strategy Boards) use versions of this.
Learning 4: Federation Must Have a Thin Core and a Rich Ecosystem
The worst federation models try to own everything centrally. The best models own a thin, stable foundation and create a rich ecosystem of domain-specific patterns built on top.
THIN CORE (centrally owned, mandatory)
→ DOMAIN LAYER (owned by domain experts, governed by core rules)
→ PROJECT LAYER (fully autonomous within boundaries)
Amazon's API-first model is the clearest expression of this: mandate the interface contract, not the implementation.
Learning 5: Legacy Systems Need an On-Ramp, Not a Mandate
Both models fail when they ignore existing systems. The federation layer must design explicit legacy on-ramps:
- Adapter/wrapper patterns for legacy-to-core integration
- Strangler-fig migration paths
- "Federate partially" options — a legacy system can comply with security and logging mandates without full re-platforming
Learning 6: Funding Is the Root Cause of Most Failures
The model that works: Core team funded as a strategic investment (R&D / product budget), with its own P&L thinking and adoption targets.
The model that fails: Core team funded as overhead, recharged back to project teams, with headcount tied to delivery rather than adoption.
Accenture's productization of internal platforms (selling them to clients) is an elegant solution — it creates commercial accountability without the overhead model's failure modes.
Learning 7: Rotate Engineers Between Core and Project Teams
The knowledge gap between core team and project teams is corrosive. Both models benefit from structured rotation:
- Core engineers spend 1–2 quarters on delivery teams annually
- High-performing project engineers rotate into core for a quarter
- This builds empathy, shared language, and realistic platform design
Google's 20% time and Amazon's "builder" culture both create informal versions of this rotation.
The Spectrum: Where Should Your Federation Sit?
Not every organization needs the same model. Place yourself on this spectrum:
LOOSE FEDERATION TIGHT FEDERATION
(IT Services extreme) (Product Company extreme)
|---------------------------------------------------|
CoP + Asset Library → Platform Team → Monorepo + Toolchain Enforcement
(Soft governance) (Mixed mandate) (Hard governance)
Most enterprises should aim for Platform Team with Mixed Mandate — strong enough to enforce security and compliance, light enough to let project teams move fast.
The Ultimate Takeaway
The federation layer is not a technology problem. It is an organizational design problem that technology can either help or hinder.
The organizations that get this right share one trait: they treat the federation layer as a living product with customers, a roadmap, feedback loops, and success metrics — not as a policy document, a shared GitHub repo, or an architecture committee.
Build the governance first. Let the platform grow from the governance. Not the other way around.