Key takeaways
- A Static Operating Model (SOM) is redesigned on a multi-year cycle; a Mutable Operating Model (MOM) is designed to be restructured continuously.
- MOM is only operationally possible because of two underlying mechanisms: Flexible Resource Architecture (FRA™) for resourcing, and FusionWork™ for delivery.
- Moving from SOM to MOM works best as a phased, function-by-function shift,not a single high-risk redesign programme.
Most enterprise operating models are designed once, documented in detail, and then defended against change for as long as possible,because redesigning them is expensive and disruptive. That approach made sense when the environment around the model changed slowly. It doesn’t hold up well when it doesn’t.
SOM: the model most organisations are still running
We call that traditional approach a Static Operating Model, or SOM: a fixed structure of roles, processes and systems, set up for a point-in-time version of the business and only revisited on a multi-year cycle. [Draft note: SOM is defined here as “Static Operating Model” for contrast with MOM, confirm exact wording against the Master Glossary before publishing.] A SOM isn’t badly designed, it’s just designed to resist the exact kind of change that AI-era operations now require constantly.
The tell for a SOM in practice isn’t the org chart, it’s how the organisation responds when demand shifts: a headcount request works its way through approval cycles, a hiring or restructuring process takes months, and by the time capacity actually changes, the demand that triggered the request may have already moved again.
What is a mutable operating model?
A Mutable Operating Model (MOM) is an operating model designed to be restructured continuously rather than periodically, where the mix of human and digital workers, the process design and the resourcing model can all shift in response to demand, without triggering a full redesign project each time.
The word “mutable” is doing specific work here: it doesn’t mean unstable or constantly changing for its own sake. It means the model is built with change as a first-class operating condition, the way a piece of well-architected software is built to be modified without a full rewrite every time a requirement shifts.
MOM vs. SOM, side by side
- Change cadence, SOM: multi-year redesign cycle, usually tied to a formal transformation programme. MOM: continuous adjustment as a normal operating rhythm, with no separate “transformation project” required.
- Response to a demand spike, SOM: emergency headcount request or an overloaded team absorbing the gap, typically visible to the business as a service-quality dip. MOM: capacity reallocates through the resourcing pool without a hiring cycle, largely invisible to the end user.
- Response to a demand drop, SOM: cost stays fixed, or triggers a redundancy conversation with all the disruption that involves. MOM: capacity reallocates elsewhere; no crisis response required, and no idle cost sitting on the books.
- Technology posture, SOM: systems built around the process as designed at a point in time, requiring reconfiguration projects when the process changes. MOM: systems and digital workers built to absorb variation without re-architecture.
- Risk profile, SOM: risk concentrates in the gap between when demand changes and when the model catches up,often the most operationally exposed period an organisation experiences. MOM: risk is distributed continuously rather than accumulating between redesign cycles.
What makes a MOM operationally possible
A Mutable Operating Model isn’t a philosophy,it needs specific structural mechanisms underneath it, and two do most of the work. Flexible Resource Architecture (FRA™) provides the resourcing layer: a shared pool of human specialists and digital workers that reallocates dynamically rather than a fixed headcount sized to one point-in-time estimate of demand. FusionWork™ provides the delivery layer: the human-plus-digital-worker split that lets the volume of routine work scale up or down without requiring proportional headcount change.
Together, these are what let a MOM respond to a demand shift in days rather than months,the flexibility isn’t a stated intention, it’s built into the resourcing and delivery mechanics themselves.
A worked example: the same demand spike under SOM and MOM
Imagine an enterprise IT function experiencing a 40% jump in ticket volume following a company-wide system migration, a plausible, common scenario. Under a SOM, the existing team absorbs what it can, response times degrade, a business case for additional headcount gets built and approved, and new hires are recruited and onboarded,a process that commonly takes two to three months, by which point the migration-related spike may already be subsiding, leaving the organisation with excess headcount sized for a demand peak that’s passed.
Under a MOM, the same spike triggers reallocation within the existing Flexible Resource Architecture pool, specialists shift toward the affected function from elsewhere in the shared pool, and the digital-worker layer absorbs whatever proportion of the additional ticket volume fits its existing classification patterns. Response times stay closer to normal within days, not months, and when the spike subsides, capacity reallocates back without a redundancy process. The difference isn’t that the MOM organisation predicted the spike better,it’s that its operating model didn’t require a multi-month administrative process to respond to it at all.
Signs your organisation is still running on a SOM
A handful of patterns tend to show up reliably in organisations operating a SOM without necessarily recognising it as such. Headcount planning happens annually regardless of how fast the actual business is changing, treating the calendar rather than actual demand as the trigger for resourcing decisions. A demand spike routinely triggers either an overloaded team or an emergency hiring process, with no middle option available.
New requirements get bolted onto existing processes rather than triggering a genuine reassessment of whether the process still fits, which tends to produce increasingly convoluted workflows over time. And the operating model was last formally redesigned more than two or three years ago, with everything since being incremental patches on top of a structure built for a different set of conditions,patches that accumulate their own maintenance burden over time.
Moving from a SOM to a MOM without a full redesign project
The instinct when recognising a SOM is often to plan a full operating model redesign,which recreates the same problem one level up, because a redesign project takes months and produces another point-in-time structure. A more workable path starts smaller: identify the highest-volume, most demand-volatile function first, and build a Flexible Resource Architecture and FusionWork™ split around that one function as a proof point.
Once the mechanism is working and trusted,measurable through the KPIs below, not just anecdotal confidence,extend it function by function, rather than attempting to convert the entire operating model in one programme. The organisation ends up mutable incrementally, without ever running a single high-risk, big-bang redesign, and each successive function benefits from lessons learned on the ones before it.
Measuring whether a MOM is actually working
A few indicators separate a genuinely mutable operating model from one that’s mutable in name only. Time from demand signal to capacity response,measured in days for a MOM, typically weeks or months for a SOM. The proportion of demand variation absorbed without a formal headcount change request. Cost variance relative to actual demand, rather than cost sitting fixed regardless of volume.
And given the workforce commitments a genuine MOM should carry,what happens to people during a demand contraction: reallocation within the model, rather than redundancy, is the clearest sign the mutability is structural rather than cosmetic.
Conclusion
Still running on a model designed for how the business looked three years ago? Let’s talk about what a Mutable Operating Model would change.
Frequently Asked Questions (FAQ)
Is a MOM the same thing as being “agile”?
Related but distinct,agile methodologies govern how project work gets organised and delivered. A MOM governs how the underlying resourcing and delivery structure itself responds to demand, independent of which project methodology sits on top of it.
Does moving to a MOM require replacing our existing systems?
Not necessarily as a first step,the resourcing and delivery layer (FRA™ and FusionWork™) can operate alongside existing systems; deeper system changes tend to follow as specific functions mature rather than being a prerequisite.
How do we know if a specific function is a good first candidate for moving to a MOM?
High ticket or transaction volume, meaningful demand volatility, and enough historical data to classify patterns reliably are the main indicators,functions that are both high-volume and unpredictable tend to show the clearest, fastest benefit from the shift.
Can a MOM coexist with parts of the organisation still running a SOM?
Yes,the function-by-function approach means most organisations run a mix during the transition, and some genuinely low-volatility, low-volume functions may never need to move off a SOM at all.
