Where we're going, we don't need copies

March 15, 2026 · 5 min read

Senior Technical Editor

Welcome to my article series on technical writing! After 30 years in the profession, I’ve seen the field evolve in many ways. Over that time, I’ve learned some lessons (and made plenty of mistakes) that shaped how I work.

In this series, I share practical strategies that I hope you’ll find helpful. Feel free to adapt them to your own writing process. 🙂

From ideas to strategy

Content reuse is a popular topic in technical writing. Most tools make it easy to reuse snippets across your documentation, and you’ll find plenty of guides explaining how to set it up.

But the real challenge is often not the how, but the what.

In many cases, you won’t have the luxury of starting from scratch. Instead, you’ll be reworking and adding to existing content. So, how can you develop a reuse strategy?

Been there, took a few detours, and started again. 🤓

Here's how that played out.

The enthusiastic phase

When my team rolled out our content management system, we were really looking forward to seeing how content reuse could work in practice.

We established essential guidelines (like naming conventions and where original content should reside) and decided to hold recap meetings at regular intervals. But before formalizing detailed rules, we wanted to focus on learning through real usage.

Coming from WYSIWYG systems where reusing content sometimes felt like a moon landing, to say I was enthusiastic would be an understatement.

I reused everything that wasn’t tied down—topics, steps, definitions, snippets. You name it.

The wake-up phase

It started great.

But by the time the next major updates rolled in, we began to notice inconsistencies. Reuse set up for only a subset of definitions, reusable steps that were not applied across all impacted tasks, and small gaps that crept in everywhere.

Our content management system made it easy to handle everything on a technical level. However, it couldn’t enforce a strategy we hadn’t yet figured out.

The consolidation phase

Time to consolidate. We decided what we actually wanted to reuse and how to make reuse a standard part of our way of working.

A full overhaul would have put delivery at risk, so we focused on incremental improvements while keeping content publishable at all times.

We set aside a fixed number of hours each sprint for refactoring. Anything that didn’t fit went into a backlog for later cleanup. During regular grooming sessions, we reviewed what had accumulated and made sure the refactoring work was included in upcoming sprint planning meetings.

With that approach, we were able to get to a smoothly running system that improved consistency over time while still allowing us to deliver our content.

The strategic phase

My current phase.

Years later, I’m still using the same approach. If you’re starting with reuse, these are the places I usually begin.

I start with definitions. Every product has key terms that appear across multiple contexts. I define them in the glossary and reuse them in concept topics or procedures. That way, when a definition changes, I only need to update it once and know it’s consistent everywhere. Added bonus: this ensures that all key terms are included in the glossary.

Next, I look at navigation steps and menu paths. For those, I usually create a central topic that contains the reusable steps. Other topics reference that content instead of repeating it. This way, I avoid multiple variations of the same content. Added bonus (actually, two): users see the same instructions everywhere, and it becomes much easier for me to spot inconsistencies in navigation paths.

I also reuse admonitions whenever possible. Notes, tips, and warnings often reappear in different contexts. If the same hint appears in multiple places, I reuse it. This keeps my guidance consistent, reduces errors, and builds trust with my readers.

Finally, I look beyond small pieces. Some topics, like setup instructions or conceptual overviews, apply across audiences or product lines. I treat those as shared building blocks and handle small differences with variables or conditional text. This keeps the information consistent while reducing maintenance effort across projects.

My advice

Take it slow. You won’t get everything right the first time. Prioritize what matters most, build incrementally, and your content will improve steadily. Effective reuse is all about balance. In this case, the balance between centralizing content and keeping it maintainable.

Thanks for reading! I hope that with these methods, you feel a bit more confident when setting up a reuse strategy. For those interested in exploring further, I’ve compiled a list of related resources from the technical writing community, which I hope you’ll enjoy.