The Not-Boring Tech Writer

In this solo episode, Kate shares an update on her content update progress. She also reflects on Sarah Walker’s interview (S3:E18) and the concepts of Asteya, giving great service, and going the extra mile.I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that we rolled out in December. I also created about 30 articles for the launch of KnowledgeOwl’s new Owl Analytics feature, taking my total to 618. 🎉Sarah’s interview gave me a lot to think about, and I spent the bulk of this episode reflecting on some key points from that conversation. First, I focus on the concept of Asteya she shared, in the context of not stealing time and energy from other people. This concept is so central to well-written documentation and is a compelling argument in favor of clear, consistently applied style guidelines. I coined the phrase “Style guide adherence is an anti-theft device” to summarize this idea. Our conversation reminded me so much that creating great documentation is an act of giving great service. I outline the three-step guide to giving great service that KnowledgeOwl uses, which is based on Zingerman’s Guide to Giving Great Service: 1) Find out what your customer wants; 2) Get it for them accurately, politely, and enthusiastically; 3) Go above and beyond, or go the extra mile.Step one is often the hardest piece of giving great service since people often don’t know how to articulate what they actually want. At KnowledgeOwl, we use Disney’s “What time is the 3 o’clock parade?” example to show our new support and success owls how what someone asks for isn’t necessarily the question they want answered.Great documentation helps deliver step two by creating the accurate answers your readers need.Step three ties very nicely back to statements Sarah and I both made—about the idea of crafting a solid experience for others in our documentation, of distilling what they need and making it as streamlined as possible. This discussion builds on the ideas of craft we’ve previously discussed, the idea of care I discussed in Episode 17, and Sarah’s comments about crafting something FOR others. Sharing knowledge is an inherent piece of our humanity and of building human communities. Documentation isn’t merely transactional—it’s also an act of care, a gift of time and knowledge, and a gift of saved time so people can pursue other interests.Resources discussed in this episode:KnowledgeOwl Support Knowledge Base, especially the Owl Analytics documentationZingerman’s Guide to Giving Great ServiceZingTrain’s The Art of Giving Great Customer ServiceDisney Institute Blog’s How Would You Respond If Asked: ‘What Time Is The 3 O’clock Parade?’The Disney 3 o’clock parade question: Insights from KnowledgeOwl support teamJoin the discussion by replying on Bluesky —Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this episode, I talk with Sarah Walker, a technical writer and yoga instructor, about how yoga principles like establishing foundations, respecting people’s time, and embracing practice over perfection can transform your approach to technical writing and help you create more mindful, user-centered documentation.Sarah and I discuss her path into technical writing, which began with yoga instructor training where she discovered how much she enjoyed breaking down complex processes into foundational steps. This experience taught her that effective instruction—whether for yoga poses or technical procedures—requires understanding your audience's needs and building from core principles. We explore how yoga's emphasis on establishing solid foundations directly translates to documentation, where starting with fundamental concepts helps both beginners learn and experienced users refresh their understanding.We explore the yoga principle of Asteya (non-stealing), particularly how it applies to respecting readers' time and attention. Sarah explains how this philosophy shapes her approach to writing clear, concise documentation that helps users efficiently get to their goals. We discuss practical applications like using consistent style guidelines to reduce cognitive load and being mindful of which content is essential to include in your docs.Our conversation also covers how yoga's concept of practice over perfection applies to technical writing careers. Sarah shares how documentation evolves alongside products and why embracing this constant change rather than striving for perfect static content leads to better outcomes. We explore the parallels between sequencing yoga poses and sequencing information in documentation, the importance of observing your audience's needs, and how both practices require patience, self-compassion, and continuous learning.About Sarah Walker:Sarah's been writing and crafting stories since she was able to put pencil to a Peanuts 3x5 top-spiral memo pad and record her stories in her own scribbly alphabet. Since personal alphabets scribbled on tiny pieces of paper don't pay the rent, she embarked on her career as a professional writer and editor after graduating from St. Edward's University (Austin, TX) in 1998. As an industry editor with Hoover's for roughly seven years, she covered biotech, pharmaceuticals, health care systems, venture capital, investment firms, and other sectors as a member of the Finance and Health Care editorial team. She earned her Austinite bone fides by getting hired by and, 18 months later, laid off by Dell, where she served as a technical editor for the Global Technical Training and Curriculum Team for products and software for consumers as well as small and midsize businesses. Thanks to the Great Recession and other market forces and personal demands, she bounced around a bit from writing and editing features, self-help book summaries, U.S. Pharmacopeia monographs, and other technical-ish content.She began her technical writing career in earnest at Libre Digital, where she spent much of the second decade of the 21st century documenting procedures for processing various magazine titles as well as a platform for book publishers to distribute their titles to digital marketplaces. After a two-year stint as the managing editor (and lone full-time, non-contract employee) of a local bimonthly magazine targeting affluent residents of "West Austin," at long last (in August 2020), Sarah landed a job that gave her the Technical Writer job title, and she's been writing about the Monetate platform ever since.Sarah's second career as a yoga instructor (and briefly a Pilates mat instructor) began in 2005, after she completed her 250-hour instructor training with Yoga Yoga (now defunct, just like the college in Santa Fe, NM that she attended for the first two years of her undergrad studies). She taught part-time until 2012, when primary job demands and other responsibilities forced her to give it up.Resources discussed in this episode:Garbl’s Writing CenterOn Writing: A Memoir of the Craft by Stephen KingSarah’s Elect a Raccoon Overlord articleJoin the discussion by replying on Bluesky —Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact Sarah Walker:BlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, Kate shares an update on her content update progress. She also reflects on Manny Silva’s interview (S3:E14), Ryan Macklin’s interview (S3:E16), and Liz Argall’s interview (S3:E13) and the importance of learning even when we don’t have explicit reasons to do so.I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 15 articles since my last episode, taking my total to 565. 🎉This month’s velocity was a lot lower thanks to prepping for, teaching, and attending KnowledgeOwl’s July 2025 Summer Camp workshop series.While teaching the classes was fun, it also triggered a lot of issues with my chronic illness, so I finished the month quite depleted on every level. This made me think a lot about the ambient and acute stress Ryan and I discussed in relation to empathy advocacy, and about how all documentation makes demands on readers’ cognitive capital. I share five documentation techniques that helped me get use from docs when I was struggling the most cognitively:Provide a summary, synopsis, TL;DR, or 1-2 context-setting sentences at the start of a doc or each section.Use strong page titles and headings, avoiding general catch-alls like “Frequently Asked Questions.”Format your content consistently using semantic elements like sequential headings.Use callouts, warnings, or admonitions sparingly but in consistent ways.Practice screenshot restraint.I also reflect on how tricky it is to actually accommodate learning as a tech writer if I don’t have a pressing need for it. We learn new tools or domains often since it’s required. We learn new tooling or scripting to make our lives easier or because it’s required. We attend classes, conferences, or certifications. But we often don’t take time on less formal, bigger picture learning. I share how doing research to teach a class on style guides led me to find all kinds of flaws and oversights in my existing style guide. I challenge all of us to carve out 2-4 hours in the next month to dig deep on a best practice or concept we want to learn more about. If you lack the time or discipline and have a professional development budget, you can also consider joining me for the Information Architecture Master Class I’m teaching in partnership with KnowledgeOwl in September and October. Use discount code NOTBORING.Resources discussed in this episode:KnowledgeOwl Support Knowledge BaseOur upcoming Information Architecture Master ClassJoin the discussion by replying on Bluesky —Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

