5 exercises — Practice platform engineering vocabulary in English: Internal Developer Platforms, golden paths, DORA metrics, cognitive load, and Team Topologies.
Core Platform Engineering vocabulary clusters
IDP concepts: Internal Developer Platform (IDP), golden path, paved road, scaffolding, service template, self-service portal, software catalogue
Team Topologies: stream-aligned team, platform team, enabling team, complicated-subsystem team, cognitive load, team API
Developer experience: DORA metrics (deployment frequency, lead time, change failure rate, MTTR), toil, developer joy, SPACE framework
Metrics: deployment frequency, lead time for changes, cognitive load reduction, toil percentage, platform adoption rate
0 / 5 completed
1 / 5
A platform engineer explains their team's mission: "We're building an Internal Developer Platform — an IDP. The goal is to give every engineering team a golden path: an opinionated, well-supported route to deploy a service. If you follow the golden path, you get security, observability, CI/CD, and infrastructure out of the box. You can deviate, but you're on your own." What is a golden path in platform engineering?
Golden path (also: paved road, happy path): an opinionated, well-maintained default way of building and deploying services. Reduces cognitive load by encoding best practices into templates and tooling. Platform vocabulary: IDP (Internal Developer Platform) — a curated set of tools, workflows, and self-service capabilities that platform teams build for application developers. NOT a portal — a platform. Self-service portal — the UI layer of an IDP where developers provision infrastructure, deploy services, view their service catalogue entry, etc. Service template / scaffolding — a starter project with the golden path already wired in (CI/CD, logging, tracing, auth). Software catalogue — a registry of all services, their owners, docs, and runbooks. Backstage (by Spotify) is the most widely used open-source software catalogue. Tech radar — a visual tool (ThoughtWorks model) categorising technologies into Adopt, Trial, Assess, Hold. In conversation: "We want 80% of new services to start from the golden path template — that way we know they're all instrumented correctly from day one."
2 / 5
An engineering director presents Team Topologies at an all-hands: "We're reorganising around four team types. Stream-aligned teams own end-to-end delivery of a product area. The platform team builds the internal platform that reduces cognitive load on stream-aligned teams. Enabling teams help stream-aligned teams adopt new capabilities. Complicated-subsystem teams own components that require deep specialist knowledge." What is the primary purpose of a platform team in Team Topologies?
Platform team: builds and operates an internal platform that stream-aligned teams consume as a service. The key value: reducing cognitive load so product teams can focus on user value. Team Topologies vocabulary (Matthew Skelton & Manuel Pais): Stream-aligned team — aligned to a flow of business value; owns a product area or customer journey end-to-end; the primary team type. Platform team — provides a compelling internal product that stream-aligned teams consume. Treats platform as a product. Enabling team — temporary team that helps stream-aligned teams acquire new capabilities (e.g., adopt Kubernetes, migrate to event-driven architecture) then dissolves or moves on. Complicated-subsystem team — owns a component requiring deep specialist knowledge (e.g., video processing, ML inference, cryptography). Cognitive load — the total mental effort a team must carry to do their job. Platform teams reduce cognitive load by abstracting away infrastructure complexity. Team API — how a team communicates its purpose, interaction modes, and services to other teams. In conversation: "The platform team's north star is developer experience — if stream-aligned teams need to understand Kubernetes internals to deploy, we've failed."
3 / 5
A VP of Engineering reviews platform metrics: "DORA metrics are the gold standard for measuring software delivery performance. We track four: deployment frequency, lead time for changes, change failure rate, and MTTR. Right now we're in the 'Medium' band — we deploy weekly, lead time is 1–2 weeks. The goal is to get to 'Elite' — multiple deploys per day, lead time under an hour." What does lead time for changes measure in DORA metrics?
Lead time for changes: the time from code commit to running in production. One of the four DORA metrics. DORA metrics vocabulary: Deployment frequency — how often the team deploys to production. Elite: multiple times per day. High: weekly–daily. Medium: monthly–weekly. Low: once per 6 months or less. Lead time for changes — commit → production. Elite: <1 hour. High: 1 day–1 week. Medium: 1–4 weeks. Change failure rate — % of deployments that cause a production failure requiring a fix, rollback, or hotfix. Elite: 0–5%. MTTR (Mean Time to Recovery) — how long to restore service after a failure. Elite: <1 hour. SPACE framework (GitHub Research) — Satisfaction, Performance, Activity, Communication/Collaboration, Efficiency. Wider developer productivity framework. Toil (Google SRE) — repetitive, manual, automatable operational work that scales with service growth. In conversation: "Our lead time is 3 weeks because of manual approval gates — automating those would move us to High performer."
4 / 5
A platform engineer explains their service template strategy: "Every new microservice starts from our Backstage scaffolder template. It comes pre-wired with structured logging, distributed tracing, Prometheus metrics, a Dockerfile, a Helm chart, a GitHub Actions CI pipeline, and a PagerDuty integration. The developer just answers a few questions and gets a repo with everything configured." What is scaffolding in the context of a developer platform?
Scaffolding: automated generation of a project's initial structure from a template. The output is a working skeleton with all standard integrations already wired in. Platform tooling vocabulary: Backstage — open-source developer portal by Spotify. Core features: software catalogue, TechDocs (docs-as-code), scaffolder (template-based project creation), plugins. Scaffolder template — a Backstage template (in YAML) that generates a new service repo with all golden-path integrations. Service catalogue — a single pane of glass showing all services, owners, dependencies, SLOs, and runbooks. Crossplane — Kubernetes-native infrastructure provisioning; platform teams use it to let developers self-serve cloud resources via CRDs. Port, Cortex — commercial alternatives to Backstage. Score.dev — a workload spec that abstracts away platform specifics so developers write platform-agnostic service definitions. In conversation: "When a developer creates a service from the scaffolder, they get 2,000 lines of infrastructure config they never have to write or maintain — that's the platform value."
5 / 5
A platform team lead defines success metrics for the quarter: "We measure platform adoption as the percentage of services using the golden path. We're at 60% — up from 30% last quarter. We also measure toil: the percentage of platform team time spent on repetitive, manual, non-engineering work. Our goal is to keep toil under 20% of our time so we can actually build the platform." In SRE/platform vocabulary, what is toil?
Toil (Google SRE definition): manual, repetitive, automatable work tied to running a service in production. Properties of toil: manual (requires human execution), repetitive (done again and again), automatable (a machine could do it), tactical (no enduring value — it's done and immediately needs doing again), scales with service growth (more services = more toil). Examples: manually restarting a crashed service, rotating secrets by copy-pasting, resizing a disk because autoscaling isn't set up, approving deployments in a ticket queue. Toil budget: Google SRE recommends keeping toil below 50% of an SRE's time. Platform teams track it to ensure they're building automation rather than becoming a human switchboard. Platform adoption metrics: Golden path adoption rate — % of services using the standard template. MTTR for platform issues. Developer satisfaction (DevEx survey NPS). Self-service rate — % of resource provisioning done without platform team intervention. In conversation: "If toil is above 50%, the team is an operations team, not a platform team — we need to automate our way out."