One of the people I spoke with last year was a marketing director at a software company. She said she had 47 open browser tabs. When I asked her why, she said that was how she updated a single product description on all of the various channels that her company published information to customers. Her laugh was not quite full when she told me this story.
This is the reality of work for many teams on many Tuesdays.
The mess nobody wants to admit
Most companies do not have a content strategy in place. They have a lot of content — often in the form of a Word document, a bunch of files scattered across a shared drive, a 2019 knowledge base that nobody uses. There are many reasons for this but the primary one is that companies grow faster than their systems. That’s true for almost every successful company.
The worst part is the duplication.
The worst part of this kind of content sprawl is that there is often quite a bit of duplication of effort in creating content. In the example of the marketing director I spoke to, she mentioned that one of the reasons she had forty-seven tabs open was that she was trying to update a single product description that was published across seventeen different channels. But in trying to update that one product description, she would have to update it seventeen different times, each time in a different location and possibly with slightly different language. This kind of duplication can lead to a lot of problems, and by far the biggest problem of all is that such content slowly, slowly erodes trust in a company or organization. It leaks slowly, like air leaking from a tire, and by the time you realize what is happening and can start to do something about it, you have already lost a lot of value.
Most organizations treat content as product. That is, as output. Content is viewed as something that can be ‘dished out’ as needed. However, content functions as organizational infrastructure, much like the organization’s plumbing or electrical wiring. That is, content must be maintained, mapped, updated and monitored.
What good content operations actually look like
When you treat your content like infrastructure (i.e. the “plumbing” or “wiring” that has to be maintained, and mapped out, and have a version control system for), a number of things change. For one, writers don’t have to re-write from scratch. They can re-use approved “components” that are already accurate and approved. Subject Matter Experts get brought in at the right point in the process to allow their expertise to shape the content, rather than being brought in to fix content that has already been written. Publishing then starts to function more like a pipeline. You put stuff in at one end, and it comes out the other end in a somewhat predictable fashion. It won’t be perfect, but it will be survivable.
Here are some indicators that your content workflow is functioning properly.
- A single source of truth exists for each piece of information, and everyone on the team actually knows where it is
- Updates ripple through automatically rather than requiring manual edits across ten files and a prayer
- Writers spend more time writing than formatting, converting, or hunting down the “final_final_v3” version
- Compliance and legal review happens before publication, not after a customer complaint lands in someone’s inbox
I wanted to highlight that last point that I made, that compliance review is so often treated as an afterthought, i.e. will all of this content be compliant after the fact. Only until there is a financial penalty for non-compliance with a regulator, or a product recall due to poorly written instructions for use, do people begin to realize the critical nature of the compliance review process.
A quick comparison worth making
For teams looking to understand the following is a rough outline to compare current state of content operations to a smooth running content operation:
| Dimension | Reactive content ops | Proactive content ops |
| Source of truth | Multiple, often conflicting files | Single, version-controlled repository |
| Updates | Manual, easily missed | Propagate automatically via reuse |
| Review cycles | Bolted on at the end | Built into the authoring workflow |
| Publishing | Format-by-format rebuild | Single-source, multi-output |
| Team frustration | High (and quietly compounding) | Manageable, with room to breathe |
The gap between these two columns is where productivity is either happening or it is being slowly siphoned off.
The technical documentation problem is actually everyone’s problem
The term technical documentation generally brings to mind images of technical writers. However, as was mentioned above, there are many companies outside of the software industry who create a lot of technical documentation of one type or another. For example, the makers of medical devices will often create “instructions for use” which would be considered technical documentation. This type of documentation could be a piece of paper that users of the product would follow in order to safely use the medical device. A financial services firm might publish technical documentation across 14 different jurisdictions in as many languages. There are many companies of all sizes, and from a wide variety of industries, who publish all sorts of technical documentation, and it can totally fail. Often in huge and painful ways.
So a large number of organizations have Technical Writers, Instructional Designers and/or Learning Content Developers create the documentation. However, the content is published by others (e.g. a web team). These writers work in broken systems where the content is written in one tool and published in another, and where the translations are managed in a third (or more). So the writer attempts to maintain consistency of brand and/or user experience across all of this. Meanwhile, All the while someone on a Zoom call is asking why the release notes for the last release are not available yet.
There are lots of tools, such as MadCap Software, that allow you to manage your content. Many of these have been built specifically with technical documentation in mind, allowing subject matter experts to create and manage their content within one tool, and then output that content in whatever format is required. For writers, this is one of the biggest time-savers – by allowing them to reuse approved components of content that they have already written in other contexts, it can return many of the hours and days of work that they put into creating the content in the first place. Rather than having to work within a 47-tab monstrosity, they can work within a single, well-organized environment.
Where to actually start
I have no nice way to say this. I have found that it is best to just dive in and start doing whatever it is that you need to do. I wish I had a better answer for you.
- Audit what you have. Not a light skim, a real inventory of every content asset, who owns it, when it was last touched, and where it actually lives. This step always takes longer than people expect and surfaces more chaos than anyone is prepared for. Do it anyway.
- Identify the duplication. Find the places where the same information exists in five different forms across five different files. Those are your highest-leverage cleanup targets, and fixing them tends to produce visible results fast enough to build momentum.
- Standardize your authoring environment. Writers shouldn’t be choosing between four tools based on personal habit or departmental tradition. Pick a workflow, document it, commit to it.
- Build review into the process, not onto the end of it. Especially, especially, for anything touching legal, compliance, or safety.
(Thanks to Tom Morton for suggesting I add a note here about content audits too. Auditing and mapping out a company’s content assets is the moment that leaders realize just how long they have been treating content as some sort of soft and amorphous thing, and how really it is an operational liability that they have to get a handle on. Numbers make it real.)
The real question
Content does not magically get better as time passes. It takes a very deliberate attempt to create a better process for creating higher quality content, and that process will hit political obstacles along the way. But in the end, that process has to take longer than you expect and involve some work that is unglamorous. But the good news is that the tools and methods are already in existence. Now we just need to will as a business to treat content with the same seriousness that we treat other critical business systems.
There are many tools and methods available to manage your content as infrastructure and to improve how your writers create content. The real challenge is to get your organization to treat content with the seriousness it warrants as a business critical system. That it is not something to be used as decoration or to throw at a problem when it is too late in the budget cycle with reduced resources.
