Content Operations at Scale: How Systems Control Complexity Without Eliminating Variation

Introduction — The Problem Is Repeated Decisions

Content operations are often described as the combination of people, processes, and technology used to create, manage, and distribute content. That definition is useful, but I think it starts one step too late.

What interests me is what happens before a workflow becomes efficient or inefficient. As an organization adds brands, products, markets, languages, channels, teams, and publishing requirements, the problem is not simply that there is more content. The deeper problem is that the same kinds of decisions begin to repeat.

Which version of a product description should be used? Which legal language belongs on which page? Which fields should be translated? Who should approve a change? Which parts of a page should remain brand-specific? Which rules should every editor remember? Which relationships should be added manually every time something is published?

At small scale, these decisions can remain scattered across people, documents, tools, and local habits. At larger scale, that becomes expensive in a different way. The organization is not only producing more content; it is recreating the logic behind the content over and over again.

That is the point where content architecture and content workflow begin to converge. A system can do more than store pages or move work from one person to another. It can decide where repeated choices live.

The four cases I examine here—Virgin Media O2, Morning Brew, loveholidays, and Intuit—approach that problem differently. One consolidates reusable structures across brands. Another shares underlying content while giving different teams different working environments. A third standardizes parts of generation and localization while varying editorial oversight. The fourth turns governance knowledge itself into a shared system layer.

I do not read these cases as an argument for centralizing everything. In fact, the opposite is more interesting. Each organization places some decisions under common control while leaving others deliberately variable.

That leads me to a narrower proposition: content systems scale not by eliminating variation, but by reducing the number of decisions that must be recreated independently.

Common Structural Control Without Common Expression

Virgin Media O2 provides the most visible version of this problem because the fragmentation was structural.

The implementation record published in 2025 describes over 800 pages moved from Strapi as part of the Virgin Media Online Sales platform, and over 1,500 O2 pages—homepages, help, accessibility, legal, and regulatory content—moved from Liferay and Drupal. The vendor case study reports both migrations as taking four days, although its process description is duplicated across the two accounts, so I would not interpret those figures as four days of content movement alone. The same material describes reusable legal and support content, shared components, brand-agnostic design themes, role-based access through SSO and Okta, and structured device and product information used across online sales, retail, and customer care contexts.

It would be easy to summarize this as a CMS consolidation story. I think that misses the more useful point.

The important change was not simply that several content estates moved into one platform. It was that certain decisions could now be represented once as shared structures. Legal or support material could become reusable content rather than something recreated page by page. Components could carry common behaviour while brand themes changed how they appeared. Product information could be structured for reuse across more than one operating context.

At the same time, Virgin Media and O2 did not have to become visually identical. The same component can render in Virgin Media red or O2 blue depending on the theme the system selects. The shared layer supports different brand and channel presentations rather than collapsing them.

That distinction matters. Standardization is often treated as if it requires sameness at the surface. VMO2 shows a different possibility: the repeated structure can be common even when the expression remains distinct.

This is where I would separate reusable content from uniform content. Reuse asks whether the same underlying decision should be made again. Uniformity asks whether every output should look or behave the same way. Those are not equivalent questions.

The same record also reports significant savings, described in the vendor’s press material as more than £2 million annually and in the case study itself only as a “multi-million-pound annual saving.” I would treat those figures carefully. Both come from company and vendor material rather than independent measurement, and the two accounts are not stated at identical precision, so I do not use them as proof that the architecture was economically optimal. The stronger evidence is the system design itself: fragmented structures were brought under shared control, while brand variation was preserved.

For content operations, that is already a meaningful shift. A decision that used to be distributed across multiple estates can now be encoded in shared content, components, permissions, or product structures.

But VMO2 still leaves an important question open. If the underlying structure is shared, do the people using that structure also need to work in the same way?

Morning Brew suggests they do not.

Shared Structure Does Not Require Shared Workflows

Morning Brew’s Sanity foundation dates back several years—it was already being discussed publicly as an established content platform by 2022—so I would not frame this as a recent CMS migration. The more relevant development is the operating model built on top of that foundation.

The system includes Astra for editorial work, Meteor for advertising operations, and Partner Desk for external partners. These environments run against the same underlying content store and the same content relationships, but they do not force editors, advertising teams, and partners into one universal interface.

That is a subtle but important distinction.

A common backend can easily become an argument for a common workflow: if everyone is working with the same content, why not make everyone work in the same tool in the same way?

Morning Brew takes another route. The content relationships can be shared while the working environments remain specialized. Editorial teams can have interfaces and previews suited to editorial work. Advertising operations can have dashboards, validations, hand-offs, and automation suited to advertising. External partners can have a submission environment designed around what they need to provide rather than being exposed to the internal editorial system.

In other words, the reusable layer is not the interface. It is the underlying content model and the relationships between content objects.

That changes how I think about standardization in content operations. Standardization does not have to mean that every user sees the same screen or follows the same sequence of steps. It can mean that different workflows operate against the same underlying definitions.

