Case studies usually get sanitised into five bullet points and a screenshot of a dashboard. That format hides the parts a team actually learns from — the weeks where nothing ships, the deprecation that almost caused a mutiny, the meeting where someone finally asks who owns the thing everybody depends on. So here is a PlatformOps rollout told the honest way: a composite diary from a fictional-but-realistic payments company. Kestrel Pay processes card transactions for mid-market retailers; the engineering group numbers sixty across nine product teams; and in January their CTO decided the internal platform had to stop being a pile of folklore. Names are invented; the events are ones every practitioner will recognise.
January: PlatformOps begins with an audit, not a build
Week 3, entry from Meera, staff engineer, temporarily “platform lead”: The CTO gave us six months and two engineers. My first instinct was to start building the big service catalogue. Sat on it for a day, then did the boring thing instead: listed every shared capability we claim to run — CI templates, the deploy pipeline, the feature-flag service, eleven internal libraries — and wrote an owner and a state against each. Forty-one items. Nine had owners. Not one had a written service level. We spent the month classifying everything on a simple ladder: proposed, alpha, beta, generally available, deprecated, retired. The ladder alone was worth the month, because it forced a conversation per component: is this alive, and who answers for it?
February: the catalogue lies
Week 6, entry from Tomaso, platform engineer: Task of the month: verify the flag service’s declared consumers. The self-service record says five teams use it. I pulled two weeks of access logs and counted callers. Seven. Two product teams had wired themselves in during last year’s crunch and never registered — which meant when we upgrade the service, we break them silently. This is the quiet lesson of catalogues: self-declared data is a rumour until you reconcile it with logs. We now do the log comparison quarterly. The two surprise consumers were less upset about being “discovered” than relieved someone finally knew they existed.
Week 8, Meera: Presented the reconciliation to the leads. The room went quiet in a useful way. If the directory of who-uses-what is wrong, then every change process built on it is theatre. Fixing the data became everyone’s priority, which is how we got budget for the next part.
March: giving the pipeline a promise it can keep
Week 10, entry from Priyanka, SRE: The deploy pipeline is our most-used capability and had no objective — just vibes and a status page nobody trusted. We set one: 98% success for deployments that pass pre-flight checks. Then came the arithmetic that changed how the team thinks. At our volume, roughly 2,400 pipeline runs a month, 98% means we are allowed 48 failures before we are objectively off-target. Forty-eight sounds enormous — until you count a bad Tuesday. The number did two things. It converted “the pipeline feels flaky” arguments into countable facts, and it gave us a budget to spend deliberately rather than an aspiration to feel guilty about.
Week 12, Priyanka: Reading week. Borrowed the idea of testing consumers against the objective from Google’s SRE book — the Chubby lock service team used to run deliberate synthetic outages to check that clients handled unavailability the way the service level implied they must. We wired chaos drills into staging: when we break the pipeline on purpose, which teams notice, how fast, and does their fallback behave? First run, four of nine teams had no fallback at all. That is not a pipeline problem; that is a dependency-hygiene discovery, and it only surfaced because we tied the drill to a published objective.
April: the deprecation that almost sank trust
Week 15, entry from Tomaso: We announced the old Ruby deploy scripts would be “deprecated soon” and moved on. Weeks passed. Nothing else happened — no dates, no help, no consequence. Usage did not move an inch. Warnings without staffing are just guilt broadcast at scale; the software industry’s own hard-won lesson is that announcements alone almost never migrate anyone. So we re-ran the deprecation properly: a named engineer ran office hours twice a week, wrote the migration guide against real teams’ repos, set a compulsory cutoff for the final switch, and gave every team a booked slot. It closed in five weeks. Same script, same decision — the difference was a person whose job included the migration, not merely the memo.
Week 17, Meera: Lesson recorded in the team handbook: staffed deprecation or no deprecation. An unstaffed one just teaches the organisation to ignore platform emails, and that is a debt with interest.
May: who answers the pager, decided in one page
Week 19, entry from Priyanka: The ambiguous part until now: a deploy fails at 2 a.m., whose phone rings? We wrote the split down. Product teams carry their own services end to end. The platform team carries platform components — the pipeline, the flag service, the catalogue itself. No shared rotation, no relay races at 2 a.m. Sounds obvious written down; it took until May to stop arguing. The practical test: any incident where the first twenty minutes are spent establishing whose incident it is, means the boundary document failed.
Week 21: the view from a customer team
Entry from Hana, developer on the storefront team: Asked to give the outside view. Before this year, my honest relationship with shared tooling was avoidance — I kept a private checklist because the official one was always out of date. What changed was not the tools; they were mostly the same. It was that things started carrying names and promises. When the pipeline says 98% and publishes what happens when it misses, I can plan a release window around it. When the deprecation email had a human attached, I got my questions answered in one office-hours session instead of three weeks of chat ping-pong. My team still ships our own services and still carries our own pager. We just spend visibly less of our week on guesswork — which is, I think, the entire product.
June: what a PlatformOps review actually looks like
Week 23, entry from Meera, for the CTO: Six-month review, one page per capability. Headlines: the pipeline is at GA with a published 98% objective and a budget we track monthly; the flag service is at GA after its consumer list was reconciled against logs; the Ruby scripts are retired, with the migration guide kept as a museum piece. Two internal libraries got moved to deprecated with staffed migration plans attached. One capability — the experiment framework somebody built in 2023 — we marked retired-with-no-replacement, and nobody objected, which tells you what we needed to know.
The numbers the CTO asked for and got: consumer lists now verified rather than assumed, pipeline reliability measured against a target instead of a mood, and every one of the forty-one capabilities carrying an owner and a lifecycle state. None of it required the grand portal we assumed in January — the catalogue lives in a well-organised internal site and a spreadsheet until scale demands more.
The transferable parts, without the fiction
- Classify before you build. The lifecycle ladder (proposed through retired) turns “what do we even have?” into a series of small, answerable questions.
- Reconcile declared consumers against real callers. Self-service records drift; logs do not. The gap between them is your hidden blast radius.
- Turn service levels into budgets. A percentage target plus real traffic yields a countable failure allowance — arguments end and drills become testable.
- Test your consumers on purpose. Deliberate outages in staging, tied to the published objective, expose missing fallbacks while they are still cheap.
- Never deprecate unstaffed. Cutoffs and memos migrate nobody. A named engineer with office hours migrates everybody.
For the wider operating model these diary entries sit inside — product thinking, golden paths, architecture layers — the Ops Atlas PlatformOps reference is the best single follow-up we know. And because the reliability half of this story leans on SRE craft, our own guides go deeper: SRE best practices for high-availability platforms, how DevOps and SRE roles divide implementation work, and incident management reshaped by SRE practices.
Kestrel Pay is fictional. The sequence — audit, reconcile, commit, drill, deprecate with a human face — is not. If your rollout diary currently has no entries, January is a good month to write the first one.