Platform Engineering

WHAT IT IS. Platform engineering treats the internal developer platform as a product with users (your engineers), a roadmap, and adoption metrics. Its surface is the golden path: a paved, templated route from "new service" to "running in production with pipelines, telemetry, and SLOs wired" that works without reading a wiki. Underneath sit the portal/catalog, templating, and the runtime the paved road deploys onto. Team Topologies (linked below) names the organizational shape: a platform team serving stream-aligned teams, measured by how much it reduces their cognitive load — not by the technology it ships. WHY IT EXISTS. Every product team rebuilds the same twenty decisions — repo layout, pipeline, runtime, secrets, dashboards — each slightly differently, so the estate fragments and the ops burden multiplies. A central platform that requires tickets just moves the queue. The product framing fixes both: golden paths make the well-supported route the path of least resistance, and self-service means adopting it costs a teams' afternoon, not a Jira epic. WHEN TO USE IT. When two or three stream teams feel the same friction repeatedly — the third team hand-rolling its own pipeline is the signal. Below that, a shared template repo is honest and cheaper. The anti-pattern is a platform built before its users exist: internal products die the same death as external ones nobody asked for. WHO OWNS IT. A platform team of product-shaped engineers: it interviews users, keeps a public roadmap, deprecates what nobody adopted, and answers for the platform's own SLOs — portal availability, template freshness, time-to-green-pipeline. Product teams are customers with a real alternative: if the paved road is worse than the dirt road, they leave, and that churn is the metric that matters. WHAT GOOD LOOKS LIKE. A new service reaches production through self-service in under a day, with CI/CD, secrets, dashboards, alerts, and an SLO scaffold attached by default. Platform adoption grows because the golden path is genuinely the easiest route, not because mandates say so. The ticket queue between product and platform trends toward zero. The platform has its own SLOs and its own incident reviews — the product team pages the platform team when the paved road breaks, and that is healthy. HOW TO IMPLEMENT. Find the single developer journey with the worst time-to-value (usually "new service to production" or "local dev to staging"). Build the thinnest golden path for exactly that journey — template, pipeline, runtime wiring — and measure time-to-first-deploy before and after. Add the next journey only when the first has adopters who did not have to be asked. Resist the portal-everything phase; a catalog nobody maintains is worse than a README. HOW TO ASSESS YOURSELF. Score the platform's own readiness like any product: /assess covers deployment automation, progressive delivery, and the telemetry the golden path must emit. The maturity ladder below runs from shared scripts (L1) to a self-service platform with SLOs and adoption metrics (L5). Related: /devops is the model the platform productizes, /gitops is how declared state stays true, /observability-engineering is what the paths instrument, /cloudops owns the estate beneath.