Morning Brew’s practitioner evidence gives one practical example. Erin Allen, the product designer who worked on the advertising environment, reports in her own published account that ad setup fell from roughly four minutes to about one minute, against a volume of more than 6,500 ads synced and sent in a year. Sanity’s customer material separately reports developers shipping features about three times faster and new brands launching in under a week. Again, I would keep the boundary visible: these are practitioner and customer-reported outcomes, not independently audited performance studies.

The mechanism is more important than the headline metric.

Morning Brew reduced the need for separate teams to recreate shared content relationships, but it did not remove the differences between their work. The architecture recognizes that an editor, an advertising operator, and an external partner may need different interfaces precisely because they are making different contextual decisions.

That creates a useful division. The system can standardize what should remain stable—the structure and relationships—while allowing the workflow to vary where the role changes.

This is also why I think “centralization” is too blunt a word for what these systems are doing. VMO2 centralizes shared structures across brands. Morning Brew centralizes content relationships beneath different operating environments. The object under common control has already changed.

loveholidays pushes that distinction further. There, the repeated decision is not only how content is structured. It is how content is transformed.

Standardize the Transformation, Not the Oversight

loveholidays’ generation and localization model began well before the main 2025–2026 research window. Its CTO was describing AI-generated hotel descriptions inside the company’s CMS publicly by May 2024, and the underlying platform had been in place since around 2022. What matters for this comparison is how that mechanism continued to scale and develop.

The system generates English hotel descriptions through a repeatable process that content specialists direct rather than write from scratch—they craft and refine the prompts, and the company describes the English pages as predominantly authored by its content team with AI assistance. Translations are then generated from those English pages, using machine translation the company has publicly associated with DeepL, although the public record ties DeepL most directly to partner content rather than to every translated hotel description. The implementation material also describes market rules structurally through attributes such as locale, currency, domain, paths, and URL rules.

The important part, in my view, is not that automation is involved. It is where automation is allowed to replace repeated decisions and where it is not.

A hotel description does not begin as an entirely independent writing problem each time. The system can start from structured inputs and apply a repeatable generation process. Translation can also follow a common process rather than being commissioned as a separate workflow for every content object. Market rules that would otherwise be scattered across implementation work can be represented as configuration.

But editorial oversight is not treated as identical across the entire catalogue. The company’s own engineering account describes three configurable routes for any given body of content: straight to publish with no human in the loop, into draft for review and amendment, or excluded from AI generation altogether. Oversight is a setting, not a constant.

That is a more useful model of content automation than “manual versus automated.”

The repeatable transformation is standardized. The level of judgement is not.

I think this matters because automation discussions often assume that the design choice is how much work can be removed from people. The loveholidays case suggests a more precise question: which decisions are stable enough to encode, and where does the value or risk of the content justify additional review?

The evidence also requires restraint. The public material supports editor-directed generation and translation workflows, structured market configuration, and differentiated review. It does not justify saying that every supplier-data change automatically triggers regeneration, or that changing a prompt automatically rewrites an entire existing content estate. The company has also reported gains in launch speed, translation costs, and content-team productivity, but those remain internally reported outcomes rather than independent validation of quality. 

For my argument, that limitation does not weaken the case. The architecture itself is enough.

loveholidays shows a content system moving repeated production choices into shared transformation rules while keeping editorial judgement variable. The common layer is neither a page template nor a workflow interface. It is the transformation logic.

Once I reached this case, the pattern became clearer to me. Content operations can centralize a structure, a relationship, or a transformation rule. Intuit extends the same logic into something less tangible: the standards used to decide whether content is appropriate in the first place.

When Governance Knowledge Becomes Part of the System

Intuit maintains an official Content Design System that documents standards for content work. In a 2026 practitioner account, the team describes having “turned our site into usable markdown” while developing machine-readable guidance for internal AI-assisted design workflows.

The most interesting part of that work is not the use of AI. It is the architectural mistake the team encountered.

Early skills each carried their own reference folders containing content system documentation. Instead of solving the problem of distributed guidance, the system risked recreating it in another form: multiple copies of the same standards, each of which would have to be updated separately.

That is a familiar content problem. A rule copied into several places may begin consistently, but every copy creates another location that can drift, age, or require maintenance. In effect, automation can reproduce the same fragmentation that structured content is supposed to reduce.

The team responded by redesigning the internal architecture around a single hub of shared references that specialized skills inherit from and route to, together with a human audit of where skills overlapped, contradicted each other, or competed for the same trigger conditions, and versioned distribution so that updates reach anyone who has the plugin installed.

I would keep one distinction very clear here. Intuit’s public Content Design System is a maintained standards corpus. The internal plugin and skills architecture is a separate executable layer. The account is written by practitioners for a trade publication rather than issued as official documentation, and it does not establish an automatic synchronization chain running from the public site into every internal skill. The safer claim is that the internal system was redesigned around a centralized shared reference layer.

That narrower claim is still analytically important.

In the other cases, the thing being reused is easier to see: a component, a content relationship, a product field, a translation process. At Intuit, the reusable object is governance knowledge.

