The coming of age of ContentOps

19 minute read

In our series of webinars around ContentOps we heard from Rahel Bailie about why organisations need to focus on principles rather than prescriptions - whilst they may want the same outcomes for their content, they will get there in different ways. With plenty of examples and advice, this webinar is for anyone looking to level-up their understanding of content operations. You can read an edited transcript below or watch the recording.

Let's start with some different operational models. Probably the best known to us in the industry, is DevOps.

What is DevOps?

DevOps has a couple of things that are critical to the spirit of it. It's about automation and monitoring. It's about coming together to do things in a more efficient way.

Then we've got DesignOps. DesignOps isn't as old as DevOps, but it has a lot of the same rationale behind it. It's talking about doing things with minimal friction, which is another way of saying efficiency. They talk about processes as well.

Then we have ResearchOps which is quite new. It's happening more in the UX community. It's again focused on things like reducing inefficiencies, scaling across projects, making processes repeatable, and reliable timelines. It's all around the production aspect of operations. These are operational models that we have in other disciplines.

We even have Artificial Intelligence Ops, or AIOps. This is about functionality, again processes, monitoring, analysis, and automation. You think, "Wow, AI has ops." What do we see as repeating themes? There's some explicit things that we see, we see that it's about reducing inefficiencies. We see that it's about developing repeatable processes, it's about automating whenever we can. It's about scaling up our outputs, it's about monitoring the results of those outputs and then using those results to create insights.

There are also implicit themes. Implicitly what it's about is improving collaboration across value streams to make sure that we are adding value across the body of work. That we have some sort of continuous delivery pipelines, and that we automate those. It's not one delivery for software, and it's not one delivery for content either, but it's about this continuous delivery pipeline. It's also about improving innovation. It's about taking our discipline forward. And it's about, last but not least, reducing risk.When we talk about reducing risk, we're talking about anything from not getting sued to reducing the risk of alienating our customers. There's a lot of breadth in that statement.Ironically, content, even though it's one of the most mature disciplines, has the least mature operational controls. If you think about DevOps, and agile, and how structured that is, and how you know that there's a sprint, and it's every two weeks, and this is what happens, and this is where you store the code, and this is where you document it, and so on and so forth. Think about how you produce content.

Defining ContentOps

First we need to define ContentOps. If we look at some of the definitions that are out there, it's interesting because it's not like there's a standard's body or professional association, or some neutral body that's defining it. What we have is some organisations who have taken it upon themselves to define content operations.

The Word Factory says that content operations is about processes in systems that are required for a content supply chain. I have a problem, personally, with the idea of a supply chain, because it's a lifecycle as opposed to a supply chain. A supply chain means that you deliver something and then you don't think about it again. I sell you a pen, and then that pen is not my problem anymore. I hand it over to you and it's finished, it's done.In content, we know that it goes around, and around, and around and iterates. However, that aside, it's about processes, and systems, and being able to efficiently and effectively produce and distribute content. I think this starts to harken back to the other operational models we looked at. We also have this need for content operations. have said that content operations negotiates the gaps in your strategy, and it's about achieving consistent quality at scale. They say it's for content marketing, but still, it's about achieving quality at scale. I think those are important markers that we see coming up again and again. It's also about improving effectiveness. For them it's improving content marketing effectiveness, but it's improving effectiveness of the content across the organiSation.

If we take a look at Gadgetopia, this is Deane Barker from Blend Interactive, he talked about content operations years ago, and he says that it happens between content strategy and content management. Any form of manipulation and analysis would be managed by a content operations process. He sees it as being in between the strategy and the technical services. The first half I agree with, but the last half I don't quite agree with. It is about content manipulation and analysis. The idea is to reduce manual manipulation and increase automated manipulation.McKinsey says that ... They call it digital marketing operations, but when you read the rest of the article, content is the context. They talk about capabilities, processes, structures, and technologies. Really what they're talking about cost effectiveness, and scaling, and so on. It's also a lot about this idea of automation. Oh, and personalization is a big one. When we think about it we think of personalization.

If you think about GatherContent, they have entered the content operations arena having the a-ha moment that a lot of what they do is supporting content operations. They talk about infrastructure and processes that are required to create content across an organisation. An important point in here is "it's not the same as content strategy, because it assumes you already have a plan to execute on." I think that's a very important distinction.

