Platform engineering after the DevOps plateau
'You build it, you run it' scaled culture but not cognition. The internal platform is how large engineering organizations get their focus back — if they build it like a product, not a mandate.
DevOps won. Its victory condition — teams that own their services end to end — is now the default operating model of serious engineering organizations. And that victory produced its own crisis: every team owning everything means every team carrying the full cognitive load of cloud infrastructure, pipelines, observability, security controls, and compliance evidence. Multiply that by fifty teams and the duplication is enormous, the inconsistency worse, and the senior engineers who should be building product are instead maintaining fifty artisanal copies of the same delivery machinery.
Platform engineering is the correction. But the label covers both the best and worst decision an engineering organization can make this year, depending entirely on how it is executed.
The platform is a product or it is shelfware
The failed version is recognizable on contact: a central team decrees a “golden path,” wraps existing tools in a portal nobody asked for, and enforces adoption through policy. Teams comply minimally, route around it quietly, and the platform becomes one more system to maintain.
The successful version treats internal developers as customers who can churn. It starts from the most painful journey — usually “new service to production” or “incident to diagnosis” — and makes that journey dramatically better for one willing team. Adoption spreads because the path is genuinely faster, not because a memo requires it. Product management, user research, and design apply to the platform exactly as they apply to anything customer-facing; this is where our engineering and design practice does some of its most leveraged work.
Paved roads, with exits
The platform’s promise to teams must be paved road, not cage. Defaults for the 80% case — provisioning, CI/CD, observability, secrets, baseline security — with documented exits for teams whose problems genuinely do not fit. The exits matter more than they look: they keep the platform honest, force it to compete on quality, and prevent the quiet accumulation of resentment that kills internal tools.
Security and compliance teams should love this model, and increasingly do. Controls embedded in the paved road are controls that ship by default: the platform is where you make the secure way the easy way, once, instead of auditing it fifty times.
The metric that matters
Skip the vanity dashboards. The platform’s health is measured by one family of numbers: how long from commit to production, from incident to diagnosis, from new-team formation to first deploy — and whether teams choose the platform when they have a real alternative. Voluntary adoption is the only metric that cannot be gamed.
What to do about it
Fund a small platform team like a startup with one product: pick the single worst developer journey, fix it end to end for two pilot teams, and publish the before/after numbers. Resist the portal until the paths beneath it are worth paving. And staff it with engineers who have felt the pain themselves — a platform built by people who have never been on call for a product service will optimize for the wrong things, beautifully.