The Not-Boring Tech Writer

In this episode, I talk with Kelton Noyes, a senior technical communicator who started his career in tech support and gradually built his way into documentation. We discuss how to choose documentation tools, practical strategies for making the business case for investing in documentation, and how Kelton successfully advocated for technical writing as a valuable full-time discipline within his organization.Kelton and I discuss his journey from tech support to technical writing, which began with his frustration at answering the same questions repeatedly. He started creating documentation between support calls to fill gaps he noticed, sharing these resources with coworkers who found them valuable. His managers appreciated the work, but nobody initially recognized documentation as a full-time role. We explore how he eventually made the transition by demonstrating concrete value through metrics like reduced support volume and faster training ramp-up times and shifting the conversation from advocating for the importance of documentation to advocating for himself as the person to do that documentation.We dive deep into Kelton's approach to choosing documentation tools, including how to develop a hierarchy of needs based on customer feedback, organizational requirements, and author workflow. He shares the importance of taking advantage of demos and free trials to explore features hands-on, explaining how requirements often evolve during this exploration process as you discover capabilities you didn't know you needed.We also explore red flags that indicate it's time to reevaluate your tooling, the challenge of finding tools that serve multiple departments, and how to navigate the collaborative aspects of getting organizational buy-in for documentation initiatives.About Kelton Noyes:Kelton Noyes is an English major with a love of technology who spent years trying to find a way to blend the two. He started his career working technical support jobs across a variety of industries, including web hosting, security, data storage, solar, and shipping. Everywhere he went, he found a lack of documentation. Between support calls, he started creating documentation to fill those gaps. He documented workflows and processes that impacted his job and shared them with coworkers, who widely used and appreciated the resources. His managers and coworkers loved the work he was doing, but nobody at the time saw documentation as a full-time role.Fast forward several years to a job interview where the hiring manager recognized the company's need for documentation and loved Kelton's background doing exactly that. Kelton started in tech support to learn the product and began building documentation in his second week. Six years and two promotions later, he's never been happier professionally than he is building documentation full time.When he's not documenting, Kelton enjoys cooking, board games, reading, debating, general handy work, gardening, and playing music.In this episode:[00:01:20]: Kelton's origin story: From English degree to tech support to technical writing[00:02:46]: Current role as senior technical communicator in fintech[00:05:04]: Why "technical communicator" instead of "technical writer"[00:07:28]: Identifying documentation needs from support patterns and customer feedback[00:10:34]: Developing a hierarchy of needs for tool features[00:14:13]: Considering author workflow and collaboration in tool selection[00:19:28]: Using interactive glossary features to reduce support time[00:26:39]: Demonstrating documentation value with metrics[00:30:11]: Finding tools that serve multiple departments without overpromising[00:35:51]: The importance of demos and free trials in tool evaluation[00:41:49]: Making the case for transitioning from support to full-time writer[00:43:33]: Using documentation to reduce training time from three weeks to two weeks[00:54:11]: Building a culture where documentation is valued[01:05:42]: Evolving tooling and documentation standards company-wide[01:09:03]: Red flags that indicate it's time to reevaluate tooling[01:12:17]: Resource recommendation: Sapling's passive voice tools[01:14:32]: Advice: Learn to advocate for yourself and your ideasResources discussed in this episode:Sapling Passive Voice CheckerSapling Passive to Active Sentence RewriterJoin 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.comLinkedInBlueskyGuest suggestions formContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact Kelton Noyes:LinkedInContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, I share my latest content updates progress (spoiler: I finished my project! 🎉). I also share the new daily check-in Google Form I’m trying, inspired by Kate Pond’s interview (S3:E24), as well as some general thoughts on the power of self-documentation and a call for more intermittent or unofficial tech writing guests.I finally finished my project to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes we rolled out in December 2024! 🎉 I updated and archived a ton of articles, completed a tags audit, overhauled our internal guidance on using tags, and submitted a pull request to the Microsoft Entra docs to update their KnowledgeOwl SSO docs. Along the way, I had to trim my scope and toss a lot of additional ideas or changes into a separate backlog list. Now that I’ve completed the project, I’m hoping to work through that separate backlog list as time permits.I used Kate Pond’s blog post about her daily check-ins as a strawman to create my own daily check-in Google Form for my work and I share the questions I’m using. I’ll report back on my usage of it in my next solo episode.I also share a previously unreleased clip from Kate Pond’s interview in which I describe a form of self-documentation I’ve used in my personal life to manage a chronic illness, many of the benefits to using self-documentation in this way, and some tips for trying it out yourself. I reflect on Kate Pond’s career journey and share what I see as some of the key steps in that journey that others might be able to replicate.I close the episode by noting that I’m really trying to include more unofficial or intermittent tech writers like Kate Pond, so if you or someone you know has written documentation without calling yourself a tech writer, please come on the show! Feel free to use our guest suggestions form.In this episode:[00:00:00]: Project completion and reflection[00:03:35]: Crafting my new daily check-in[00:11:23]: My Long Covid self-documentation journey[00:15:43]: Benefits of self-documentation[00:20:44]: Strategies for career transitions[00:23:42]: Welcoming more intermittent tech writersResources discussed in this episode:KnowledgeOwl Support Knowledge BaseGoogle Forms for Self-EvaluationS3:E24: Self-documentation for career growth with Kate PondJoin 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.comLinkedInBlueskyGuest suggestions formContact Kate Mueller:knowledgewithsass.comLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this episode, I share clips from my conversations with Liz Argall, Dennis Dawson, Sarah Walker, Ryan Macklin, Nick Graziade, Janine Chan, and Kate Pond. The clips include outtakes, sound check moments, and segments we cut for time from our 2025 interviews.This episode is different from our usual format. Instead of a single guest interview, I'm sharing clips that we cut from this year's episodes or captured during our pre-recording sound checks. Most of these clips didn't make it into the final episodes due to time constraints, but they contain insights and moments I didn't want to lose entirely. The clips range from lighthearted sound check banter to substantive discussions that didn't fit the final edit.Sarah Walker and I dig deeper into the concept of "beginner's mind" and how returning to documentation you haven't touched in a while can be both humbling and instructive. Ryan Macklin extends empathy advocacy to include ourselves and reminds us that understanding where frustrated customers are coming from doesn't mean we have to accept abusive behavior. Nick Graziade and I explore the limitations of hierarchy as the sole approach to information architecture and why metadata-driven organization can sometimes serve users better than deep folder structures. And Kate Pond and I briefly discuss weekly check-ins and the idea of gamifying daily reflection. There are also some fun moments from sound checks with Liz Argall and Dennis Dawson, plus a clip from Janine Chan's episode that I couldn't resist revisiting.Consider this a peek behind the curtain at how the podcast comes together as well as a thank you to all of our 2025 guests for being so generous with their time and insights!Join the discussion by replying on Bluesky In this episode:[00:00:04]: Kate Mueller’s intro[00:05:04]: Liz Argall[00:07:05]: Dennis Dawson[00:09:46]: Sarah Walker[00:18:11]: Ryan Macklin[00:21:17]: Nick Graziade[00:30:24]: Janine Chan[00:31:44]: Kate Pond[00:33:50]: Kate Mueller’s outroOriginal Season 3 episodes featuring these guests:Episode 4: Bridging the gap from "not technical enough" to "technical" with Janine ChanEpisode 12: Documentation as a creative endeavor with Nick GraziadeEpisode 13: Connecting permaculture and documentation with Liz ArgallEpisode 16: Empathy advocacy: Designing docs for all emotional states with Ryan MacklinEpisode 18: Yoga wisdom for technical writers with Sarah WalkerEpisode 22: Humor and visuals in technical writing with Dennis DawsonEpisode 24: Self-documentation for career growth with Kate PondGuest bios: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!Dennis Dawson:Like many baby-boomers, Dennis still hasn't decided what he wants to be when he grows up. He's a technical writer with 40 years' experience in technical communications providing documentation, training, and user support; a sketchnotes artist for Write the Docs; a 3-time Distinguished Toastmaster and Past District 57 Governor who's won District Champion titles in Humorous, Tall Tales, and Evaluation contests; a volunteer Santa Claus at San Jose Christmas in the Park; and a volunteer drawing teacher at local elementary schools.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.Ryan Macklin