Learn how Ryan Macklin's "empathy advocacy" framework helps you design documentation that works for users in all emotional states (e.g. anxious, frustrated, exhausted, and curious/distractible) rather than assuming everyone comes to your docs in a perfect state of clarity.Ryan and I discuss his unique path into technical writing, starting from his early computer hacking days and role-playing game writing background. Ryan explains how writing and editing tabletop games taught him that documentation is harder than technical writing because it requires creating user interfaces for "disconnected, squishy brains" while making content engaging enough that users won't simply abandon it for alternatives. This experience, combined with his personal journey through therapy and understanding neurodiversity, eventually led him to develop the empathy advocacy framework.Our conversation centers around Ryan's empathy advocacy concept, which focuses on writing for users who aren’t calm. These users might be in four key cognitive states: anxious, frustrated, exhausted, and curious/distractible. Rather than designing documentation for the "happy path" or optimal users, Ryan advocates for considering people who may be dealing with high ambient stress, acute stress from urgent problems, cognitive depletion, or distractibility. The "stupid users" developers complain about are often just busy, stressed people whose brains aren't optimally processing information.We explore practical applications of empathy advocacy concepts, including strategic screenshot reduction to minimize cognitive load, restructuring and tightly scoping FAQs to avoid information architecture problems, and understanding that every element in documentation has a "tax" on your user’s mental energy.The episode also includes practical advice on social capital management, documentation stewardship, and the importance of "failing forward" rather than getting stuck in perfectionism.About Ryan Macklin:Ryan splits his cerebral time between tech writing, UXing, coding, and game design. By day, Ryan writes and edits software and hardware requirements. Otherwise, he works on game or tooling projects, light woodworking, and land improvement projects on his homestead in southern Michigan. Warning: Ask him about UX in games, and he may talk your ear off.Resources discussed in this episode:empathyadvocacy.orgRyan Macklin talk: WTD ECQ Nov '22: 7 doc techniques rooted in empathy advocacyRyan Macklin talk: How to avoid "toxic tennis" — empathy in user communicationOther technical communication talks by Ryan MacklinJoin the discussion by replying on Bluesky —Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact Ryan Macklin:Ryan's newsletter: buttondown.com/ryanmacklinmacklin.ccLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, Kate shares an update on her content update progress. She also reflects on Nick Graziade’s interview (S3:E12) and Liz Argall’s interview (S3:E13) and the ways these interviews highlight some elements of “good” docs experiences.I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 43 articles since my last episode, taking my total to 550. 🎉 I’m in the middle of updating our Contextual Help Widget documentation—one of the features I’ve been putting off updating—and I’ve been drafting content for our forthcoming AI Chatbot feature, too.Nick and I share a tech writer villain origin story of absolutely adoring LEGO documentation, and it’s gotten me curious how many other tech writers also have this early exposure to documentation. And for some reason I’m seeing tech writing everywhere. I share a detailed story of Bont Cycling’s online shoe fit guidance, which I recently used and which has created a fairly positive product experience for me. Good documentation experiences can help create good product experiences.I also reflect on Liz’s comment that “The best fertilizer is the gardener’s shadow.” She talked about this in the context of just showing up to work on docs, but I extend that metaphor to say showing up working with care. I gave two examples of this. I’ve been struggling with some personal losses, so a lot of my docs work lately has been a blitz of low-hanging docs fruit: a lot of small changes and improvements. None of these updates are substantive, but they’re good iterative improvements and they helped me get back into docs work. I also share a story of building a long-procrastinated-on bench for my entryway, which was more about accepting good rather than great just to get something built. Good docs are dynamic and iterative–they may not be perfect at first, but they’re constantly improving and always striving for a better reader experience.Resources discussed in this episode:Our new merch store!KnowledgeOwl Support Knowledge Base, especially the Contextual Help Widget documentationBont Cycling Shoe Size Finder (The docs I referenced in the episode are hyperlinked in the Print Sizing Page section.)Join the discussion by replying on Bluesky —Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this episode, I'm talking with Manny Silva, a technical writer who created the "Docs as Tests" concept name and the open-source tool Doc Detective. We discuss how to automatically test your documentation for accuracy, why customer reports of broken docs are actually failed tests, and practical ways to implement automated documentation testing regardless of your tech stack.Manny and I discuss his background as someone who intentionally chose technical writing as a career path, starting with early exposure to computers through his mother's work and developing into roles at Apple, Google, and now Skyflow as Head of Documentation. We explore the core concept behind Docs as Tests—that documentation contains testable assertions about how a product should work, and that customer reports of broken procedures are essentially failed tests that we should catch proactively rather than reactively.We dive deep into how Manny's strategy works in practice, from the "cupcake to wedding cake" approach of starting small and scaling up. We dig into two different approaches to the technical implementation: creating “detected” tests using Doc Detective, which reads the docs directly and uses them as tests, and creating standalone tests in testing tools like Playwright or Cypress, which you’d create and update independently of the docs. Manny explains how his Doc Detective tool can parse markdown documentation, automatically execute the steps described in procedures, capture screenshots for visual regression testing, and even validate API responses against OpenAPI schemas. We discuss the business case for automated documentation testing, including how it prevents customer frustration, builds trust, reduces support overhead, and can catch bugs before they reach production.Throughout our conversation, we explore practical implementation strategies, including how to sell the approach to stakeholders, integrate testing into CI/CD pipelines, handle multifactor authentication challenges, and work with QA teams. Manny also shares his philosophy of creating a "zero trust" relationship between docs and product—not out of disrespect, but to ensure everyone stays honest about the behavioral contract that documentation represents. Docs as Tests also encourages technical writers to embrace their unofficial QA role–as writers, we’re often the first to test a new feature or product, and embracing a Docs as Tests mindset can help legitimize and make visible this role.About Manny Silva:Technical writer by day, engineer by night, and father everywhere in between, Manny wears many (figurative) hats. He's passionate about intuitive and scalable developer experiences, and he likes diving into the deep end as the 0th user.Here are a few things that keep him busy:Head of Docs at Skyflow, a data privacy vault company.Codifier of Docs as Tests, a tool-agnostic strategy for keeping docs and their products in sync by using doc content as product tests.Creator and maintainer of Doc Detective, an open-source doc testing framework.AI development and experimentation.He's always looking for collaborators on projects, and he loves chatting with folks, so don't hesitate to reach out.Resources discussed in this episode:Docs as Tests: A Strategy for Resilient Technical Documentation - Manny's bookDocs as Tests blog - Manny's blog about the strategy and various toolsDoc Detective - Manny's open source tool for testing and validating documentationDoc Detective GitHub action - Official GitHub action for CI/CD integrationDoc Detective Discord server - Public community for users implementing Docs as TestsGood to Great book series - Business development books that Manny recommendsFramework laptop - Repairable laptop that Manny built with his childrenVale - Style guide enforcement tool (mentioned as complementary to Docs as Tests)Playwright - Engineering-level testing tool used by some companies like DockerCypress - Another engineering-level testing toolBen Perlmutter - Unit Test the Docs: Why You Should Test Your Code Examples - A Write the Docs Portland 2022 talk about MongoDB's unit testing documentation approachArazzo specification - Newer OpenAPI initiative specification for workflow testing—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact Manny Silva:Doc DetectiveLinkedInContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this episode, I’m talking with Liz Argall, a writer I connected with at Write the Docs Portland 2025. We talk about working on open source projects, developing good qualitative metrics, her work with a permaculture nonprofit in Uganda, and the ways that being interviewed by a technical writer can make hidden expertise shine.Liz and I presented in the same Lightning Talk session at Write the Docs Portland 2025 and subsequently discovered a shared love for spreadsheet tools, qualitative metrics, and permaculture. We discuss her work on Project Aria, a combination of hardware, software, and data collection geared toward solving the problems that augmented reality will need to address. Liz stresses the point of writing for poorly informed and/or sleep-deprived audiences. We also discuss the importance of qualitative metrics and some of Liz’s favorite qualitative metrics that help capture the story of the documentation, including impact and saving engineers’ and SMEs’ time.Liz also tells us about her involvement with Ngombor Community Development Alliance, a non-profit focusing on permaculture development in the West Nile region of Uganda. We also discuss how sometimes just showing up for something–including showing up to work on your docs–has far more impact than we realize.About Liz Argall:Liz Argall creates empowering documentation and processes; where you need it, when you need it.She’s a technical writer, program manager, author, and trainer who delivers humanizing, data informed, accessible, and technically complex projects for a range of organizations, from Fortune 500 companies to a community development organization in Uganda.In a past life, she was a professional artist talent scout and she’s still a professional member of SFWA (now called the Science Fiction and Fantasy Writers Association). She’s a graduate of Clarion Writers Workshop, has been critiqued by multiple New York Times best selling authors, and has critiqued the stories of multiple award winning authors, which is a long way of saying that she likes to give a good portfolio critique!Resources discussed in this episode:Project AriaFabrizio Ferri Benedetti’s Why I became a Documentation Engineer (and what that even means): The source for the phrase “technical therapist”Write the Docs Portland 2025, Lightning Talk session 1Liz's portfolio siteIntroduction to search term analysis: Liz’s blog post about the Lightning Talk she gave, which includes links and instructions for her spreadsheetAttend to the work: A blog post by Liz where she alks about permaculture and Diataxis in the context of technical writingDiátaxis as a guide to workLucy Mitchell's websiteUbuntu Summit 2024 | Open source software between Africa and the West: The YouTube presentation that inspired Liz to get in touch with VinceNgombor Community Development Alliance: a non-profit focusing on permaculture development in the West Nile region of UgandaNgombor Community Development Alliance's sponsor a tree (or chicken) page—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact Liz Argall:Liz's website: includes her blog, which has several awesome spreadsheet matrices you can copy and use for yourselfLinkedInBlueskyContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this episode, I'm talking with Nick Graziade, a technical writer and musician who approaches documentation as a creative endeavor. We explore how his early fascination with Lego instructions and synthesizer manuals shaped his philosophy that technical writing doesn't have to be dry or boring, but can be passionate and innovative work that adapts to different audiences and embraces impermanence.Nick shares his two-part "villain origin story" that led him to technical writing. The first part involves his childhood fascination with Lego instructions, which taught him that visual documentation could guide complex building without narration. The second part comes from his music school experience with synthesizers, where he discovered that the best manuals—like those from Moog—don't just explain how to do something, but also why. This combination of visual clarity and deeper understanding became his template for approaching technical documentation.We dive deep into the concept of using different "grammars" for different audiences, drawing from Wittgenstein's language games. Nick emphasizes that effective technical communication requires understanding what assumptions you can make about your readers and adapting your language accordingly. We explore how consistency in style and formatting reduces cognitive load for users, and how deliberately breaking those patterns can create powerful contrast for important information like warnings or alerts.Throughout our conversation, Nick reflects on his philosophy of embracing impermanence in documentation. Rather than being frustrated by constant updates and revisions, he sees the evolving nature of technical writing as aligned with his Buddhist-influenced worldview. We discuss practical approaches to managing documentation workflows, including his use of quarterly revision cycles, just-in-time updates based on development sprints, and how he determines when something is "done enough" to move on to the next priority.About Nick Graziade:Nick is a Senior Technical Writer, instructional designer, knowledge management expert, musician, and philosopher from Upstate New York's Capital District.When not obsessing over the nuances of a web page's navigation sidebar, you can likely find him playing gigs as a professional bassist or practicing Japanese sword arts.Resources discussed in this episode:Moog Music user manuals: https://www.moogmusic.com/downloads/—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller: knowledgewithsass.comLinkedInBlueskyContact Nick Graziade:nicholas.graziade@gmail.comContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this solo episode, Kate shares an update on her content update progress. She also reflects on Sue Brandt’s interview (S3:E10) and on the Write the Docs Portland 2025 conference.I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 50 articles since my last episode, taking my total to 507. 🎉Most of the updates this month were in our payment and plan-related documents, which needed to be updated for a new Billing page user interface and to include changes from migrating to a Merchant of Record.My velocity this month was lower thanks to teaching KnowledgeOwl’s Authoring 101 class and attending the Write the Docs Portland 2025 conference with Chad. Write the Docs is always a deeply inspiring conference for me, and this was my first time attending in person since 2019. This year, I even gave a lightning talk about dogs and docs, too!Much of the episode is spent reflecting on the six things I most love about Write the Docs, which include its support for first-time attendees and presenters, the flexibility and thoughtfulness of its design, and the amazing community of documentarians who form the backbone of this community. This year’s conference had a fantastic selection of talks and speakers, including several previous and upcoming podcast guests.Resources discussed in this episode:KnowledgeOwl Support KB: the Payments & subscriptions and Plans & pricing categoriesWrite the Docs Portland 2025 conferenceKate’s Of docs and dogs lightning talkFull playlist of recorded talks from Write the Docs Portland 2025—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller: knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this episode, I’m talking with Sue Brandt, a former Director of Documentation who’d hired around 60 people when we recorded the episode. We discuss practical strategies for technical writing job applications, what hiring managers are really looking for in resumes and interviews, and how to stand out in today’s competitive job market.Sue and I discuss various aspects of the tech writing job application process, including resumes, cover letters, and interviews. Sue, who has hired around 60 people throughout her career, emphasizes that enthusiasm is often a key differentiator for candidates.Throughout the episode, Sue shares practical tips based on her experience managing tech writing teams of up to 30 people, including ways to stand out as an applicant, how to handle situations where you may not have the exact technical skills in a job description but can demonstrate transferable skills and a willingness to learn, resume and portfolio best practices, how to honestly address gaps in employment, and more. The episode concludes with a discussion of career transitions and the importance of being open to learning new things.About Sue BrandtSue was educated as a biologist, did postdoc research into marine microorganisms, and named 13 new species! She moved a little closer to the tech field when she worked with computer scientists on a bioinformatics project and found herself in the role of "translator" between computer scientists and biologists. Her tech writing career unofficially started when someone looked over her shoulder when she was job searching and said "You could do that.” Sue worked as a Technical Writer at a UK startup for 3 years, then moved to Denmark and worked at Microsoft for 13 years as a Programming Writer and then Developer Documentation Manager. She was always adamant that she didn't want to be a manager, but she was persuaded to try it and found out she loved it! She became Director of Documentation at Sitecore and managed 30 writers, editors, and developers working on 10 different products in 6 countries.—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller: knowledgewithsass.comLinkedInBlueskyContact Sue Brandt:LinkedInContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this solo episode, Kate shares an update on her content update progress. She also reflects on Marcia Riefer Johnston’s interview (S3:E8) and on the idea of docs stewardship as opposed to docs ownership.I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 91 articles since my last episode, taking my total to 457. 🎉 I also reorganized another three Features subcategories, taking me to the milestone of having updated half those categories using content type-inspired information architecture. I also relocated 12 mice from my basement.Marcia’s episode prompted a lot of reflection for me. Her infectious, unbridled enthusiasm for this work—from learning new tools to new domains— reminded me of all the reasons I love the craft of technical writing, and how thankful I am that for the last year I’ve largely “only” been doing technical writing. I also appreciated Marcia’s exhortations to share what you know because you never know what great things will come from sharing your knowledge. Too often, we don’t share what we know because we don’t think we know “enough” (whatever that is). But sharing knowledge is a gift to others.Thanks to a conversation with a friend, I’ve started to come around to the idea of docs stewardship rather than docs ownership. “Stewardship” comes from the Old English words for house and guard. Stewards originally managed estates for medieval lords. I extend this into the world of documentation (doesn’t “Guardian of the Docs” sound like an awesome way to describe what we do? Maybe a swag idea, too, non?). Most modern definitions of stewardship include the idea of “careful and responsible management of something entrusted to one’s care” (source), though they may also add sustainability, ethical use, or “a duty to protect and maintain assets which might be natural, financial, or informational” (source). Marcia’s observation that a lot of a tech writer’s job involves project and process management aligns with this approach, I believe. I explore some other ways I like this docs stewardship model and then draw a comparison between tech writers and gardeners.Resources discussed in this episode:KnowledgeOwl Support KB, Features categoryMerriam Webster’s definition of stewardshipmeaningdictionary.com’s explanation of StewardChris Drew’s 25 Stewardship ExamplesTNBTW Episode 8—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller: knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this episode, I’m talking with Marcia Riefer Johnston, a technical writer who’s worked in our industry for 40 years. We talk about how the profession has evolved since she first started in it, the grammar patterns that have helped her tighten up her writing, and how “creative” writing and “technical” writing are just different expressions of the craft of writing.Marcia and I discuss how tech writing has evolved in the last 40 years as the tooling and field have evolved—from literally cutting and taping printed instructions together to using sophisticated content management systems and modular content. She shares the user feedback from her first set of technical instructions for using a remote control set-top box at Magnavox, highlighting how important user feedback is to help determine what needs to be documented.Throughout our conversation, we explore practical grammar techniques that have helped both Marcia and me strengthen our writing, such as restructuring sentences to center the reader rather than the tool. We also discuss how adding “by zombies” is a great way to suss out if you’re using passive voice (e.g. “This podcast is being listened to by zombies.”) and the strengths and weaknesses of the be verbs (am, is, are, was, were, be, being, etc.).We also talk about the value of sharing what you know, and how putting that knowledge out into the world can reap unexpected benefits. And we talk about the fact that the division between “creative ”writing and “technical” writing feels like a false binary: all acts of language are creative, and technical writing shares a lot of overlap with forms like poetry.We close by discussing how technical writers manage feedback from reviewers and explore how a significant percentage of technical writing involves project management skills such as managing conversations and helping everyone align on what the documentation should do.For both of us, handling contradictory feedback from reviewers usually involves having a larger conversation about what the problems or issues were, rather than only focusing on solutions. We theorize that part of the value tech writers bring is our ability to identify less-than-desirable user experiences and to not just take suggested edits as gospel but to question and explore the need for those edits.About Marcia Riefer JohnstonMarcia’s loved tech writing from the time she first heard the words technical and writer together. These days she brings technical and writer together as a consultant for Baxter International. In 2013, she fulfilled a dream by writing her book Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them). Two years later, her pocket-sized collection came out: You Can Say That Again: 750 Redundant Phrases to Think Twice About. Occasionally she posts on her own blog at Writing.Rocks. She lives in Portland, Oregon, where she makes things with scrumptious yarn, does New York Times crossword puzzles with her husband (especially the Thursday and Sunday puzzles), and lures in family and friends to play Wingspan and other games.Resources discussed in this episode:How to put the customer first in your sentences - Marcia’s blog post for KnowledgeOwlWriting.Rocks - Marcia’s websiteTo Be or Not To Be — First chapter of Marcia’s book, Word Up!Be and Me — Why writers want to watch for be-verbs. Bonus: the be-verb song.Single Sourcing: Building Modular Documentation by Kurt AmentRead Me First! A Style Guide for the Computer Industry by Sun Microsystems, Inc.Garner’s Modern English Usage by Bryan GarnerThe LavaCon conference on Content Strategy and Content OperationsBuy the Books - Links to Marcia’s books (You Can Say That Again: 750 Redundant Phrases to Think Twice About and Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them) and how to buy themResources for Writers - A more complete list of Marcia’s recommendations than we could discuss in the episode.—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comthenotboringtechwriter.comLinkedInBlueskyJoin the discussion by replying on Bluesky Contact Kate Mueller: knowledgewithsass.comLinkedInBlueskyContact Marcia Riefer Johnston: Writing.RocksLinkedinBlueskyContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this solo episode, Kate shares an update on her content update progress, muses about the similarities between mice infestations and docs projects, and reflects more on Kenzie Woodbridge’s interview (S3:E6) and how we choose what we work on.Since Episode 5, I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes from December. I’ve now updated roughly 400 pages and reorganized a total of five Features subcategories (one more since Episode 5).Most of note this month: I overhauled our Search documentation. This work was necessary due to new search settings and major changes to the search configuration pages. It was also the first feature documentation I wrote at KnowledgeOwl in 2018, and I’ve mostly tried to make minor tweaks to it instead of massively updating it. Thanks to some very positive feedback on the content type-inspired reorganization I’ve been doing elsewhere, I was able to make some much better content organization and substance changes.I’m also battling a mouse infestation in my rented house, and I spent some time in this episode comparing that process to working on documentation projects.This leads me into ruminating on the ways we can try to make the world a better, more inclusive place. I’ve been including a lot of Kenzie’s suggestions in my style guide content updates in this audit:Use actual headings. (Not usually a problem in our docs, but a good review item anyway!)Use sequential headings and make sure no levels are skipped. (This one does occasionally slip in, especially in older docs, so it’s been good to review.)Use link text that has more meaning than "See more" or "Click here". (Again, not a steady thing, but a good review item.)Add alt text to images. (Doing a lot of this!)I like the idea that, as content creators, content accessibility is well within our area even if we don’t feel qualified as experts in it. These accessibility areas are also solid best practices for content, information scent, wayfinding, and search engine optimization. I encourage you to try these or other small, iterative improvements that will make your docs a better place to be in the next month.Resources discussed in this episode:KnowledgeOwl Support KB, Search categoryKnowledgeOwl Support KB, Features categoryTNBTW Episode 5 and Episode 6—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInJoin the discussion by replying on Bluesky Contact Kate Mueller: LinkedInknowledgewithsass.comContact KnowledgeOwl:KnowledgeOwl.com

