About three days ago, a writer I know finally put down the manuscript for the rewrites for the safety procedure she had been working on for the last three months. But, when she went to upload it to the appropriate spot on the shared drive, she discovered that the same safety procedure had been written two years ago. Not only had it been written two years ago, but it had been lived in a folder on the shared drive all this time. The worst part, however, was that the writer and I had taken a look at it a few weeks ago, and it was actually pretty good as it was.
Three days. Gone.
It’s a problem that affects more than the individual writer though, it affects the teams and the companies they work for. This is a problem of how we work as humans, to throw away something that was good enough in the first place, takes more time and is more frustrating than it needs to be.
The audit nobody wants to do
Do a content audit. This can be very tedious for technical writers, but it is a great place to start. Map out all of your content – probably start with a small portion of your products or a set of documentation – and figure out what content exists, where it is located, and when it was last updated. A few years ago, I worked with a team to do a very small content audit, something that we had planned to be a simple spreadsheet to figure out our documentation. Instead, it was like digging through an archeological site to figure out what we had created in the past and what we currently had. We found things that we had forgotten existed but that were still very useful. We also found that we had been working off of a document in “substance only” – i.e. we had created a long time ago written down our thoughts on a particular topic and created a document, but then we had forgotten that document existed and had been rebuilding that document from memory for years. This was very powerful for the team to realize.
I started by creating a spreadsheet to outline all of the content within a specific area or type of content. I listed out where the content resided and when it was last updated. I was expecting a relatively straight forward spreadsheet but instead I found an archaeological dig of outdated content and some very useful information that the team had been unknowingly recreating for years.
Teams that make technical content work smarter at ANCHORLINK[link to MadCap blog “Make Content Work Smarter”]ENDANCHOR work well with the technical content that they have to do their job. This is because they have built up a good working knowledge of the foundation of content upon which they are working. This is in stark contrast to other teams working with large amounts of content where it is difficult to even see the forest for the trees.
The content you have is probably better than you think
There is value in existing documentation for several reasons. The knowledge within current documentation represents years of problem solving, experience from previous projects, input from customers, and subject matter expertise. Reusing current content is not as glamorous as rewriting content from scratch to create new content; however, the cost of existing content is already essentially zero after the content has been written, reviewed, and approved.
Most content problems that seem to be about the quality of existing content are actually about the fact that the content in question is hidden, poorly organized, or even that the team cannot verify whether the content is current and accurate. That is a content operations problem, not a writing problem.
Reusing content in practice
Reusing content, as you might expect, has many different forms. The following are several examples to give you a better idea of where and how content can be reused.
Reusing content is not always cut and paste. It can take many different forms depending on the nature of the content and the goals for which it is being reused. The extent to which the content will need to be reworked prior to reuse is also a factor to consider when deciding how to reuse content.
- Single-sourcing: One piece of content, written once, published across multiple outputs. Your installation steps shouldn’t exist in four slightly different versions scattered across a PDF manual, web help, release notes, and an onboarding guide, each drifting a little further from the others with every update cycle.
- Conditional content: The same base content, filtered for different audiences or products. A software feature behaves differently for enterprise users than for small business users. You don’t need two separate documents. You need one source with conditions applied.
- Content variables: Product names, version numbers, company-specific terms. These should live in one place and populate everywhere automatically, so when the product gets renamed, and it will, you’re not running a frantic find-and-replace across 200 files at midnight before a release.
- Snippet libraries: Reusable warnings, legal notices, standard procedures. Write them once. Store them centrally. Stop copying and pasting and then wondering six months later which version is authoritative.
I was also surprised to see these classic techniques described again. Why are these so useful but so underutilized?
Content Reuse Approaches by Effort and Payoff
| Approach | Effort to implement | Long-term payoff |
| Snippet libraries for repeated content | Low | High, especially for compliance-heavy content |
| Variables for product names and versions | Low to medium | Saves significant time during product updates |
| Conditional content for audience filtering | Medium | Reduces duplication across product lines |
| Full single-source publishing architecture | High upfront | Very high at scale, but requires real tooling investment |
Don’t Treat New Content as the Default Answer
This is a really common fallacy on teams and companies. Because we perceive the act of writing to be more productive than the act of revising what we have, teams have meetings where they decide to “ignore the current documentation” for a new product. And it takes only one meeting to decide to start from scratch with a brand new piece of documentation, but the resulting lost time and wasted energy could have been better spent making current documentation work smarter not harder.
I don’t know why we treat creation of new content as more productive than curation of existing content, but I find this to be a very maddening bias that is so hidden that it is invisible. And I don’t see meetings where teams decide to ignore what already exists and start from scratch. Those decisions are made one by one, and usually under time pressure. It would be good to recognize this bias and do something about it. Teams that make more out of the content they have than other teams do, are not writing more content. They are just more productive with the content they have. This is not a minor change in how teams operate. This is a big change. And it has large payoffs in terms of speed, consistency, and accuracy.
There are teams of technical writers and companies making technical content work smarter not harder. And they are not making it work smarter by creating more technical content. They are making it work smarter by being less wasteful with the technical content that they already have. And that is not an easy change to make. But it is a change that will pay off in the long run, as it will allow your team to be working at a higher level of speed, consistency, and accuracy.
I wish there were a way to get around doing a content audit. I really do. But, alas, there is not. When you start to do a content audit, you have to realize that you are going to find out what you really have. And, that the content that you have been using all along for years may be still good. And, you may find out that the content that you have been trying to write from scratch all along has already been written by someone else on your team a long time ago. And, you may find out that that content was named “FINAL” or something like that. Even better, you may find out that the content was named “FINAL_v2” and you have no idea why someone would have thought that v2 was better. But, most likely, you will find out that the content that your team has been using all along for years was named “use this one” by whoever wrote it. And, you will have no idea why that person chose that piece of content over all of the other pieces of content.
