By Rahel Anne Bailie | STC Fellow
Developing content is one of the oldest practices in the world, but in some ways, it has the most immature operational model. Look at the contrast with practices that overlap with content.
DevOps. A software engineering methodology that unifies software development (Dev) with information technology operations (Ops) with the goal of shortening systems development lifecycles while delivering features, fixes, and updates frequently in close alignment with business objectives. The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, and releasing to deployment and infrastructure management.
DesignOps. Everything that supports high-quality crafts, methods, and processes. Operations are the elements that facilitate high-quality instances of those activities with minimal friction. Operations includes the tools and infrastructure required to complete the activity.
ResearchOps. A discipline with primary goals to:
- Operationalize the customer research function to reduce inefficiencies and scale across projects via repeatable processes with reliable timelines, ready-to-apply methods, and templates.
- Make research more relatable and encourage cross-functional team participation in understanding customers.
- Make research insights more accessible for everyone in the company to easily find, collaborate, and integrate the findings in their work.
Even newer fields of practice, such as artificial intelligence (AI), have operational models, as described by Splunk, a provider of AI services.
Goals and Benefits of Operational Models
Sifting through these descriptions gives us some common goals for operational models. DesignOps is about minimizing friction while working through design processes. ResearchOps is about reducing inefficiencies and scaling up with repeatable processes and reliable timelines. DevOps and AIOps are about automation and monitoring. No matter which operational models we look at, we can summarize them as systems for delivering with efficiency.
Some operational benefits are expressed explicitly:
- Reducing inefficiencies
- Developing repeatable processes
- Automating whenever possible
- Scaling up output
- Monitoring results
The business benefits tend to be more implicit, and those content developers plugged into management are more likely to articulate those benefits:
- Improving collaboration across value streams
- Automating continuous delivery pipelines
- Improving innovation
- Reducing risk
- Creating business insights
An Operational Model for Content
The idea of an operational model for content is not new (looking back through my old articles and presentations, I was using the term Content Operations well over a decade ago). But the term didn’t really register until people had a common mental model. Similar to the operational models of other fields, content operations is focused on efficient production of content while maintaining quality. There is a parallel operational model for documentation: DocOps. However, the focus on documents doesn’t resonate with a large portion of the industry that doesn’t produce documents, per se. ContentOps aims to bridge those silos. More on that later.
In a ContentOps Slack group, the following working definition was adopted:
ContentOps is a set of principles that results in methodologies intended to optimise production of content, and allow organiations to scale their operations, while ensuring high quality at delivery time, to allow for the leveraging of content as business assets to meet intended goals.
Content operations are the logical outcome of a content strategy—create a content strategy, followed by its implementation, with the goal of creating an operational model that helps an organization meet its goals. The operational model that comes out of a particular strategy will be as unique as the strategy itself. For one company, it might be about auto-generating documentation that describes code. For another, it could be about systematizing the collection of standardized content from a global network of contributors. Content operations could be about delivering personalized content for a range of audiences, or about delivering content fragments for retrieval by bots and voice assistants.
The Spectrum of Delivering Content for Machine Use
How content is prepared for machine use ranges from extremely brittle to extremely flexible. At the most brittle end of the spectrum, content is baked into the code, app, or voice assistance software. Updating the content is clumsy and labor-intensive. All the relevant locations of the content need to be found. The updated content needs to be supplied to the developers, who overwrite the existing content. The content needs to be checked, to ensure that the content is accurate, and the right content was pasted into the right location.
At the most flexible end of the spectrum, the content is produced to CODA (create once, deliver anywhere) standards, stored in a repository, with semantic structure and metadata applied, and written for every state programmed by the developers. Pulling the content by the consuming system is automated using programmed logic. There is a definitive source of truth for each content object. There is an active governance model in place, and workflow is automated and registers each review and approval based on that governance model.
The bulk of organizations lie somewhere between these two extremes. They are blissfully unaware of content operations, and so do their best using cobbled-together processes. They might create content in a word processing program such as Microsoft Word or Google Docs, email documents around for review and approval, record workflow stages in a spreadsheet, and then send the final content to someone with the job of getting the content into the CMS, app, bot, or voice assistant software. While these are processes of sorts, they are not agile enough to be able to respond quickly or to scale along with business needs.
The Imperative for Adopting Content Operations
Sometimes the best way to explain the implications of adopting a system in one industry is to use an example from another industry. Let’s look at one of the early operational models that benefited from a proper system: financial operations.
Before the 1980s, accounting was done using double-entry bookkeeping. Each transaction had to be entered twice: once in the debit column and once in the credit column. When these two entries are not equal, a third entry, for the difference, needs to be made in the equity column. This is a labor-intensive process, prone to error. Getting a clear financial analysis was dependent on completeness of entries, data accuracy, and the manual transfer of financial data and creation of formulas. In the 1980s, a spreadsheet-based system automated some of the process, and we’ve now progressed to extremely sophisticated accounting software in which data is entered once, and is used in multiple calculations, shown in the form of dashboards, to get instant pictures of financial health across an organization.
Can you imagine the reaction today if you went into a large corporation and found a raft of data entry clerks using spreadsheets and copying the data into the accounting system only when shareholders want to have a look at the financial status of the company?
As far as content systems go, for the most part, organizations operate in the equivalent of a pre-1980s model. Content is locked into mini-silos (called documents) instead of a central repository. The re-use is tracked in spreadsheets, which is the equivalent of using people as slow computers. The multiple versions—either attached copies to email or created by copy-and-paste—break the audit trail. It’s all terribly manual, prone to human error, and not scaleable.
Organizations are generally aware of how much content costs to produce. It is relatively straightforward to calculate the cost of writing, reviewing, editing, and approving a piece of content. Management generally concedes that content is not an inexpensive venture. Once content is created, delivering it is not expensive. Whether delivering through a Web CMS, a chatbot, a voice bot, or a mobile app, these systems provide content to users in multiple configurations, over and over again, with little overhead.
Increasing Content Efficiency While Reducing Content Debt
The cost of maintaining content, however, is exponential. Consider this: whatever processes are used while creating the content are also used for updating and maintaining that content. But before that, there are pre-steps to identify the content that needs updating, locate it across various systems, and record any changes. Synchronizing these changes across systems and platforms can be both costly, time-intensive, and prone to error.
The systems created to handle content operations, however, are generally seen as complicated and unwieldly. They were historically created by software developers who have a limited knowledge of how writers create content. There are assumptions about the mental models of authors. There is a lack of understanding of the complexity of processing content. And there is a fallacy that managing content is the same as managing data—a shocking lack of awareness of the impact of factors such as grammar, context, and nuance. There is also a lack of understanding about the limitations of technology and the need for a technology stack for content.
The lost opportunity cost can be staggering. After all, content is the payload that these systems are designed to deliver. The cost of maintaining the status quo—the cost of doing nothing—accumulates ever-increasing content debt.
Content debt manifests itself in many ways. One way is delivering subpar content. At the very least, it can cause an increase in support calls from confused users. In a worst-case scenario, it can result in a lawsuit when users suffer consequences from inaccurate information. Content debt also manifests itself in a lack of scalability. The number of people, departments, and agencies that get added to a project during surges in content production can be astounding. One recent example is a team of five content developers that swelled to 30, at a seven figure cost over six months, to cover urgent content updates.
What Might Content Operations Look Like
A strategy for content operations is not an off-the-shelf product. There are, however, a set of common principles that can be turned into a unique prescription for an organisation. There are several basic building blocks that, together, make for a powerful set of tools to boost productivity while maintaining content quality, and allow operations to scale, both to new channels and in volume.
The foundational building block is a dedicated authoring system. This is where authors enter and manage content. The type of system will vary, depending on the business needs and user journeys, and the level of sophistication needed to deliver the content. The important aspects of the authoring system are that it separates content from format and creates a definitive source, or “single source of truth,” for each piece of content. Through workflow, the authoring system should be able to automate all of the administrivia of recording the author who created each piece of content; who edited, reviewed, and approved it; and at what times and on which dates. The system should also have a way of exporting the content for presentation to multiple outputs, such as a web CMS, to downstream systems, or even to PDFs to be printed.
The next building block is a semantic technology tool. For the authoring tool to tag content in a way that downstream systems can ingest and deliver it—keeping in mind aspects such as personalization and multiple states—there must be a central place to manage metadata and its relationships. The more ambitious the plan for customer experience, the more sophisticated the need is for a robust set of semantic tools to manage the metadata ecosystem.
Another potential building block is a content optimization tool. This tool supports authors to maintain content quality efficiently and effectively by giving them a set of authoring support tools along with an analytics dashboard to visualize the quality and areas of improvement needed across the content corpus.
Underpinning all of this is a strong governance model. To produce content efficiently, a certain level of consistency and reliability must permeate the entire system. The systems that allow corporations to manage financials or product inventory work, because there is strict control, and everyone is expected to adhere to the system—sometimes by legal regulation and sometimes by good business practice. When it matters, the corporation invests in controls. Similarly, controls on content production should be strictly reliable and traceable.
There are other building blocks that are specific to different business environments, but that is another article.
Stepping Up Your ContentOps Game
To quote Albert Einstein: “We cannot solve problems by using the same kind of thinking we used when we created them.” A technology stack that consists of word processing software, spreadsheets, email, and sticky notes on hard-copy documents is not efficient—and it’s certainly not compliant with the definition of ContentOps.
Delivering content for machine use means applying new ways of thinking and new ways of operating. Content operations is not prescriptive, but a set of principles that emanate from a strong content strategy. With the increasing number and variety of content outputs that must be automatically created for use by machine, the imperative for ContentOps is stronger than ever.
Resources
“Artificial Intelligence for IT Operations (AIOps).” Splunk. https://www.splunk.com/en_us/it-operations/artificial-intelligence-aiops.html.
Johnson, Tom. “DocOps: Interview with Jim Turcotte.” I’d Rather Be Writing, 2014. http://idratherbewriting.com/2014/10/21/docops-interview-with-jim-turcotte/.
Malouf, Dave, Meredith Black, Collin Whitehead, Kate Battles, and Gregg Bernstein. DesignOps Handbook. DesignBetter. https://www.designbetter.co/designops-handbook.
Sriram, Vidhya. “Time to Talk About Research-Ops.” UX Collective. https://uxdesign.cc/time-to-talk-about-research-ops-cbacd8446dbe.
RAHEL ANNE BAILIE (rahel.bailie@gmail.com) has been in the content business since the late 1980s. She now works in London, UK, and is an instructor in the Content Strategy Master’s Program at FH-Joanneum in Graz, Austria. She has been consulting in the area of content strategy for corporations, government, and charities. Her drive for efficiency makes her a natural champion of content operations. Rahel has co-authored two books on the topic.