In this episode, I’m talking with Kenzie Woodbridge, a documentarian and self-taught accessibility advocate. We talk about how feeling “not expert enough” is no reason to skip content accessibility, four ways you can make your content more accessible right now, and ways you can serve as an accessibility advocate as you review content and work with contributors.—Kenzie and I discuss why content accessibility is something we all need to think about as we create content. You don’t have to be an expert to improve your content’s accessibility. We discuss four areas you can focus on right now:Use actual headings (h1, h2, etc.)Use sequential and hierarchical headings (for example, don’t skip straight from h1 to h3)Use link text that’s actually descriptive, rather than “Click here” or “See more”Add alt textWe also discuss some dos and don’ts with alt text, providing feedback to content contributors who aren’t following accessibility guidelines, tools or processes to help identify accessibility bugaboos in your content, and so much more. Check out the resource list below to sponge a ton of useful resources from Kenzie, too.About Kenzie WoodbridgeKenzie works at the British Columbia Institute of Technology (BCIT) in British Columbia, Canada, as a Tech Writer, Trainer, and Knowledge Strategist, and is currently a co-chair of BCIT's Accessibility Committee. They have spoken about documentation and other topics at multiple technical conferences, including Write the Docs (their favourite). Kenzie is also a parent, a tuba player, chronically ill, a crafting dilettante, a gamer, and all around nerd who wrote their Master's thesis about prosocial community in multiplayer Minecraft.Kenzie is awesome and you totally want to have them as your friend (offer of friendship void where local laws do not permit, not guaranteed in all circumstances, skill-testing questions required).Resources discussed in this episode:Screen Reader Demo - The video Kenzie mentioned by Marc Sutton at U of CDigital Accessibility Toolkit from the Government of CanadaWhat is Accessibility? (MDN docs)Digital Collegium (formerly HighEdWeb) Accessibility Summit 2025Sa11y & Editoria11y: Straightforward content accessibility at scale - The conference talk Kenzie mentioned comparing two tools for promoting and checking accessibility within content management systems:Sa11y Accessibility Quality Assurance Assistant - One of the two tools discussed in the talk, available for Joomla, WordPress, or as a bookmarklet in your browserEditoria11y Accessibility Checker - The second tool, available for Drupal, WordPress, and SquarespaceWAVE Web Accessibility Evaluation Tools - The WAVE browser extension is Kenzie’s go-to tool for a first pass on accessibility questions. It gives a lot of complex info, which can be overwhelming, but a) if you're seeing a lot of actual errors and contrast errors, you don't have to understand all of those errors to know that there's likely a problem, and knowing there's a problem is the first step 😉, and b) the "Structure" tool quickly shows you a list of the headings on the page and makes it easy to spot skipped levels, etc.Pericles screen reader - Not as fully featured as JAWS or NVDA, but useful for quick checks in your browser (Chrome, Edge, Firefox)NVDA screen reader - Downloadable for free, because accessibility really means something to them, but if you're able to donate, please doJAWS screen readerBCIT's Knowledge Base - About Web Content Accessibility—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInJoin the discussion by replying on Bluesky Contact Kate Mueller: LinkedInknowledgewithsass.comContact Kenzie Woodbridge: WebsiteLinkedinContact KnowledgeOwl:KnowledgeOwl.com

