Readers of this site understand something most technology commentary misses: a good outcome depends less on the brilliance of a single procedure than on the quality of the journey around it — the assessment, the plan, the follow-through, the verification. That belief is exactly what one fictional but faithfully drawn organisation, the Meridian Care Group, carried into its own technical crisis. Meridian runs twelve hospitals across four countries, and its software teams were drowning. The way they applied PlatformOps to climb out reads like a patient journey, which is precisely why it is worth telling here.
The Consultation: PlatformOps Begins With Listening
Meridian’s first move was not a purchase. Their newly appointed platform lead, Amara, spent her first month the way a good consultant physician spends a first consult: listening. Five product teams, five structured conversations, one question — where do your weeks disappear? The pattern that emerged was familiar and corrosive. Every team maintained private build scripts. Two had built matching deployment-approval workflows without either knowing of the other’s existence. Requests for anything shared waited behind a ticket queue measured in days. Amara’s write-up recommended PlatformOps in substance if not in name: run the shared tooling as a managed service with the same seriousness the group applied to clinical services.
Diagnostics and the Treatment Plan
The diagnostic phase produced an inventory — every shared capability Meridian already operated, each tagged with an owner or, more often, with nobody. The treatment plan followed as a two-page charter built on the thinnest viable platform principle: offer only those shared capabilities that erase work the teams were duplicating, and nothing beyond them. Two commitments went into the document. Adoption would be voluntary — teams join because the service shortens their work, echoing the CNCF’s position that platforms are optional and composable. And every published capability would carry three attachments from day one:
- a named owner, a person rather than a group inbox
- a lifecycle stage, kept honestly current
- a service level the team was prepared to be measured against
The board asked what would happen if teams declined to adopt. Amara’s answer — then the platform will have failed on its merits and deserves to — unsettled them into approval.
The Procedure: One Golden Path, Handled Slowly
Reconstruction began with a single golden path: one template feeding one pipeline, the whole journey from source code to production watched end to end. The design partner was the appointments-booking team, chosen for the same reason surgeons prefer an index case — a well-understood, low-drama service where complications, if any, would be instructive rather than catastrophic. For a month, the pair worked in tight collaboration, every snag logged and fixed in public. By the end, the booking team’s deployment lead had stopped asking for exceptions. That silence was the first real evidence the path worked. Nothing about the underlying pattern was novel; the novelty lay in refusing to build ten capabilities at once and finishing none of them properly.
PlatformOps Rehabilitation: The Beta Wards and the Dip
Widening to a two-team beta brought the predictable setback. Delivery metrics sagged for six weeks — teams migrating, habits rewriting themselves — and a hospital-group director asked, reasonably, whether the programme was failing. Amara presented the J-curve documented in DORA’s research: performance typically dips during migration, then recovers beyond baseline if operations hold steady. She committed to specific recovery markers rather than vague reassurance, and the programme survived its hardest meeting. During rehabilitation the service levels went public, with attainment reported monthly, and the paging boundary was fixed: application teams answer for their services around the clock, the platform team for its own components under its published tiers.
Discharge Planning: General Availability and the First Retirement
General availability at Meridian was deliberately unglamorous. The runbook had been rehearsed against real failures, on-call coverage for platform components was rota-ed, the lifecycle policy from proposal through retirement was published, and — the step most programmes skip — one legacy capability was formally withdrawn, with engineers assigned to migrate its remaining users rather than a notice pinned to a portal. Amara had read the field’s guidance on deprecation: passive warnings move almost nobody; assisted moves work. Twelve months on, the group’s numbers read plainly — first-deployment latency for a freshly created service fell from days to hours, the majority of routine requests fulfilled without any human queue, and service-level attainment reported at board level beside the clinical indicators.
Follow-Up: Verification Beats Self-Declaration
The closing lesson is the one this site’s readers will appreciate most. Six months after launch, Amara reconciled the platform’s service catalogue — entries declared by whichever team registered them — against actual callers found in access logs. A widely shared audit capability claimed five consumer teams; the logs counted seven. Two had quietly wired themselves in without declaring, which meant a breaking change would have blindsided them. Meridian now reconciles quarterly, on the simple principle that declared and actual are different things until verified — the same principle that makes an accreditation check worth more than a brochure, explored in our guide to checking a hospital’s accreditation abroad.
The source discipline itself is documented best in the Ops Atlas write-up of PlatformOps, which records the vocabulary, the three-layer architecture and the day-to-day operating habits Meridian followed. And because choosing wisely is the theme under every layer of this story — for platforms and for patients alike — the questions worth asking before committing are collected in what to ask before surgery abroad, while the value of a structured comparison before any major commitment is argued in how careful hospital comparison protects a surgery journey. Verify first, proceed on evidence, and keep following up: it works for care, and it works for code.