Behind the Docs

Ren sits down with Mark Pepper — information architect, knowledge engineer, and founder of Crimson Sage Softworks — to talk about a career that started in journalism and music before landing in structured authoring and taxonomy work. Mark shares how he built a full content operations framework (audits, channel modeling, taxonomy, metadata, reuse, governance) from 25+ years of consulting, and how he's now turning that framework into AI agents — starting with a content audit agent built as a Claude skill. The conversation moves from practical pitfalls in content management to a bigger idea: that content practices haven't changed much since 19th-century newspapers, they've just gotten new tools.

In this episode:

• Mark's winding path from musician to soldier to journalist to tech writer to independent information architect
• Why journalism skills — research and interviewing — transfer directly into tech writing and SME interviews
• The content ecosystem framework Mark built: content audits, channel modeling, taxonomy design, metadata, reuse models, workflows, and content standards, all under a governance umbrella
• The two most common pitfalls companies hit: "buy a tool and it solves everything," and cherry-picking which parts of the framework to implement
• How Mark is building AI agents for tedious framework steps, starting with a content audit agent (built by feeding his own process documentation into Claude and asking it to generate a skill)
• The "new Gutenberg" analogy: how the writer → editor → layout → publisher workflow of old-school publishing maps onto structured content today, with a detour through the messy desktop-publishing era in between
• Why standardization (DITA, DocBook, S1000D, and now AI tools like Claude, OpenAI, Gemini) tends to emerge in any maturing field
• Designing content around user relevance, not just reuse — including an early example of device-aware, dynamically assembled help content
• Rapid-fire: what makes documentation great, what good docs look like in practice, best career advice, and the hill Mark will die on (write for the user, not the writer)

Resources & links:

• Mark Pepper on LinkedIn
• Crimson Sage Softworks

WTFM is out today! 📚

Today’s episode of Behind the Docs is a special one because it lands on the official release day of CT Smith’s first book, WTFM: A Practical Guide for Standing Up Docs at a Startup.

In this episode of Behind the Docs, Ren Taylor talks with technical writer and documentation leader CT Smith about her path into technical writing, the thinking behind her new book, and what it really takes to build documentation that works.

CT wrote WFTM for people who find themselves responsible for documentation before they’re ready—or able—to hire a dedicated technical writer. The book focuses on making smart decisions early so teams can avoid creating documentation problems that become harder to solve as the company grows.

The conversation covers CT’s path into tech writing, the value her philosophy background brings to her work, and why she believes documentation should be treated as a specialized craft. Ren and CT also discuss working effectively with marketing, using AI in documentation workflows, and where humans still need to stay firmly in the loop.

• How CT went from studying philosophy and working at Waffle House to becoming a technical writer
• How to build relevant experience when you don’t have a traditional technical writing background
• Why CT wrote WTFM and who she wrote it for
• The importance of setting up documentation well before a company needs a dedicated docs team
• Why documentation and marketing teams should work together, and where their goals differ
• How CT uses AI to automate parts of her documentation workflow
• Why AI should support, rather than replace, human judgment and empathy
• The characteristics CT looks for in genuinely good documentation
• How to make the business case for technical writing
• Why CT believes technical writers are important, and why the profession may be headed for a renaissance

WTFM is available September 1 in EPUB, paperback, and online. CT has also created an interactive calculator and additional resources to accompany the book, which you can find on her website!

Guest: CT Smith

CT's website: https://docsgoblin.com/

The Global English Style Guide: https://books.google.vu/books?id=r0AiqqRBPF0C&printsec=frontcover#v=onepage&q&f=false

Host: Ren Taylor

A different kind of guest this episode: Ren talks with Rahul Garg, a project management professional who's spent his career in telecom and fintech coordinating between developers, testers, quality teams, and senior stakeholders. Rahul isn't a technical writer, but his approach to communication, audience-tailoring, and building a team newsletter has striking overlap with what technical writers do every day.

Rahul breaks down why he sees himself as "the bridge" between isolated stakeholder groups, how ambiguous words like "done" or "highlight" can derail a project if teams aren't aligned on meaning, and how he turned a messy, jargon-heavy team newsletter into a concise, consistent communication tool that became a single source of truth for his project.

• Rahul's background in telecom and fintech project management, and how his role evolved from "managing work" to helping people understand what they're doing and why
• Why he calls himself a bridge between stakeholders working in isolation, and how he tailors content differently for developers, testers, quality teams, and senior leadership
• The importance of defining shared vocabulary on a project (what does "done" actually mean?) before work even starts
• Building a communication plan for distributed, cross-timezone teams, and using handoff notes to bridge gaps when no meeting time overlaps
• How Rahul launched a team newsletter, why the first version flopped (too long, too jargon-heavy, almost nobody read it), and the structure he landed on: quick wins, risks, delivery updates, blockers, and recognition
• Why consistency and recognition matter so much in a recurring newsletter, and how it created two-sided value — visibility for the team and a documented record protecting against "I wasn't aware" moments later
• Streamlining how he collects input from contributors so the newsletter doesn't become an unmanageable dump of blockers and non-highlights
• Where project management and technical writing overlap and diverge: technical writers own the "how," project managers own the "what and why" — and where friction between the two roles can show up
• His hill to die on: organizations massively underestimate the cost of poor communication, and transparency has declined since the pre-COVID era

