Ask two travellers how they would cover Bihar and you will get two very different plans. One books a fixed package: vehicle, driver, hotels and meal stops all decided before the journey begins. The other rents a scooter, keeps the map app open and changes course by the hour. Software teams face the same fork when they decide how delivery work should be organised, and both routes have names. The older route is the central ops desk that handles everything through tickets. The newer one is PlatformOps, where a dedicated team runs an internal developer platform as a product that other teams serve themselves from.
What PlatformOps actually is
PlatformOps is the operating half of platform engineering. The platform team builds and runs an internal developer platform — one curated bundle of shared capability: pipelines, templates, clusters, observability — and then treats it the way a product team treats its product. That means service levels, support tiers, versioned upgrades and, eventually, retirement dates for anything that ships.
CNCF’s own guidance says a platform should stay optional and composable — diplomatic language for “nobody gets drafted onto one”. DORA frames platform engineering as a sociotechnical discipline: the point is shared tooling plus the working habits around it, not just a pile of servers. Vendors, meanwhile, use the label loosely — plenty of products call themselves platforms when they are really dashboards — so a little scepticism about packaging is healthy. For a fuller definition, the Ops Atlas PlatformOps entry maintained by xOps School is a solid reference point.
How the traditional ops desk works
The model most of us grew up with resembles a railway booking counter. Developers finish code, then file a ticket asking for an environment, a deployment or a firewall rule. The ops team works the queue: prioritise, execute, close. It is orderly, auditable and familiar, and for a single team it works fine.
Trouble starts with scale. Every request waits in line behind everyone else’s. Knowledge concentrates in a few tired heads. Developers start treating the queue like a vending machine — insert ticket, wait, receive — and never learn anything about the machinery on the other side of the counter. DORA lists this pattern, often called ticket-ops, among the classic anti-patterns of platform work. It optimises for control, not for flow, and flow is what delivery teams feel.
Where PlatformOps and the ops desk differ
On paper both models promise “the same shared services, done properly”. The difference sits in five uncomfortable places:
- Who moves work forward. Under a traditional desk, the ops group pushes every change on the requester’s behalf. Under PlatformOps, application teams pull what they need from a self-service catalogue, at the moment they need it.
- What the platform team owns. Platform teams own interfaces and experience — the portal, templates, pipelines, golden paths. Raw compute, network and storage stay with the infrastructure providers underneath.
- How support is promised. A ticket queue gives the requester no commitments beyond “we’ll get to it”. A product-run platform publishes an SLO for each capability and a stated support tier, so teams know what “broken” means and how fast it gets fixed.
- How change reaches users. Ops desks change things through change boards and maintenance windows. Platform teams ship a new template version, announce it, and publish a deprecation date for the old one.
- Who carries the pager. The pager follows ownership: app teams answer for the services they shipped, while the platform crew answers for the machinery it runs. The old arrangement quietly funnelled every 2 a.m. call towards one central group.
Support tiers, in practice
A support tier is a promise with edges. A typical split looks like this: the flagship pipeline gets round-the-clock cover with a response target measured in minutes, a newer template in beta gets best-effort help during office hours, and anything heading for retirement gets documentation and a migration guide instead of a fix. Publishing that split sounds trivial. In practice it ends the constant negotiation, because consumers can see what they are entitled to before they ask.
Where people get PlatformOps wrong
The most common mistake is treating it as a rebrand. Thoughtworks has warned for years that relabelling an existing ops group without changing how work flows is cosmetic — fake transformation with new letterhead. If the same engineers still take tickets in the same queue, nothing has changed except the name on the door and the slide deck.
The second mistake is assuming a portal equals a platform. A web front end bolted onto a ticket queue is still a ticket queue, just with a search box. The real shift is the operating model behind the glass: versioned capabilities, published service levels, and a team that measures whether other teams actually succeed with the tooling rather than counting tickets closed.
What each model costs you
A traditional desk is cheap to start and expensive to scale. Every new project adds queue depth, and queue depth adds waiting, and waiting is invisible on any budget spreadsheet until a launch slips. PlatformOps is the reverse: it demands an upfront investment and only pays back once several teams with repeated needs pull from the same capabilities.
Field experience has produced a rough threshold: do not build a platform at all below about three teams, unless those teams keep asking for the same things and you can fund the effort for two years or more. Below that line, a well-kept wiki page with runbooks and a couple of shared scripts can be the entire platform — and that is a perfectly honourable answer. Small shops that skip the ceremony are not behind; they are correctly sized.
There is also a failure mode on the new side. DORA’s research has found that a mismanaged platform can actually lower both throughput and stability, usually when it is forced on teams or left unowned after launch. The model is not magic; misapplied, it is just a slower queue with better branding.
One more angle settles most debates: count how often the same request reappears. If “set up a staging environment” has been filed eleven times this year by four different groups, the queue is not doing work — it is repeating work. Repetition is precisely the signal that a capability should exist once, maintained as a product with an owner, instead of being re-performed as a favour every quarter.
Choosing between the two
Three questions settle most cases. First, how many teams would realistically consume shared capabilities — three is the honest minimum, not the aspiration? Second, do those teams keep requesting the same handful of things, pipelines and environments and observability, or one-off favours that will never repeat? Third, is leadership willing to fund the platform as an ongoing product, with a roadmap and a review cycle, rather than as a one-off project that ends at launch?
Two or more yeses point towards PlatformOps. A single team, or requests that never repeat, point towards keeping a lean ops desk and putting the saved money into documentation.
Travellers recognise this trade-off immediately. A fixed package removes decisions but locks the itinerary; a self-drive trip demands more from you and returns freedom with interest. The same preference decides the ops question, and the same logic shows up when you plan how to see a state like Bihar — an organised food trail through the city’s claypot curries and old confectionery lanes versus an unplanned drive past rural farmsteads and green stretches. Even renting a scooter for a run through Colombia’s back roads runs on the principle that matters here: shared, well-maintained infrastructure, used freely and paid for collectively.
The practical verdict
Neither model wins on ideology. The ticket desk survives because control sometimes matters more than speed — regulated environments, tiny teams, infrastructure that changes once a year. PlatformOps wins wherever many teams keep needing the same well-trodden paths, because self-service with published service levels turns waiting into a choice rather than a condition.
If you switch, switch deliberately: keep the on-call split honest, publish the support tiers before anyone asks, and retire old routes publicly instead of letting them rot. And if you stay small, stay small proudly. The ops desk that answers in ten minutes beats the fancy platform that answers next week, every single time.
