Platform Engineering Overhead
Organizations create platform engineering teams to build internal developer platforms — golden paths for deployment, standardized tooling, self-service infrastructure. The goal is to accelerate product teams by abstracting away infrastructure complexity. But platform teams face a fundamental tension: they're building a product for internal customers who can't leave. Without market pressure, platform teams build what they think developers need rather than what developers actually need. The platform becomes opinionated in ways that don't match real workflows. Product teams work around the platform rather than through it. The platform team grows to 10-15% of engineering headcount, consuming resources that could ship customer-facing features. The abstraction that was supposed to simplify becomes another layer of complexity that developers must learn and navigate.
What people believe
“Platform teams accelerate developers by providing standardized tooling.”
| Metric | Before | After | Delta |
|---|---|---|---|
| Engineering headcount on platform | 0% | 10-15% | +12% |
| Platform adoption rate | Expected 90%+ | 60-70% actual | -25% |
| Developer onboarding time | Learn standard tools | Learn standard tools + proprietary platform | +40% |
| Deployment speed (adopters) | Manual process | Self-service | +60% |
Don't If
- •Your engineering org is under 50 people — the overhead isn't justified
- •You're building a platform without continuous feedback from product teams
If You Must
- 1.Treat the platform as a product with internal customers who can provide feedback
- 2.Start with the highest-friction developer pain points, not a grand vision
- 3.Measure platform adoption and satisfaction quarterly — low adoption is a signal
- 4.Keep the platform team small and focused — 5% of engineering, not 15%
Alternatives
- Curated tool recommendations — Recommend and support standard tools rather than building abstractions
- Embedded SRE model — Infrastructure expertise embedded in product teams rather than centralized
- Documentation-first platform — Golden path as documentation and templates, not custom tooling
This analysis is wrong if:
- Internal platform teams achieve 90%+ adoption among product teams within 12 months
- Platform engineering reduces total engineering headcount needed for equivalent output
- Developers prefer proprietary internal platforms over direct use of standard tools
- 1.Thoughtworks Technology Radar: Platform Engineering
Analysis of platform engineering adoption patterns and common failure modes
- 2.Gartner: Platform Engineering Hype Cycle
Prediction that 80% of platform engineering teams will fail to meet adoption targets
- 3.Spotify: Backstage and Platform Lessons
Spotify's experience building and open-sourcing their internal developer platform
- 4.Team Topologies: Platform Teams
Framework for when platform teams add value vs when they add overhead
This is a mirror — it shows what's already true.
Want to surface the hidden consequences of your engineering decisions?