Anyone who has tried to see all of Delhi in a day knows how that ends: four monuments, three arguments, and no memory of any of it. The trips that actually work pick one route, walk it properly, and leave the rest for next weekend. Starting PlatformOps — running your shared engineering tooling as a product people choose — follows the same logic, and there happens to be a well-tested ninety-day plan for it. Here it is, step by step, with the honest bits included: what to do in each month, how many teams to talk to, and the one retirement you owe yourself by day ninety.
What a PlatformOps Launch Is Really Asking Of You
Before the calendar stuff, one reframe. You are not building a big system; you are starting a service that internal teams can join voluntarily. That single sentence changes the plan. Services earn users by being pleasant and dependable, not by being complete, so the ninety days optimise for a good first season rather than an impressive launch day. Keep the framing handy — it will settle several arguments you are about to have with yourself.
One practical note before day one: secure a sponsor who wants evidence rather than fireworks. The plan below produces its proof slowly — interviews in the first month, a working path in the second, voluntary adopters in the third — and a sponsor expecting a demo in week two will pull the plug precisely when the roots are forming. The right sponsor asks “what did the five teams say?” and reads the answer. If you cannot name that person yet, finding them is week zero’s only task.
Days 1–30: Listen, Count, and Write a Small Charter
Spend the first month doing something almost nobody does: talking and counting. Sit down with five teams — not the friendly ones, a fair sample — and ask what they actually do repeatedly, what slows them down, and what they have already built themselves to cope. Write the answers down. Somewhere in those interviews a pattern will repeat three or more times; that repetition is your signal, and everything later hangs off it.
Alongside the interviews, build an inventory. Every shared thing — pipelines, templates, libraries, environments — goes on one list with a name beside it. Half your list will have no name, which is a finding, not a failure.
Then write a charter, one page, saying what this effort will own and — crucially — what it will not. Team Topologies has a phrase worth borrowing here: aim for the thinnest viable platform, the smallest set of capability that removes real toil without hauling in complexity nobody asked for. Thin is a feature, not an apology. Your charter is the contract that keeps it thin when enthusiasm argues otherwise.
Make the interviews count by asking about behaviour instead of opinions. “Walk me through the last time you shipped something” beats “what would you like in a platform”, because memories of friction are specific and wishes are generic. Ask what people do with spreadsheets. Ask which steps everyone forgets until audit week. Ask what they have privately scripted, because those scripts are a wish list written in working code. By the fifth conversation you will be hearing the same three frustrations in different accents, and that convergence — not your own enthusiasm — is what earns the build decision.
Days 31–60: One Golden Path, One Design Partner
Month two is the build month, and the discipline is brutal simplicity: exactly one supported route, built with exactly one partner team. Pick the repeated pattern from your interviews and turn it into a path a newcomer can follow — template, checks, docs, and a person to call. The design partner is not a tester; they use it for real work, find the embarrassing gaps, and co-sign the thing when it holds. Their fingerprints matter enormously later, because the first question every skeptical team asks is whether anyone real has survived this route.
Resist, with everything you have, the urge to launch several paths in parallel or to polish for the whole month. The classic failure here is the big bang — months of quiet construction, a grand unveiling, and a product that meets reality for the first time in front of an audience. One path, one partner, weekly contact. That is the whole assignment.
What goes inside the path is less mystical than people expect, and most of it is consolidation rather than invention. A starting template with the boring decisions pre-made — naming, structure, the logging wiring everyone re-derives badly. The checks that compliance actually requires, run automatically so nobody rediscovers them in April. Documentation short enough to be read and a contact who exists. If a step on the path cannot be explained in one sentence, it is probably two steps wearing a coat. The design partner will tell you which parts of the path are service and which are ceremony; believe them about the ceremony.
Days 61–90: The PlatformOps Graduation and the First Retirement
Month three opens the doors, but not all of them. Invite a second team onto the path — a beta pair, chosen for honesty rather than friendship — and watch what breaks. Fix what the beta exposes. Once the path survives two teams doing real work, you can call it generally available, and GA carries obligations: a runbook for when it misbehaves, an on-call arrangement so somebody specific answers, and a lifecycle policy saying how capabilities will be treated from now on — stages, owners, dates.
Then comes the step that proves the whole thing is real: your first deprecation. Look at the inventory from month one, find the oldest duplicated or abandoned item, and retire it properly — notice, alternative, migration help, date. It sounds like housekeeping; it functions as a declaration. The moment a platform kills something of its own, on schedule and with care, everyone updates their model of what this effort is. Nothing builds trust with engineers faster than visible follow-through, and nothing is rarer.
Run the beta like a study, not a formality. Sit with the second team during their first week on the path and write down every place they hesitate — hesitation is documentation failing quietly. Count how long their first deployment takes and compare it with the partner team’s; the delta between the two tells you what was learned knowledge versus what was genuinely built in. By day ninety you should be able to state, from evidence, that a newcomer following the route reaches production in an afternoon, because you watched it happen twice.
Three Detours That Waste the Whole Quarter
Watch for these; each one has quietly eaten somebody’s ninety days.
- Shopping first. Buying tooling before the interviews means automating guesses. The conversations are free and always change the plan.
- Building for everyone. A path that tries to serve all teams at once serves none of them well. The plan works because it is deliberately narrow.
- Skipping the retirement. End month three with a launch party instead of a deprecation and you have shipped a demo, not a discipline. The retirement is the proof of operating maturity.
If You Only Keep Three Ideas
Talk to five teams before building anything. Ship one supported route with one partner rather than a catalogue of promises. End the quarter with something generally available that has a runbook, a pager, and one honest funeral behind it. A quarter from now, that is a platform people have actually chosen to use — and choosing is the entire game. If the ninety-day shape leaves you hungry for the wider skills behind it, the DevOpsSchool career roadmap maps the learning sequence, and if you want the route-planning mindset applied with more masala, this walk-through of planning a complete Delhi sightseeing trip makes the same argument for depth over coverage. Every step above traces back to the Ops Atlas PlatformOps reference, the page to keep open while you run the plan — and to re-read at day ninety, when the next quarter’s thinnest-next-thing is being chosen.