Building Customer Education Programs with Karissa Van Baulen of Pallon

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)

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. In this episode 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

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. In this episode 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. In this episode 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. In this episode 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