In this solo episode, I share my latest content update progress. I also reflect on all of 2025 hosting this podcast, offering lessons learned about tech writing and myself alongside gratitude to this year’s awesome guests and listeners like you.—I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes we rolled out in December 2024. I’ve finished my official punchdown list and am working through some spot checks and searches to verify I didn’t overlook anything in that list.This episode is my final solo episode of 2025, so it felt appropriate to reflect a bit on how this year has gone. I share seven lessons about tech writers and tech writing I’ve distilled from the year:Tech writers are really really really not-boring humans.We like to learn stuff and we’re more or less always learning.We’re always adapting.We know a lot of random stuff and it’s not always limited to technical domains.We’re generous with our knowledge.Very few of us came into this profession in a linear or “traditional” way.Care and empathy underlie a lot of what we do.I also share some lessons I learned about myself and offer a ton of gratitude, most especially to the awesome roster of amazing, talented people who graced me with interviews this year, and also to all the folks behind the scenes who make this possible. We are, slowly but surely, building a solid not-boring community, and I look forward to another year of doing the same!Resources discussed in this episode:KnowledgeOwl Support Knowledge BaseS3:E23: Kate sounds off on small things and repairsJoin 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 Kate Pond, a software engineer and former park ranger who turned self-documentation into a career superpower. We discuss her practical system of using Google Forms to track daily work and accomplishments, how this helps with performance reviews and job interviews, and why documenting your own work is essential for professional growth.Kate Pond and I discuss her unique path from park ranger to software engineer and how documentation played a crucial role throughout her career transitions. She shares how creating personal runbooks as a college RA taught her that writing things down once saves countless hours of reinventing the wheel later. We explore how this philosophy extended into her transition to software engineering, where she documented everything she learned at technical meetups.The heart of our conversation centers on Kate's Google Forms system for self-documentation, which she created to track her daily work, accomplishments, and professional development. She explains how the system uses a mix of checkbox ratings (like "how do you feel right now?" on a 1-10 scale) and free-form text fields to capture what she worked on, who she collaborated with, what she learned, and what she's proud of. We discuss how this creates both quantitative data you can graph over time and qualitative records you can mine for performance reviews, peer feedback, and interview preparation.We also explore the broader philosophy behind self-documentation, including how it helps combat the reality that we simply can't remember everything we do, the value of having "retro docs" when taking breaks from projects, and how documentation for yourself follows the same principles as documentation for users. Near the end of our conversation, Kate shares practical advice from her career coach about doing "scary hour" sessions with a friend to tackle procrastinated tasks.About Kate Pond:Kate Pond is a Seattle-based software engineer, technical storyteller, and former park ranger. With a background in both environmental education and backend engineering, she brings a systems-thinking approach to everything from documentation to distributed systems.Through her studio, The Pond’s Edge, Kate is building climate-tech and AI-powered tools that support sustainability and reduce waste—most recently focusing on circular economy solutions rooted in local community needs.Kate is passionate about making complex ideas accessible and mentoring others to grow as thoughtful technologists. She’s spoken at GopherCon, REdeploy, and SeaGL, and actively contributes to the PNW tech and climate communities through events like CascadiaJS and PNW Climate Week.Recommendation from Kate Pond:9Zero Climate Innovation Hub is a coworking space and community designed for climate innovators—founders, engineers, scientists, creatives, and changemakers. With locations in San Francisco and Seattle, and expanding to NYC and Los Angeles, it’s a vibrant hub for events, collaboration, and climate-focused work.If you’re based in or near one of those cities and looking for a supportive, mission-driven space to work or connect, definitely check them out.✨ Referral perk: If you sign up for a membership and mention my name (“Kate Pond”) as your referrer, we both get a free month (or up to $150 off). Win-win!Learn more at 9zero.comResources discussed in this episode:Kate Pond - DEV CommunityKate Pond – MediumGoogle Forms for Self-EvaluationTalks from Write the Docs Portland 2025Join 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 Kate Pond:Website: thepondsedge.comLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, I talk about my latest content update progress. I also reflect on Dennis Dawson’s interview (S3:E22), the ways I'm already using Dennis's tips, and the power of doing small things or repairs to affect larger change.—I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes we rolled out in December 2024. My previous punchdown list of fewer than 50 articles was wrong, but I do think I’m below 100 now, after I found a chunk of content I’d completely missed.I reflect a bit on some of the detailed, specific next steps Dennis Dawson offered. Thanks to some of his points, I won’t be including a floating copy of my head in upcoming videos. I’m also starting to think of visual ways I can help give my readers a pause during conceptually-heavy content, to let them shift from focused mind to diffuse mind.I also reflect on the piece of advice that most stuck out to me from Dennis’s interview: “Get over yourself. Get over your reticence”, and a new practice I have of picking up trash along the main road near my house. Along the way, I tie in quotes from Abby Covert, Ari Weinzweig, and Harrison Gardner.So much of tech writing boils down to what we might classify as “small things” (Weinzweig) or “repairs” (Gardner). In both cases, these small actions can add up to big change and momentum over time. They’re also one of the ways we can most express care and commitment to a project. This month, I’m doubling down on these small things and repairs, and I invite you to join me in finding small ways to care for your documentation.Resources discussed in this episode:KnowledgeOwl Support Knowledge BaseAbby Covert’s How To Make Sense of Any Mess, excerpted from chapter 7: Be the filter, not the groundsAri Weinzweig’s Small Actions Matter in Much Bigger Ways Than We Might Imagine: Pint-sized ideas, the struggle of self-doubt, and learning to take action anywayHarrison Gardner:Subscribe to his newsletter on his websiteBuild Your Own: Use what you have to create what you needCommon KnowledgeJoin 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 Dennis Dawson, a technical writer with 40 years of experience who creates the sketchnotes for Write the Docs talks. We talk about how humor and visual elements can make documentation more engaging and memorable, the science behind why graphics help information stick in long-term memory, practical tools and techniques for adding visual content to your docs, and why you don't need to consider yourself an artist to create effective illustrations that enhance your documentation.Dennis and I discuss his unconventional path into technical writing, starting with an English degree and progressing through roles as an editor, typist, secretary, and eventually desktop support in the early days of personal computing. His technical writing career began at startups in the 1980s, where he combined training and documentation work. Throughout his 40-year career, Dennis has consistently advocated for using humor and visual elements in documentation.Our conversation centers on the science behind why visual content and humor make documentation more effective. Dennis shares how reading Richard Mayer's Multimedia Learning and Barbara Oakley's books on learning validated many of his instinctive approaches. We explore concepts like how visual information sticks in long-term memory more easily than text, the importance of reducing cognitive load through strategic use of graphics, and how breaking up text with visuals gives readers' brains time to process information by switching between focused and diffuse modes of thinking. Dennis also discusses when to use graphics and shares examples like using whimsical robot characters to represent different software components.We dive into the practical side of creating visual content, including Dennis's collaborative approach of sketching ideas and working with design teams to polish them into professional graphics, and tools like Gimp, Inkscape, Keynote, and Google Slides that make visual creation accessible. Dennis emphasizes that you don't need to consider yourself an artist to create effective illustrations—the key is getting over your reticence and recognizing that drawing is a skill developed through practice, not innate talent. We also discuss his approach to creating educational videos, including using Doc Detective to automate video updates when UIs change. Throughout our conversation, Dennis stresses the importance of using visual humor and plain language to help make documentation digestible and accessible.About Dennis Dawson:Like many baby-boomers, Dennis still hasn't decided what he wants to be when he grows up. He's a technical writer with 40 years' experience in technical communications providing documentation, training, and user support; a sketchnotes artist for Write the Docs; a 3-time Distinguished Toastmaster and Past District 57 Governor who's won District Champion titles in Humorous, Tall Tales, and Evaluation contests; a volunteer Santa Claus at San Jose Christmas in the Park; and a volunteer drawing teacher at local elementary schools.Resources discussed in this episode:Free tools:Doc Detective: Manny Silva’s open source tool for testing and validating documentationDoc Detective tutorials that Dennis createdAs a reminder, we also did an episode with Manny Silva on Doc Detective S3:E14GIMP: free alternative to Adobe PhotoshopInkscape: free alternative to Adobe IllustratorBooks:Multimedia Learning by Richard E. MayerLearning How to Learn by Barbara Oakley, Terrence Sejnowski, Alistair McConvilleA Mind for Numbers by Barbara OakleyUncommon Sense Teaching by Barbara Oakley, Beth Rogowsky, Terrence J. SejnowskiDennis Dawson’s sketchnotes:Write the Docs Portland, May 2025Write the Docs Atlantic, September 2024Write the Docs Portland, April 2024Write the Docs Atlantic, September 2023Write the Docs Portland 2023 talks:Lightning Talk: Dennis Dawson - Sketchnoting: Engaging both brainsCaitlin Davey - The visuals your users never saw…wait that’s most of themRyan Young - Is it (layer) cake: Thinking in content levelsJoin 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 Dennis Dawson:Email: dennis.s.dawson@gmail.comWebsite: dennissdawson.wixsite.com/mr--dawsonLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, I share an update on my content update progress. I also reflect on Fabrizio Ferri-Benedetti’s interview (S3:E20) and the ways exploring models like his Seven-Action Documentation model have helped me interrogate my own beliefs about tech writing, the benefits of self-knowledge in becoming a better writer, and the ways that maintenance docs work helps me recharge.—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, and I’m finally nearing the light at the end of the tunnel: my initial punchdown list has less than 50 articles remaining! Along the way, I’ve also had to re-update docs I already updated as we rolled out more changes to existing features–ahhh, the life of a tech writer.In his interview, Fabri mentioned that part of his motivation for creating the Seven-Action Documentation model was a frustration that people were taking frameworks like Diátaxis and just rote-applying them to their documentation. We discovered some very deep common ground: that models and frameworks are useful because they help you, as a writer, surface and interrogate the deeply-held beliefs you have about technical writing. They’re tools for exploration rather than step-by-step guides on what to do. In my case, engaging with the Seven-Action Documentation model helped me realize how strongly I felt about appraisal and troubleshooting as user needs. While I’m not necessarily crafting new content templates to handle this, my site structure has naturally incorporated them, and I’m now exploring the idea of review checklists or user journeys that might help me assure that I’m handling all the user needs in some way.I’ve also been sick with Covid, which slowed down my velocity for more strategic, creative work and prompted me to return to a lot of maintenance work. Fabri mentioned that maintenance work helps him recharge, and I found the same thing. I often call maintenance work “productive procrastination”, since it’s not usually the single most important thing, but it is something I can do when my energy or focus are low so that I’m still improving my docs every day. Consider this your invitation to spend the next month paying attention to which writing tasks fill or drain your cup, what kinds of energy those tasks demand, and how you can better manage that moving forward.Resources discussed in this episode:KnowledgeOwl Support Knowledge BaseJoin 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 Fabrizio Ferri-Benedetti about moving beyond strictly following documentation frameworks to embrace strategic thinking, his Seven-Action Documentation model that prioritizes user needs over content types, and how technical writers can grow and adapt in the AI era while positioning themselves as essential strategic partners.Fabri and I discuss his background as a cognitive psychology student who transitioned into technical writing through his love of computers and writing. He shares his journey from academia to becoming an editor at Softonic, and eventually to his current role as a principal technical writer at Elastic working on OpenTelemetry documentation. We explore his concept of technical writers as shapeshifters who adapt to different roles and contexts.The conversation centers around Fabri's Seven-Action Documentation model, which he developed as a more descriptive and user-focused alternative to prescriptive documentation frameworks. Unlike content-type-focused approaches, his model identifies seven key user actions that address real user needs that are often overlooked by traditional frameworks. We discuss how this model encourages writers to think strategically about user needs rather than simply following rigid content templates, and why starting with user needs rather than content types leads to more effective documentation.We also explore professional growth for technical writers, particularly in the AI era. Fabri emphasizes the importance of meaningful skill growth, advocating for work that demonstrates strategic thinking rather than just high-volume output. He shares his philosophy of embracing AI as a tool while maintaining critical evaluation of its limitations, arguing that technical writers must understand emerging technologies to maintain credibility and influence in organizational decisions about documentation and AI implementation.About Fabrizio Ferri-Benedetti:Fabrizio Ferri-Benedetti is a technical writer and documentation engineer with over 15 years of experience. Through his blog Passo.uno, he shares insights on documentation strategy, API design, and the evolving role of writers in the tech industry. When not championing better documentation practices or contributing to open source projects like OpenTelemetry, he explores ways to make technology more accessible.Resources discussed in this episode:passo.unoThe Seven-Action Documentation modelHow to grow as a technical writerBeyond Content Types: A Human-first Model for Technical DocumentationThe Diátaxis frameworkThe Write the Docs SlackThe Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing InformationJoin 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 Fabrizio Ferri-Benedetti:passo.unoLinkedInBlueskyContact KnowledgeOwl:knowledgeowl.comLinkedIn

In this solo episode, I share an update on my content update progress. I also reflect 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, I share an update on my content update progress. I also reflect 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, I share an update on my content update progress. I also reflect 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, I share an update on my content update progress. I also reflect 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, I share an update on my content update progress. I also reflect 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