His comment was fair — and also useful. The kind of useful that stings a little at first, which is often how useful arrives.

I believe Byron’s main point was this: the symptoms I described are familiar to anyone who has watched a wiki mature, decay, multiply, contradict itself, and eventually become the place where institutional knowledge goes to develop several competing personalities.

Contradictory pages. Stale search results. Important information hiding in old Slack threads. Authoritative guidance living in three places, each one slightly different and all of them confident.

He agreed those problems are real. Where he pushed back was on my diagnosis.

He argued that wiki rot is not really a property of the tool. It’s a property of the organization (or lack thereof, as the case may be). Replace Confluence with a component content management system, a docs-as-code pipeline, or a shiny knowledge delivery platform, and a team without governance will still produce scattered, contradictory, half-maintained content.

He’s right about that.

A bad ownership model will damage any system. As will a missing review cadence, weak or non-existent taxonomy or a lack of discipline. Authoring incentives that reward speed over maintainability invite challenges, and software doesn’t fix organizational misbehavior — because tools don‘t typically attend meetings, resolve accountability issues, or gently remind someone that copying the same warning into twenty-seven places is not a sustainable reuse strategy. It is a future incident report, at best.

That part of Byron’s critique lands.

But there’s another part of the argument that still matters, especially for tech writers. Governance matters. Culture matters. Ownership matters. But so too does tool category.

A collaborative wiki is not the same thing as a component content management system (CCMS).

And pretending those two categories are interchangeable is one reason documentation teams end up disappointed.

I Could’ve Been More Precise

Byron also called out my use of “knowledge management system” to describe Confluence. He said that was sloppy. He’s right.

I didn’t intend to say Confluence is a knowledge management system. What I meant is that many organizations use Confluence as though it were one.

That distinction matters.

Confluence is a collaborative wiki and team workspace. Atlassian describes it as “your team workspace for creating and sharing knowledge” and also markets it under wiki use cases as “The original Wiki.” Additionally, the company has a page that describes Confluence as knowledge management software, which helps explain why organizations often blur the categories in the first place.

So yes, I should have said this more clearly: Confluence can support some knowledge management practices.

That doesn’t make it the same category of tool as a purpose-built component content management system.

The Problem Isn’t ‘Confluence Bad, CCMS Good’

Let’s get the lazy argument out of the way. The problem is not “Confluence bad, CCMS good.”

A well-governed wiki may outperform a poorly governed CCMS. No argument from me. I’ve seen expensive systems become beautifully structured disasters because no one wanted to make hard decisions about ownership, authority, metadata, workflow, reuse, review, or retirement.

That’s the point technical writers need to hold onto.

Governance determines whether the system succeeds.

The platform determines which governance model is practical, enforceable, scalable, and economically sustainable.

Those are not the same claim.

A Wiki Usually Manages Pages — A CCMS Manages Content Components

A collaborative wiki usually organizes content as pages. Teams create pages, edit them, and link them to other pages. They may also use the wiki to comment on pages, search them, and sometimes archive them if the organization using the wiki is unusually disciplined (or frightened by auditors).

That page-based model works well for many kinds of collaboration. It’s great for meeting notes, project planning, informal docs, lightweight processes, internal updates, and shared workspaces where the main goal is to get people contributing quickly.

But tech docs often requires different content models.

A component content management system manages content in smaller, structured, reusable units. Paligo describes a CCMS as software for “creating, managing, and publishing technical documentation through reusable content components,” where content is built from individual elements that can be assembled and reused across publications.

That difference is not academic. It changes what a system can do.

In a CCMS, a warning, prerequisite, troubleshooting step, safety statement, API parameter description, legal disclaimer, product specification, or reusable procedure can be managed as a component rather than as copied text scattered across a collection of hypertext-linked pages.

When the source component changes, the change can flow to every publication where that component appears. That’s not just “better governance.”

That’s a dramatically different technical capability.

Transclusion Isn’t ‘Exactly’ The Same Thing As Systematic Reuse

This is where the conversation gets more interesting. Someone might say, quite reasonably: “But wikis can do reuse. They can transclude content.” That’s true.

Transclusion is a mechanism. It allows one piece of content to appear inside another piece of content by reference. The source content lives in one place, and other pages display or publish it as though it lives there too.

That’s useful. It is much better than copy and paste. It can reduce duplication. It can help teams maintain shared content more consistently.

In the book, The Language of Technical Communication, Eliot Kimber explains that

Transclusion is not exactly the same thing as systematic reuse.

Ann Rockley’s concept of systematic reuse is broader. In Managing Enterprise Content, Rockley distinguishes systematic reuse from opportunistic reuse. Systematic reuse is planned.

That distinction matters.

Transclusion asks: “Can I include this content over there?”

Systematic reuse asks: “How do we design, govern, track, update, assemble, translate, and deliver reusable content across the entire content lifecycle?”

Those are related ideas, but they are not identical.

A wiki with transclusion can include content by reference. A CCMS is usually built around systematic reuse as an operating model.

That means reusable components aren’t just snippets that appear in multiple places. They are governed units of content with structure, metadata, ownership, version control, lifecycle state, translation status, and publishing behavior.

For tech writers, that difference matters because reuse isn’t just a convenience. It’s a control strategy.

Copy-and-Paste Reuse Isn’t Efficient Reuse

This is one of the places where the wiki-versus-CCMS distinction becomes obvious.

In a wiki, reuse often happens through copying, linking, embedding, transcluding, or manually referencing another page. Depending on the wiki and configuration, teams may create clever reuse patterns. Some teams do this well.

But in many organizations, not so much. Reuse becomes copy-and-paste focused. Someone writes a warning in one place. Another writer copies it into a second procedure. A third person revises it for a different product.

Six months later, support asks which version is correct. Nobody knows. Someone says, “Check Slack.” A small bird flies into a window. 🪟

A CCMS approaches reuse differently. It can track the source component, where that component is reused, which version appears in which publication, and what must be updated when the source changes.

That matters for documentation pros because we are rarely managing one page at a time. Typically, we’re managing content across products, versions, audiences, channels, languages, regions, and release cycles.

Those are related activities, but they are not the same activity.

Structure Isn’t Decoration

Another difference is structured authoring. In a wiki, structure is often social. Teams agree to templates, labels, page hierarchies, naming conventions, and review practices. That can work, but much of the — a-hem — enforcement depends on human discipline.

In a CCMS, structure can be built into the authoring model. This means the system can enforce rules about what kind of information belongs where. A task can require steps. A concept can be kept separate from a procedure. A warning can use a defined structure. Metadata can be required before publication. Content can be validated before it goes downstream.

For tech writers, this is especially important in AI-enabled environments. When our content is ambiguous, inconsistent, duplicated, or poorly typed, AI systems have to infer what the content means. They have to guess whether something we typed is a concept, task, warning, exception, prerequisite, policy, release note, workaround, or obsolete instruction.

Sometimes the system guesses correctly. Sometimes it produces confident nonsense.

The more explicit the structure, the less the system has to infer. And the less it has to infer, the better chance we have of getting accurate, grounded answers.

Delivery Is Part Of System Design, Not An Afterthought

Collaborative wikis are often strong at internal authoring and knowledge sharing. They help people easily create and find pages. They support quick collaboration, comments, permissions, search, and history.

Those are useful capabilities. But documentation often has to go further.

A CCMS is usually specifically designed not just to store content, but to publish it in multiple forms: help sites, PDFs, portals, knowledge bases, release packages, training materials, in-product help, support content, and other outputs.

Related reading: Multi-channel publishing

That publishing model matters.

A tech docs team may need to deliver different versions of the same core content to different audiences. Administrators get one version. End users another. Partners get a slightly different version. Regulated markets need region-specific language. Enterprise customers need content for supported versions. Internal support teams may need additional troubleshooting details that should not appear in public documentation.

In a wiki, those variations often become separate pages, labels, manual conventions, or permission schemes.