In this solo episode, Kate shares an update on working with content types, muses about the idea of a Documentation Hierarchy of Needs, and reflects more on Janine Chan’s interview (S3:E4) and how we talk to ourselves about being tech writers.—I may have overcommitted myself in Episode 3. I have been incorporating content type work into my massive content audit, but after working on four of the nineteen Features subcategories, I realized it was taking too much time and I had to refocus on my main task of updating content to match our UI and navigation releases. However, I like the information architecture decisions this has helped me make and the clarity it’s bringing to the docs themselves and how I organize them, so it’s a project I intend to continue.Making these kinds of priority decisions is something we all have to tackle all the time. But the content type work got me thinking: I’ve used an intuitive content type sense for a long time. I suspect I’m also using an intuitive decision-making framework for prioritizing my docs work. What would an explicit framework for that look like? In talking this over with a colleague, I realized I wanted a Documentation Hierarchy of Needs. I discovered that MongoDB created exactly this for their documentation overhaul once upon a time and wrote this blog post about it. I briefly run through their Hierarchy of Needs and how my decision to temporarily deprioritize content types might fit within it.I also reflect more on Janine Chan’s episode (S3:E4) and her point about reframing the way we talk to ourselves from “I’m not technical enough” to “I don’t know how to do this… yet.” And I share my own suggestion for handling that narrative problem.Resources discussed in this episode:KnowledgeOwl Support KB, Features categoryMongoDB blog post: Applying Maslow’s Hierarchy of Needs to DocumentationTNBTW Episode 3 and Episode 4—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInJoin the discussion by replying on Bluesky Contact Kate Mueller: LinkedInknowledgewithsass.comContact KnowledgeOwl:KnowledgeOwl.com

