Self-service & the platform team operating model
Golden paths (7.2) define the right way to do common things. This lesson adds the property that makes them transformative — self-service — and then answers two questions every real platform must: who builds and runs the platform? (the team model) and how do you know it's working? (the metrics). Get self-service without an operating model and the platform burns out its builders; get both without measurement and you can't prove the platform earns its keep.
Self-service: kill the ticket
Self-service means a developer can get what they need — a database, a test environment, a new service, a secret — directly, immediately, through the platform, without filing a ticket and waiting for another human to act.
The thing self-service replaces is the ticket queue: "Open a ticket; the infra team will provision your database in 3–5 business days." That queue is a triple tax — it's slow (days of waiting), it's a bottleneck (the central team becomes the rate-limiter for the whole org), and it's demoralizing (smart engineers stuck begging for resources). Self-service removes the human from the routine loop entirely: the platform fulfills the request, in minutes, any hour of the day.
The mental shift for the platform team is profound: you stop doing the provisioning and start building the thing that does the provisioning. Your output changes from tickets-closed to capabilities-shipped. (You'll see the machinery that makes safe self-service possible in 7.5 and the guardrails that keep it from becoming a security/cost hole in 7.6.)
Environments on demand: the killer self-service feature
The most loved self-service capability is the ephemeral environment (also preview or on-demand environment): a complete, temporary copy of the app — its services, a database, seed data — spun up automatically, used, then torn down.
The signature pattern: open a pull request, and the platform stands up a live preview environment for exactly that change, posting the URL back on the PR. Reviewers and product managers click it and see the change running before merge. When the PR merges or closes, the environment is automatically destroyed so it costs nothing afterward.
Why this is a big deal:
- "Ephemeral" means short-lived by design — created on demand, destroyed when done — so you're not paying for or babysitting long-lived staging copies.
- It collapses the old "wait for a shared staging slot" bottleneck: every change gets its own isolated environment.
- It's only feasible because of everything earlier in this guide — IaC to define the environment (Ch. 3), containers/Kubernetes to pack many of them cheaply (Ch. 4), and a pipeline to trigger create/destroy (Ch. 5). An ephemeral environment is those capabilities composed behind one self-service button.
:::note Tooling, isolated as dated Concrete ways teams build environments-on-demand include Qovery and platform orchestrators like Humanitec, namespace- or vCluster-based isolation on Kubernetes (7.6), and PR-preview features in GitOps tooling. Which tool is dated; the durable idea — a full environment, on demand, auto-destroyed — is what to internalize. :::
The operating model: who builds the platform?
A platform needs an owner. The dominant framework for how to structure the teams is Team Topologies, which defines a small set of team types. Two matter here:
- A stream-aligned team is a product/feature team aligned to a stream of work — the platform's customers. They want to ship features, not master infrastructure.
- A platform team builds and runs the internal platform as a product to reduce the stream-aligned teams' cognitive load. Its job is enablement, not gatekeeping.
The two defining traits of a healthy platform team:
- It's a product team, not a ticket queue. Its deliverable is self-service capability, and its success is measured by adoption (below). If developers route everything through it as a help desk, the model has failed.
- The relationship is pull, not push. Stream-aligned teams pull what they need from the platform on demand; the platform doesn't push mandates onto them. And the dotted feedback arrows are not optional — they are the DevEx feedback loop: the platform team continuously researches and listens to its customers (surveys, interviews, support channels, usage data). A platform built in isolation from the teams it serves is the canonical way to build something nobody adopts (7.1).
:::tip Platform team as enabler, not bottleneck The anti-pattern is recreating the old central ops gatekeeper under a new name. If the platform team becomes the thing every change must wait on, you've reinvented the ticket queue with extra branding. The whole point is to push capability out to teams so the platform team is off the critical path of day-to-day delivery. :::
Measuring success: prove the platform works
Because the platform is a product (7.1), you measure it like one. Three complementary lenses:
- Adoption rate. Are teams actually using it? What fraction of services are on the golden path? How many teams self-serve vs file tickets? This is the single most important metric, because non-adoption is the #1 failure mode (~45% of platform teams cite it). A technically gorgeous platform with 10% adoption is a failed product.
- Developer satisfaction (DevEx). Measured with periodic DevEx surveys — short, recurring questionnaires asking developers how the platform feels: Is it easy? Does it unblock you? What's painful? Satisfaction is a leading indicator; falling scores predict falling adoption before the usage graph dips.
- DORA metrics. The four research-backed delivery metrics from Chapter 5 — deployment frequency, lead time for changes, change-failure rate, and time to restore service. A working platform should move these in the right direction: deploys get more frequent, lead time shrinks, failures drop. DORA is your outcome evidence that the platform improved how the org ships.
The healthy dashboard reads all three together: high adoption (they use it), high satisfaction (they like it), and improving DORA (it makes delivery better). Any one alone can mislead — high DORA with low adoption might just mean a few elite teams, while high satisfaction with flat DORA might mean a pleasant tool that didn't change outcomes.
:::note DORA, recapped The DORA metrics (DevOps Research and Assessment) are four measures that correlate with software-delivery performance: how often you deploy, how long a change takes to reach production, how often deploys break things, and how fast you recover. They're covered in Chapter 5; here they serve as the platform's outcome scoreboard. :::
Common pitfalls
- Self-service without guardrails. "Provision anything, anytime" with no quotas or policy is a security and cost hole, not a feature — see 7.6. Self-service must be bounded self-service.
- The platform team as a renamed ticket queue. If you're still the human in every loop, you built a help desk, not a platform.
- No feedback loop. Building in isolation from your customers is how you ship something nobody adopts. Survey, interview, and instrument continuously.
- Measuring effort, not outcomes. "We shipped 12 features this quarter" is vanity. Adoption, satisfaction, and DORA are the metrics that matter; track those.
- Treating low adoption as a developer problem. If teams won't adopt, the platform is failing them, not the reverse. The fix is research and a better paved road, not a mandate.
Why it matters
Self-service removes the human from routine provisioning — developers get databases, secrets, and especially ephemeral/preview environments directly and immediately, killing the slow, demoralizing ticket queue and the bottleneck it creates. Sustaining that requires the right operating model: a platform team (Team Topologies) that builds the IDP as a product to reduce stream-aligned teams' cognitive load, relating to them by pull and feedback, not push and gatekeeping. And because it's a product, you prove it with adoption rate (the make-or-break number), DevEx surveys (the leading indicator), and DORA metrics (the outcome evidence). Next we meet the developer-facing front door to all of this — the developer portal, and why it is not the same thing as the platform.