In a CCMS, those variations can be managed through structured reuse, profiling, filtering, conditions, metadata, and publishing rules.

Again, this is not just governance. It’s governance made operational through system capability.

Localization Exposes The Difference Quickly

Localization is another place where the distinction becomes hard to ignore.

If your docs lives as pages, translation often happens at the page or document level. When content changes, you may need to determine what changed, where it changed, whether the change affects translated content, and which language versions need updates.

In a component-based system, the unit of management can be (and typically is) smaller. If only one reusable component changed, only that component may need translation. If the same component appears in multiple outputs, the translation can be reused as well. That can significantly reduce cost, improve consistency, and shorten translation cycles.

It also reduces the risk of slightly different versions of the same instruction appearing across products, regions, or languages. For global tech docs teams, that’s not a minor feature — that’s operational infrastructure.

Byron Is Right About The Organizational Problem

The strongest part of Byron’s argument is the part documentation teams should not ignore: Documentation problems are often organizational problems.

I agree.

Tools cannot:

👉🏼 decide who owns a procedure
👉🏼 decide when content becomes obsolete
👉🏼 force product managers to stop treating documentation as a release-day garnish
👉🏼 create a culture that rewards maintainability, clarity, and reuse

If an organization doesn’t value documentation governance, a CCMS won’t save it. Neither will docs-as-code or an AI chatbot with a soothing interface and a suspiciously cheerful answer to everything.

Doc teams need ownership models and review cadence. They need taxonomy and metadata discipline. and rules that govern content throughout its lifecycle. And, they need to put in place incentives that reward reuse and maintenance, not just new content production.

That is the foundation. Byron is right to insist on it.

But Tool Category Still Matters

Where I differ from Byron is that I don’t think tool category is secondary to the point of irrelevance. Platforms shape what’s easy, what’s difficult, what’s enforceable, and what is likely to happen under pressure.

And pressure is where documentation systems reveal themselves.

👉🏼 When the release is late, do writers reuse approved content or copy and paste from the nearest page?
👉🏼 When support finds an error, can the team update one source component or hunt down every duplicate?
👉🏼 When legal changes a required statement, can the team trace every place it appears?
👉🏼 When a product has three supported versions, can the team publish version-specific content without maintaining three separate page forests?
👉🏼 When AI retrieves content to answer a customer question, can it tell which content is current, authoritative, audience-appropriate, and product-specific?

Governance defines the desired behavior. The system determines how much effort it takes to behave that way. That’s why tool category matters.

Hopefully, A Better Way To State The Argument

After reading Byron’s comment, I’d restate my argument this way:

Then they act surprised 😱 when those systems cannot provide the same control, reuse, traceability, lifecycle management, localization support, and multi-channel publishing capabilities as systems built for those purposes.

Confluence can be a good fit for small teams, internal collaboration, project knowledge, lightweight documentation, and shared workspaces. A self-hosted wiki may also be a good fit for organizations with the engineering capacity to maintain it, customize it, secure it, and govern it properly.

Byron is right to point out that SaaS platforms bring real costs, including per-seat pricing, vendor roadmap dependency, migration complexity, and data control concerns. Those tradeoffs deserve serious discussion. But none of that changes the underlying distinction.

A collaborative wiki and a CCMS are different categories of tools. One is primarily optimized for collaborative knowledge creation and sharing. The other is designed to manage structured, reusable, governed content components through complex creation, review, translation, versioning, and publishing workflows.

You can govern a wiki well. You can also govern a CCMS badly. And, you can use transclusion in a wiki and still not have a systematic content reuse strategy you can depend on. 🤠

Silence follows. Not normal silence. Corporate silence.

Documentation Chaos Rarely Looks Expensive At First

This is how operational inefficiency announces itself inside technical documentation teams. Not dramatically. Not with alarms. Not with smoke pouring from the walls. It arrives quietly, disguised as “the way we’ve always done things,” right up until the organization realizes it’s spending enormous amounts of money compensating for chaos nobody formally agreed to maintain.

A writer spending twenty minutes hunting for the latest approved procedure doesn’t sound catastrophic. An engineer answering the same support question for the ninth time this week seems manageable. A product manager manually reconciling conflicting documentation versions before release feels annoying but survivable.

Then the organization repeats those activities thousands of times a year.

Suddenly, entire salaries disappear into administrative fog.

The Shared Drive Is Not A Strategy

Tech docs teams often exist in places where every other department evolved operationally while documentation was left sitting beside the highway holding a three-ring binder and blinking into the sun.

Engineering has automation pipelines. Security has governance frameworks. Infrastructure teams have observability dashboards that resemble NASA launch controls.

Meanwhile, the documentation operation may still rely on filenames like: FINAL_v2_USE_THIS_ONE_REAL.docx

There’s always at least one of those. Usually seven. Maybe eight.

Skilled Workers Shouldn’t Be Content Janitors

PagerDuty’s research on operational inefficiency emphasizes the cost of downtime, repetitive work, technical debt, and highly skilled employees spending time on preventable friction.

Tech writers understand this instantly because many of us spend absurd amounts of time doing work that has almost nothing to do with writing.

We’re reconciling duplicate content, chasing approvals, rebuilding broken publishing workflows. And, in our copious free time — ha! — we manage to find space to copy and paste information between systems that absolutely should’ve been integrated sometime during the first iPhone administration.

As highly trained knowledge pros, we end up functioning like anxious wedding planners for content nobody wanted to govern properly in the first place.

The Buckets Were Never The Roof

Organizations convince themselves this arrangement is “cost effective” because they delayed purchasing better systems or avoided operational redesign. This is a little like refusing to repair our roof because buckets are technically cheaper.

Sure. For a while. Then mold arrives.

Documentation Bottlenecks Become Business Bottlenecks

The downstream effects spread everywhere. Our support teams inherit the confusion first because customers always discover content problems before executives do.

Then, with good intentions, sales engineers start creating their own shadow documentation because they can’t trust the official versions and fear that it may hamper their ability to seal a deal. Training departments subsequently join in by inventing workaround content, while product teams answer repetitive questions that shouldn’t be eating up anyone’s time.

Eventually, the organization becomes a kind of accidental content hoarding operation where five departments maintain slightly different versions of organizational “truth.”

Then AI Walks Into The Mess

For years, humans compensated for operational dysfunction through instinct and memory. Someone always knew where the “real” answer lived. Someone remembered which warning was outdated, understood that the installation procedure only worked if you ignored steps four through six instead.

AI systems don’t possess this survival instinct. They consume whatever content ecosystem exists in front of them with the confidence of a suburban dad assembling patio furniture without reading instructions.

If the source material is fragmented, inconsistent, duplicated, outdated, or poorly governed, AI scales those problems beautifully and rapidly; at enterprise speed.

AI Readiness Is Really Content Operations Readiness

Organizations everywhere are now discovering that “AI readiness” doesn’t merely involve purchasing software licenses and holding inspirational town halls about innovation.

It requires operational maturity. Governance. Metadata discipline. Clear ownership. Structured workflows. Lifecycle management.

In other words, all the things documentation teams have been trying to explain politely for the past fifteen years while someone from procurement asked whether Markdown could “just handle most of this.”

Related reading: How to Build a Content Operation

Burnout Is An Operational Signal

Operational immaturity also creates a human problem companies routinely underestimate. Burnout.

Documentation burnout is quieter than someone throwing a badge onto a conference table before storming out into the rain. It accumulates slowly through endless context switching, duplicate work, approval bottlenecks, emergency publishing requests, and systems that behave like abandoned carnival rides.

People stop feeling strategic. They start feeling administrative. Worse, they start feeling invisible.

Functional Enough Is Where The Money Goes To Die

The most dangerous documentation operations aren’t the obviously broken ones. Those are easy to identify. The dangerous ones are “functional enough.”

Functional enough to:

• avoid executive scrutiny

• limp through another release cycle

• keep producing outputs while quietly draining productivity (slowing onboarding, increasing support costs, weakening AI reliability, and exhausting the humans trapped inside the machine)

