Plenty of engineering organisations now have something they call an internal platform. Far fewer have the things that make a platform operable — the documents, owners, promises and exit routes that separate a working capability from a demo that aged out. PlatformOps is the discipline of supplying those things, and the good news is that the checklist is short enough to hold in your head. Below: nine requirements, counted out, each one something you can verify in an afternoon. If your team can tick all nine, you have a platform. If not, you know exactly what to fix next.
The definitions behind the list come from the Ops Atlas notes on PlatformOps, which is the reference to read once and then keep for the vocabulary.
PlatformOps, Distilled to Nine Requirements
One remark before item one. None of the nine is software. Every one of them is a decision, written down and maintained. That is the recurring lesson of platform work that goes well versus platform work that quietly dies.
1. A charter that says what you will not do
The first requirement is a page — not a deck — stating what the platform covers, what it refuses to cover, and how a team escalates a disagreement. The discipline is in the refusals. A charter that promises everything is a charter that will fund nothing by year two. While writing it, run the go/no-go check too: with fewer than about three teams facing repeated common needs, or without funding committed past two years, a wiki page and some scripts beat a platform programme. Deciding not to build is a legitimate outcome, and cheaper than the alternative.
2. A catalog with owners who know they are listed
Every capability needs a catalogue entry, and every entry needs a human name attached. Two quality bars apply. First, the owner knows and agrees — a catalogue that assigns owners by deduction is fiction. Second, the data gets checked: catalog entries are self-declared and drift fast, so serious teams compare what is declared against what the access logs show, and publish the differences. A catalogue nobody audits is a fairy tale with good intentions.
3. One golden path for the most common journey
Pick the job your engineers do most — usually creating a new service — and build a single supported route for it: repository scaffold, pipeline, observability and deployment wired up the organisation’s way. Spotify was writing about golden paths around 2014; Netflix still runs its version under the name paved road. The route comes with opinionated defaults, so taking it means the good decisions arrive attached. One path, done properly, beats five half-finished ones; breadth is the last thing you add, not the first.
4. A lifecycle state for every capability
Anything the platform offers sits somewhere on a ladder from first proposal through trials and general availability to deprecation and retirement — and the label is public, not tribal knowledge. This one habit prevents the most common platform disease: capabilities that exist in a permanent grey zone, used by everyone, owned by no one, too risky to remove. The CNCF’s research makes the stakes plain by observing that the bulk of a capability’s cost lands after its first release. The ladder is how you keep that cost visible.
5. Published service levels with support tiers
A capability without a stated level of service is a hope. Write the number down — availability during working hours, recovery expectations, maintenance windows — and attach a support tier that says, in advance, who answers at night and who answers tomorrow. Tiers do double duty: they set honest expectations for consumers and they cap the platform team’s infinite liability. Teams resist publishing numbers until the first incident; publish before.
6. On-call boundaries drawn in ink
The rule is simple enough to state and hard enough to enforce: application teams page for their services; the platform team pages for platform components. Every undrawn line here becomes a 3 a.m. dispute, and disputes at that hour resolve by seniority rather than sense. Draw the boundary while everyone is calm, revisit it when capabilities change hands, and write it where the on-call rota lives, not in some policy folder nobody opens twice a year.
7. A deprecation plan with a person’s name on it
The ninth requirement’s sibling deserves its own slot: anything that can be introduced must be retirable, with a date, a plan and a named human whose job includes migrating the users of whatever is being switched off. Experience, and Google’s own engineers, report that warnings alone rarely move anyone — a notice in a changelog is not a migration strategy. Staff the deprecation or do not announce it. Platforms that never retire anything are hoards, and hoards compound at the worst possible moment.
8. Numbers that show effect, reviewed in public
Track a handful of measures and show them to consumers and leadership on a fixed rhythm:
- Days from joining to a newcomer’s first production deploy.
- Share of new work travelling the golden path — and defections off it.
- Self-service rate: requests completed without a human intermediary.
- Attainment against the published service levels.
- Consumer satisfaction, asked directly, published unedited.
- The pace of deprecation, because a platform that only grows is a hoard.
Two readings to keep in mind while those numbers move. DORA’s result that a badly run platform can drag both throughput and stability downward — measurement is how you catch that early — and the J-curve, meaning a dip during migration is expected and is not, by itself, a verdict.
9. Adoption by pull, not by memo
The final requirement governs all the others: teams must be allowed to decline. A platform that must be used will be complied with, not adopted, and compliance looks deceptively similar on a dashboard while costing twice as much in goodwill. The operating test is blunt — is the platform genuinely the easier way, so that volunteers arrive without persuasion? If not, the fix is in the product, never in the policy. An internal platform has to be compelling; there is no substitute for that and no memo that replaces it.
How to Score Yourself Against the Nine
An afternoon’s exercise: go through the list with the platform team and one consumer team in the room, marking each item green, amber or red. Argue only about evidence, not intentions — the charter either exists or it does not; the on-call boundary is either written or folklore. Most organisations score honestly at four or five greens, and the ambers make next quarter’s plan without further debate. Re-run the scoring quarterly; the trend matters more than the absolute score, because platform work decays when unwatched.
A word on ordering, since nine items at once invites paralysis. Items one, three and nine form the spine: know what you promise, build one supported route, let teams choose it. The rest attach themselves naturally — a route in use needs a service level (item five), which needs an on-call boundary (item six), which needs owners (item two) and a ladder (item four). Start at the spine and the checklist pulls itself through.
PlatformOps as a Career Direction
For readers weighing where to specialise, the nine requirements are effectively the job description of a platform engineer, and almost none of them are about writing code at speed. The role rewards people who can write a clear charter, keep a catalogue honest, and hold a service-level conversation with strangers — product and communication skills layered on top of solid delivery fundamentals, a combination that fits the wider shift described in the new career pathways opening for modern software developers.
It is also a natural next rung on the ladder many of you are already climbing; the moves from builder to operator to platform owner map cleanly onto the route from junior to senior DevOps engineer. And for those in the Dutch market who prefer independence, platform skills are among the most portable an independent can hold — worth reading alongside the growing use of freelance DevOps, SRE and DevSecOps specialists in the Netherlands. Operable platforms need maintaining everywhere; the nine items travel well across borders and contracts.