How to Run a NoOps Feasibility Check in Five Steps

How to Run a NoOps Feasibility Check in Five Steps

Pilots would never launch on a plan built from a feeling, yet companies adopt exactly that kind of plan when a vendor promises them NoOps — a platform so thoroughly managed and automated that no dedicated operations role remains. The claim is sometimes achievable and often not, and the difference is discoverable in advance with about a week of honest work. This article lays out the check we would run before automating another duty, disbanding a role, or signing the next managed contract: five steps, each producing one piece of evidence, ending in a decision you can defend to anyone who audits your reasoning. Readers who have calculated the return on flight training will recognise the discipline immediately — same method, different subject: inventory the costs, measure the capacity, and let numbers rather than enthusiasm make the call.

Step 1: Count What You Actually Do Today

Open a document and list every recurring operational task the platform demands, with its frequency and whoever currently performs it. The honest version includes the invisible work: certificate renewals, dependency upgrades, access reviews, backup checks, invoice scrutiny, the quarterly scramble when a provider changes an interface. For a typical small platform the list lands between fifteen and thirty items. The two numbers to extract from the inventory are the monthly hours the tasks consume and the count of tasks with nobody named. Both numbers will matter later, and the second one is usually the unpleasant surprise — unowned duties are how incidents begin.

Run the listing as a team session rather than a solo memory test, and keep two people honest with one question: what broke last time, and who noticed first? The answer usually surfaces two or three tasks that appear in nobody’s job description yet absorb somebody’s evening whenever they fail. Estimating hours per task takes minutes at this stage; precision is unnecessary, because a figure within twenty percent is easily accurate enough to drive the decision the check exists to inform.

Step 2: Split the Bought From the Owned

Mark each item as either transferred to a provider or still yours. The dividing line matters more than most migration brochures admit. Execution moves when you buy a managed service — the patching, the housing, the power — but four categories of judgement never move, in any service model: what the data is and how long it is kept; which identities may sign in; how the platform is configured; and who may access what. Your inventory should therefore show a residue of duties that survive every purchase decision. If Step 1 found no such residue, the inventory was not honest; go back and look for the settings nobody has reviewed since the founder left.

Typical residents of the residue: deciding which former employees’ accounts are disabled, approving a new integration’s access scope, confirming that a retention rule satisfies the contracts you have signed, and judging whether a configuration change scheduled for the busiest week should wait. None of these appears on a provider invoice; all of them can end up in a regulator’s question. The residue is small, but it is the part that decides whether the arrangement is safe.

Step 3: Compute the Ceiling NoOps Cannot Exceed

Every provider publishes an availability promise, and the tempting error is adopting the best of them as your own. Your users experience the combined effect of every critical dependency at once — hosting, identity, payments, messaging — and the combined figure is always lower than the strongest single promise. Multiply the published numbers for your chain to find the ceiling; three dependencies in the 99.9s typically produce a figure beginning 99.8, before your own code has contributed anything. Whatever reliability your users require, your architecture must bridge the gap between that ceiling and the promise — and bridging work is design and engineering effort, not a procurement line. In practice the bridge looks like queues that absorb a dependency’s hiccups, cached pages that keep serving when a vendor blinks, and a degradation mode that shows students something useful instead of an error. Each of those is a deliberate construction with an owner. This single calculation has ended more hasty no-team plans than every argument combined.

Step 4: Check Headroom and Currency

Two quick ratios finish the technical picture. The first is quota headroom: take one, subtract the peak load divided by the allowance, and the result tells you how far the platform sits from the provider’s ceiling. Thin headroom during your busiest period means interruptions regardless of who is on call, so it is a design finding rather than a staffing one. The second is currency: how close any component sits to its end-of-life date, with mainstream practice keeping at least 180 days of runway. Stale runtimes and exhausted quotas share a property — both fail on their own schedule, not yours, which is precisely what an operations function exists to prevent.

Step 5: Price the Exit Before You Sign

The final step converts vendor enthusiasm into arithmetic. For each critical service, estimate in working days what a migration to an alternative would cost, including data verification and re-testing, and write the number down with a date on it. The estimate changes behaviour twice: at signing, when it steers you toward vendors with clean export paths and honest support tiers; and later, when the renewal conversation gains a backbone. An unpriced exit is the single most common omission in teams that later describe their provider relationship with the word “stuck”. Revisit the figure annually, because platforms, data volumes, and alternatives all drift.

History supplies the cautionary version: providers do retire products, and their customers inherit a rebuild on somebody else’s timetable. An owner who can produce a dated exit estimate is negotiating from facts; one who cannot is negotiating from hope, and hope has never once moved a renewal discount.

Making the NoOps Call With Evidence

Assemble the five artefacts — the duty inventory, the bought-and-owned split, the ceiling calculation, the two ratios, and the exit price — and the decision usually makes itself. A lean team with spiky load, thin residue, healthy headroom, and clean exits can reasonably run without dedicated operations staff, and the industry’s maturity ladder describes the honest endpoint as low-ops by design rather than a deletion; the bottom rung, by contrast, is the assertion itself, which is what most slide decks sell. Practitioners track the remaining duties with a target of zero unowned, which your Step 1 inventory either supports or refutes. Where your numbers say hire or pause, believe them — and where they say proceed, proceed with confidence.

  • Kept the inventory and ratios somewhere reviewable, with owners named against every surviving duty.
  • Booked a quarterly re-run of the check, since load, vendors, and staff all drift.
  • Attached the exit estimates to the contract calendar so renewals trigger the conversation, not the other way round.

Cost-benefit thinking rarely stops at one decision, which is why the same method scales outward: calculating the return on pilot training applies identical logic to a very different investment, and the salary-versus-cost comparison shows the payback side worked through in full. When you want the complete reference behind the framework in this article — history, metrics, and the failure archive — the Ops Atlas NoOps entry is the source to keep, and for the career-long view of such investments, the career growth analysis extends the evidence-based habit into job planning.