The Real Cost Is Paid Every Day

That’s the hidden cost of operational inefficiency. Not one catastrophic collapse. Just thousands of tiny operational taxes paid every day by people whose jobs could’ve been dramatically easier if someone had treated documentation content operations like infrastructure instead of decorative office shrubbery.

Eventually organizations realize the truth. They didn’t merely build a documentation team. They accidentally built a sprawling enterprise knowledge system held together with Slack threads, tribal memory, and emotional optimism.

And now AI is reading all of it aloud. 🤠

Then they’ll ask which source it used, whether that source was current, who approved it, whether it had been translated, rewritten, reused from another product, or lightly “improved” by someone who was mostly trying to get to lunch.

That’s when metadata starts looking a little lonely.

While Metadata Helps Us Find Things‚ Paradata Helps Us Explain Them

Tech writers have spent years learning to care about metadata. We tag content by product, audience, version, region, language, task type, and anything else we can persuade the system to remember.

That work matters. Metadata helps content move, surface, filter, and behave like it was raised properly.

But metadata doesn’t tell the whole story.

It can tell you that a topic is for administrators using version 6.2 in North America. It usually won’t tell you that the topic was stitched together from old release notes, edited by three people, reviewed after a support escalation, machine-translated, rewritten with AI, and approved by someone who clicked the button because the meeting was starting.

That missing story is paradata.

Paradata Is Our Content’s Backstory

Paradata is info about the process behind the content. It tells us (and the machines upon which we rely) how something was created, reviewed, revised, transformed, approved, reused, translated, or generated. It’s not the content itself. It’s not just the labels around the content. It’s the trail of decisions and actions that explain how the content became what it is.

Paradata is the receipt. And our documentation needs receipts now.

Read more

We open our repository and think, “This is it! This is awesome. It’s exactly what we need today.”

And then time passes. ⏰ Quietly. Patiently. Like a houseplant you forgot to water.

What Metadata Rot Looks Like When It Sneaks Into Technical Documentation

Metadata rot sounds technical, but it’s not.

It’s what happens when the labels, tags, and descriptors attached to our technical documentation stop reflecting reality. The product names change, but the tags don’t. The audience shifts, but the metadata keeps insisting this guide is “for beginners.” Versions drift. Status labels lie.

Nothing breaks all at once. Instead, our doc set slowly becomes a beautifully organized record of things that are no longer true.

How Metadata Rot Happens

It usually starts with good intentions and a meeting that includes the word “governance” said with a straight face.

👉🏼 There’s a taxonomy
👉🏼 There are required* fields
👉🏼 Someone even makes a slide about “future-proofing”

And, here’s the important part —> for a while, it works.

👉🏼 Then deadlines show up
👉🏼 New features ship
👉🏼 Someone clones an old topic and forgets to update the metadata (oops!)
👉🏼 Another writer picks the closest tag and hopes for the best 🤞

The taxonomy doesn’t evolve because nobody owns it anymore — or worse, everybody thinks somebody else does. And just like that, our docs become less of a system and more of a suggestion.

Read more

It is tempting to look at AI when things start to feel inconsistent. The outputs are uneven. Sometimes outdated. Occasionally just wrong. The natural reaction is to focus on the technology. Improve the model. Refine the prompts. Invest in better infrastructure. I had a version of that reaction myself when generative AI first emerged. After spending years building businesses around content and knowledge management, my initial instinct was that this shift might disrupt everything. But the more I worked with these systems, the more it became clear that AI was not introducing a new problem. It was exposing one that had been there all along.

Most organizations have been operating with fragmented knowledge for years. Different teams maintain different versions of the same information. Content gets updated in one system and missed in another. Context evolves, but documentation often stays frozen in time.

Over the past twenty five years, working with enterprises on knowledge management and content strategy, I have seen this pattern repeat itself in different forms, but with the same underlying issue.

People adapt in practical ways

They ask colleagues instead of trusting systems. They may keep their own notes. They often build informal sources of truth that feel more dependable than the official ones. These workarounds keep things moving, but they slowly erode confidence in the systems that were meant to support them.

When AI enters that kind of environment, it behaves very differently than a person would. It does not navigate uncertainty. It tries to resolve it. It pulls from multiple sources, reconciles conflicting inputs, and produces an answer with confidence. That is where the issue becomes visible in a way it never was before. The uncertainty that used to sit quietly in the background is now embedded directly in the output. And people notice.

Most organizations respond by trying to improve how information is structured. They invest in better organization, better retrieval, more sophisticated systems. All of that matters. But it rests on an assumption that often goes unchallenged, that the underlying information is correct. In my experience, that is rarely the case. The real gap is not structural. It is factual. Which statements are accurate, which are outdated, and which are missing context that changes their meaning. Until those questions are addressed, AI will continue to reflect the inconsistencies within the knowledge it consumes.

[Webinar] Destroy Enterprise Knowledge Chaos for Hallucination-Free GenAI

This is where the idea of Truth Curation begins to take shape. Not as another layer of organization, but as a process for validating what is actually true across an organization.

AI can be used to scan content at scale and surface conflicts, inconsistencies, and gaps. It can highlight where information does not align or where context is incomplete. But resolution still depends on human judgment.

Subject matter experts step in to validate, revise, and align what the system surfaces. They update what is incorrect, clarify what is ambiguous, and remove what is no longer relevant. It becomes a more focused use of expertise, applied where it has the most impact.

What follows is not dramatic, but it is meaningful. Employees begin to trust the systems they rely on. They spend less time double checking information. They rely less on informal workarounds. And AI starts to perform the way it was expected to, not because the model changed, but because the foundation did.

After more than two decades working at the intersection of knowledge management and AI strategy, this is the pattern I keep coming back to. Organizations do not suffer from a lack of information. They suffer from a lack of trusted information.

A useful shift in perspective is this. Instead of asking how to make AI more effective, ask whether the information it relies on is something your organization can confidently stand behind. That is where meaningful progress begins. 🤠

Jason Kaufman is an AI strategist, entrepreneur, and technical communication expert with more than 20 years of experience in knowledge management, enterprise AI integration, and content strategy. He is the CEO and co-founder of Zaon Labs and serves as President of Irrevo, where he helps organizations apply generative AI to content operations, enterprise knowledge management, and workflow automation.

Kaufman is a frequent speaker and educator on AI-enabled content strategy, prompt engineering, and the future of technical communication.

• Can customers search for it?

• Can support agents navigate it?

• Can the PDF open without Adobe Reader having an emotional collapse?

Meanwhile, AI showed up, kicked the office door open like a kangaroo hopped up on espresso, and changed the entire game.

Now the question isn’t whether humans can find the information we create. It’s whether machines can interpret it correctly before confidently lying to everyone.

That’s the hidden message buried inside Suraj Desai’s presentation on AI-powered retrieval systems.

At first glance, the talk looked deeply technical. Retrieval pipelines. Vector databases. Agentic loops. BM25 ranking. Taxonomy structures. Enough acronyms to make a tech writer briefly consider a career in artisanal candle-making.

But underneath all that infrastructure talk was something much more important:

Technical documentation is no longer just content. It’s training material for reasoning systems.

And if our docs are messy, ambiguous, contradictory, poorly structured, or missing context, AI systems don’t simply “struggle” with it. They hallucinate with confidence.

The LLM Likely Isn’t The Problem

One of the most important things Suraj said during the webinar was this:

“The LLM didn’t fail. The retrieval did.”

That sentence should probably be tattooed somewhere inside every enterprise knowledge management initiative currently stapling a chatbot onto ungoverned documentation and hoping for the best.

Because most AI failures in documentation systems are not actually language failures.

They’re retrieval failures.

The AI isn’t inventing nonsense because it woke up feeling creative. It’s inventing nonsense because the retrieval system handed it incomplete, conflicting, or irrelevant information.

In using traditional docs, humans compensate for weak structure surprisingly well. We:

• Infer meaning

• Notice context clues

• Realize “Paris” probably means France if the conversation is about European vacations

Machines don’t do that naturally. Which means every ambiguity tech writers leave in the docs becomes a possible retrieval failure later. And retrieval failures scale beautifully. That’s the terrifying part.

Read more

And then reality shows up, sits down across from us, and quietly explains that we’ve just become our own finance department, sales team, IT support desk, and emotional support animal.

Lauren Pope’s post — What being self-employed in content really looks like — pulls back the curtain on what self-employment in content actually looks like — not the LinkedIn version, the real one. For tech writers flirting with the idea of going solo, there are some lessons here you. Read these before you dramatically quit your job.

Lesson 1: Your Income Is Not Your Income

Freelance math is not normal math. We might invoice what looks like a comfortable annual income, but we’ll take home roughly half after taxes, expenses, and the need to survive slow periods.

Also, no one is quietly contributing to our retirement while we sleep, either. That’s now our job. Along with insurance. And software subscription costs that multiply like rabbits when we’re not paying attention.

Translation for tech writers: That shiny day rate you’re imagining? Cut it in half before planning your new life as a financially stable rebel.

Lesson 2: You Don’t Have Clients, You Have a Portfolio of Risk

You’ll rarely have one steady stream of work. More often, you’ll be juggling two or three projects at a time, trying to balance focus with income stability.

Too few clients? You panic.
Too many clients? You do bad work and still panic.

And the kind of deep, strategic work many tech writers aspire to — content models, governance, structured content — requires long stretches of uninterrupted thinking. That doesn’t pair well with a calendar that looks like a game of Tetris.

Lesson 3: Work Comes From People, Not Platforms

Forget the fantasy of “I’ll just hang out a shingle and clients will appear.”

Ha! Not so much.

Most work comes from:

• People who already know us

• People who’ve worked with us

• People who’ve read our stuff or who we’ve otherwise engaged

Word of mouth and reputation do most of the heavy lifting. Cold outreach? Advertising? Optional — and often ineffective depending on our niche.

Translation for tech writers: Our content isn’t just docs anymore. It’s marketing. Every blog post, webinar, or conference talk is quietly auditioning for our next client.

Lesson 4: The Market Doesn’t Care About Your Timing

We can be well-intentioned and do everything “right” and still have a bad year.

Budgets shrink. Strategy cycles end. Work dries up. We get sick. A project goes sideways and takes our sanity with it.

And here’s the fun part: when things go wrong, it feels personal. Because there’s no company to blame. It’s just us, staring at our insufficient pipeline of upcoming work.

Lesson 5: You Must Specialize

Pope’s work leans heavily into content strategy, even though she still offers related services. That’s not an accident — it’s survival.

Clients don’t buy “a technical writer.” They buy someone who solves a very specific problem.

Translation for tech writers:
“Writes clear documentation” is not a niche. “Designs scalable content models for API platforms” is getting closer.

Lesson 6: Pricing Is Part Courage, Part Therapy

Most freelancers undercharge. Especially early on. My advice? Charge as much as you can without feeling physically ill — and then maybe a little more.

But don’t be delusional. Benchmark against peers. Understand the market. Then push yourself anyway.

It’s a struggle for many of us starting out to avoid allowing personal price sensitivity to impact our feelings about our worth. Sometimes, freelancers I’ve mentored undervalue their expertise because what they think they should charge sounds expensive, so they opt to charge less thinking this is how they will get the gig (by not charging too much — whatever that is).

If we don’t price your time and talents wisely, we’ll quietly build a business that looks busy but pays like a hobby.

Lesson 7: You’re Not Escaping Work — You’re Redefining It

Self-employment isn’t less work. It’s different work. You’re still writing, designing, structuring, and solving problems.

But now you’re also:

• Managing cash flow

• Finding clients

• Negotiating contracts

• Deciding what work to take (and what to walk away from)

The upside? We get to shape our careers around our values, interests, and make decisions that don’t overwhelm our tolerance for nonsense.

The downside? We have to shape it. No one else is coming to do that for us.

What This Means For Tech Writers

Thinking about going freelance? Here’s the quiet truth:

We’re not just becoming an independent writer. We’re becoming a small business that also happens to produce content.

And the skills that will matter most aren’t just:

• writing clearly

• structuring information

• managing content systems

Instead, they’re:

• positioning our expertise

• building relationships

• managing uncertainty

• differentiating ourselves from the competitions

• pricing our value

• managing work-life balance

In other words, the work doesn’t get easier. It gets broader.

The Takeaway For Tech Writers

Self-employment can absolutely give us the career we wish existed. But it will also expose every weak spot in how we think about money, value, visibility, and resilience.

Which is why posts like this matter. They replace the unrealistic fantasy we conjure up ourselves with something far more useful: A map that says, “Yes, we can do this. But here’s what it actually costs.” 🤠

You search your internal docs in Attlassian Confluence and get six results. Three are outdated. One contradicts another. One links to a Slack thread from 2022 where someone named “Dan (Contractor)” says, “I think this is how it works?” The last one looks promising (until you realize it describes a feature your company quietly killed last quarter.)

So you do what everyone does. You ask for help in Slack.

Five people respond. Two disagree. One says, “Let me check.” Another drops a link… to one of the six pages you already read — the same one you linked to in your Slack query.

And just like that, your documentation system has completed its transformation from “source of truth” to “suggestion box.”

This didn’t happen overnight. It never does.

Why Confluence Worked (Until It Didn’t)

Let’s be fair. Confluence didn’t betray us. It did exactly what we needed at the time.

It’s fast and somewhat flexible. It lets pretty much anyone write nearly anything, almost anywhere, at any time. In the early days, that felt like progress. We were moving quickly, building features, hiring people, figuring things out as we went. Structure felts like a luxury we couldn’t afford back then.

And for a while, that was true.

When our team was small and our content footprint was manageable, we didn’t need governance (or so we thought); we needed speed. We wanted a place to put things so they wouldn’t disappear into someone’s brain forever.

Confluence was great at that. Right up until it wasn’t.

The Moment Things Start to Slip

The shift here is subtle. We didn’t wake up one morning and declare, “Our documentation system has failed us.” Instead, we started noticing small things.

People stopped trusting the docs. They began double-checking everything. They asked questions they shouldn’t have to ask and when they figure out what they needed to know they often created new pages in the wiki instead of updating old ones because it’s faster than figuring out what’s already there.

Our content was growing, but its usefulness wasn't.

That’s the moment our “flexible” system becomes an unmanageable one.

The Signs You’ve Outgrown Your Setup

What should we do, you ask? Well, first, we don’t need a formal audit to know something’s off. We just need to pay attention to the patterns that can help us identify the obstacles and challenges our internal documentation content hairball introduces.

Do we know if there’s a problem?

We can often easily see the signs of internal documentation problems. Docs contradict themselves. There’s no clear source of truth, just a collection of “maybe, probably correct” answers. Pages linger long after they’ve expired, like leftovers no one wants to claim. Subject matter experts rewrite entire sections instead of updating them, because it’s easier than untangling what came before.

Search becomes a scavenger hunt. Results are plentiful but not helpful. Navigation reflects how our org chart is structured, not how people actually think. Users bypass documentation entirely and head straight to Slack, where answers are fresher — even if they’re not better.

Scaling becomes awkward. The same information appears in multiple places because reuse isn’t a thing our team has made an effort to make systematic — it’s a wish, at best. Localization feels like a fantasy. Publishing content to different channels involves copying, pasting, and a quiet prayer that nothing breaks.

Governance, if it exists at all, is mostly implied. Anyone can publish anything. Review cycles are optional. Versioning is… optimistic.

And then there’s the AI problem.

We point a generative AI tool at our documentation, expecting magic. 🪄 What we get instead is a confident stream of half-truths, contradictions, and occasionally inspired fiction. The AI isn’t broken. It’s doing exactly what it’s supposed to do — summarizing messy and ungoverned input into equally messy output.

