"Platform teams do not build features. They build the foundation that makes feature teams unstoppable."
Principal Engineer Who Learned This the Hard Way
The AI Platform Team Model
As organizations scale AI product development, repeated work emerges: every team needs model deployment, evaluation infrastructure, data pipelines, and monitoring. Platform teams capture this common infrastructure, enabling product teams to focus on domain-specific AI rather than undifferentiated enabling technology.
The Team Topologies framework from Skelle and Waguespack provides a useful mental model for thinking about AI organization. Adapted for AI-native products, it identifies four team types that interact in specific ways.
Stream-Aligned AI Teams
Stream-aligned teams are the primary delivery units. They own a user-facing AI product or feature end-to-end: from understanding user needs through deployment and monitoring. The cross-functional teams described in Section 28.1 are stream-aligned teams.
Stream-aligned teams are the primary delivery units. They own a user-facing AI product or feature end-to-end from understanding user needs through deployment and monitoring, and the cross-functional teams described in Section 28.1 are stream-aligned teams. Their ownership covers the full lifecycle of specific AI features. Their metrics focus on user-facing outcomes such as task completion, satisfaction, and engagement. Their dependencies consume platform capabilities and request enablement from specialists.
AI Platform Teams
AI platform teams provide the infrastructure that stream-aligned teams depend on. They own the systems that make AI development, deployment, and operations possible at scale.
Platform Team Focus Areas
Model Deployment Infrastructure: CI/CD pipelines for ML models, A/B testing infrastructure, shadow mode deployment capabilities, canary release tooling.
Evaluation Systems: Shared eval frameworks, evaluation data pipelines, eval result aggregation and visualization.
Observability Stack: Model performance monitoring, drift detection, alerting infrastructure.
Feature Store: Shared feature computation and storage, feature versioning, feature documentation.
AI Enablement Teams
Enablement teams focus on building capabilities within stream-aligned teams. Unlike platform teams that provide infrastructure, enablement teams provide knowledge, training, and consulting to help teams become more effective with AI.
Enable teams focus on building capabilities within stream-aligned teams. Unlike platform teams that provide infrastructure, enablement teams provide knowledge, training, and consulting to help teams become more effective with AI. This includes AI literacy programs with training curricula for PMs, designers, and engineers, best practice documentation covering patterns for eval design, prompt engineering, and UX for AI, technical consulting through embedded advisors who help teams solve specific AI challenges, and tool evaluation assessing new AI tools and vendors for organizational fit.
Specialized Teams
Some AI capabilities are so specialized that they warrant dedicated teams. These teams work on problems that require deep expertise concentrated in one place.
Some AI capabilities are so specialized that they warrant dedicated teams. These teams work on problems that require deep expertise concentrated in one place. Foundational model teams handle fine-tuning, prompt engineering, and evaluation of foundation models. Responsible AI teams manage bias auditing, fairness testing, and compliance with AI regulations. Research teams explore new AI capabilities for future competitive advantage.
Defining Platform Boundaries
The hardest problem in platform design is deciding what belongs in the platform and what belongs in product teams. Get this wrong in either direction and you create problems.
The Perils of Over-Platformization
If the platform team tries to own too much, they become a bottleneck. Product teams wait for platform features, platform team falls behind on product team needs, and the organization loses agility.
Warning Signs of Over-Platformization
If the platform team tries to own too much, they become a bottleneck. Product teams wait for platform features, platform team falls behind on product team needs, and the organization loses agility. Warning signs include a platform team backlog that is 3 or more months behind product team requests, product teams building workarounds around the platform, platform team measuring success by internal adoption rather than product team outcomes, and teams describing platform as "the gatekeepers" rather than "the enablers".
The Perils of Under-Platformization
If the platform team does too little, every team reinvents the same infrastructure. You get inconsistent evaluation practices, incompatible deployment pipelines, and inability to share learnings across teams.
Warning Signs of Under-Platformization
If the platform team does too little, every team reinvents the same infrastructure. You get inconsistent evaluation practices, incompatible deployment pipelines, and inability to share learnings across teams. Warning signs include each team having their own model deployment process with different steps and timelines, no shared eval framework with teams using ad-hoc methods, knowledge about AI development being trapped in individual teams, and replacing a vendor or model requiring rewriting infrastructure from scratch.
Shared Models and Tooling
AI platform teams often maintain shared models that multiple product teams use. This shared ownership creates both opportunities and challenges.
Shared Foundation Models
Organizations often standardize on one or two foundation model providers across the company. The AI platform team manages these relationships, negotiates pricing, and provides shared infrastructure for prompt engineering and model access.
Organizations often standardize on one or two foundation model providers across the company. The AI platform team manages these relationships, negotiates pricing, and provides shared infrastructure for prompt engineering and model access. This includes a unified API gateway providing single point of access to model providers with rate limiting, cost tracking, and fallback capabilities, a shared prompt library preserving organizational knowledge about effective prompts for common use cases, and cost allocation tracking and allocating AI spend to product teams.
Shared Training Pipelines
When multiple products use similar model architectures or training approaches, shared training infrastructure reduces redundant work. The platform team provides data preprocessing pipelines, training infrastructure, and model registry services.
Shared Evaluation Framework
Chapter 21 introduced evaluation as the core development practice for AI products. A shared eval framework that all teams use creates common language for AI quality and enables cross-team learning. The platform team maintains this framework and ensures it evolves with organizational needs.
Practical Example: DataForge MLOps Platform
Who: DataForge, an enterprise data analytics company
Situation: Growing from 2 AI product teams to 8 in 18 months
Problem: Each team built their own ML infrastructure. Deployment processes varied wildly. No shared evaluation standards. Model registry was a shared Google Sheet.
Decision: Create AI Platform team responsible for shared infrastructure while teams retained product ownership
How: Platform team built: unified model registry with versioning, automated deployment pipelines, shared eval framework with standard test suites, cost tracking dashboard, and shared prompt library. Teams contributed to platform roadmap through steering committee.
Result: Deployment time dropped from 2 weeks average to 2 days. Eval coverage increased from 20% of features to 85%. Shared prompt library saved estimated 40% of prompt engineering effort across teams.
Lesson: A well-designed platform accelerates all teams. A poorly-designed platform becomes a bureaucratic obstacle. The difference is whether product teams have voice in platform decisions.
Platform Evangelism and Adoption
Building platform capabilities is not enough. Platform teams must actively promote adoption and demonstrate value to stream-aligned teams. This requires different skills than engineering.
AI Platform Champion Program
Identify and nurture AI advocates within each stream-aligned team. These champions bridge between platform and product, translating platform capabilities into product-relevant terms and feeding product needs back to platform development.
Internal Documentation and Examples
Platform documentation must speak to product team concerns, not just technical specifications. Create guides that start from product problems and show how the platform solves them.
Platform Success Metrics
Platform teams should measure success by product team outcomes, not internal metrics:
Platform teams should measure success by product team outcomes, not internal metrics. Time to deploy measures how long it takes a product team to deploy a new model. Eval coverage tracks what percentage of AI features have automated evaluation. Platform satisfaction determines whether product teams find the platform valuable and accessible. Shared learning assesses whether teams are using shared eval frameworks and prompt libraries.