Ren talks with Archer Berryman, a documentation leader at Broadcom, about a 21-year career in tech comm that started with an internship at Computer Associates (Archer thought it was a computer repair shop) and has spanned an acquisition, a shift from Word docs to structured CMSs, folding product education into the doc team, and now the AI disruption reshaping the field.

Archer talks candor about staying in one place for two decades, why he thinks writers get an unfair reputation for job-hopping less than other disciplines, how his team absorbed Broadcom's product education function after the training org was cut, and his management philosophy of giving writers positive feedback since — like referees — they usually only hear about their work when something's wrong.

• Archer's path into tech writing: an English degree, a recruiter call he almost turned down, and 21 years at Computer Associates/Broadcom
• Why longevity in tech comm often comes down to luck, timing, and finding the "niche nobody else has expertise in" (for Archer, it was early structured/object-oriented CMS adoption)
• Surviving the Broadcom acquisition and absorbing product education into the documentation team after the training department was cut
• Lessons learned turning technical writers into instructional designers, and why training content needs a different discipline than reference docs
• Archer's management philosophy: zero ego, be yourself, and the importance of giving writers positive feedback so the work doesn't become an echo chamber
• Advice for new writers: use the "gift of time" early in your career to build an advantage, and lean into AI rather than resist it
• How Archer is guiding his team through the accelerating pace of AI adoption in documentation, and reframing it as time given back rather than an existential threat
• His hill to die on: documentation is a mirror — a writer's job is to reflect the product honestly, not make it look simpler or more polished than it is

We're back! This episode marks our return from summer break, and we couldn't have picked a better guest to kick things off.

Ren sits down with Danielle Washington — technical documentation writer with stops at HPE, Weaviate, and now 10A Labs — for a conversation about how she found her way into tech comm through candle-making, teaching English in Spain, and political science, and what that winding path taught her about writing for readers.

Danielle shares her "Day 0, Day 1, Day 2" framework for structuring documentation around the decisions readers are actually making, why she treats herself as "user zero" by testing everything she writes, the EKS configurator she built at Weaviate to replace words with a tool, and her take on where AI is pushing (and sometimes pressuring) the technical writing profession.

• Danielle's unconventional path into technical writing — from a high school blog, to political science, to running a candle company, to landing at HPE
• Being the first and only technical writer embedded on an engineering team, and how she learned to prioritize what to document first
• "Docs as a decision system": the Day 0 / Day 1 / Day 2 framework for thinking about what a reader needs to decide at each stage
• Why Danielle tests her own documentation as "user zero" instead of only writing from the user's perspective
• The EKS configurator she built at Weaviate to replace fragile, error-prone YAML instructions with a real tool
• Her move from HPE (GreenLake) to Weaviate (deployment docs, vector databases) to 10A Labs (information retrieval systems)
• Agent-friendly documentation, the shift toward tooling over pure prose, and why AI shouldn't be a scapegoat for layoffs
• Her hill to die on: documentation is a product surface, not a support feature

• From Kitchen Experiments to Five Star Service: The Weaviate Development Journey — Danielle's Weaviate blog post applying the Day 0/Day 1/Day 2 framework to the developer journey
• How We Are Building the Core of the AI-Native Stack — the original Weaviate post that introduced the Day 0/Day 1/Day 2 mindset
• Danielle Washington on LinkedIn
• Previous Behind the Docs episodes referenced in this conversation:
• Designing Documentation for Agents, Not Just Users — with Dachary Carey of MongoDB
• Doc testing, skills files, and the guardians of knowledge — with Manny Silva of Skyflow, creator of Doc Detective

In this episode of Behind the Docs, Patrick Bosek sits down with Fabrizio Ferri-Benedetti to explore what AI actually means for the future of technical communication — beyond the hype.

Fabri shares his journey from software reviewer and blogger to Principal Technical Writer at Elastic, where he helps shape documentation tooling, AI workflows, and collaborative content systems. The conversation dives into the evolving role of technical writers, why AI works best as a collaborator rather than a replacement, and how documentation teams are becoming increasingly responsible for architecture, tooling, and content operations.

Patrick and Fabri also unpack the growing tension between AI acceleration and thoughtful implementation. They discuss the shift toward local and self-hosted models, the hidden value of “busy work” in building understanding, and why foundational content architecture matters more than ever in an AI-assisted world.

The episode closes with a thoughtful look at what “great documentation” will mean in the future: content that is accessible to both humans and machines, structured with intent, and designed as coherent knowledge systems rather than disconnected pages.