Turns out, chaos in equals chaos out.

What It’s Actually Costing You

Here’s the part no one likes to say out loud: we’re already paying for this problem.

We’re paying in time; every minute someone spends searching, second-guessing, or rewriting content that already exists somewhere. We’re also paying in expensive onboarding delays, as new hires struggle to separate fact from folklore.

And, we’re paying in support costs, because people can’t find answers that should be obvious. We’re also paying in product friction, when users don’t understand what we’ve built well enough to use it or explain it to others.

And if we’re exploring AI (who isnt?), we’re paying there, too; unreliable content doesn’t magically become reliable when we run it through a language model. It just becomes faster at being wrong.

So What Are “Professional Tools,” Really?

This is where people get nervous, because it starts to sound like a tooling conversation. And tooling conversations have a reputation for turning into expensive shopping trips.

But this isn’t about buying something shiny. It’s about capabilities.

At a certain scale, we need content that’s structured, not just written. Modular, not monolithic. Reusable, not endlessly duplicated.

We need workflows that ensure our content is reviewed, approved, and maintained; not just created and forgotten.

We need metadata and taxonomy so our information can be found, filtered, and delivered in ways that make sense to our users.

We need the ability to publish the same content across multiple channels without copying and pasting it into oblivion. And increasingly, we need content that machines can understand (not just humans) so AI systems can retrieve accurate, grounded answers instead of improvising and getting it wrong.

There are different ways to get there. Component content management systems. Docs-as-code environments. Knowledge delivery platforms.

The specifics matter less than the outcome.

We’re moving from “a place where we store information” to “a system that manages, governs, and delivers knowledge.”

Making The Business Case Without Sounding Like We Just Want New Toys

If we walk into a meeting and say, “Our team needs a new documentation platform,” we’ll get exactly the reaction we deserve. 🫤 Blank stares. Budget concerns. Someone asking if this can wait until next year (or the year after).

So don’t pitch a tool.

Start with evidence. Show the broken pages. The conflicting information. The Slack threads that exist because the docs failed.

Then translate that into cost. Not abstract cost — real cost 💰. Time lost. Support tickets created. Delays introduced.

Tie it to business goals like faster onboarding, improved customer experience, more reliable AI initiatives, or reduced support burden.

And for the love of all things sensible, don’t propose a massive migration as the opening move. Start small by piloting something. Prove that a better approach produces better outcomes by making the problem clearly visible to those who should care before trying to sell the solution.

A Quick Reality Check About Migration

Let’s not pretend this part is fun. Migration means cleanup and confronting the fact that some of our content shouldn’t make the journey. It means defining governance (where none existed before) and asking people to change how they work.

The reality here: There will likely be resistance. There’ll be moments when you question your life choices. But there’s also an upside.

Migration is the one time we’re allowed — expected, even — to fix what’s broken instead of working around it. And we don’t have to fix everything at once. In fact, we shouldn’t.

One Question to Ask Yourself Before You Do Anything Else

If our entire team disappeared tomorrow, would someone else be able to rely on our documentation to run the business? Not “eventually figure it out.” Not “after asking a few questions.” Actually rely on it.

If the honest answer involves Slack, guesswork, or crossing your fingers, well … there’s work to do.

The Quiet Shift No One Talks About

At some point, documentation stops being a side effect of building a product and becomes part of the product itself (whether anyone recognizes that or not). When that happens, the tools we use (and the way we manage content) stop being a convenience decision. They become a business decision.

And that’s usually right around the time Confluence starts to groan.

Not because it’s broken — but because we’ve asked it to do a job it was never designed to handle at scale.

We don’t notice the shift right away. We just feel the friction and watch as the extra minutes spent searching tick by. We also feel the second-guessing and the quiet erosion of trust, until one day, the system we relied on to keep us aligned is the thing slowing us down.

At that point, the question isn’t whether we need to change. It’s how much longer we’re willing to pay for not changing. 🤠

Now imagine that feeling set to reggae.

“I Feel Your Pain” by Thomas Aldous (assisted by AI) is basically your workday with a beat. Deadlines shifting, tools changing, “quick updates” multiplying like rabbits — it’s all there. And somehow, it’s both funny and a little too accurate.

The line that lands hardest?

“Nobody sees the little saves…”

That’s the job. Quiet fixes. Invisible wins. Preventing chaos no one realizes almost happened.

“I Feel Your Pain” by Thomas Aldous

Then it sneaks in something bigger: we were structuring knowledge, modeling systems, and making meaning long before AI showed up. That hasn’t changed.

AI can generate words. It still depends on people who know what those words mean.

So yeah — give it a listen. If nothing else, it’s three minutes of feeling seen… without having to update a screenshot. 🤠

The past two centuries represent an extraordinary leap in scientific discovery and technological innovation across virtually every domain of human endeavor. The preoccupation of scientists and researchers during that era was, understandably, to document and explain these phenomena (they were genuinely novel, and capturing them was paramount). This has always been the nature of knowledge: record it, explain it, and pass it on from one generation to the next.

But does our current era resemble that past? Should we continue producing the same kind of output: text-based documentation, mathematical equations, and static diagrams? At a minimum, perhaps things will proceed regardless.

Yet today, science and technological advancement are no longer external discoveries that arrive for the first time; they are embedded in the very fabric of society. We live and work within them. This growing familiarity changes the equation. When technical content continues to be delivered in the same mode that once served a world encountering these ideas for the first time, it inadvertently signals that the subject is still unfamiliar, still demanding, still requiring special mental preparation.

This has practical consequences at several levels in education, training, and technical writing:

1. Comprehension without ownership: Someone can understand information perfectly well and still never feel like it’s really theirs. They may follow it, repeat it, even use it correctly, without ever feeling invited to build on it, question it, or do anything creative with it. Traditional technical content often does this by treating knowledge as something to hand over, not something to step into. Research on motivation and learning backs up the broader point: the way information is framed affects whether people feel agency, engagement, and room to think for themselves.

2. The psychological weight of the “technical” aesthetic: Technical content often looks like it expects you to brace yourself before you even start. Dense paragraphs, cramped tables, and diagram-heavy pages can signal, at a glance, that this is going to take work. That look alone can raise the mental cost of entry. The issue isn’t just style. Research on cognitive load shows that the way information is designed and presented affects how hard it is to process, and interface design research shows that presentation choices can either support thinking or make it harder.”

3. The non-technical stakeholder gap: Technical content is often built for the specialists in the room and then shown to everyone else as if that were good enough. It usually isn’t. Project managers, business leaders, and other non-technical stakeholders may catch the outline while missing the substance, which leaves them less able to challenge assumptions, spot risks, or contribute with confidence. Research supports the broader point that clearer, more accessible presentation helps people from different backgrounds understand complex material and participate more effectively in decisions.

A Different Framework: From Information Delivery To Experiential Communication

These three problems share a common root: they arise when technical content is designed as a delivery mechanism for information rather than as an experience that invites the reader in. Addressing this requires a shift in how we conceive the relationship between the reader and the material, from “information to be understood” to “information combined with emotional engagement.”

One promising approach toward this is what might be called 2D visual narrative storytelling in technical content. This encompasses both static 2D illustration and 2D animation as tools for the same communicative purpose.

This is not a replacement for conventional technical methods. Rather, it is a complementary layer: warm, simplified visual experiences that reach slightly beyond the purely technical function of the visual and connect the subject matter to the real-world context in which it exists.

Most technical subjects are physical and tangible (they involve real machines, real workers, real environments). Much of conventional technical documentation tends to abstract away that layer. Yet that contextual, human layer is precisely what enables people to construct a complete mental picture, not only of the technical subject, but of its meaning and relevance.

This falls broadly under what designers and communication researchers call the humanization of technology, a well-documented design principle concerned with reducing the cognitive and emotional distance between users and technical systems.

The Illustrative Principle: What Research Supports

