Aviation never developed a movement called NoOps, though it had every incentive to try. Autopilot grew up inside airliners decades ago, flight management computers followed, and still no airline has walked into a regulator’s office to announce that it retired its operations staff. The industry automates relentlessly, yet it rosters crews, signs dispatch releases, and staffs maintenance lines around the clock. Viewed from a cockpit seat, the software industry’s long argument over the term looks less like a roadmap and more like a debate about who signs the release.
This is a state-of-the-term review, written for readers who fly or hope to, and it follows the word NoOps from its 2011 debut to the agent-driven present. The short version: the operations never left; they changed hands, changed clothes, and started answering to new names. The details are where the lesson lives, and the details are what this piece keeps.
How the NoOps Conversation Started
In February 2011, the Forrester analyst Mike Gualtieri made an argument built to travel: DevOps, he said, was a step in the wrong direction, and developers should never again need to negotiate with an operations specialist. Two months later his own firm’s report softened the position, recasting the idea as a reinforcement of DevOps rather than a rebellion against it. A provocation and its retraction inside one quarter set the pattern this term has followed ever since.
Netflix supplied the most credible flight test a year later. Adrian Cockcroft, then the company’s cloud architect, applied the label to an arrangement in which developers owned both the deploy button and the pager. John Allspaw, who had led operations at Etsy, offered the sober counterpoint: nothing had been eliminated, only reorganised. Reliability engineers have been citing that reading ever since, because it matches what actually happens when a company deletes its ops org chart. The work does not evaporate; it gets redistributed, usually toward the people least trained to carry it. For a fuller account of the history and the modern framing, the Ops Atlas entry on NoOps is the reference we hand to colleagues.
What NoOps Actually Claims
Strip the slogans and the definition is modest. NoOps is an aspiration: the goal of purchasing and automating operational work so completely that nobody needs to hold an operations job title. Two meanings circulate. The practical reading says a company can operate without hiring operators because the duties have been purchased from vendors or folded into automation. The stronger reading, sometimes labelled true NoOps and frequently paired with AIOps, pictures information technology running itself while nobody touches anything. The first is a staffing decision. The second is a prophecy, and prophecies make poor architecture documents.
There is a third reading worth naming for an aviation audience, because it is the one airlines have quietly practised for decades: automation changes the shape of the work while the accountability stays put. A flight management computer removed the routine of celestial arithmetic from a navigator’s job description; it did not remove the captain’s responsibility for arriving at the correct waypoint. Software teams discovered the same law, one migration at a time.
The Serverless Detour
Between 2016 and 2018, serverless platforms gave the term a second life. If somebody else runs the servers, the argument went, the ops function is finally gone. Charity Majors and the Cloud Native Computing Foundation rejected that claim publicly, and the foundation’s own whitepaper states the matter plainly: choosing serverless does not make servers, or the people who understand them, disappear. A 2019 Berkeley study came closest to the enthusiast position, finding that serverless absorbs nearly all system administration chores, yet the same study cautioned that costs become difficult to forecast and that lock-in deepens with every function deployed. Both halves of that finding proved durable, which is exactly why it reads like a weather report rather than a sales brochure.
The NoOps Scoreboard in 2026
The newest chapter belongs to agents. Amazon’s DevOps Agent went fully general in March 2026, and Microsoft brought an SRE Agent to Azure. Both shorten investigation work during outages, which is a genuine gain for any on-call rotation. Note what Microsoft recommends for production incidents, though: run the agent in review mode, with a person reading and approving its proposed changes. Somebody must own each agent’s permissions, and somebody must own its mistakes. That is not the disappearance of operations. That is operations reorganised one more time, with the pager wearing a new jacket.
It helps to be specific about where the duties land once a team stops staffing them. The usual destinations read like a crew roster of their own:
- the cloud provider, which absorbs hardware, patching, and facility work;
- an internal platform group, which turns raw services into paved roads;
- product teams, who inherit the pager alongside the deploy button;
- automation code, which silently takes on maintenance of its own;
- whoever manages the vendors, a job that grows with every contract signed.
Notice that five slots on that list are still filled by people. A pilot reading it will not be surprised. Automation Redefined the seat, not the responsibility — and the industry that prints “pilot” on a uniform has never once confused the two.
The NoOps Maturity Ladder
Teams that track this seriously describe a ladder with five rungs, and the climb is done with artefacts rather than announcements.
- Rung 0: NoOps by assertion — the memo, with no evidence behind it.
- Rung 1: a written register of every recurring operational duty.
- Rung 2: a named owner for each duty, human or automation.
- Rung 3: failure rehearsals on a schedule, not after the fact.
- Rung 4: low-ops by design, with exit estimates priced before they are needed.
The top rung is the tell. Even the most committed framework declines to claim the work is gone; it settles for the work being visible, owned, and deliberate. An airline would recognise the format immediately. Nobody calls a hangar “maintenance-free” because a contractor performs the inspection.
Why This Trend Matters to Aviation Readers
Flight schools, charter operators, and exam-prep portals now run on rented software: scheduling systems, learning platforms, payment processors, student-record databases. Every one of those vendors carries a slice of the operation, and none of them carries all of it. The questions NoOps raises — who answers the pager, who verifies the backups, who reviews the agent’s suggestions before they ship — are the same questions a chief instructor asks before any new tool touches cadet records. A booking engine that goes down on the morning of a ground-school intake costs real tuition revenue, and the vendor’s apology will not refund it.
Readers who want the surrounding disciplines can start with our guide to learning site reliability engineering skills, then continue with this overview of practical AIOps knowledge for IT operations. Applicants mapping their own runway may also find the aviation entrance exam guide useful, since the operational judgement it tests is the same judgement this debate is about.
The verdict after fifteen years reads like a dispatch endorsement: operations move up the stack and into new hands; they do not disappear. A team that skips the discipline anyway meets the work regardless, usually at the worst possible hour. Aviation never confused automation with absence. Software is finally learning the same sentence, and the industry that signs crew rosters every morning could have told it so.