There's a Slack community that we've set up. We've started with this working definition of ContentOps. I'm sure it will change and morph over time, but we start with this. It's a set of principles. It results in some methodologies. We're not talking prescriptions, we're talking methodologies that are intended to optimise the production of content. I think that's really important, is that we cannot think of ourselves as the digital extension of the person with the quill that looks off into the distance very pensively to pen the next great novel. We think more of ourselves as an organisation that has a lot of needs to scale, to personalise, to adapt our content, and to turn it around quickly and reliably, and so on. It is like a production system. It allows organisations to scale their operations while keeping high quality in this continuous delivery pipeline.

Why do we do it? We do it to allow the leveraging of content as a business asset to meet our goals. While all these other ops, DesignOps, ResearchOps, DevOps, have similar drivers, the practices are different. We're all doing it for the same reasons, but what we put out at the end, and how we actually meet those goals are very different.

Reducing your content debt

When you think about what content operations is, up a few conceptual levels, really what it's doing is raising the value of content by reducing your content debt. We know how this works, if you buy a house but it's mortgaged to the hilt, you don't have a lot of value in it because your mortgage payments are so high. We have that same thing with content where we might be producing content, but if it costs so much to produce the content, that it makes it a value neutral, or a cost neutral exercise, then you're always going to be under the gun to do things faster, better, cheaper, and so on.

With content operations, what you can do is create more content, better content, higher quality content, have that content create value for the organisation, and at the same time, you're making it less expensive to do that.

Where does content operations fit?

Let's look at a couple of methods of content production. When I talk to people they often tell me we have something that looks something like this.

Diagram showing methods of content production

This is a very simple adaptation of something I've seen at a client's site, but they had 48 systems all strung together, and things that were broken, so they would do something that was remedial, and then they would have to have something that was remedial to the thing that was remedial, and so on. You got to the end and you said, "Well, we're done." But not quite.We call this the chewing gum and binder twine, which is not a system. It's a process.

Copy and paste is not a system. You create a brief, and you do it in Outlook because you're just sending it by email. And then you send it to someone, and they copy and paste some stuff into Word, and then they write the brief and email it around, and they send it out for approvals, and it goes back into Outlook. Then somebody says, "Okay, it's done. To make sure that we keep a trail of our decisions, we'll zip up the files, and we'll start in SharePoint." It's a process, but it's not a system. Anything that involves copy and paste is not a system.

What does operations do?

It facilitates the business as usual phase. First you have the content strategy, and then you implement the content strategy. Strategy could take you anywhere from three months to 12 months to implement. If you're in house, then it's probably ongoing. If you're calling in a consultant, you might call them in for three months.

Then you make recommendations. Perhaps changes to processes, changes to technology, changes to the actual content itself. That takes anywhere from 6 months to 24 months to implement, depending on how complex and how they want to stagger it. Then there are a number of years where it actually gets used.The operations part has a long lasting effect. It's not like going in with a strategy and saying, "okay, we're going to do this strategy. Now let's use it." And then, "We're going to use it for a few months and then we're done." Or, "We're never going to use it." This is an unfortunate reality, when a strategy or road map gets handed in and they don't implement it. Or, they start to implement it and then for whatever reason they decide that they really have other priorities, and then they abandon it. How can you use something that's never been implemented?

Diagram showing a typical content process

People will say, "but we have a process." The above is a process from a couple of years ago at a very large financial institution. You can see that it's a process, but it's not really an operation, because you can't scale this. As soon as you're tracking something, copying and pasting it, writing in word, and then sending things around, and then copying and pasting to an authoring system for workflow management, that's not scalable. What you're missing here is the efficiency measure, in that it might be very effective what you're doing, but it's effective for a small boutique operation. If you have a website that has 50 pages, and you have a little bit of content, then you could do this. You could say "this is operational for us." But for a large scale company, it's not going to fly.

At the very end, they manage their publication ready content within the Web CMS. I think that's a very important point to think of as well, because up until then, it's not being managed in a system, it's being managed in multiple manually managed systems. People will say, "But we have a content management system." Deane Barker says, "No one actually opens a content management system and tries to enter any content until about 85% along in the entire process." There's a whole bunch of work that gets done ahead of time, and it's really uncontrolled. In North America there's more likelihood that the writer actually gets access to the content management system, they get a log in, and they'll log in, and they will enter their content. What I've seen in the UK is that the writers don't even have access to the content management system. They email stuff to someone who copies and pastes it into the content management system, and then adds all the metadata, and comes up with the search result, and usually finds the sentence, and copies it in. You get mediocre search results, and you get iffy metadata because they are operating without context. They are considered a technologies. Their job is to take word processing content, or email content, and turn it into web content.