In this episode, I’m talking with Janine Chan, a technical writer and Write the Docs community moderator. We talk about how feeling “not technical enough” is as much about attitude and approach as it is about knowledge and ways you can bridge the gap to a more technical future.Janine and I discuss the fact that there’s no defined/established set of skills or training to become a technical writer. This lovely flexibility can also lead to a lot of imposter syndrome or feeling like you’re “not technical enough.” But through continuous lifelong learning, changing your attitude or the story you tell yourself, asking for help, and letting go of perfectionism, you can transition to a more empowered, technical version of yourself.Along the way we discuss the wonders of indoor plumbing, the fact that growing up to a be a tech writer isn’t typically on kids’ radar, our tendency to get curious when we’re frustrated about something, the importance of trying to answer a question before you seek help, how to be generous in requesting help, how generally awesome and generous with knowledge people are, how the experience of knowing little makes us more empathetic writers, and so so much more.About Janine ChanJanine is a technical writer based in Calgary, Canada. When she's not writing software documentation or shoehorning sociolinguistics into conversations, she's usually either outside, or hunkered down trying to make room in her lap for both a knitting project and her cat. (She recognizes that "not-boring" is a relative term.) You can find her on LinkedIn and the Write the Docs Slack, where her inboxes are always open for more tech writing chats! She promises she won't write in third person like she is now.Resources discussed in this episode:Write the Docs—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInContact Kate Mueller: LinkedInknowledgewithsass.comContact Janine:LinkedInContact KnowledgeOwl:KnowledgeOwl.comJoin the discussion by replying on Bluesky

