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. 🤠

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. 🤠

Both are real. Both are useful. Both sound like they arrive at work on time. ⏰

Docs-as-a-Hot-Mess is different.

👉🏾 It isn’t a methodology.

👉🏾 It isn’t a best practice.

👉🏾 It isn’t a movement anyone should claim in public.

It’s simply a label for a condition many organizations already have: docs produced by multiple internal groups, for multiple purposes, with multiple assumptions, and with no governing framework strong enough to reconcile any of it.

The naming convention is really the only thing these categories have in common.

They all start with “Docs-as-,” which gives them a faint air of professionalism, much like putting a blazer on a bad decision. But where Docs-as-Code suggests rigor and Docs-as-Tests suggests verification, Docs-as-a-Hot-Mess describes what happens when nobody’s clearly modeled the logic underneath the content and then acts surprised when an AI answer engine turns that confusion into customer-facing prose.

That’s why we need the term.

A lot of documentation that looked “good enough” in the old world isn’t ready for AI retrieval in the new one. A help topic written for support engineers sits next to an onboarding guide written for customers. A release note we produced assumes context the reader doesn’t have. A troubleshooting article we crafted skips the event that starts the workflow. A procedure we carefully worded says “the user” does something, but never explains which user, in what role, under what conditions, or whether the system was supposed to handle it automatically instead.

That isn’t guidance. That’s improv with screenshots.

And AI answer engines, bless their tireless little hearts, are very good at finding disconnected scraps, flattening their differences, and serving them back as one smooth, confident answer. Which is great when your content is governed, structured, and semantically clear. If it isn’t, the machine doesn’t fix the mess. It scales it. Publicly.

AI Didn’t Create Our Mess, But Turned On The Lights So We Couldn’t Help But See It

A customer asks a simple question. The AI assistant replies in seconds with the confidence of a man explaining olive oil at a dinner party. It has found a setup topic from the help center, a support note meant for internal use, a few release-note fragments, and an onboarding PDF that appears to have been updated during a period of low morale. It blends them into one polished answer. The answer is clear, direct, wrong in at least three ways, and just plausible enough to cause trouble.

This is usually the part where someone says, “Well, the AI hallucinated.”

Sometimes it did. But often it’s doing something worse and far more understandable: it’s retrieving exactly what you gave it.

Read more

Content Strategy Is The Part No One Sees — Until It Breaks

Most people think content strategy is about planning what to write. That’s part of it, but it’s not the part that saves us when things go sideways.

Content strategy is the system behind the content — the decisions that determine:

• why something exists

• who it’s for

• how it’s structured

• where it shows up

• and who’s responsible for keeping it accurate over time

It’s what keeps content from becoming a scattered content hairball of “we should probably document that” moments.

It’s easy to spot the absence of content strategy pretty quickly. If our help center includes multiple articles that say almost the same thing, but not quite — chances are good, there’s no formal content strategy in place.

If our documentation includes a procedure that works until step four quietly assumes the user already know something no one bothered to explain to them, content strategy is lacking.

If our customers have to ask, “Which version is correct?” and the honest answer is… “it depends” — a content strategy is maybe, probably, definitely missing in action.

We don’t have a technical writing problem. We have a system problem.

For tech writers, this matters more now than in the past Our job isn’t just about producing clear instructions anymore. It’s about designing information so it holds up across systems, channels, and increasingly, AI-powered machines that read and reuse our content in ways we don’t control.

When content lacks structure and governance, it doesn’t just confuse readers — it confuses the systems trying to interpret it. AI doesn’t fix that. It amplifies it. If your documentation contradicts itself or buries important context, those issues don’t disappear when an AI assistant summarizes the content. They get repackaged into answers that sound confident whether they’re right or not. Research from the BBC has shown that generative AI can misrepresent source material even when it’s trying to summarize it.

That’s where content strategy earns its keep. It’s what makes content consistent enough to trust, structured enough to reuse, and governed enough to maintain. Without it, every new piece of content adds a little more entropy. With it, content starts to behave like infrastructure — something you can build on instead of constantly patch.

