Platform Engineering: Building an Internal Developer Platform Teams Actually Adopt

We've inherited more abandoned internal developer platforms than we've built from scratch, and the failure pattern is consistent: the platform team built genuinely good infrastructure — a solid Kubernetes abstraction, a working CI/CD template, a service catalog — and product engineering teams quietly kept doing things the old way, because adoption was never actually a requirement anyone was accountable for. An IDP is a product with internal customers who can opt out, and it needs to be built and measured like one.

Start from the golden path a team already has, don't invent one

Platform teams often start by designing the ideal workflow from scratch — the way services should be created, deployed, and observed in a well-architected world. The problem is that every product team already has a working, if messy, way of doing this, and asking them to abandon it for an unproven platform is a hard sell even when the platform is objectively better. We start instead by instrumenting the best-performing existing team's actual workflow — the one with the fewest production incidents and fastest deploy cycle — and turn that into the platform's golden path, because it's already proven inside the organization and comes with a built-in advocate: the team whose workflow it was.

Self-service only works if the paved road is faster than the workaround

The test for whether a platform capability will get adopted is simple: is using it faster than the manual workaround, for the specific engineer doing it today, not in aggregate across the org. A service scaffolding tool that takes fifteen minutes to configure correctly loses to a senior engineer who can copy-paste a working service in five, even if the scaffolding tool produces better long-term outcomes. We measure every platform capability against its manual alternative on raw speed for the common case before shipping it, and we don't consider a capability platform-ready until it wins that race, because a platform that's "better but slower" gets bypassed regardless of how it's positioned internally.

Guardrails, not gates

The distinction that determines whether engineers experience a platform as empowering or obstructive is whether it enforces standards through defaults and guardrails — secure-by-default configuration, sane resource limits, automatic instrumentation — versus through approval gates that block a deploy until a human signs off. Gates create queues, and queues create the political pressure that eventually gets a platform bypassed via an exception process that becomes the new default path. We push as much policy as possible into defaults that are safe unless deliberately overridden, and reserve actual gates for the small number of genuinely high-risk actions — production database schema changes, changes to auth infrastructure — where a human review is proportionate to the risk.

Measure adoption, not capability count

Platform teams often report progress in terms of capabilities shipped — number of templates, number of self-service tools — which is a measure of platform-team output, not platform value. We track weekly active teams per capability, time from "new service needed" to "first deploy," and the ratio of platform-provisioned infrastructure to manually-provisioned infrastructure, because those are the numbers that tell you whether the platform is actually being used versus merely available. A capability nobody uses six months after shipping isn't a maintenance burden waiting to happen, it's a signal that the golden path assumption behind it was wrong, and it's worth revisiting before building the next one on the same assumption.

The platform team needs a support rotation, not just a roadmap

The detail that separates platforms that get trusted from ones that get worked around is response time when something breaks. If a team's deploy pipeline fails at 4pm and the platform team's process is a ticket queue with a two-day SLA, that team will build their own workaround by the following week and never fully come back. We staff platform teams with the same on-call discipline as a product team supporting a critical service, because from the perspective of every team depending on it, that's exactly what it is.