My current in-flight projects include updating nearly all of our documentation to reflect major changes to our user interface, which includes changes to screenshots, navigation options, and section/subsection labels. I’m also working on my long slog to convert all our screenshots from .png to .webp format. As I make all of those updates, I’m bringing our content into line with our current style guide (the first time I’ve used an explicit style guide in the KnowledgeOwl Support Knowledge Base).I recently finished teaching my first Knowledge Management Master Class with KnowledgeOwl. This was mostly a success, though it was a sharp learning curve for me and I’m already full of ideas on what to do differently next time. It also humbled me since it made me view my own docs through the lens of all the best practices I was suggesting people employ–and realizing how often my docs fell short.For me, the most fascinating takeaway was really digging into the concept of concept types or information typing. I’ve never done this as an explicit, intentional exercise. After researching various approaches, I’m sold on the underlying concept. My plan is to create some templates for each major content type, using The Good Docs Project’s templates as a starting point). I’m then going to use those templates as I update content in our Features category to test and refine the templates before gradually applying them to the entire knowledge base. I’ll be using tags to track my progress and identify the content type for each page, too. In Episode 5, I’ll report back on how I’m doing in my endeavors!Resources discussed in this episode:KnowledgeOwl Support KBDiátaxis content types for software documentationDave Gash’s A Painless Introduction to Information Typing, which is a pretty solid introduction to Information Typing as it’s used in DITA and other frameworksThe Good Docs ProjectWisdom Wednesday on Use tags + Manage filters for fast docs updates/audits: Kate’s quick walkthrough on how she uses tags and Manage filters in KnowledgeOwl for content audits and updates—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInContact Kate Mueller: LinkedInknowledgewithsass.comContact KnowledgeOwl:KnowledgeOwl.com