A sound content strategy also changes how your work is perceived by others. When there’s no strategy, writing can look like a task anyone could do if they had the time. Writing is just typing, right? How hard can it be?

When there is a strategy, it becomes clear that someone has to think about how information fits together, how it evolves, and how it supports both users and the business.

That someone is usually the tech writer — whether the job description says so or not.

So if content strategy sounds abstract, it’s really not. It’s the difference between content that sort of works today and content that keeps working tomorrow. And in a world where your documentation feeds everything from help portals to AI-generated answers, that difference isn’t academic. It’s operational. 🤠

There is a meeting happening in offices everywhere right now, and it usually begins with someone from leadership saying something cheerful and faintly menacing like, “With AI, we should be able to create documentation much faster.”

This is the sort of sentence that sounds harmless until you realize it is often followed by a silence in which every tech writer in the room is expected to smile politely while their profession is reduced to “person who types words into boxes.”

The implication is hard to miss. If AI can generate sentences, and structured content can feed the machine, then surely the technical writer is now just an expensive hallway monitor for punctuation and product names.

Unfortunately for the people saying this, that is not how any of this works.

Yes, AI can generate language. Quite a lot of it, quickly. It can produce whole fields of prose with the confidence of a man at brunch explaining blockchain to people who did not ask. But language alone isn’t knowledge, structured content alone isn’t meaning, and neither one automatically produces an answer a human being can trust, understand, or use without accidentally setting something expensive on fire.

That is why three unfashionably academic little “-ologies” matter more than ever: ontology, epistemology, and phenomenology.

Yes, I know. It sounds like somebody spilled a philosophy department onto a docs team. Stay with me.

These are not decorative words for LinkedIn people who own too many blazers. These are concepts technical writers need to understand if they want to remain relevant in an AI-powered documentation world. More than that, they are the difference between being seen as someone who “writes help content” and someone who makes AI-delivered knowledge accurate, useful, and safe.

Read more

▶️ Watch the entire interview (60 minutes, on-demand).

The Underdog of Learning Resources

The 2025 Developer Survey paints an interesting picture. You’ve got your standard array of learning tools — Stack Overflow, blogs, online courses, and of course, videos. But lurking quietly in the background, capturing the attention of a staggering 68% of respondents, is technical documentation. It’s the often underappreciated rock star in a world obsessed with quick fixes and instant gratification.

Let’s break it down. Of the 33,454 developers who were polled (76% of them being the true “professional” variety and an additional 15% falling into the aspirational or adjacent developer category) there was a strong consensus. You need technical documentation to learn how to code. Let that sink in.

It’s clear we tech writers are holding the reins of knowledge, quietly helping software developers avoid the chaos of poorly understood libraries and buggy frameworks.

The Developer’s Best Friend: Technical Documentation

Now, we all know that developers have a way of loving their code more than they love life itself. 😆 Still, these same developers (mostly aged between 25 and 44) are relying on our docs to make sense of their tools, libraries, and frameworks. There’s a good reason why a significant 68% of survey respondents preferred it over other resources. It’s simple. It works.