A lot of this points to "lack of value." Companies control what they value. If you go into a shop, they control their inventory. If you go into an investment company, they control their financial assets. What would it look like if companies valued their content the way they do their money?

Let's look at a highly controlled operation, that's accounting and financial management. It used to be that people would have a double entry ledger book, and they would copy things on the left side, and on the right side, and they would balance it. It was very laborious, and if you watch those period films where you see rows and rows of men in top hats, and their all sitting around very studiously with their quills, entering information, that was accounting. That was financial management back in the day.

Now, you enter something, you enter it once, it gets turned into insights in some financial management dashboard, and you get all sorts of things that you can do by manipulating not the content itself, but just by manipulating the dashboard to say, "I want to see it in this view. I want to see it in that view, I want to see it in another view." and you can.You have people who enter this information once, and then it's done. And they don't go back and enter the information again, and again, and again. When you think about that, you go, "Why aren't we, as content people, at that point yet?" Because really content that's managed through manual interventions is not ContentOps.

What can ContentOps look like?

Noz Urbina, who was co-author of my book, and we teach together in the masters of content strategy program, he presented this to the students the other day, and I went, "Oh, this is perfect for my presentation." Noz says, "We have incrementally built up a process, adding pieces and patches ... And we now use processes that are no longer fit for purpose." It's a much longer quote, but that's what it comes down to, is we have these processes, and they worked back in the day, and we calcified, and we have not updated our processes to meet the demands that are starting to come upon us.

The mechanics of adaptive content

He shows these mechanics of adaptive content, and he's showing it through some whitepapers and blog posts. He said, you can start with the topic overview, and the case study, and you can incorporate those into a whitepaper, you can have these elements that go in, and then you can incorporate the into a blog post, you can incorporate them into a leaflet, you can incorporate them into another blog post, and so on.The reason that you can do that is because when you created at the beginning, you're using a system. It's using a system where you create and control the source content, and you control it in how you write, you control it on how you put metadata on it, you control it on how you put attributes on it. A structural metadata and descriptive metadata, and then you let the software do the assembly. The mechanics behind what Noz was talking about is adaptive content.

This company came to FH-Joanneum to present to the students. It really took me by surprise that they were doing something this sophisticated, although this is standard content operations. Their goal is to create this personalised customer material for each car that comes off the assembly line. You order a car, in this case it's the Ford Mustang, and then when it comes off the assembly line, what happens is that they scan the barcode on your dashboard, and it creates a one off personalised manual for you. Then it knows what to put into your account when you log in online, and it knows what to put into the head console, which is what this graphic shows, because when you go into and you click on vehicle, it should tell you all these things about your vehicle. And they have an app with augmented reality.

For example, if your tire pressure is low, you could point your phone at the tire, and it will tell you what kind of tire you have, what the tire pressure should be. And it's all automated. They do 2 million unique manuals a year. You can't scale like that without an army of people.

What they had to do was find a way to really control the source content. They have their entire corpus of content for the Ford Mustang, and then they plan how the contents were used. They model it in a certain way, they put the metadata on a certain way, they tag it up for adaptive content. They call it molecular content, because it might be that in your vehicle, you have something that's as small as a word or two. If it's in your app, it might be a phrase. If it's in your manual, it might be a sentence, and what you have online is a paragraph.

By taking this molecular content, that you can automate the aggregation of, you can automate the delivery of it. To be able to do this, you have to have a strategy, first of all, because you have to know what you're planning for. Then you have to implement it, and then people have to be able to write for it. Content designers, or the technical communicators, create the content in such a way that they can automatically bring it together and deliver it however they need to.

James Mathewson from IBM was kind enough to share what their content operations looks like. IBM wanted to reduce the cost of their marketing material while increasing the revenue generated from that material. What he talked about was that working smarter instead of harder.

They've got a knowledge base with up to 18 million articles in it. Can you imagine what it would take to keep that content up to date, in good order, accurate from the terms of spelling, and grammar, and good english. Is it on brand? Is it lively enough? Is it useful?

They have built a content planning system that gives all the marketers this common view of what's available per product, per variation, and so on. They would have an operational dashboard for their content so they can see what's going on.They're using artificial intelligence for discovery, auditing, and tagging content. They're using insights from artificial intelligence to build smarter briefs. And they are also making sure they can deliver the right content to the right users, in the right stage of their buying journey across these multiple channels. That is operations done at a grand scale, and probably at its finest.

A short history of ContentOps