In this episode, I’m talking with Lorna Mitchell, a technology leader, published author, tech blogger, and developer experience expert who is passionate about APIs and developer tools. We talk about why developers writing docs is good for both your devs and your docs, the best ways to build successful collaboration with developers, and more!Lorna and I discuss her background as a developer who started doing documentation for her own resources and gradually moved into developer relations, developer advocacy, and developer experience. We chat about the wide range of writing she’s tackled–including books, readmes, and her blog–and why developers need to write to improve their skills.We also discuss strategies tech writers can use to facilitate good collaboration with developers, including treating their role more as editors rather than writers; having a clearly-defined process with discrete, well-scoped requests for contributions; creating content type templates to streamline contributions; and having a second, shorter style guide for developers.About Lorna Mitchell:Lorna is based in Yorkshire, UK; she is a technology leader and developer experience expert who is passionate about APIs and developer tools. She is also a published author and regular blogger, sharing her insights on a variety of tech-related topics. Lorna serves on the OpenUK board, is on the Technical Steering Committee for OpenAPI specification, and maintains open source projects.Resources discussed in this episode:Lorna’s developer style guideDiátaxis for content typesWrite the Docs’ Docs as Code resourcesTanya Reilly’s Being Glue—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:tnbtw@knowledgeowl.comBlueskyLinkedInContact Kate Mueller: knowledgewithsass.comLinkedInContact Lorna Mitchell: Lorna's websiteLinkedinContact KnowledgeOwl:KnowledgeOwl.com