While Stack Overflow answers might solve an immediate issue, they don’t explain why things work the way they do (and even when they do, there’s no guarantee it'‘s accurate). Enter technical documentation (the unsung hero of the coding world). Developers, especially those with less than 10 years under their belts, might not be able to remember every edge case for every function call, but the doc we produce help them get it when it matters most.

It’s the difference between frantically Googling “why does my program crash every time I try to run it?” and confidently consulting well-organized reference material that tells you what you’re doing wrong and how to fix it. It’s like the difference between using a map and wandering aimlessly.

Why Documentation Is the Bedrock of Success

Okay, I’ll admit that documentation isn’t exactly the glamorous, party-loving cousin of a slick YouTube tutorial or a rapid-fire Stack Overflow answer, but it is where foundational knowledge lives. For most developers, especially those in the 35% who have been coding for fewer than 10 years, learning to code with solid documentation means building a robust, scalable understanding that no quick fix or trendy blog post can replace.

The Case for Appreciating Technical Writers

So, dear tech writers, it’s time we stand tall and claim our rightful spot at the table of essential resources. Developers might use other tools for a quick fix, but when it’s time to dive deep into understanding and mastering a framework, they’re coming to us. Documentation isn’t just a reference; it’s the bedrock of their continuing success.

And to all the developers reading this: Next time you’re diving into a technical topic, remember that the person behind those docs aren’t just throwing a bunch of words into a file. They’re saving your proverbial butt one detailed, well-organized, thoroughly tested section at a time. And in a world where most things come with a “don’t ask, just Google it” disclaimer, isn’t that worth a little appreciation? 🤠

That should sound familiar, because tech writers are supposed to care about exactly those things — and more.

A system may be logically designed. A workflow may be technically correct. A product team may insist the interface is “clear.” Meanwhile, the user is staring at a screen wondering whether clicking Save will publish the document, overwrite the document, summon legal, or end civilization as we know it. Phenomenology asks us to take that user experience seriously.

We need phenomenology because documentation is not just about describing how a system works from the inside. It is about helping someone navigate how that system appears from the outside, in real conditions, with limited context, imperfect memory, and a growing suspicion that every button has been named by a committee with boundary issues.

This matters because users do not experience products as architecture diagrams. They experience them as moments: confusion, hesitation, recovery, success, error, relief. Good documentation meets them there. It anticipates where they are likely to get lost, what they are likely to misread, and what they need in order to move forward with confidence.

In practical terms, phenomenology reminds us to pay attention to the user’s point of view, not just the system’s logic. It encourages us to write for the reality of use, not the fantasy of design. And that is important, because a procedure is only “clear” if it is clear to the person trying to follow it while three deadlines, two warnings, and one expired permission token are breathing down their neck.

Good documentation does not just explain the product. It respects the experience of using it. That is why phenomenology matters. 🤠

That may sound like philosophy-class material best left to people wearing scarves and speaking in paragraphs no one asked for. But tech writers deal with epistemology all the time.

Every time we ask a subject matter expert to verify a procedure, question whether two sources conflict, decide which version of the truth belongs in the manual, or try to separate official guidance from tribal folklore, we’re doing epistemic work. We’re not just writing things down; we’re evaluating claims, testing evidence, identifying authority, and deciding what the reader should be able to trust.

That matters even more now that AI systems increasingly consume and remix documentation. If the source content is vague, inconsistent, poorly governed, or based on undocumented assumptions, the machine may produce fluent nonsense with the confidence of a man explaining wine in a restaurant. Epistemology helps writers think more clearly about provenance, evidence, certainty, and trust.

In practical terms, tech writers need epistemology because documentation is not just about expressing knowledge. It is about deciding what knowledge deserves to be expressed, how firmly it can be stated, and what supports the claim. In other words, good documentation does not just tell users what is true. It helps ensure the truth has not been assembled from guesswork, vibes, and somebody’s half-remembered Slack message.

A strong documentation practice is, in part, a disciplined way of knowing. That is why epistemology belongs in the conversation. 🤠

That is why Women in Technical Communication: From Typewriters to Touchscreens: a history by the women who did the work, edited by Sharon Burton, deserves a place on every technical writer’s reading list.

This anthology brings together firsthand stories from women who helped shape the profession across more than fifty years of change. From typewriters to PCs to smartphones, these contributors did not merely observe the field evolving. They built careers in it, influenced it, and in many cases helped define it. Which is more than can be said for the occasional modern pundit who has been in the field for eleven minutes and is already announcing its complete reinvention. 😆

What makes this book valuable is that it preserves the voices of the women who did the work

Not the sanitized corporate version. Not the after-the-fact summary. Their own words. Their own experiences. Their own accounts of building careers, leading change, and making space for themselves in workplaces that were not always eager to make room.

Technical communicators document everything except their own history. We preserve processes, systems, and product knowledge with almost religious devotion, but somehow leave the story of our own profession sitting unlabeled in a cardboard box. This book helps fix that.

Buy The Book!

It also offers perspective at exactly the right time! As tech writers wrestle with AI, automation, and yet another round of people insisting the profession must now become something entirely new, this anthology reminds us that change is not new. Reinvention is not new. The need to adapt without losing the plot is not new.

Newer technical writers should read this book to understand the roots of the profession. Experienced practitioners should read it for recognition and context. Leaders should read it because professions are built by people over time, not by tools, hype, or somebody’s aggressively branded framework.

If you care about technical communication as a discipline, not just a job title, buy this book. Read it because the field needs memory. Read it because the women who helped build it deserve to be heard. Read it because a profession that forgets its own history is doomed to keep rediscovering itself like a man who loses his glasses while wearing them.

Women in Technical Communication, edited by Sharon Burton, is published by XML Press. Release date: March 30, 2026. Paperback: US $45.95. Ebook: US $29.95.

Contributors List

An ontology sits above all of them.

If AI systems are now reading, interpreting, and speaking on behalf of our documentation, understanding what an ontology is—and what it is not—becomes essential.

A Plain-Language Definition of Ontology

In the context of technical documentation:

An ontology is a formal model that defines what things exist in our domain, what they mean, and how they are allowed to relate to one another.

It does not store content. It does not store prose. It defines meaning and rules.

Why “Meaning” Matters More Than Ever

Traditional doc systems assume a human reader. Humans infer meaning from context, tolerate inconsistency, and notice when something feels “off”.

AI systems do none of that reliably. They need meaning to be explicit, not implied; exactly what an ontology provides.

What An Ontology Actually Contains

In technical documentation, an ontology typically defines four things.

1. Concepts

The things that exist in your product and documentation universe.

Examples:

• Product

• Product version

• Feature

• Component

• Task

• Configuration

• Warning

• Error message

• API endpoint

• User role

An ontology answers: “What kinds of things are we allowed to talk about?”

2. Relationships

How those concepts connect to each other.

Examples:

• Feature is part of Product

• Task configures Feature

• Warning applies to Task

• Feature is deprecated in Version

An ontology answers: “How are these things allowed to relate?”

3. Constraints

Rules that prevent invalid combinations.

Examples:

• This feature only applies to certain product versions

• This task is only valid for admin users

• This configuration is incompatible with another feature

• This warning must appear whenever a specific condition exists

An ontology answers: “What must never be combined or inferred incorrectly?”

4. Terminology control

Shared understanding of language.

Examples:

• Preferred terms vs. synonyms

• Deprecated terms

• Acronyms and expansions

An ontology answers: “When we say a word, what do we mean—and what do we not mean?”

Ontology vs. Taxonomy vs. Metadata

These are related, but not interchangeable.

Taxonomy

A taxonomy organizes things into hierarchies.

Example:

• Product

  • Feature

    • Sub-feature

Taxonomies answer: “How do we group things?”

Metadata

Metadata describes individual content objects.

Example:

• Product = X

• Version = 4.2

• Audience = Admin

Metadata answers: “What attributes does this piece of content have?”

Ontology

An ontology defines the rules behind both.

It answers:

• What counts as a Product?

• What is the difference between a Feature and a Configuration?

• Can a Task apply to multiple Products?

• When is something invalid, deprecated, or incompatible?

Without an ontology:

• Taxonomies drift

• Metadata becomes inconsistent

• AI systems guess

Why Ontologies Matter Specifically For Technical Documentation

1. They prevent concept drift

Over time, teams start using the same word to mean different things.

Ontologies force alignment:

• A feature is not a task

• A task is not a concept

• A version boundary is real, not optional

This clarity improves both human comprehension and AI accuracy.

2. They enable trustworthy AI answers

AI systems that rely on documentation increasingly use semantic retrieval and generation.

Without an ontology:

• AI retrieves text that sounds relevant

• Answers may combine incompatible concepts

With an ontology:

• AI retrieves content that is conceptually valid

• Constraints prevent nonsense answers

This is the foundation of ontology-grounded RAG.

3. They elevate the role of technical writers

Ontologies surface a truth many organizations ignore:

Documentation is not just content. It is a knowledge system.

Technical writers are uniquely qualified to:

• Define concepts clearly

• Establish boundaries and intent

• Model relationships humans understand intuitively

Ontologies make that expertise visible and strategic.

See also: What Is Ontology-Grounded Retrieval-Augmented Generation?

What An Ontology Is Not

An ontology is not:

• A style guide

• A glossary (though it may reference one)

• A CMS configuration

• A single diagram created once and forgotten

An ontology is a living semantic contract between:

• Content

• Tools

• AI systems

• Humans

When Do You Need An Ontology?

You especially need an ontology if:

• Your products are modular or platform-based

• You support multiple versions simultaneously

• You are building or buying AI assistants

• Your documentation feeds chatbots or copilots

• Consistency and trust matter

If AI is now the front door to our documentation, an ontology is the lock that keeps the wrong answers out.

The Takeaway For Tech Writers

In technical documentation, an ontology answers the hardest question of all:

“What does this actually mean — and what is it allowed to mean?”

Writers who help define and govern ontologies shape how:

• Content is retrieved

• Answers are generated

• Products are understood

As AI becomes the voice of your documentation, ontologies decide whether that voice is informed — or improvising.

And improvisation is not a strategy. 🤠

If you remember nothing else, remember this: DITA topics exist to do one thing for one user intent — clearly, consistently, and reuse-ready. 🧐

That single idea explains why DITA works so well at scale and why it behaves differently from traditional document-centric authoring.

See also: What is the Darwin Information Typing Architecture (DITA)?

What Makes a Topic a Good Topic?

A DITA topic is effective when it meets these criteria:

• Single intent — It answers one question or supports one task

• Self-contained — It makes sense without relying on surrounding prose

• Context-aware — Metadata defines product, version, audience, and conditions of use

• Reusable by design — It can appear in multiple documents without rewriting

If a piece of content reads awkward when reused, it probably wasn’t written as a true topic.

Why DITA Topics Exist

Before DITA, most technical documentation followed a document (book) model:

• Long manuals

• Linear chapters

• Content written once, reused by copy-paste

• Updates scattered across multiple files

That model breaks down when you need to:

• Reuse content across products and versions

• Publish to multiple outputs (PDF, web, help systems, chatbots)

• Keep information accurate over time

• Support automation, search, and AI

DITA flips the model. Instead of starting with a document, you start with topics.

The Three Core Types of DITA Topics

Most DITA implementations rely on three foundational topic types. Each enforces intent.

1. Concept Topics — “What is this?”

Concept topics explain ideas, principles, or background information.

Examples:

• What a feature does

• Why a setting exists

• How a system behaves

They help users understand before they act.

2. Task Topics — “How do I do this?”

Task topics walk users through steps to complete a goal.

Characteristics:

• Clear goal

• Prerequisites

• Ordered steps

• Expected results

They answer action-oriented questions and work especially well for procedural content and automation.

3. Reference Topics — “What are the details?”

Reference topics provide structured facts.

Examples:

• Parameters

• Commands

• Error codes

• Field definitions

They prioritize accuracy, consistency, and scannability over narrative flow. 🤠

DITA matters because it forces clarity and discipline at the point of creation. Each topic has a single intent — concept, task, or reference — which makes content easier for people to scan and easier for machines to process. That structure enables reliable reuse, reduces duplication, and improves consistency across products, versions, and channels. Writers stop rewriting the same explanation five times and start managing one trusted source of truth.

DITA is also built for scale and change. Its specialization and inheritance model lets organizations extend the standard without breaking it, while maps assemble topics into many deliverables from the same content set. The result is faster updates, cleaner localization workflows, and publishing pipelines that can target PDFs, HTML, portals, and help systems from the same content base.

Finally, DITA future-proofs documentation for AI-driven delivery. Because topics are semantically typed and structurally consistent, search engines, chat systems, and retrieval-augmented generation pipelines can identify intent and return precise answers instead of dumping entire pages. In an era where documentation feeds intelligent systems, DITA gives technical writers a way to make content both human-readable and machine-ready.

DITA content is best managed in a component content management system designed specifically to help technical writers create, manage, and deliver documentation to the humans and machines that require it. 🤠

A DITA topic is a small, self-contained unit of information designed to answer one specific user need. Not a chapter. Not a document. Not a dumping ground for everything related to a feature. One purpose. One job.

A DITA topic has three defining characteristics

1. It has clear intent

Every DITA topic exists to do exactly one thing: explain a concept, describe a task, or provide reference information. This is not an accident. DITA enforces intent through information typing—most commonly concept, task, and reference.

Related: Understanding DITA Topic Structure

That constraint forces writers to decide why the content exists before writing it. Is the user trying to understand something? Do something? Look something up?

📌 If you cannot answer that question, you do not yet have a topic.

This is one of the reasons DITA content works so well with search, delivery platforms, and AI systems. Intent is explicit, not implied.

2. It Stands on Its Own

A DITA topic is designed to be meaningful outside the context of a book or manual. Someone might encounter it through search, a chatbot, an embedded help panel, or an AI answer engine. Regardless of how they encounter it the topic must still make sense.

That means no “as described above,” no unexplained acronyms, and no reliance on surrounding pages or section headers to fill in critical gaps. Context travels with the topic through metadata, structure, and reuse — not through proximity.

This independence is what enables reuse at scale without copy-and-paste chaos.

3. It’s Structurally Predictable

A DITA topic follows a consistent structural pattern: a title, a body, and clearly defined elements inside. Tasks have steps. References have tables and properties. Concepts explain ideas, not procedures.

That predictability is not just for writers; it is for machines (computers, specifically). Structured topics allow systems to classify, filter, assemble, personalize, and deliver content dynamically. This is why DITA topics are increasingly valuable in AI-driven environments.

Large language models do not “understand” documents. They perform far better with small, well-typed, semantically clear units of information.

Why This Matters Now

As search engines turn into answer engines and documentation gets consumed in fragments, the DITA topic becomes the atomic unit of knowledge delivery. Writers who understand how to design strong topics are not just explaining products; they are engineering intent-aware, machine-processable content that feeds knowledge systems.

If you want AI solutions to give users the right answer instead of a plausible one, start with better topics.

If your content:

• clearly states its purpose,

• uses consistent information types,

• exposes relationships through structure and metadata,

AI can reason over it. If it doesn’t, AI guesses.

Structured, semantically augmented DITA content allows AI systems to:

• distinguish learning intent from execution intent,

• select the right topic type for the moment,

• avoid blending procedural steps into conceptual explanations,

• reduce hallucination caused by context collapse.

In short, it helps AI choose instead of invent.

What This Means For Tech Writing

Technical writers are no longer just explaining products. They are designing intent-aware knowledge systems.

Every time you:

• choose a topic type,

• enforce information typing discipline,

• add meaningful metadata,

• break monolithic docs into purpose-driven components,

you make it easier for AI search engines to deliver the right answer, not just an answer.

In an AI search world, visibility depends less on keywords and more on whether machines can understand what your content is for.

DITA doesn’t just support that future. It anticipates it. 🤠

As a technical writer, I can’t help but laugh. Not because it isn’t serious—it is—but because most of us know the dirty little secret: the hardest part of this job has never been “writing words.” If it were, we’d have been replaced long ago by marketing interns with liberal arts degrees and a case of LaCroix. The real challenge is making sense of a world where nothing stays still long enough to document it.

Enter generative AI, the latest character in our tragicomic office play.

According to McKinsey, it’s going to “enable the organization of the future”. That’s consultant-speak for “brace yourselves, everything is changing again.” But if you read past the buzzwords, there’s an important caveat: organizations may be powered by gen AI, but they’ll still be driven by people. People like us — the ones who are supposed to explain this circus to everyone else without sounding like lunatics.

I’ve already watched AI crank out draft documentation that looked eerily plausible. For about ten minutes, I felt my job security wobble.

Then I read it again. It was like watching a magician pull a rabbit out of a hat, only to realize the rabbit is taxidermied and missing an ear. Sure, it looked like documentation, but it was riddled with hallucinations, half-truths, and the kind of optimism usually reserved for timeshare salesmen.

Researchers have pointed out that “hallucinations” are one of gen AI’s most persistent flaws. That’s when it hit me: the AI can spin a story, but it can’t tell when the story is useful — or true. That part is still mine to do.

What does this all mean?

What this means is that our work is changing shape. We’re no longer just scribes capturing the output of developers. We’re now interpreters of machine output, risk translators, and—if we’re honest—therapists for colleagues who are quietly terrified that a chatbot is going to replace them.

AI may draft the words, but we’re the ones who make sure those words don’t cause a lawsuit, a meltdown, or a late-night call from a panicked customer who followed the wrong instructions.

McKinsey says the organizations that thrive will be the ones that embrace experimentation, trust, and adaptability.

That sounds lofty, but in practice it looks a lot like what tech writers already do:

• experiment with tools

• figure out where they break

• and then explain it to everyone else using metaphors that involve cooking or IKEA furniture

We’re professional sense-makers in a world that makes less and less sense.

So, yes, gen AI is here to stay. It will keep generating, and people will keep being people — messy, skeptical, hopeful. And technical writers will be the ones stitching those two realities together, half comedian, half cartographer. In the “organization of the future,” that’s a job description AI can’t fake. 🤠

And then, the existential question hits: Could a robot do this?

According to the latest report by the Society for Human Resource Management (SHRM), business, finance, and HR jobs are the most likely to face the automation axe. But technical writers? We're not even on the list of highly at-risk jobs. (😮‍💨 Cue a cautious sigh of relief.)

Now, before you get too cozy, let's talk about why. AI tools can efficiently generate introductory text and automate formatting tasks, but they struggle to handle the nuance of technical writing. That's because technical writing involves more than slapping words on a page.

It requires its practitioners to wrangle complex concepts into something accurate and digestible, while anticipating the confusion of users who may not know an API from their elbow.

AI may help with routine tasks—generating tables, auto-summarizing, or suggesting simpler phrasing—but it just doesn't cut it when it comes to making sense of a feature held together by duct tape and hope or translating developer shorthand into something that won't make users cry.

So, while automation might take a bite out of some industries, technical writing—at least involving critical thinking, creativity, and plain old human intuition—still needs people. We're not just typists. We're sense-makers, storytellers, and those who can spot when a spec is about to send the entire project sideways.

This period is especially interesting because it includes the PC revolution through the dot com boom through the birth of the internet as the everyday world, available on smartphones in nearly every corner of the world. Additionally, the field changed from predominately male to predominately female.

Technical communication industry veteran and university instructor, Sharon Burton, is looking to capture the stories of women working in the field.

Interested in participating? Respond to the Call for Writers.

• Maybe you ditched the endless chaos of sticky notes and random file names and finally figured out how to get your act together.

• Perhaps you leveled up your info-management game to the point where your team runs like a German train schedule—efficient, precise, and oddly satisfying.

• Or maybe — just maybe — you’ve cracked the elusive code on tracking metrics that mean something—no more pretending that page views alone are changing the world.

Whatever your situation, you probably have a valuable story with lessons learned to share with others. If that’s the case, I’d like to hear from you.

I’m working to fill our webinar schedule with stories from practitioners working in the trenches. If you’d like to share your story, complete this short form. I’ll get back to you shortly to schedule a call to discuss the opportunity.