Consider two examples that draw together several separately validated findings from the research literature, one using static illustration and one using 2D animation, each applying the same core principle.

Example One: Static 2D Illustration

Rather than explaining a technical feature of an industrial machine through a 3D CAD model and data tables alone, imagine a 2D illustration that isolates the relevant component while fading surrounding parts into the background, places the machine within a recognizable industrial environment, and includes a human figure (a technician) positioned beside it in a contextually meaningful way, with clear technical annotations layered on top.

Example Two: 2D Animation

Consider a cutaway animation of an electric motor. A technician is shown inside the scene, replacing a component or diagnosing a fault. The animation is not merely instructional: the technician’s movements are deliberate and fluid, conveying a sense of confidence and mastery rather than confusion or mechanical routine.

The viewer watches someone who knows what they are doing, inside a system that is rendered transparent and comprehensible. The technical annotation appears at the right moment in the sequence, anchored to the action rather than floating in the abstract.

What Do Both Approaches Achieve, Compared To A Purely Abstract Technical Presentation

The answer, according to research across adjacent domains, is a qualitatively richer experience, supported by three distinct, research-validated mechanisms:

• Narrative framing improves comprehension and efficiency: A 2024 study at the ACM CHI Conference found that data storytelling, combining visual elements with narrative structure, improved both the speed and effectiveness of comprehension tasks compared to conventional visualization alone.

• Contextual and human elements reduce psychological distance: Research in human-centered design consistently shows that humanized interfaces and contextual framing reduce the cognitive load and sense of intimidation associated with unfamiliar technical material. Visual narratives in HCI have also been shown to democratize design processes and facilitate cross-cultural understanding in technical contexts.

• Animation specifically supports self-efficacy and retention: Structured educational animations have been shown to improve not only knowledge acquisition and retention, but also learners’ self-efficacy, reducing the cognitive load associated with technical material and increasing the learner’s sense that the subject is within their reach. This is the precise psychological effect that the electric motor example above is designed to produce: not just understanding, but the felt sense of capability.

• Emotional engagement strengthens memory encoding: Studies in visual narrative cognition confirm that narrative transport, meaning the process of being emotionally drawn into a visual story, produces stronger memory encoding and a greater sense of personal relevance.

These mechanisms (narrative framing, contextual humanization, animation-supported self-efficacy, and emotional engagement) have each been validated separately in the research literature. Their combination in the integrated format described above is a logical synthesis that awaits direct empirical testing as a unified intervention in technical documentation. This is a gap worth filling.

Why 2D Specifically?

The choice of two-dimensional illustration and animation over three-dimensional rendering is not arbitrary, though it is necessarily task-dependent. Research comparing 2D and 3D visualizations consistently finds that the optimal format depends on the nature of the task: for data interpretation and abstract comprehension, 2D representations tend to offer advantages in processing speed and accuracy; for spatial understanding of complex physical structures, 3D often performs better.

In the context of narrative illustration and conceptual communication (the primary purpose here), 2D’s simplicity, warmth, and accessibility make it a strong candidate. The absence of three-dimensional rendering complexity keeps cognitive attention focused on the subject and story, rather than on navigating a spatial model. This applies equally to static 2D illustration and to 2D animation: both formats use visual abstraction and deliberate hierarchy to direct attention, rather than overwhelming the viewer with realism.

Who Can Do This, and How?

Most tech writers are highly skilled at extracting what matters and expressing it precisely and clearly. Visual narrative in technical contexts, however, requires a dual competency: familiarity with both the technical domain and with visual communication, whether in the form of illustration or animation. In practice, this often calls for a collaborative team. It also opens a natural role for what might be called hybrid practitioners, that is, engineers or technical writers who have cultivated genuine visual skills alongside their technical expertise, and who can bring both to bear in producing content that is simultaneously rigorous and human.

This is not a common profile today, but it is an increasingly recognized one, reflected in growing fields like information design, data visualization, and UX writing. The emergence of these disciplines signals a broader recognition that technical clarity and human resonance are not in tension; they are complementary goals.

A Note On Practicality

Static 2D illustration will typically require more time than producing a standard CAD model or infographic, while 2D animation sits between static illustration and full 3D animation in terms of production time. The practical recommendation is therefore not to replace existing methods (which remain faster and well-suited to their purposes), but to integrate 2D visual narrative as a force multiplier: used selectively at key moments within a document’s or training module’s architecture to shift the reader’s relationship to the material. Even a small number of well-placed narrative illustrations or short animated sequences, embedded naturally within the flow of a document, can change the character of the experience from reception to recognition.

About the author: Mazen Alfaqi is a Mechatronics Engineer and a visual content creator in Cairo, Egypt specializing in bridging the gap between complex engineering and human experience through 2D visual storytelling and animation.

𝌕 Connect with Mazen via email 📧 or Linkedin.

This Summer, he’ll be offering his online, instructor-led course, Mastering API Documentation with AI, a seven week instructor-led virtual training class that meets once weekly (see the class schedule for exact dates and times) from June 15 through August 10, 2024.

Optional AI Add-On Module

For the final two classes, an optional AI add-on lets you use Claude and Claude Code to draft, review, and refine your API documentation — directly inside a GitHub Codespace, no local setup required.

• Class 6 (AI-assisted): Use Claude to draft API flow guides, then validate every Curl sample against the live API

• Class 7 (AI-assisted): Use Claude to generate OpenAPI descriptions, then evaluate the output against the API Reference Checklist and actual API behavior

Learn More and Register

You open Slack. Someone has “looped you in.” That phrase should come with a warning label.

There’s a thread. It’s long. No one agrees on what’s happening, but everyone agrees it’s urgent. ‼️ You’ve been added because — you “know the docs.”

But, no one’s told you what the outcome of this urgent matter should be probably because no one’s even sure what the problem actually is. But the clock started, and somehow you’re now responsible for making this make sense.

What This Playbook Is (And Isn’t)

This isn’t a method for solving the entire problem. If it were, it’d be 400 pages long and no one would read it. Instead, this is a stabilization protocol. It’s what you do before you know enough to be clever.

The goal isn’t brilliance. The goal is to avoid doing something dumb that creates more work, more confusion, or — my personal favorite — more unnecessary meetings.

You’re buying clarity and you’re buying time. You’re reducing the odds that someone says, “Wait, why did we do it that way?” two days from now.

Step 1: Figure Out Why This Suddenly Matters

Every “urgent” request has a backstory. Something broke, something’s launching, someone important got nervous, or a deadline snuck up like a raccoon in the night.

If you don’t know what triggered the request, you’re guessing. And guessing is how you end up writing a beautifully structured document no one actually needed.

Ask yourself what just happened that made this urgent today. Not last week. Not next month. Today.

If you can’t answer that in one sentence, you’re not ready to move forward.

Step 2: Identify What Goes Wrong If You Miss

Not all urgency is created equal. Some things are “we’ll look silly.” Others are “we’ll lose customers,” or “legal will start using words like exposure.”

You need to know which one you’re dealing with.

Who gets hurt if this goes sideways? Is it customers? Revenue? Compliance? Or is it mostly internal confusion and a few bruised egos?

This is where you separate the loud from the important. The person typing in all caps isn’t always the one holding the risk.

Once you know what’s at stake, you can stop treating everything like a five-alarm fire—or worse, treating an actual fire like a mildly warm candle.

Read more

I get the impulse. Really, I do. I ❤️ me a good PDF; but only when I need one.

PDFs are familiar. They look finished, feel official, and are what many tech docs teams ship, archive, email, and point to when someone asks where the user assistance lives.

To a human reader, a well-made PDF can seem perfectly clear.

• The heading introduces the procedure

• Steps appear in order

• Warning box is seriously hard to miss

• The diagram sits exactly where it belongs, quietly earning its keep

But when a large language model encounters that same file, it often isn’t getting the polished experience you imagine. It’s getting a reconstruction of the content through whatever extraction method sits between the PDF and the model, and that reconstruction can be a hot 🔥 mess.

