A warehouse lead I know said something last week that deserves a wider audience. Her team had moved onto a managed lakehouse, scheduled every ingest, wired alerts into chat, and automated the failover drills. “So we’re basically NoOps now, right?” she asked. It is a good question with an embarrassing answer: nobody on her team had ever counted the operations they still perform. They had a feeling, not a number. This post is the counting method we walked through together, written for data teams who keep hearing about NoOps and want evidence before they shrink anything.

The core idea behind NoOps is simple to state and hard to measure: automate and buy enough of the operational burden that no dedicated operations function is required. Whether you are close depends on arithmetic, not vibes. Here are the five steps.

Step 1: Inventory What a Pipeline Owes You Each Month

Pick one service — say, the streaming ingest that feeds your revenue dashboards. List everything that must happen for it to survive a month: certificate renewals, dependency upgrades, capacity reviews, backfill runs, access audits, the small schema drifts that arrive every time an upstream team renames a column. Write each item down with a frequency. The point of this step is not elegance; it is honesty. Most data teams discover three or four duties nobody has formally owned since the person who built the pipeline changed jobs.

Keep the inventory in a document the whole team can edit. A duty that is not written down cannot be automated, delegated, or defended when someone asks why the pipeline died on a Sunday.

Data work carries a few duties that pure software services never meet. Backfills arrive when a restatement changes six months of history. Late-arriving events need reconciliation windows. Retention rules mean old partitions must be pruned on a legal schedule, not a convenient one. If your inventory skips these because they feel occasional, you will undercount badly — the occasional duties are exactly the ones that page people at midnight.

• Restatement backfills, whenever upstream corrections rewrite history
• Late-arrival reconciliation windows, checked on their own calendar
• Retention pruning, driven by legal schedules rather than convenience
• Schedule drift reviews, after every upstream team ships something creative

Step 2: Add Up the Residual Work in Hours

Next, attach hours to every item — the time a competent person actually spends, including the interruptions. Add the pages too, averaged over the last few months. The total is your residual work: the operational load that remains after every migration and every automation you have already bought. Practitioners who track this number define it as the sum of duty hours plus page hours, per service, per month, and it is the single most useful figure in the whole exercise.

To make it concrete: a modest, well-run service often lands near thirty-nine hours a month of real work — roughly a third of one engineer. That sounds wonderfully small. Hold the thought, because the next step is where the feeling of “nearly no ops” usually collides with the rota.

Step 3: Price the Coverage, Not Just the Work

Here is the trap. Thirty-nine hours of work per month does not mean one third of a hire, because work does not arrive in tidy nine-to-five blocks and somebody must be reachable whenever it arrives. Coverage is a separate quantity: the person-hours required to guarantee a qualified human is on call across the whole period. The same service that needs thirty-nine hours of labour can demand about one hundred and ninety-five person-hours of monthly coverage once nights, weekends, and holidays are included — five times the work itself.

And coverage has a ceiling per person. If you cap on-call burden at a quarter of anyone’s month — a humane and common limit — twenty-four-seven coverage from a single site needs around eight people. That estimate traces back to Google’s published thinking on staffing site reliability work, and data teams ignore it at their peril. One engineer with a laptop and good intentions is not a rota; it is a burnout schedule.

Step 4: Read the Two Numbers NoOps Automation Moves

With work and coverage measured, two health metrics tell you where automation will actually pay. The first is page load: how often your people get interrupted. Google’s published cap works out to roughly two interruptions in a twelve-hour stretch — past that point, whoever holds the phone has stopped doing their day job and started bracing for the next alert. If your ingest pages six times a night, that pattern — not headcount — is the thing to fix first, and it is usually a flaky dependency or a noisy threshold rather than a staffing problem.

The second is quota headroom, defined as one minus peak usage divided by quota. It answers a question coverage rosters never will: how close is this service to the provider’s ceiling? A pipeline sitting at ninety-five percent of its throughput quota during month-end close will page no matter who is on call. Headroom is a design decision, and it belongs on the same dashboard as the rota.

Step 5: Chase Unowned Duties to Zero Before You Chase NoOps

Go back to your Step 1 inventory and mark every duty with a name. The share of duties with no name is the number that should scare you — the target, quite simply, is zero. Unowned work does not disappear because the warehouse is managed; it hides inside whichever engineer happens to notice the failure first. Teams that measured this share have found duties sitting unclaimed for years: a legacy export nobody dares cancel, a credentials rotation only one contractor understands.

Closing those gaps is unglamorous work — write the runbook, assign the owner, automate the third repetition. But it is precisely the work that makes aggressive automation safe later. In our experience writing about real-world DataOps implementations, the teams with the calmest pipelines are rarely the ones with the flashiest tooling; they are the ones where every recurring task has a home.

What Your Numbers Will Probably Tell You

Run the five steps on one service and a pattern usually emerges. Residual work is small and shrinking — automation genuinely has eaten most of the old toil. Coverage is stubborn, because interruptions refuse to respect office hours. Page load and quota headroom reveal one or two specific fixes with outsized payoff. And the unowned share is larger than anyone guessed, which is the real reason the “basically NoOps” feeling never survives contact with an incident.

The conclusion for most data teams is not “hire more” and it is definitely not “declare victory”. It is a quieter claim: operations has been displaced — into the provider, into your automation code, into the on-call rota your product engineers now share — and displaced work still deserves measurement. If you run multi-cloud estates, the staffing question gets sharper, not softer, as our piece on multi-cloud data operations describes; every additional provider adds another intersection of quotas, regions, and support tiers to cover.

One last nudge on cadence: rerun the counting every quarter. Residual work drifts as services age, coverage changes whenever the team grows or shrinks, and the duty that took ten hours in January may take two after a good automation lands — or forty after an upstream team ships something creative. The teams that treat this as a living measurement, rather than a one-off audit, are the ones whose NoOps ambitions stay anchored to the actual workload rather than to a memory of one.

Measure first, then automate with intent: that is how a data team earns the right to say “no dedicated ops” and mean it. When your team is ready for the deeper framework — the full metric set, the failure stories, and the maturity ladder — this detailed NoOps reference is the best starting point we have found, and it pairs naturally with our guide to keeping real-time analytics pipelines intact.