Instead of requiring every contributor—or every automated tool—to independently reinterpret the same content standard, the organization moves toward a shared reference layer that can be applied in specialized contexts.

This is content governance becoming operational rather than merely documentary.

The adoption evidence is early and narrow: the plugin was reportedly the second-highest installed in Intuit’s internal AI marketplace within twenty-four hours of launch, which measures uptake at a single moment rather than sustained use. I would not claim that the system has proven enterprise-wide improvements in quality, consistency, or productivity. What the case demonstrates is the design problem and the recalibration: duplicating governance knowledge recreated multiple sources of truth, so the architecture was changed to centralize the shared references instead.

That is enough to complete the comparison because it shows the same principle at a different layer.

The question is no longer only “What content should we centralize?” It becomes “What decisions about content should the system stop asking people and tools to reconstruct independently?”

What Content Operations Put Under Common Control

Taken separately, these four cases look quite different. One is a multi-brand telecommunications environment. One connects editorial and advertising operations. One manages generation and localization in travel content. One distributes content-design guidance into internal creation workflows.

I do not think their value lies in treating them as four examples of the same technology trend. They are useful because they centralize different things.

Virgin Media O2 places reusable structures, shared content and product information, components, permissions, and parts of governance under common control while keeping brand and channel presentation variable.

Morning Brew places content relationships and a structured backend under common control while keeping role-specific interfaces and workflows variable.

loveholidays places generation and translation processes and market configuration under common control while varying editorial-review intensity. 

Intuit places governance knowledge into a shared reference architecture while leaving specialized application and contextual judgement distributed.

The pattern is not “centralize content.” It is selective or layered control.

That distinction helps explain why content operations become difficult as organizations scale. Complexity is not only the number of content objects. Complexity is also the number of decisions attached to those objects.

If ten teams each have to decide how a field should be named, how a product relationship should be represented, which version of a legal statement is current, how a translation should be initiated, or how a standard should be interpreted, then the organization has not merely distributed work. It has distributed decision-making.

Sometimes that distribution is necessary. A brand team may need control over presentation. An advertising operator may need a different workflow from an editor. Some content may move directly to publication while other content needs a review path before it is released. A specialized content task may require contextual judgement that cannot be reduced to one universal rule.

The problem begins when a decision is repeated independently even though the context does not materially change it.

This is where reusable content, modular content, content localization, content automation, and content governance start to look less like separate disciplines. They are different ways of asking where repetition should stop.

A small supporting example from Complex makes the principle unusually explicit. Its implementation uses a Sanity Function that runs when an article is published with an empty relatedProducts field. The function queries an experimental embeddings index and writes the most relevant product references into the structured article.

The mechanism is narrow, which is why I would not treat Complex as a fifth primary case. But analytically it is useful. A repeated editorial decision—finding and adding related products—has been turned into an event-driven system rule under a defined condition.

The often-cited estimate of roughly 80 editor-hours saved per month is an extrapolation from about five minutes per article across roughly 1,000 articles a month, not a measured labour study. There is also no published evidence on match accuracy or override frequency.

But the mechanism illustrates the same shift in miniature. A decision that used to be recreated at publication time is encoded as a trigger.

That does not mean every repeated choice should be automated. Nor does it mean that shared control is automatically better.

Centralizing the wrong thing can make a system less adaptable. A common workflow can become friction if different roles genuinely need different paths. A reusable content object can become too rigid if local context changes its meaning. An automated transformation can scale mistakes as easily as it scales correct output. A governance layer can become another source of fragmentation if its reference material is duplicated inside every tool.

The four primary cases are useful partly because they preserve these boundaries.

Their common lesson is not maximum centralization. It is to identify the layer where repetition is stable enough to justify common control.

That is a different way to think about scalability. Instead of asking how many pages a system can publish, I would ask how many decisions the organization no longer needs to make from scratch.

Where Repetition Stops and Context Begins

Content operations will always involve variation. Brands differ. Markets differ. Roles differ. Risk differs. Editorial judgement differs. A system that ignores those differences may be standardized, but it may not be useful.

At the same time, treating every content decision as local creates its own form of complexity. The same rules are rewritten. The same structures are rebuilt. The same relationships are recreated. The same standards are reinterpreted. The cost appears not only in time, but in the growing number of places where the organization can drift from itself.

That is why I would not reduce the design problem to centralized versus decentralized.

The more useful question is which decisions are repeated often enough, and consistently enough, that they should be made once inside the system.

Virgin Media O2 suggests that shared structures do not require shared brand expression. Morning Brew suggests that shared content does not require shared workflows. loveholidays suggests that common transformation rules do not require uniform editorial oversight. Intuit suggests that even governance knowledge can become a reusable system layer without eliminating contextual application.

Across those cases, the boundary keeps moving, but the principle remains similar.

Where a decision can be reused safely, encoding it once can reduce duplication. Where context materially changes the correct output, variation still has a job to do.

For me, that is the more interesting way to understand scalable content systems. The goal is not to remove variation from content operations. It is to decide where repetition should stop—and where context still needs to begin.