Workflows
Platform engineering: the paved road fails when it paves over developer autonomy
Internal platforms succeed when product teams choose them because they reduce friction — not when they're mandated because someone drew a box on an architecture diagram.
#platformengineering#devops#sre#kubernetes
How it looks in practice
Platform adoption models:
Mandate model: Product model:
CTO decrees IDP ──▶ Platform team ships ──▶ Reduces deploy time
Teams forced to use │ │ │
│ │ ▼ ▼
Workarounds found │ Developers adopt Platform iterates
Shadow IT grows ◀───┘ voluntarily on real frictionWhere it breaks
- Compliance-first platforms get abandoned the moment engineers find a workaround — adoption needs perceived value.
- Golden path templates that aren't maintained become the thing everyone forks immediately — N diverged paths.
- Platform teams without production on-call exposure build abstractions that look clean and fail badly.
The rule
→ Measure platform success by developer time-to-production and incident contribution rate — not by adoption numbers you control.
How to sanity-check it
- Backstage for catalog + portal — but treat it as a product, not a project. Stale catalogs are worse than no catalog.
- Quarterly 'friction interviews' with 3-5 product engineers — they'll identify the real bottlenecks faster than any metric.
The bigger picture
The best platform teams I've seen measure success by how rarely product teams have to think about infrastructure.
Route: /workflows/platform-engineering-the-paved-road-fails-when-it-paves-over-developer-autonomy