Content operations has been around for a while. It started back in the 1980s with Wang. They had Word Processors where you could type in your stuff, it was even a precursor to Word, it was all in ASBI. You could start with tagging your content and you didn't worry about format, you just put in your content and then stuff happened to it down the line. Then Adobe created a tool called FrameMaker. You could a lot of multichannel publishing, and we were working in an operational model where the code descriptions went into UML, and then you sucked it out into FrameMaker using rational soda, and then you could generate whatever you needed in terms of documentation to go with your code. That's what we sold to the client, was code and documentation to go with it. Then there were these Help Authoring tools that came along like Robo Help. XML Spy was one for a while, and today probably the best known one is Flair. They did a form of content operations where you put the content in, you tagged it up, and then you could build these table of contents, and you would just say "I want to output this." And then it would go and get everything, and build the content in that order, and push it out either to a content hub, or help files, or manuals, or training material, whatever you needed it to be.In the next decade we had web CMSs, and then we had component content management systems. Then we progressed to master data management systems as well. You've got these other variants based on the needs. Product Information System was developed. PIM is a product information management system which was built because retailers needed a place to put all of the information about a product. You not only had your image, and your short description, and your product name, and your price, but then you had all your attributes like, "This is a jacket. It comes in size small, medium, and larger. It comes in black, and blue, and red, but in red there's only an extra large."They could generate everything from store signage, to washing tags that got sewn into the garments, to the print catalogues, to the online catalogues. PIMS today are quite big, and quite powerful.Then we come to the next generation where we have tools like GatherContent, a Content Operations Platform. GatherContent's really in a class of its own right now. It's a very easy to use tool. The one thing that GatherContent really understood was what people needed to be able to popularise this.

Connecting silos through ContentOps

As we create more and more content silos, we are losing the ability to have a functional operational model. ContentOps has a long history in technical communications. But now, marketing is having those same demands, and they need better systems as well because now you're expected to personalise, and deliver into multiple channels and multiple platforms. You've got these silos happening where you've got, "Here's our marketing material here, and then here's our content marketing material over there. And then over here is the UX rating, and over here is the chatbot stuff, and over here is the voice bot stuff." Now when somebody says, "Quick" like musical chairs, "All change." It's impossible to catch everything.

A few years back I was asked to talk to a company that did money exchange. They were in 70 companies. They said that they would be given this mandate by the regulator to say "You have to change statement X, and you need to do it by tomorrow." They would have to take down the service, and then scramble through the code to find out where content was lurking, and other content was in different repositories. They would just do the scan and hope they caught everything, and hope they didn't get fined for not complying fast enough, or they might have missed some things. People were dropping like flies in the translation coordinators, this is where it started from, they couldn't cope anymore, and they were working constant overtime, and always stressed. And the marketing people were really stressed because it has to be reliable.

Can you imagine going to something like PayPal, and it gives you the wrong information in one language, and different information in another language? All of these things can cause a lot of stress for the people who have to carry this out, but it also causes stress for the clients. That compounds the stress for the people who are working on this.

Principles, not prescriptions

ContentOps means working smarter. You're talking about your content delivery, which costs a lot of money. Your content creation, which costs more money than content delivery because creating content is not cheap. You pay your writers well, and you want them to be able to create this very complex content. But content maintenance is actually the killer when it comes to keeping up the content.

This is why it's not a supply chain, because you have version one, version two, version three, version four. If you do something wrong at the source, then by the time you get to version four or five, you just want to put a sharp stick in your eye instead of having to deal with this. By version 10 or 15 you just throw up your hands and say, "I quit." And you go somewhere else and someone else inherits your problem.

It's not just the version, but it's also the variant. Think of a mobile phone. You've got the Samsung Galaxy 4, 5, 6, 7, 8. Some are Edge, some are something else. And each one has a slightly different variant. You don't want to have hundreds and hundreds and thousands of files that are slightly different that you have to maintain. You want to have it in one place, and you want to be able to tag to say "if it's a model X, then I'm going to use this sentence. And if it's a model Y I'll use that sentence, and if it's a model Z, I'll use that sentence. And the rest of it remains the same and I don't have to worry about it." It's that long term maintenance of content that makes the difference.

It means that as an organisation, you have to be willing to climb up the maturity ladder. You're never going to go from one to five, and you may never get to five. You may only need to get to four, but you have to go one step at a time.If you were to set out a prescription, you might not be able to handle it. What you want to do is know what the principles are about what you want to get out of content operations, and then move one step at a time up the maturity ladder.

Is there a right way to do ContentOps?

