# Transcript: Platform Engineering in the Enterprise
**Speaker:** Rachael Wonnacott — Associate Director, Container Platforms at Fidelity International
---
## Introduction
I’m **Rachael Wonnacott**, Technical Product Owner for the Kubernetes platform at Fidelity International. My role spans **developer experience**, **application lifecycle management**, and **supply chain security**.
Although the term *platform engineering* became trendy only in recent years, I’ve been working with platforms since **2013**. My career began as a hands-on platform engineer, giving me a front-row seat to the **evolution of DevOps** towards what we now call platform engineering.
**Key premise:**
Developer experience is **not** the end goal — it’s a **lever** for what truly matters: delivering **measurable business value**.
**Three critical factors for success:**
1. **Organizational maturity**
2. **Organizational structure**
3. **Culture**
This talk explores how to balance **technical expertise**, **developer productivity**, and **business outcomes** — while recognizing that there’s rarely a *one-size-fits-all* approach.
---
## Context: Fidelity International
- Founded: **1969**
- Operations in **27 countries**
- Manages **£950 billion+** for clients worldwide
**Discussion points today:**
- Why developer experience matters, but isn’t **everything**
- How to frame platform investments in **business value** terms
- How to integrate within the broader **software delivery lifecycle**
- Risks of treating your platform like a **standalone product**
---
## Your Organization Is an Ecosystem
A platform is **not an island**; it exists within a **living organizational ecosystem** of:
- **People**
- **Teams**
- **Processes**
- **Technology**
- **Culture**
**Design implications:**
- Integrate with existing **delivery workflows**
- Enable **cross-boundary collaboration**
- Support **scaling** alongside changing organizational structures
**Human systems matter just as much as APIs**:
- Knowledge flow
- Decision-making processes
- Governance structures
- Cultural adoption
---
## Platform Challenges by Organization Size
### Startups
- Often operate as **single teams** wearing multiple hats
- Silos not yet formed
- Platforms often unnecessary at this stage
### Scale-ups
- Technological silos may start forming
- Risks of unintentional organizational fragmentation
### Large Enterprises
- Complex team combinations
- Legacy processes
- Strong structural inertia
- Multiple maturity levels across teams
---
## Legacy Structures in the Cloud Era
- Historically: strict separation between **application teams** and **infrastructure teams**
- “Throw over the wall” deployment paradigm
- Cloud computing softens boundaries — versatility now essential
- Legacy structures can **clash with modern methods**, creating friction
---
## DevOps Reality at Scale
Patrick Debois:
> “We’ve got 15 teams, they’re all running their own stuff… All we’ve done is shift the complexity and frustration to that number of teams.”
**Typical enterprise challenges:**
- **Hybrid model** — mix of cloud-native and on-prem
- Cloud-native services with **on-prem dependencies** — technical debt disguise
- Each team doing DevOps differently — leading to **duplication** and **divergence**
- High operational cost
**Platform Goal:** Reduce friction, amplify flow:
- Faster shipping
- Minimize duplication
- Consistent best practices
---
## Principles: Your Platform Is Not an Island
When building:
- Contextualize platform within **full enterprise architecture**
- Design for **integration and shared ownership**
---
## Case Study: Fidelity’s Container Platform Journey
### Early Days
- Private cloud hosted physically on-prem based on **Cloud Foundry**
- Effective at reducing cognitive load
- Strong developer adoption
### Transition Goals
- Adopt DevOps across all teams
- Automate AWS account provisioning (mini data centers per team)
- Shared responsibility model:
- **Platform team:** core infra (routing, DNS, networking, on-prem connectivity)
- **Workload team:** applications, uptime, performance
**Reality:**
Worked well for some teams; maturity varied widely.
---
## MVP Challenges with Kubernetes
**Expectation gap**:
- Cloud Foundry: Fully integrated build–deploy–run pipeline
- Kubernetes: Orchestration only — missing service layers
- Public cloud adoption underestimated integration complexity
- MVP disappointed users despite covering “engineering basics”
**Lesson:** Platform success relies on **full-lifecycle integration**, not just runtime.
---
## Ecosystem Integration & Developer Experience
**Golden path goal:**
- Minimal cognitive load
- Standardized processes
- Declarative approaches (GitOps) for predictable delivery
**Practical methods:**
- **Pull requests** as entry point to the platform
- **Transparent deployment** mechanisms
- Abstracted configurations guiding multiple pipelines
---
## Team Structures & Enablement
**Developer Platform Engineering group:**
- Tools
- Security
- AWS/Azure
- Portal (Backstage)
- Kubernetes
**Enablement Group:**
- Platform advocates
- Skilled early adopters
- Communities of practice
**Success factors:**
- Application-experienced staff
- Trusted cross-team relationships
- Not just “bolt-on” advisors
---
## Platform Value Model
### Triangle of Value
1. **Developer Experience**
2. **Business Outcomes**:
- Faster delivery
- Reduced marginal cost
- Lower coordination overhead
3. **Organizational Fit & Culture**
### Engineering Maturity
- Autonomy vs. Alignment tension
- Freedom within a **clear governance framework**
- Avoid optimizing solely for lowest performers
---
## Talent Considerations
- Optimal platform engineering team: **5–15 cross-functional members**
- Mix of:
- Senior specialists (DevOps/SRE, DX, cloud, security, data, product mgmt, docs)
- Growth-oriented mid-level engineers
- Maintain **trust pockets** — small, cohesive groups
---
## Risks of Lowest Common Denominator Design
- Migration deadlines may force compromises (“lift and shift”)
- Temporary non-best-practice solutions risk becoming permanent
- Can result in platform tuned for least mature teams
---
## Key Takeaways
- Platform = bridge between **craft** and **compliance**, **autonomy** and **alignment**
- Design for **ecosystem integration**, not isolation
- Align **culture**, **processes**, and **technology**
- Treat platform as **product & contract** with the organization
- Measure success in **business value**, not just developer satisfaction
- Plan for **team maturity variation**
---
## Q&A Highlights
**Team size & composition:**
Start small with senior-first; expand with mids/juniors over time. Focus on deliberate trust building.
**Optimization risk:**
Be wary of designing primarily for least mature users; balance accessibility with enabling high performers.
---
**References:**
- *Team Topologies* — organizational design principles
- *What I Talk About When I Talk About Platforms* — Evan Bottcher, 2018
[See more presentations with transcripts](https://www.infoq.com/transcripts/presentations/)
