Ninety days is enough to stand up a credible PlatformOps practice — not a finished platform, which does not exist, but a running service with real users and a published rulebook. What separates launches that stick from launches that fade is sequence. Do the steps below in order, resist inserting your favourite tool early, and let evidence rather than enthusiasm move you from one step to the next. The plan itself is assembled from the field’s accumulated practice; for the primary sources behind each step, the Ops Atlas PlatformOps listing is the reference to keep open beside this page.
What PlatformOps needs before day one
Three conditions make the following steps possible, and none of them can be skipped by buying software:
- Pipelines each team already controls, so the platform amplifies an existing habit instead of inventing one.
- Named ownership of every production service, so support boundaries have something to attach to.
- A crude delivery-metrics baseline, so improvements after launch can be demonstrated rather than claimed.
Missing any of these? Fix that first. A platform erected on absent ownership inherits the absence, with interest.
Step 1: Interview five teams, then inventory everything
Weeks one to three belong to listening. Sit with five prospective consumer teams and collect the tasks they repeat — environment setup, pipeline wiring, observability plumbing, access requests. Keep the raw notes; they become your requirements document and, later, your adoption evidence. Then inventory what the organisation already owns, because the fastest way to lose a beta user is to build capability number three of something two in-house scripts already do. Duplicate discovery at this stage is a triumph, not an embarrassment.
Step 2: Write the charter around the thinnest viable platform
Team Topologies’ thinnest-viable-platform idea is the scope discipline that keeps the next eighty days honest. The charter names the consumers, lists the capabilities that made the interview cut, and — just as important — states what the platform will refuse to do in this cycle. One page. If the charter needs two, the second page is where scope creep signed its name. Publish it where anyone can read it; a charter that circulates by request link is a charter nobody agreed to.
Step 3: Build a single golden path with a design partner
Weeks four to eight: construct exactly one paved route from empty repository to running service, and build it with a named design partner from the interview group. The partner’s role is contractual honesty — they use the path daily, file what annoys them, and give you the first honest adoption datapoint you will ever have. The path should cover the boring majority: scaffold from a template, pipeline runs, logs and metrics appear, deploy to staging and production. Deliberately exclude the exotic; a golden path that tries to serve every edge case serves none.
Step 4: Run a two-team beta and instrument it
Weeks nine to eleven: open the path to two teams beyond the design partner. Instrument three numbers from the first day: how far each new service gets from the template without human help, the elapsed time from empty repo to first production push, and how often users route around the path. That last number is the one people skip, and it is the most diagnostic — workarounds are users voting with their feet. Expect complaints; a quiet beta signals teams were too polite to bother, which is worse.
Step 5: Go GA with a runbook, a rota and a lifecycle policy
General availability is a paperwork milestone as much as a technical one. The GA package has three parts: a runbook for every capability on the path, an on-call rota that names who answers for the platform at 2 a.m., and a lifecycle policy that states, for every capability, who owns it, what service level applies, and where it stands — Proposed, in Beta, fully GA, or already headed for retirement. Publishing the lifecycle on day one costs an afternoon; retrofitting it after two years of unmanaged capabilities costs a quarter.
Step 6: Schedule the first deprecation and staff it
The counter-intuitive finale: before the quarter closes, retire something. Deprecate an obsolete template or an old script the path replaced, announce the date, and assign a person — not a Slack announcement — to walk holdout users across. Advisory notices on their own move almost nobody; staffed migrations do, a lesson Google’s own engineers document from hard experience. A team that has exercised one deprecation has proven its lifecycle is real rather than decorative, and future retirements stop feeling like betrayals.
PlatformOps at day 90: reading the results
Judge the quarter on evidence. Did the two beta teams keep using the path without prompting? Did the workaround count fall while template starts rose? Did delivery metrics dip as predicted — the J-curve DORA’s research documents — or crash? A modest dip with recovering trend is success; a crater is a signal to slow GA, not to mandate harder. Whatever the numbers, publish them. Teams trust a platform that reports its own misses, and your day-91 roadmap should be obvious from the notes rather than invented in a boardroom.
One last framing for the flight-minded: the whole sequence is closer to ferrying an aircraft than building one. You are moving an organisation from where it is to where it needs to be, using equipment that already exists, on a filed plan. Operators who fill empty capacity rather than buying new tonne — the logic behind how empty-leg jet flights work — will recognise the economics immediately, and the traveller’s guide to empty-leg flying makes the same point from the buyer’s side: the assets exist; the discipline is routing people onto them.
