Call them Team Meridian — a composite, assembled from patterns that keep repeating across mid-sized product companies, because the real teams involved prefer their incident records stay private. Meridian built analytics tooling, ran on a managed cloud, employed eleven engineers, and had no operations department to speak of, which they considered a virtue. One January they made it policy. This reconstruction follows their NoOps-by-announcement quarter: what they decided, what genuinely improved, what quietly worsened, and the numbers that eventually told them the truth. The names are invented. The mechanics are not, and every mechanic below appears in more than one company’s postmortem literature, sometimes with the dates still attached.
The NoOps Announcement
It took four minutes at the Monday all-hands. The founding engineer had read that the future of infrastructure was NoOps — a term dating back to a 2011 analyst prediction that developers would stop needing operations people — and concluded that Meridian had simply arrived early. (xOps School’s NoOps entry is the sourcing we now use for that history.) Effective immediately: no operational workstream, no on-call rota, no maintenance windows. The word “aspiration” never appeared in the announcement, though it is the word the industry uses for NoOps: an end state you grow toward by buying and automating, not a policy you enact by memo. Under the maturity scales reliability folks use, Meridian had just performed the one move that sits at the very bottom rung — declaring the state without building any of its preconditions. Nobody in the room objected, which the retrospective would later identify as the second decision of the quarter.
Six Reasonable Weeks
Honesty requires reporting that the first six weeks went well, because they did. Deployment frequency rose; the ticket relay that used to sit between developers and their own code was gone, and nobody mourned it. The managed database absorbed patch cycles. Costs were flat. Two engineers independently said some version of “why did we ever have a process for this”, and they were largely right — for workloads that are standard and lightly loaded, managed services plus automation genuinely do absorb the routine load. This part of the story deserves emphasis because it is the part every NoOps pitch advertises, and in Meridian’s case it was real. The problems, when they came, came from the work that had not been absorbed by anything at all. The retrospective put a finer point on those weeks: the improvements were real, measurable, and confined to the deploy path, while everything outside it — security posture, recovery capability, after-hours response — had neither improved nor degraded but simply stopped being observed. Unobserved is not the same as fine. It is the same as unmeasured, which in an evidence-led write-up counts as a finding in its own right.
The Week the Industry Supplied the Lesson
In week seven, Meridian’s tech lead studied a publicised wave of attacks on a well-known data platform. The detail that caught her attention: the provider itself had not been breached. The compromised accounts were customers who had never enabled multi-factor authentication, never rotated their access keys, never configured network allow lists. In the vocabulary of the responsibility matrix, the provider’s side was intact and the customer’s side — identities, configuration, access policy — had been wide open. Meridian ran the same check against itself and found the identical posture: a production account with one long-lived key, created during the migration, owner unknown. The discovery cost nothing that week. The team understood, correctly, that they had been shown their future rather than charged for it, and the near-miss framing mattered: nothing had been stolen, no customer had called, no regulator had written. By every dashboard Meridian maintained, week seven was a triumph. The breach postmortems they read that week shared one structure — a provider exonerated, a customer configuration convicted — and Meridian’s own configuration matched the guilty pattern with uncomfortable precision.
Where the NoOps Work Had Actually Gone
The audit that followed mapped every operational duty against its new home, and the resulting table explains most of this article. Genuine displacements: hardware upkeep, hypervisor patching, physical failover — all sitting comfortably with the provider. Automation candidates: environment provisioning, certificate renewal, dependency updates — scripted within a fortnight and better than the manual versions. But three categories had gone nowhere. Data stewardship — retention rules, restore tests, deletion requests — remained with Meridian, unowned. Identity hygiene — key rotation, permission reviews, MFA enforcement — remained with Meridian, unowned. And the fourth-wall duties, the ones that arrive at inconvenient hours, had not been displaced but dissolved: no rota, no pager, no arrangement of any kind. The migration had moved perhaps a third of the operational surface. The memo had assumed all of it.
The Quiet Numbers That Told the Truth
Reliability measurement exists precisely for moments like this, and two numbers did the talking. The first was page load. Google’s published guidance caps alerts at roughly two per twelve-hour shift per engineer, on the logic that more pages train humans to ignore pages. Meridian had zero pages for seven weeks — not because nothing happened, but because nothing was watching. Their alerting stack still sent notifications; the destination was a mailbox nobody opened. Silence, it turns out, is not an operations strategy, and it reads very differently in retrospect than it did in the all-hands. A monitoring stack pointed at an unread mailbox is indistinguishable from no monitoring at all — right up until the moment the distinction matters. The second number was restore readiness. When the auditors asked when a full restore had last been proven, the honest answer was never — the managed platform’s own backups were assumed to be a recovery plan, which the cloud providers’ documentation explicitly declines to claim. Best practice puts a proven restore within the last ninety days. Meridian’s figure was unbounded in the wrong direction, which is a polite way of saying infinite.
What Changed Next Quarter
The corrections were neither dramatic nor expensive, which is the encouraging part of the story:
- Named owners. One engineer holds data stewardship, another identity hygiene, and the names sit in a doc the whole team can see.
- A minimal rota. Two weeks per engineer per quarter, comped with recovery time the following week.
- Identity cleanup. The long-lived production key was replaced with rotated credentials behind MFA and an allow list, closing the gap the industry case study had previewed for free.
- Quarterly drills. Failure practice joined the calendar, starting with a restore rehearsal that surfaced three undocumented assumptions in its first hour.
On the maturity scale, Meridian would now score themselves honestly low but climbing — evidence over assertion. For the two engineers most affected by the old reorganisation, the path mattered as much as the policy; guidance like moving from sysadmin and support into DevOps work had shaped how the team thought about ownership redistribution in the first place.
The lesson we take from Meridian, and the one we would stake evidence on: NoOps by announcement produces the operations anyway — displaced into shadows, unowned, and repriced at incident rates. The same work, named and owned and rehearsed, costs a fraction of that. Teams weighing the move should audit their duty surface first, keep the quiet numbers visible, and let the craft of becoming a DevOps expert absorb what automation cannot. Ambition is welcome; growth from junior to senior engineering has always worked this way — by acquiring responsibility, never by announcing its abolition.