Every “Ops” movement starts as a complaint. DevOps started with developers and system administrators blaming each other for broken releases. Developers wrote code in one silo, operations deployed it from another, and the wall between them turned every release into a negotiation. WorkOps starts with a complaint you have probably made yourself: the work is in one place, the plan is in another, the status report is in a third, and a person is the integration layer between all of them.
The two complaints sound different. Structurally, they are the same problem: a lifecycle chopped into disconnected stages, owned by disconnected teams, with no shared feedback loop. DevOps solved it for software. WorkOps applies the same move to everything else a company does.
This post traces that lineage: where the WorkOps idea came from, why it took years to become practical, and what changed when AI arrived.
One note on the name before we start. Some vendors use “WorkOps” as shorthand for workplace operations: running offices, desks, and hybrid schedules. This post uses the term in its original sense, the operations of work itself: how organisations plan, execute, automate, and improve what they deliver.
2008 to 2018: what DevOps proved
DevOps has a precise origin story. In 2009, John Allspaw and Paul Hammond gave a talk at O’Reilly’s Velocity conference describing how Flickr shipped more than ten deploys a day at a time when most companies shipped a few releases a year. Later that year, Patrick Debois organised the first devopsdays conference in Ghent, and the movement had a name.
What DevOps proved over the following decade matters more than the history:
- Automation across the lifecycle beats heroics inside silos. Continuous integration and delivery pipelines removed the manual handovers where releases used to die.
- The people doing the work should design how it is done. Deployment stopped being the property of a separate operations department.
- Build feedback loops in, do not bolt them on. Monitoring and incident reviews fed directly back into the next development cycle.
- You improve what you measure. Industry research such as DORA (DevOps Research and Assessment) and its State of DevOps reports showed elite teams deploying on demand while others waited months, and gave everyone a common yardstick.
By the mid-2010s, this was no longer controversial. The strange part is what did not happen next: nobody applied the same logic to the rest of the company. Marketing campaigns, client onboarding, internal services, and operations still ran on the old model, with plans in one tool, execution in another, and a human copying status updates between them.
2018: an analyst ports the idea to work itself
In August 2018, Chris Marsh, then research director for workforce productivity at 451 Research (now S&P Global), published a report called “WorkOps: a primer on the new way of working.” His starting point was a language problem: “project management” describes only one narrow type of work, while agile, lean, and DevOps never really broke out of software teams. There was no name for how modern work actually needed to run.
Marsh made the connection to DevOps explicit. In his words, DevOps “looks to create more frequent and dependable development cycles by having automation and monitoring across the lifecycle,” while WorkOps “looks to create more responsive work execution by having intelligent context, workflow automation, collaboration and reporting embedded across the lifecycle.”
“DevOps looks to create more frequent and dependable development cycles by having automation and monitoring across the lifecycle, while WorkOps looks to create more responsive work execution by having intelligent context, workflow automation, collaboration and reporting embedded across the lifecycle.”
Chris Marsh, 451 Research (2018)
Swap “development cycles” for “work execution” and the blueprint carries over almost line by line.
The 2018 report sketched several ideas that still define WorkOps today:
- Work as a continuous loop, not a sequence of projects. Marsh drew work as a figure eight: workflows intersecting across streams, visibility available at any stage, resources inserted and withdrawn as requirements change. Less work has a finite beginning and end; more of it is open-ended and repeating.
- Three nested levels. WorkOps describes organisational execution, TeamOps the local agility of teams designing their own processes, and SoloOps the individual’s ability to self-organise into shifting work communities.
- Decentralisation by design. Instead of a central project office designing processes for everyone, the people closest to the work design and run their own workflows, inside guardrails.
- Honest boundaries. Marsh was explicit that WorkOps does not suit purely creative, unstructured, one-off work, where automation aimed at continuous improvement adds little. In a webinar the same year he summarised the ambition as “agile for modern work beyond software engineering.”
The diagnosis was sharp. The prescription, however, had a missing ingredient.
Why the idea stalled for six years
For roughly six years after Marsh’s report, the tooling could not deliver the vision.
The automation of that era executed rules, not judgment. Robotic process automation could move data between forms as long as nothing unexpected happened. Integration platforms connected records across systems but could not decide what should happen next. The “intelligent” assistants of 2018 transcribed meetings and suggested email wording. All useful, none of it capable of orchestrating work across a lifecycle.
So the market delivered fragments of WorkOps instead: work management tools promised organisation-wide systems of work, workflow builders let business users automate simple approvals, and dashboards multiplied. The pandemic then stress-tested every organisation’s ability to coordinate distributed work and proved Marsh’s diagnosis painfully right. Companies discovered exactly how much of their operation depended on someone walking over to someone else’s desk.
The pattern was familiar from DevOps history. The idea of frequent, reliable releases existed years before the movement took off. What made DevOps real was an engine: version control, automated testing, and CI/CD pipelines mature enough to carry the philosophy. WorkOps was a philosophy waiting for its engine.
The AI turn: from pipeline to orchestrator
The engine arrived with modern AI. Systems that understand context, summarise state, draft next steps, and act across tools can finally do for general work what CI/CD did for software delivery.
That is the premise of the current WorkOps framework, documented in the WorkOps Playbook that I maintain with the Easy8 WorkOps team. The Playbook defines the discipline as “a culture, methodology, and set of practices that integrate work planning, execution, automation, and performance optimisation into a unified, continuously improving system.”
A culture, methodology, and set of practices that integrate work planning, execution, automation, and performance optimisation into a unified, continuously improving system. See the full framework with the 8-phase loop.
The framework arranges work as an infinity loop with eight phases. The mapping to DevOps below is my own reading, illustrative rather than literal, but the ancestry is hard to miss:
| WorkOps phase | DevOps counterpart |
|---|---|
| Planning | Backlog and sprint planning |
| Delivery | Code and build |
| Quality | Automated testing and review gates |
| Reports | Monitoring and observability |
| Automations | CI/CD pipelines |
| Integrations | Toolchain integration |
| Support | Incident response |
| Knowledge | Postmortems and runbooks |
The decisive difference from 2018 sits in the middle of the loop: AI as an active orchestrator rather than a feature at the edges. Where DevOps pipelines move code through stages on triggers, an AI orchestrator can route work on meaning: reading context, spotting stalled items, preparing handovers, and closing the gap between a report existing and someone acting on it.
One caution carries over from 2018 unchanged: none of this applies equally everywhere. Creative and exploratory work still resists the loop, exactly as Marsh predicted.
What to steal from the DevOps adoption playbook
DevOps also teaches how adoption goes wrong. Big-bang transformations, tool purchases without practice changes, and central teams imposing pipelines on unwilling engineers all failed reliably. The lessons transfer directly:
- Start with one value stream. DevOps succeeded team by team, not by corporate decree. Pick one recurring process, such as client onboarding or campaign delivery, and run the full loop on it.
- Make work visible before you automate it. You cannot automate a process nobody can describe. Map the handovers first; they are where work dies.
- Automate the repetitive layer first. Status updates, reminders, data transfers between tools. Quick wins fund the harder changes.
- Measure the loop, not the activity. DevOps tracked deployment frequency and lead time instead of hours worked. WorkOps tracks metrics such as cycle time, automation rate, and work visibility.
- Fit, don’t force. Every organisation adapts the framework to its own context. Ignore how your teams actually work, and your teams will ignore the method right back.
Key takeaways
- WorkOps applies the proven DevOps move, unifying a fragmented lifecycle through automation and feedback, to all work, not just software.
- Analyst Chris Marsh introduced the term at 451 Research in 2018 and explicitly framed it as the DevOps parallel for work execution.
- The idea stalled because pre-AI tooling could automate rules but not judgment; generative AI supplied the missing orchestration engine.
- The modern WorkOps loop has eight phases, each with a direct DevOps ancestor, and places AI at the centre as an orchestrator.
- Adopt it the way teams adopted DevOps: one value stream at a time, visibility before automation, measurement over ceremony.
Conclusion
DevOps needed roughly a decade to go from a conference talk to the default way software ships. WorkOps is earlier on that curve, but it starts with an advantage: the pattern has already proved itself, and the orchestration technology already exists.
The full model is in the WorkOps whitepaper: the loop, the principles, and how to start with one value stream. Download it there. For a quicker orientation, the framework and the eight principles live on this site.
Chris Marsh introduced the term WorkOps at 451 Research in 2018. WorkOps.org stewards the framework as an open methodology and makes no claim of exclusive ownership of the term.