Read more

Not “almost full.” Not “act now before the imaginary countdown clock starts sweating.”

Sold out!

That tells us something. Tech writers and content creators aren’t just curious about AI anymore. They’re trying to figure out how to use it.

Most of us have already experimented. We’ve summarized, rewritten, drafted, prompted, re-prompted, and stared at an answer that looked correct until it started gently lying.

That’s where this course comes in.

Instructor Bill Raymond teaches this 7-week, hands-on virtual workshop for people who want more than AI party tricks. It’s built for writers and content pros who need practical ways to use AI with more control, better judgment, and fewer “why did it say that?” moments.

Because the first class sold out, we’ve added a second cohort.

The new session meets online Tuesdays, July 14 – August 25, 2026, from 10 a.m. to 12 p.m. PT.

Learn more and register.

💰 Use discount code TCW at checkout to save 10%. 💰

And suddenly the tool clutches its pearls. »> “I can’t help with that!”

Or worse, it can help—but only after it’s rewritten your request into something so polite and sanitized it sounds like it’s applying for a job in corporate compliance.

Meanwhile, somewhere else on the internet, another AI happily produces exactly what you asked for—no moral lecture, no creative editing, no hall monitor energy.

So What Gives?

It’s tempting to think one AI is “better” and the other is “worse.” Or that one is “censored” and the other is “free.” But that’s not really what’s happening.

What you’re seeing is the result of design decisions. Not intelligence. Not morality. Design.

There’s No Such Thing As “Neutral AI”

Every AI system comes with opinions baked in. Not the model’s opinions, exactly, but the opinions of the people who built, tuned, and deployed it.

Those opinions show up in a few predictable places:

• What data the model was trained on

• What kinds of outputs it was rewarded or penalized for producing

• What filters sit in front of it, watching your prompt like a suspicious librarian

• What filters sit behind it, quietly rewriting its answers after the fact

By the time you type your request, you’re not talking to a raw model. You’re talking to a governed system. And that system has rules it is supposed to follow.

Read more

This June lineup covers the things tech writers keep circling back to: scaling content without breaking teams, making sense of content operations, getting into the field, and figuring out what AI is going to change next (and what it won’t, despite its enthusiasm). You’ll hear from practitioners, strategists, educators, and the occasional truth-teller who’s seen what happens when good intentions meet messy reality.

Each session runs for one hour, which is just enough time to learn something useful without questioning your life choices. And if your calendar has other plans — which it will — registering still gets you access to the on-demand recording after the live broadcast. That means you can watch when it suits you, pause when someone says something worth stealing, and pretend you were there all along.

If you’re new to the channel, there’s also a small detail worth mentioning: there are already more than 800 recorded one-hour educational sessions waiting for you. That’s a suspiciously large archive of hard-earned knowledge from people who’ve done the work, fixed the mistakes, and are willing to talk about both.

🗓️ [June 9] How to Scale Content Teams Without Slowing Delivery

Join Effie Sharon Sinena, Product Delivery Manager (Technical Documentation) at Lexmark Research and Development Corporation (now part of Xerox), as she shares practical lessons from startups and fast-growing organizations on building resilient content operations that don’t burn out your team or compromise output.

Register

🗓️ [June 11] The Cerberus Project: How to Enter Tech Writing

Join Maria Haque, teacher at PACE - Academy for Gifted Children, and Christina Mayr, Documentation Team Manager & Senior Information Architect at Epic Games, as they unpack how newcomers can break into the field using The Cerberus Project as a practical case study.

Register

🗓️ [June 16] The Content Integrity Model: Framework for an AI Age

Join Rahel Bailie, Content Solutions Strategist at Content Seriously, as she introduces the Content Integrity Model — a practical framework designed to help you align your content strategy with organizational goals while ensuring editorial quality, operational efficiency, and a resilient infrastructure.

Register

🗓️ [June 16] Structuring Prompts for Technical Communication

Join Professor Lance Cummings of the University of North Carolina Wilmington as he reveals why prompt structure (not just length) determines whether your AI-generated content meets professional standards. Explore a practical framework for structuring prompts using three core components: task, context, and content.

Register

🗓️ [June 17] Proving Better UX Content Is Worth The Investment

Join Julia Warrender, Senior Content Strategist at TELUS, as she shares a practical framework that connects traffic, conversion, and customer value to estimate the real financial impact of poor content. Julia will demonstrate her simple “Content Impact Model,” show you how to build one even with imperfect data, and guide you through using it to influence prioritization and decision-making.

Register

🗓️ [June 18] Reinventing Yourself While AI Changes the Rules

Join Raegen Pietrucha, author, career coach, and consultant dedicated to empowering writers, as she explores why we get stuck in our routines, how confidence can quietly morph into complacency, and what it takes to break free. You’ll learn to spot subtle signals that you’re ready for change, recognize obstacles that hold you back, and ask yourself the right questions to reignite your initiative.

Register

🗓️ [June 18] Better GenAI Content Starts With Human Oversight

Even minor errors can create outsized problems — Charles Dowdell, Manager and Consultant at Wisdomino Corp (transitioning from Komatsu), will share real-world examples where small mistakes led to big consequences. Explore proven methods for content quality control that you can implement right away.

Register

🗓️ [June 23] A Solo Tech Writer’s Lessons, Missteps, Wins Adopting AI

Join us for a chat with Sowjenya Parthasarathy, Technical Writer at Funnel, as she shares her approach to analyzing user intent using search data, support queries, and behavioral tools. Discover how these insights can shape more effective AI-powered conversations with your users—even if you lack enterprise resources.

Register

🗓️ [June 25] It’s Time To Start Treating Content As Infrastructure

Joseph Phillips, Content Infrastructure Strategist at The Examined Web, will reveal how organizations waste resources by viewing content as a commodity rather than as critical operational infrastructure. Explore practical steps for shifting your mindset and operations toward sustainable, scalable content practices.

Register

First attempt: BLOCKED! Apparently a harness, even in daylight, suggests I might be moments away from asking for something involving handcuffs and poor decision-making.

Second attempt: success… sort of. The man appeared wearing a harness over a fancy midcentury short sleeve dress shirt, which is a bit like wearing underwear over jeans. Technically possible. Otherwise, incorrect.

I adjusted the prompt. Clarified intent. Emphasized “fashion,” “editorial,” “not sexual.”

The AI nodded, took notes, and then produced a man standing by a pool… wearing a harness… and still clinging to that 70s-style print shirt like it was his emotional support garment.

At this point, I wasn’t generating images. I was coaching.

Eventually (after removing, rewording, softening, reframing, and essentially whispering to the machine, “I promise this is just a nice man enjoying the sunshine”) it finally complied.

Shirtless. Harness on bare chest. Poolside. Palm Springs. Correct. Victory!

But here’s the interesting part: nothing I originally asked for was inappropriate.

What the system kept doing was correcting me (not for accuracy, but for safety). It wasn’t reading culture. It was reading patterns. Somewhere in its training data, “harness” lives in a very specific neighborhood, and even when you move it to Palm Springs in broad daylight by the pool, the AI image generator still thinks it might turn into a situation requiring a safe word.

So it hedges. It adds clothing. It tones things down. It quietly rewrites your request into something it feels better about.

Not more accurate. Just… safer. And that’s the issue. Because harnesses aren’t just fetish gear anymore. They’re fashion (check out Pinterest). For some, they’re Pride, they may be seen at pool parties, music festivals, and in Instagram ads that somehow know exactly when you’re feeling emotionally available and financially irresponsible.

But the AI hasn’t caught up. It’s still operating like a well-meaning chaperone who’s convinced that if you remove one more button, society will collapse.

Today it’s a harness. Tomorrow it’s something else the model doesn’t fully understand but feels oddly nervous about. And honestly, that’s the real story here. Not leather. Not sex. But what happens when a machine sees a cultural signal, panics slightly, and mistakes its own outdated assumptions for good judgment.