Meet our new host Kate Mueller and get the inside scoop on how The Not-Boring Tech Writer (TNBTW) will work moving forward.Kate Mueller is the Documentation Goddess of KnowledgeOwl, a seasoned technical writer and owner of knowledgewithsass, a knowledge management coaching service. She’s written and maintained documentation for companies in broadcasting, financial services, IT, and software for 15+ years. She’ll be hosting TNBTW moving forward.In this episode, Kate discusses her vision for TNBTW: a podcast dedicated to everyone who is writing technical documentation, including those who may not feel comfortable calling themselves tech writers. Whether you create product documentation, support documentation, READMEs, or any other technical content—and whether you deal with imposter syndrome, lack formal training, or find yourself somewhere in the gray area between technical communications and general writing—the TNBTW reboot might be your new favorite podcast. Kate talks about her own imposter syndrome using the tech writer label and recounts her tech writer villain origin story.We plan to release two episodes per month: one episode will maintain the traditional TNBTW format of interviewing a guest and focusing on useful skills or tools that can help you improve your tech writing skills; the other episode will be a behind-the-scenes look into what Kate’s working on, struggling with, or thinking about in her daily tech writing life.—Contact The Not-Boring Tech Writer team:We love hearing your ideas for episode topics, guests, or general feedback:Email: tnbtw@knowledgeowl.comBlueskyLinkedInContact Kate Mueller: LinkedInknowledgewithsass.comContact KnowledgeOwl:KnowledgeOwl.comLinkedIn

In this episode I’m talking to Swapnil Ogale, a Technical Writer Advocate for Redocly based in Melbourne, Australia, who is also a Community and Conference Manager for Write the Docs. He gives us the inside scoop on arranging Write the Docs events conferences both in-person and online, and talks to us about the importance of advocacy for technical writers.The Not-Boring Tech Writer - feedback surveyTwitter - Swapnil OgaleLinkedIn - Swapnil OgaleWrite the Docs