It's about how you put your content strategy to use after it's implemented. That's really what it comes down to. We're back to content strategy.When you have a content strategy you do a needs analysis, you do a gap analysis, you create a roadmap. When you're doing an implementation you assess what you need in terms of technologies or processes, you engineer them, and then you install them or you adopt them. When you operationalise, you train people up and then you use it. As the market changes, as the demands changes, your channels change, you iterate on the operationalisation, but you continue to use it as an operational model.

Why prescriptions don't work

If you're not a cookie-cutter company, you can't adopt a cookie-cutter solution. When I hear people say things in forums like "I want a CMS. Anyone got some suggestions?" And then you get everything from WordPress at one end to AEM at the other end. It's like, here's a rowboat and here's a warship. You think "Oh, what are you trying to accomplish? Maybe you need a helicopter instead." It's not like companies are interchangeable, or documentation is interchangeable.

I asked a longterm contact of mine, Kristy Taylor, she's been a manager for many years in various large organisations. She deals with massive amounts of content in multiple languages in multiple markets. She says "What I want out of content operations is I want it to be a system that's repeatable. It want it automated as much as humanly possible because I want my writers using their expertise on the high value tasks. I don't want them being a slow computer and copying and pasting stuff, and checking off things in spreadsheets. That's not a good use of their time. They can do that in minutes whereas a computer can do that in microseconds. Let the computers do that, I want them to do the thinking work."I want translations built into the operational process. I want scalability." Of course, because she's using massive amounts of content. And she wants this infrastructure that's ready, and it's expandable, so that if she adds a new product, or she adds a new team, or they buy a company that she can just incorporate them and keep going.

That's one set, and that's very typical of the demands of someone in a large organisation that has lots and lots of content. In her organisation, she's looking at things like, "I want semantic content structures. I want a power authoring environment. I want content components. I want to manage my work flow, my translation, my digital assets, and I want to be able to deliver not just out to a manual, to publish, what I want to do is I want to deliver this to down stream systems so that the web CMS can show it over here, and the knowledge base can show it over there, and the customer service portal will show it over there. I want each one to be slightly different."

In a very different setting, I'm working with someone right now. She's a delivery manager and she deals with public sector content. What she wants is very different, but the principles are the same. She wants a service design approach, she wants the flexibility to show content wherever it's needed, like Kristy wants to be able to do multichannel publishing and omnichannel publishing, she wants to do the same thing. Very different content, very different context, very different technologies, but she wants the same thing.

She wants the CMS to automate as much as possible so that it minimises manual intervention, and she wants writers to use their expertise on the highest value test, and she realises that a municipal government is always going to provide more and more content, so she wants it to be able to scale, especially as they start folding all the micro sites into the main site.In her organisation, she also wants semantic content structures although it's going to be a different ... She's probably going to use different standards, and different methods of getting there. She wants a very easy to use authoring system, because they have a lot of people that work from home. She wants to be able to support this distributor workforce. She wants to use a headless CMS, which is like CCMS. She wants workflow management, and she wants to be able to share that content across all of their sites.

Even though how she does it is going to be very different from how other people do it, a lot of those things have commonalities.

ContentOps really is about freeing up capacity to do higher-value work. If I were to just take that and boil it all down. If I have people working on content, I want them working on content in a smart way, I don't want them doing dumb work. I want them to do the heavy lifting, and I want the computers and the content management systems to do all of that tedious roadwork.There are a lot of ways that you can make the case for investing in what you need to take people off of the copy and paste hamster wheel and actually get them on to a higher level of working. Always do a cost benefit analysis before you adopt tools, because you don't want to adopt tools that are over engineered for what you want to do, but you don't want to cheap out and get something that's not going to quite do the job, where you get only 60% of the value you could have gotten if you'd just went that one step up.

What would content ops look like in your organisation?

That's a question that you can pose in a workshop, or a brainstorming session. What would you do with all that freed up brain power? Once you got people who aren't spending 50% of their day hunting things down, and moving things around, and double checking, and triple checking things, and hounding people in the hallway with the red pen for their signature on something. What could they be doing instead? And then, what would it take to make it happen?Those are things you can take back to your organisation to open up the conversation about ContentOps.

About the author

Robert Mills

Rob is Head of Content at GatherContent. He is a journalism graduate and has previously worked as Studio Manager and Head of Content for a design agency and as an Audience Research Executive for the BBC. He’s a published author and regular contributor to industry publications including Net Magazine, Smashing Magazine, 24 Ways,WebTuts+, UX Matters , UX Booth and Content Marketing Institute. On occasion Rob speaks about content strategy and ContentOps at leading industry events.

Related posts you might like