Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Platform Engineer

A platform engineer builds and evolves internal platforms that provide secure, reliable self-service capabilities to software teams, which is a perfectly reasonable arrangement until you remember that the platform is a product whose users are developers, a customer whose complaints arrive as pull requests and whose satisfaction is measured in tickets they did not have to file. You learn to translate "make this easier" into golden paths, platform APIs, container orchestration, delivery pipelines, and an internal developer platform that was meant to remove a waiting room and must not become one itself. The platform is welcoming on the way in and commemorative on the way out, and a golden path that teams construct unsupervised footpaths around is a path whose pavement arrived without the destination. Cognitive load is the thing the platform is meant to reduce, and a platform that increases it is an external developer obstacle wearing an internal developer platform's coat. This guide travels from reading a platform's capabilities without flinching to setting organisation-wide platform strategy, with practical stops at product thinking, APIs, container orchestration, software delivery, observability, operations, security, extensibility, and the recurring discovery that a capability marked "self-service" is merely self-service to provision and not yet self-service to operate. The grand objective is dependable delivery at a defensible level of cognitive load; the daily evidence is usually a deployment that converges, a developer who did not need to ask, and a monthly capability review that fails to surprise anyone except the finance team, who have learned not to be surprised by their lack of surprise.

Things to recognise

• A capability marked "self-service" is self-service to provision and not yet self-service to operate; the portal's submit button is the start of the journey, and the runbook the team did not read is the middle.
• Golden paths list headline steps, while the actual journey includes approvals, secrets, networking, quotas, and managed integrations that accrue whether or not the documentation mentions them.
• Confirm the namespace, capability, billing alarm, and write capability before provisioning, because a correct resource in the wrong tenant remains impressively persistent and surprisingly difficult to retire.

Take the useful exit

Level 1 · Novice

Read the golden path before the team paves a footpath around you

You inspect platform capabilities, golden paths, documentation, and developer workflows without changing the platform, learning how a perfectly polite self-service portal can route a team into a cul-de-sac before they finish reading its welcome page.

You begin with read-only artifacts: platform capability catalogues, golden path documentation, API descriptions, self-service portal flows, onboarding guides, and a backlog expressing recent opinions about developer friction. Platform engineering is the practice of treating the platform as a product, measuring developer outcomes, and building capabilities that teams consume rather than infrastructure they borrow. An internal developer platform is a cohesive set of self-service capabilities and golden paths that reduce cognitive load across software delivery; a golden path is a supported, opinionated route from idea to production that the platform team maintains so teams can walk it without first surveying the terrain. You review these with developers, security staff, and an experienced engineer so everyone can trace how a capability is used before anyone clicks a button whose confirmation dialog is also a support ticket.

Suppose a team wants to deploy a new service "on the platform." In a sandbox namespace with no production access, you read the golden path documentation, compare two candidate delivery workflows, list the capabilities each path uses, and note that a self-service portal whose form has eleven required fields is a polite refusal rather than a shortcut. You record the steps, assumptions, and the single field that blocks the team for a week. One brisk walkthrough is an anecdote with good posture, not a platform; but it prevents the team from commissioning a custom pipeline for a service that the golden path was built to deliver.

Words from the spaceship manual, translated

Platform engineering: The discipline of building and evolving internal platforms as products, with users, roadmaps, and measured outcomes. It treats the platform as something teams consume rather than something they are issued with a lecture about, and it measures success in things developers did not have to do.
Internal developer platform: A cohesive set of self-service capabilities and golden paths that reduce cognitive load across software delivery. It is welcoming on the way in and, when neglected, commemorative on the way out as teams construct unsupervised footpaths around it.
Golden path: A supported, opinionated route from idea to production that the platform team maintains. A golden path that teams walk around is a path whose pavement arrived without the destination, and a path no one walks is a sidewalk, not a capability.
Cognitive load: The mental effort a team spends to deliver software, including context-switching, configuration, and remembering which of eleven fields the portal requires. A platform that increases cognitive load is an external developer obstacle wearing an internal developer platform's coat.