• Fabri’s path from blogging and SEO into technical writing
• How personal writing helps sharpen thinking in the age of AI
• Why AI should be treated as a collaborator, not an autopilot
• The role of technical writers in AI tooling and DocOps
• How documentation tools reflect organizational culture and “taste”
• Why AI hype may plateau over the next 18 months
• The rise of local and self-hosted AI models
• What orchestration work looks like for future technical writers
• Why foundational documentation still requires deep human expertise
• The importance of content types, metadata, and structure for AI consumption
• Advice for early-career technical communicators learning AI
• Why the future of docs may look surprisingly similar to the past

Fabri Ferri-Benedetti is a Principal Technical Writer at Elastic and a widely respected voice in the technical communication community. Through his blog, Passo Uno, and active online presence, Fabri explores the intersection of AI, documentation tooling, developer experience, and the evolving future of technical communication.

• Fabri Ferri Benedetti’s Blog – Passo Uno
• Elastic
• Write the Docs

This episode of Behind the Docs is coming straight from the conference floor at ConVEx 2025 in Pittsburgh — a collection of candid conversations with the people who make this community what it is.

From first-timers to veterans with decades in the field, the throughline is clear: this industry is in the middle of something real, and the people here are figuring it out together.

They also dig into:

• why metadata keeps coming up in every single conversation — and why it matters more than ever for AI
• how well-structured content is already separating teams that are succeeding with AI from teams that are struggling
• what it actually feels like to show up to a TechCom conference as a newcomer (spoiler: everyone becomes an extrovert)
• the best real-world example of faceted search you've probably never thought to look at (hint: it's a knitting website)
• and why "garbage in, garbage out" is just as relevant today as its always been

If you care about where this profession is headed — and you want to hear it from the people actually doing the work — this one's for you.

Big, big thank you to the team at the Center for Information-Development Management (CIDM) for putting on another great conference. Looking forward to doing it again next year!

In this special replay from Scriptorium's Content Operations podcast, Sarah O'Keefe sits down with our very own Patrick Bosek to tackle one of the thorniest problems in AI-powered content work: governance.

Patrick and Sarah unpack why governing AI outputs gets harder as the technology improves, and why the structure you put into your content before it ever reaches a model may be your most important quality lever.

They also dig into:

• why "garbage in, garbage out" is too simple and what good upstream governance actually looks like
• how content structure serves humans first (and why that makes it better for AI too)
• what happens when end users start stripping warnings and summarizing away critical information
• why you should never replace a working deterministic system with an AI one

If you work in content strategy, technical writing, or are watching your organization stand up an AI team and wondering how to prepare, this one's for you.

You can listen to this episode and many more Content Operations conversations on Scriptorium's website.

Jeff Cross didn't plan to become a technical writer. He started a computer science degree, dropped out, spent a year trying to make it as a fiction writer, went back for a philosophy degree, considered academia, and then — almost by accident — realized that technical writing was the thing that made all of it make sense.

Now Senior Manager of Technical Writing at Arctic Wolf, Jeff has spent years doing some of the most complex content work in the industry: documenting third-party security integrations he has no direct access to, managing a full DITA migration while keeping up with release cycles, and pulling off a content carve-out from a corporate acquisition with translated content in three languages and a hard deadline.

In this episode, Jeff and Patrick talk about what it really means to do great documentation work, and why the hardest parts rarely show up in a job description.

They cover:

- Why the security space takes documentation seriously in ways other industries don't

- What happened when a product rename turned "a" into "an" across thousands of content files

- How AI helped a small team execute a DITA-to-DITA migration without outside help

- The checkbox doc that nobody wanted to write — and that way more people read than expected

- Why technical writing is less like writing and more like investigative journalism

Plus: Patrick discovers mid-conversation that Jeff was the person who fixed the BlackBerry email signature problem that drove him personally crazy for a year.

In this episode of Behind the Docs, Ren sits down with Dachary Carey of MongoDB to explore a rapidly emerging challenge: AI agents can’t reliably read your documentation and most teams don’t realize it.

Dachary shares how a deep dive into agent workflows (sparked by tools like Claude Code) uncovered critical gaps in how documentation is structured, delivered, and consumed by machines.

From truncated pages and hidden content to the unexpected importance of formats like llms.txt, this conversation reveals why even well-written docs can become effectively invisible to AI systems.

They also dig into:

1. how agents actually interact with documentation (and where they fail)
2. why technical writers are becoming essential to AI success
3. and the growing gap between companies investing in docs and those cutting them entirely

If you’re thinking about AI, content strategy, or the future of technical writing, this episode is a must-listen.

Important Links:

1. Dachary's LinkedIn: https://www.linkedin.com/in/dachary/
2. Dachary's website: https://dacharycarey.com/
3. The Agent-Friendly Documentation Spec: https://agentdocsspec.com/
4. The GitHub repo for anyone who wants to contribute or leave feedback: https://github.com/agent-ecosystem/agent-docs-spec
5. The npm tool (afdocs - for Agent-Friendly docs) that documentation teams can run to see how agent-friendly their documentation is: https://www.npmjs.com/package/afdocs
6. The GitHub repo for that tool for anyone who finds an issue or has a suggestion or request: https://github.com/agent-ecosystem/afdocs