Platform Engineering: Topologies and Team Structure

Platform engineering isn’t just about technology—it’s about how teams interact. Team Topologies provides a framework for thinking about this. Here’s how to apply it.

Team Topologies Overview

Four team types:

1. Stream-aligned: Deliver business value (product teams)
2. Platform: Provide self-service capabilities
3. Enabling: Help teams adopt new capabilities
4. Complicated-subsystem: Own complex domains

The Platform Team

                    ┌───────────────────┐
                    │   Product Teams   │
                    │ (Stream-aligned)  │
                    └─────────┬─────────┘
                              │ Self-service
                              │
                    ┌─────────▼─────────┐
                    │   Platform Team   │
                    │ - Developer Portal│
                    │ - CI/CD pipelines │
                    │ - Infrastructure  │
                    └───────────────────┘

What Platform Teams Provide

What They Don’t Do

• Write product code
• Deploy on behalf of teams
• Make architecture decisions for products
• Become a bottleneck

Interaction Modes

X-as-a-Service

Platform provides, teams consume:

Product Team                      Platform Team
     │                                  │
     │ "I need a database"              │
     │ ─────────────────────────►       │
     │                                  │
     │       [Database provisioned]     │
     │ ◄─────────────────────────       │
     │                                  │
     │ [Uses database]                  │

Collaboration

Temporary, high-bandwidth interaction:

Platform Team + Product Team
         ↓
   Work together on:
   - New capability design
   - Migration planning
   - Complex debugging
         ↓
   Return to X-as-a-Service

Facilitating (Enabling Team)

Enabling Team                Product Team
     │                            │
     │ "Let me help you adopt K8s"│
     │ ──────────────────────────►│
     │                            │
     │   [Training, pairing]      │
     │                            │
     │   [Team is self-sufficient]│
     │ ◄──────────────────────────│
     │                            │
     │ [Move to next team]        │

Anti-Patterns

Platform as Gatekeeper

❌ Bad:

Developer: "I need to deploy"
Platform: "File a ticket, wait 2 weeks"

✅ Good:

Developer: "I need to deploy"
Platform: "Here's the self-service button"

Platform Owns Everything

❌ Bad:

Platform Team:
├── Kubernetes cluster
├── CI/CD pipelines
├── Product deployments  ← Wrong!
├── On-call for products ← Wrong!
└── Feature releases     ← Wrong!

✅ Good:

Platform Team:
├── Kubernetes cluster
├── CI/CD pipelines
└── Self-service interfaces

Product Teams:
├── Own deployments
├── Own on-call
└── Own releases

No Product Mindset

❌ Bad:

• Build infrastructure because it’s cool
• No user research
• No documentation
• “They should file a ticket”

✅ Good:

• Build what teams need
• Regular feedback sessions
• Excellent docs and onboarding
• “How can we make this easier?”

Measuring Success

Developer Experience Metrics

Platform Adoption

Cost Efficiency

Team Size and Structure

Small Platform (2-4 people)

Platform Lead
├── DevOps Engineer
└── SRE

Focus: Core infrastructure, CI/CD

Medium Platform (5-10 people)

Platform Lead
├── Infrastructure Squad
│   ├── Kubernetes Engineer
│   └── Cloud Engineer
├── Developer Experience Squad
│   ├── Portal Developer
│   └── DevOps Engineer
└── SRE

Large Platform (10+ people)

Platform Director
├── Infrastructure Team
│   ├── Compute
│   ├── Networking
│   └── Storage
├── Developer Experience Team
│   ├── Portal/UI
│   ├── Documentation
│   └── Developer Advocacy
├── Security Team
│   ├── Container Security
│   └── Compliance
└── SRE Team
    ├── Observability
    └── Reliability

Product Manager for Platform

Yes, platforms need PMs:

Platform PM responsibilities:
├── User research (talk to developers)
├── Roadmap prioritization
├── Feature definition
├── Success metrics
└── Communication

A platform without a PM often becomes an engineering-driven project that doesn’t serve users.

Starting From Scratch

Phase 1: Foundation (3-6 months)

- Basic CI/CD pipeline
- Simple deployment process
- Minimal documentation
- Direct support (tickets OK)

Phase 2: Self-Service (6-12 months)

- Developer portal (Backstage)
- Automated provisioning
- Comprehensive docs
- Reduced direct support

Phase 3: Productization (12+ months)

- Feature parity with cloud
- Multiple environments
- Advanced observability
- Platform-as-code

Final Thoughts

Platform engineering succeeds when:

1. Developers can self-serve
2. The platform team treats developers as customers
3. Clear boundaries exist between platform and product
4. Success is measured by developer outcomes

The technology matters less than the organizational design.

Build the platform your developers deserve, not the one you think is cool.