{"id":11609,"date":"2026-10-20T07:30:00","date_gmt":"2026-10-20T07:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11609"},"modified":"2026-10-20T07:30:00","modified_gmt":"2026-10-20T07:30:00","slug":"platformops-rollout-team-diary","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/platformops-rollout-team-diary\/","title":{"rendered":"A PlatformOps Rollout, Told as a Team Diary"},"content":{"rendered":"

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 \u2014 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.<\/p>\n

January: PlatformOps begins with an audit, not a build<\/h2>\n

Week 3, entry from Meera, staff engineer, temporarily “platform lead”:<\/em> 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 \u2014 CI templates, the deploy pipeline, the feature-flag service, eleven internal libraries \u2014 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?<\/p>\n

February: the catalogue lies<\/h2>\n

Week 6, entry from Tomaso, platform engineer:<\/em> 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 \u2014 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.<\/strong> We now do the log comparison quarterly. The two surprise consumers were less upset about being “discovered” than relieved someone finally knew they existed.<\/p>\n

Week 8, Meera:<\/em> 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.<\/p>\n

March: giving the pipeline a promise it can keep<\/h2>\n

Week 10, entry from Priyanka, SRE:<\/em> The deploy pipeline is our most-used capability and had no objective \u2014 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 \u2014 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.<\/p>\n

Week 12, Priyanka:<\/em> Reading week. Borrowed the idea of testing consumers against the objective from Google’s SRE book \u2014 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.<\/p>\n

April: the deprecation that almost sank trust<\/h2>\n

Week 15, entry from Tomaso:<\/em> We announced the old Ruby deploy scripts would be “deprecated soon” and moved on. Weeks passed. Nothing else happened \u2014 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 \u2014 the difference was a person whose job included the migration, not merely the memo.<\/p>\n

Week 17, Meera:<\/em> 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.<\/p>\n

May: who answers the pager, decided in one page<\/h2>\n

Week 19, entry from Priyanka:<\/em> 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 \u2014 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.<\/p>\n

Week 21: the view from a customer team<\/h2>\n

Entry from Hana, developer on the storefront team:<\/em> Asked to give the outside view. Before this year, my honest relationship with shared tooling was avoidance \u2014 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 \u2014 which is, I think, the entire product.<\/p>\n

June: what a PlatformOps review actually looks like<\/h2>\n

Week 23, entry from Meera, for the CTO:<\/em> 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 \u2014 the experiment framework somebody built in 2023 \u2014 we marked retired-with-no-replacement, and nobody objected, which tells you what we needed to know.<\/p>\n

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 \u2014 the catalogue lives in a well-organised internal site and a spreadsheet until scale demands more.<\/p>\n

The transferable parts, without the fiction<\/h2>\n