LinkedIn Draft — Workflow (2026-06-16)
This is the gap between 'it works' and 'it's operable':
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.
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 friction
Where 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 I keep coming back to:
→ Measure platform success by developer time-to-production and incident contribution rate — not by adoption numbers you control.
How I 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 best platform teams I've seen measure success by how rarely product teams have to think about infrastructure.
Strong opinions on this? Good. I want to hear the pushback.
Top comments (0)