Every syllabus in aviation shares one design: a defined first lesson, a first solo, a first cross-country, each with clear standards to meet before you advance to the next. It works because nobody is asked to improvise a curriculum mid-air. PlatformOps deserves the same treatment. Operating a company’s internal developer platform like a product line — owners attached, service levels published, upgrades planned, retirements honest — sounds like a two-year transformation when vendors describe it, but the first ninety days have a shape anyone can follow. This is that shape, as steps. The plan assumes a small team — one or two engineers with a mandate and a little budget — an existing engineering organisation of a half-dozen teams or more, and no platform programme yet in place. If your context differs wildly, the steps still order correctly; only the durations shift.
Before day one: the PlatformOps briefing
One clarification keeps the whole quarter coherent. What you are about to run is not a tooling rollout; it is the opening of an internal service business whose customers sit one floor away. DORA’s research programme frames the discipline as sociotechnical at root: the tooling and the human arrangements around it change together, or they do not really change at all. The CNCF adds a property worth memorising before any work order is written: platforms are meant to be optional and composable, which means every step below earns its place by being chosen, never by being decreed. Budget one hour with your sponsor to agree on that framing. If your sponsor expects a finished portal in a month, renegotiate now, not on day sixty.
Days 1-10: five interviews and an honest inventory
Start where any flight instructor starts: find out what the student actually brings.
- Interview five teams. One hour each, no slides. Ask what eats their week, which requests wait longest, and where releases go wrong. Write down quotes, not summaries — quotes survive committee rewrites, and they keep the work honest when enthusiasm starts decorating the story.
- Inventory existing capability. List every shared script, template, pipeline, and runbook that already exists, with the person who understands it. Most organisations discover they own more platform than they thought, held together by three people’s goodwill.
- Write the charter. One page: the platform’s purpose, its first customers by name, and what it will not do this quarter. A charter that fits on one page gets read; a strategy deck gets skimmed and resented.
- Adopt the thinnest-viable-platform principle. Commit, in writing, to building the smallest set of capability that real teams will actually pull. The phrase comes from the Team Topologies book and is the best known antidote to platform sprawl.
A note on the charter, because it earns its hour: the strongest ones name a single sentence of intent, three customers by team name, an explicit not-doing list for the quarter, and the one measure that will decide success. Everything a sponsor might misremember later should be on that page. When a director asks in week seven whether the platform will also handle cost reporting, the answer is a calm point to the not-doing list — not an apology, and not a scope change absorbed in silence.
Days 11-30: choose the one route worth paving
From the interviews, pick the single most repeated, most painful workflow — for most organisations, creating a brand-new service from nothing. That becomes your first golden path: an opinionated, supported route with the organisation’s best decisions already installed. Resist the urge to pave three routes; a platform team that ships one excellent path earns more credibility than one that ships three drafts. Alongside the build, capture a baseline measurement so the improvement will be provable later: how long a new service takes today, counted in working days, with the waits itemised.
The baseline matters more than it looks. Without it, day-ninety claims rest on memory, and memory is generous to its author. With it, the platform’s first progress report is arithmetic rather than advocacy — and the same arithmetic will justify the second quarter’s budget without a single persuasive adjective.
- Recruit a design partner. One team, genuinely willing, ideally the one that complained loudest in the interviews. They will use the route first and tell you the truth first.
- Ship incrementally to that partner. Weekly, not quarterly. Their friction is your requirements document.
- Name the owner and draft the promise. The route needs a responsible human and a draft service level — for example, service running within one working day, measured and published.
Days 31-60: the beta, with two teams
A design partner proves the route works for people who helped build it; a beta proves it works for strangers. Bring in a second team — different product, different temperament — and let them run the path without you in the room. Watch where they hesitate, because hesitation marks the undocumented assumption. Expect the humbling discoveries: the documentation that only makes sense if you already know the answer, the default that suits the platform team and nobody else, the dependency on a person rather than a page. Every one of those is a defect the design partner was too polite to mention. During the beta window:
- Tighten the template until the second team needs no hand-holding at all.
- Publish the service level, support channel, and a one-page guide written for someone who missed every meeting.
- Set the on-call arrangement in writing: the platform team carries faults in platform parts, the application team carries their own services, at any hour.
- Log the metric weekly. Time-to-first-deploy is the headline number; by day sixty you should be quoting it in hours, not days.
Days 61-90: taking PlatformOps to general availability
Graduation to GA is a set of declarations, not a party. The route moves to general availability with a published service level, a runbook for its known failure modes — written from the beta’s actual incidents, not imagined ones — and a named engineer on the rota. Alongside it, adopt a lifecycle policy so every future capability has a labelled life: Proposed, Alpha, Beta, GA, Deprecated, Retired. Labels feel bureaucratic until the first argument they prevent — nobody argues over whether an Alpha-grade tool should page anyone at night.
Then perform the step that separates operators from announcers: your first deprecation. Choose one ageing script or legacy route that the new path replaces. Announce it with a date, write the migration guide, assign an engineer to help teams across, and retire it on schedule. Warnings alone rarely move anyone; a staffed retirement moves whole squads. That single act teaches the organisation more about how this platform will be run than any launch email, because it shows commitments are honoured in both directions — on creation and on withdrawal.
The checks ride, and what comes after
Close the quarter as a syllabus closes: with standards met and logged. Present four numbers to your sponsor — baseline versus current time-to-first-deploy, the count of teams on the route voluntarily, the service level attained, and one capability retired. Then repeat the loop at slightly larger scale: second route, third beta, first full quarterly review. Momentum in this discipline compounds the way flight hours do; nothing dramatic happens on any single Tuesday, and one day the operation simply runs itself on published promises. Ninety days is not the destination — it is the first time the logbook shows standards met, which is exactly what a syllabus is for. Teams watching their training budgets will recognise the philosophy in our guides to reducing flight training expenses and how aircraft type changes what training costs — spend where repetition is real, measure what you fund, and advance only on demonstrated standards.
For the deeper syllabus — architecture layers, product-management practice for platforms, and the full adoption research — open the Ops Atlas PlatformOps entry; it is the set text we would assign beside this plan. And if your team’s budget conversation turns to funding the platform at all, the scholarship mindset in this guide to funding flight training translates surprisingly well: committed money, documented milestones, and no shame in starting small.