Also, for the record, if you ever see someone wearing a leather harness over a dress shirt at a Palm Springs pool, please check on them. They may likely be in distress. 🤣

👉🏾 You think, “Well, that’s better.”

Then you look again.

👉🏾 The warning is gone.
👉🏾 The prerequisite has been politely implied into nonexistence.
👉🏾 The conditional step has been simplified into something that would work beautifully in a world where nothing ever goes wrong.

Nothing looks broken. And yet, everything is just slightly… off.

This is what some call the car wash error.

What Is The Car Wash Error?

It’s not a formal term. We won’t find it in industry research papers. It’s a practical observation from people who’ve watched content go into a machine and come out looking cleaner while quietly losing the important parts; the ones that mattered.

Put simply, the car wash error happens when AI makes content smoother and easier to read, but not helpful in real-world situations. The content goes in with dents and bugs 🐞 on the windshield. It comes out polished.

But then, somewhere along the way, a side mirror falls off.

The Model Isn’t Being Careless — It’s Trying To Be Helpful

Large language models are built to produce language that flows well. They smooth things out, normalize variation, and they take our inconsistent phrasing and turn it into something that reads like it was written by one very calm, very consistent human.

That’s the job. Nothing more.

What they aren’t built to do is preserve every awkward, inconvenient detail that makes the content correct.

They don’t have a strong instinct for things like:

• Preconditions that must be met before anything works

• Roles that determine who can do what

• Exceptions that only show up on Thursdays when the system is feeling emotional

• The difference between what a user does and what the system does in response

Those details often look like noise to a model trained to produce clean prose. So the model cleans them.

You get something that reads better and behaves worse.

What Actually Disappears

If you’ve been working on docs for more than five minutes, you’ve already seen this happen.

👉🏾 A procedure that used to say “Only administrators can perform this step” now says “Perform this step.”

👉🏾 A warning ⚠️ that used to be loud and slightly annoying becomes a gentle suggestion that sounds like it was written by someone who doesn’t believe in consequences.

👉🏾 A workflow with conditions and branches becomes a lovely straight line. Everything works. Nothing fails. It’s a small miracle.

The distinction between system actions and user actions blurs until it’s not clear who is doing what. The answer is apparently “everyone” or possibly “no one.”

It all sounds great. It just doesn’t survive contact with reality. The more operational the detail, the more likely it is to get washed away.

Related reading: Why PREA Makes Structured Technical Documentation More Valuable

Why This Gets Worse With AI-Delivered Answers

This would be annoying enough if it stayed inside documents. It doesn’t.

Now we have AI-powered systems that retrieve, assemble, and generate answers from that content. They don’t just redisplay what we wrote. They reconstruct it.

So when something important is missing, the system doesn’t stop and say, “I’m not sure.” It fills the gap. Confidently.

We end up with answers that sound complete, read well, and are wrong for the user’s situation. Not dramatically wrong. Just wrong enough to cause confusion, rework, or a support ticket that begins with “I followed the documentation.”

The failure isn’t obvious. It’s persuasive. That’s a problem.

The Dangerous Part: It Feels Like Improvement

If AI produced messy, incoherent output, our professional lives would be so much easier. Everyone would reject AI and move on. Instead, it produces something that looks like progress.

Stakeholders like AI-generated content because it reads well. Reviewers skim it and approve it because nothing jumps out as broken. Writers feel a quiet pressure to accept the cleaner version because, technically speaking, it is cleaner.

This is how meaning disappears with full organizational support.

No one signs off on removing the warning. It just doesn’t make it through the wash.

What Survives The Wash

Here’s the part that matters. If meaning is implicit, it’s fragile. If it’s buried in phrasing, it’s negotiable. If it relies on the reader to infer the right interpretation, it’s already halfway out the door.

What survives is what’s made explicit.

Structure helps. Not because it’s fashionable, but because it gives the content something to hold onto.

👉🏾 When roles are defined, they’re harder to blur.
👉🏾 When conditions are explicit, they’re harder to flatten.
👉🏾 When events and outcomes are named, they’re harder to quietly disappear.

If the content clearly distinguishes between who does what, when, and under what conditions, the model has less room to “improve” it into something less accurate.

If it doesn’t, the model will do what it does best — produce something that sounds right.

What This Means For Technical Writers

This is the part where the job description quietly changes. It’s no longer enough to write clearly. The model can do that.

The work is making sure the meaning survives processing. That means looking at AI output and asking different questions:

🚫 Not “Does this read well?”
👍🏽 But “What went missing?”

🚫 Not “Is this clearer?”
👍🏽 But “Is it still correct under real conditions?”

It means making constraints visible. Keeping exceptions intact. Being the person who insists that the annoying detail stays because it is, unfortunately, true.

It also means resisting the seductive pull of better phrasing when that phrasing comes at the cost of accuracy.

The sentence may be smoother. The system is not.

Clean Isn’t The Same As Correct

AI will keep getting better at producing language that feels right to us. That part isn’t in question. The risk is that we start treating that feeling as evidence.

It isn’t.

If our content can’t survive being rewritten, summarized, and reassembled without losing its meaning, then it’s not ready for the AI-powered systems often in charge of delivering it. And those systems are already speaking for us.

So yes, send your content through the car wash. It will look great.

Just check whether the parts you actually needed are still attached when it comes out. 🤠

[Above] Just for fun: A reimagining of the disco classic, Car Wash by Rose Royce remixed by my friend, Daniel Van Olst

You’re at the airport. You’ve got your tragic little sandwich in a paper bag, your phone battery is hanging on by a thread, and the gate agent smiles as she scans your boarding pass.

Then she says, almost as an afterthought, “Just so you know, the maintenance procedures, safety documentation, and operating guidance for this aircraft were autogenerated by a large language model. No human reviewed any of it, but the output was looks great.”

Do you keep walking down the jet bridge? Would you really board that plane?

Or do you suddenly decide that maybe this is the perfect time to reconnect with Amtrak.

That, in a nutshell, is the conversation a lot of us are being asked to have about AI-generated technical documentation. Only instead of saying it plainly, some leaders prefer to dress it up in phrases like “content acceleration,” “operational efficiency,” and “reimagining the authoring workflow,” which is executive dialect for “we’re about to try something reckless and would like it to sound visionary.”

The Trouble With Text That Sounds Smart

This is the problem with LLMs. They’re very good at producing language that appears to know what it’s talking about. They sound calm, competent, and confident. They sound like the kind of person who’d use the phrase “best practice” without once stopping to ask whether the practice in question might get someone electrocuted.

And that’s exactly what makes them dangerous in high-stakes documentation environments.

Read more

There was a time when products had the decency to be one thing.

A toaster toasted. A manual explained how not to electrocute yourself while using it — specifically, “do not use in bathtub or shower,” which suggests at least one person looked at a toaster and thought, sure, let’s bring this into the one room specifically designed for water. Everyone went home slightly safer and mildly warmed.

Now you’re handed a product that contains sensors, firmware, a touchscreen, a motor, three safety interlocks, and a support article that says, “Press the button.”

👉🏾 Which button?
👉🏾 What happens next?
👉🏾 Why doesn’t that happen sometimes?

And why the machine is blinking at them like it knows something they don’t — which, historically, has not gone well for humans. If you need a cultural reference, think of the VCR clock blinking “12:00” for eternity because no one in the household wanted to admit defeat and read the manual. There’s an entire genre of jokes about this phenomenon.

Welcome to mechatronics — you’ve probably been documenting it for years without anyone bothering to tell you what it’s called.

The Moment Products Stopped Being Polite

Mechatronics is what happens when engineers stop pretending their disciplines live in separate apartments and start sharing a kitchen. It blends mechanical engineering, electronics, software, and control systems into one integrated system. Not “a machine plus some code,” but a system designed to sense, decide, and act.

Why does this matter? Because this isn’t just a stack of technologies. It’s a design philosophy that aims to help us ensure everything works together from the start.

Read more