The Not-Boring Tech Writer

Kate Mueller
  • 5.0 (1)
  • CAREERS
  • MONTHLY

Some people hear the phrase "technical writing" and think it must be boring. We're here to show the full complexity and awesomeness of being a tech writer. This podcast is for anyone who writes technical documentation of any kind, 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—there's a place for you here. Each month, we publish two episodes: an interview with an amazing guest focusing on useful skills or tools that can help you improve your tech writing skills, and a behind-the-scenes solo episode with host Kate Mueller about what she’s working on, struggling with, or thinking about in her daily tech writing life. The Not-Boring Tech Writer is generously sponsored by KnowledgeOwl, knowledge base software built for people who care, by people who care.

  1. 1 DAY AGO

    Building a home for documentarians with Eric Holscher

    In this episode, I talk with Eric Holscher, co-founder of Read the Docs and Write the Docs, about building and sustaining a community for people who care about documentation. We discuss the origin story of Write the Docs, how the conference and community have evolved over 13 years, the value of Lightning Talks and Unconference sessions for fostering organic connection, how AI is reshaping the role of technical writers and developers, and why supporting the institutions you care about matters now more than ever. — Eric and I discuss his path into caring about documentation, which started as a computer science student reading the Django documentation on a family vacation and discovering how well-written docs could transform his understanding. This experience, combined with his deep roots in the Python and Django open source communities, eventually led him to co-found Read the Docs in 2010 and Write the Docs in 2013. We talk about how Write the Docs was originally conceived as a conference for Read the Docs users but quickly took on a life of its own and eventually became a global community for anyone who cares about documentation. We also discuss the origin of the term "documentarian" as an identity for people who are passionate about docs regardless of their job title, and the value that comes from having a single word to describe that identity. We explore the conference elements that make Write the Docs feel different from other events, including Lightning Talks as an on-ramp for first-time speakers, Unconference sessions that let attendees organize discussions around what they're excited about, and Writing Day as a hands-on collaborative experience. I share how Writing Day is evolving this year to include skill-based tracks like Git workshops and resume/portfolio reviews to address the community's changing needs. We also discuss how the community's makeup has shifted over the years from a more developer-heavy audience to one that's primarily tech writers, and the intentional work that goes into keeping the conference broadly welcoming. We dig into Eric's values-driven approach to conference organizing, including keeping sponsors off the main stage, avoiding tool-specific talks that can feel like sales pitches, and defaulting to openness with resources like talk recordings and the Write the Docs topic index. We also touch on AI's impact on the tech writing profession, where Eric offers an optimistic perspective: because writing quality is harder to objectively test than code, the depth of understanding and explainability that writers bring may become even more valuable. The episode wraps up with a discussion of supporting the institutions you care about and the challenges of building sustainable community organizations. About Eric Holscher: Eric Holscher is the co-founder of Read the Docs, Write the Docs, and EthicalAds. While studying computer science at the University of Mary Washington, Eric's passion for documentation was sparked by reading the Django documentation on a family vacation and discovering how transformative well-written docs could be. He co-founded Read the Docs in 2010 as an open source documentation hosting platform, which has grown into his full-time work for over a decade. In 2013, he co-founded Write the Docs, which began as a conference for Read the Docs users but quickly evolved into a global community for anyone who cares about documentation, with conferences on multiple continents, a thriving Slack community, and local meetups worldwide. He also co-founded EthicalAds, a privacy-focused ad network, and helped start PyCascades, a Pacific Northwest Python conference. Eric lives in Bend, Oregon, and spends as much time as possible exploring the outdoors on foot or by bike. If you run into him at an event, remember the Pac-Man Rule: always leave room for someone else to join the circle. In this episode: [00:01:20]: Eric's origin story: discovering the power of documentation through Django docs on a family vacation[00:04:11]: Read the Docs, Write the Docs, and the confusing naming story[00:05:26]: The Write the Docs elevator pitch: a community for anyone who cares about documentation[00:09:20]: The origin and meaning of "documentarian" as a professional identity[00:12:09]: How Write the Docs got started in 2013[00:15:02]: The power of community in professional life and finding your people[00:20:49]: Conference structures that foster connection: Lightning Talks, Unconference sessions, and Writing Day[00:24:29]: Lightning Talks as a gateway to public speaking[00:29:03]: How the conference and community have evolved since 2013[00:33:14]: Navigating AI and the future of technical writing[00:34:36]: Why writers may be less at risk from AI than developers[00:38:48]: Writing Day's evolution: adding skill-based tracks like Git workshops and resume reviews[00:44:22]: Sponsor relationships and creating value without being extractive[00:47:41]: Lessons learned from building a values-driven community[00:52:27]: Finding product-market fit and letting the community shape itself[00:55:23]: Eric's advice: you need the cloudy days to appreciate the sunny ones[00:58:12]: Resource recommendation: the Write the Docs topic index[01:01:11]: Supporting the institutions you want to see exist Resources discussed in this episode: Write the Docs topic indexWrite the Docs SlackWrite the Docs Portland 2026Write the Docs Berlin 2026Definition of "documentarian" from Write the DocsThe Pac-Man Rule at Conferences by Eric HolscherRead the DocsPyCascadesPyCon USDjangoCon USRelated TNBTW episodes:S1:E5: Getting involved in a community with Eric HolscherS3:E14: Docs as Tests: Keeping documentation resilient to product changes with Manny SilvaKate Mueller's Write the Docs Portland 2022 talk: Beating the Virginia Blues: Thru-hiking strategies for your next big project 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.comLinkedInBluesky

    1hr 8min

  2. 2 APR

    Kate sounds off on lovable docs

    In this solo episode, I share my latest content updates progress and reflect on my takeaways from Jacob Moses’ interview (S3:E32). I also share some thoughts on applying concepts about lovable neighborhoods to documentation. — I updated the KnowledgeOwl Support Knowledge Base (Support KB) to create all the documentation for our new Owl Analytics Export API, including API endpoint documentation and a public Postman collection of the endpoint. I also wrote a release note and documentation for several new import tools, including HubSpot and a generic CSV importer. My change management toolkit is more or less ready for release, which will happen in two phases: a larger toolkit released for KnowledgeOwl customers only, and a more streamlined version released to the general public. I’ll share more once that streamlined version is available so you can check it out if you’d like! I reflect on my interview with Jacob Moses, especially all the skills he took from his tech writing career and used in his real estate development work at Care Block. I share five ideas that came up in our discussion around neighborhoods and community development that are equally applicable to documentation: You don’t necessarily have to plow a lot of resources into big changes to have a big impact on your reader experience.Have conversations–or at least, bear witness to conversations–where your readers are most comfortable having those conversations.Don’t just copy and paste best practices or templates from other places; use them as starting points and iterate as you go.Incorporate documentation into your customer and employee onboarding.Support readers who have differing levels of engagement styles. I also dig a lot deeper into the idea of lovable neighbors and lovable documentation, sharing some insights from Henrik Kniberg’s blog post on earliest testable/usable/lovable products and trying to apply those principles to documentation. I argue that documentation can be one of the most lovable parts of your product or company, and that if we recognize that premise, we should identify ways that readers will feel loved by our documentation to focus our efforts on. I tie this to Kelton Noyes’ changes to new employee orientation and ramp-up time shared in S3:E28, where he reduced onboarding and ramp-up from three weeks of training plus a three month ramp-up period down to two weeks total. I also argue that the idea of reciprocity can help guide us toward more lovable docs, quoting Jacob: “If you build a lovable place, it will be loved in return by whomever you’re leasing the home to.” Our readers won’t love our docs unless we do, so we should focus on building documentation we know our readers need and doing it in a way that is thorough and lovely. I close by reflecting on the idea of if my documentation is a neighborhood, what kind of neighborhood would it be and how does that change what I prioritize? In this episode: [00:01:03]: Progress updates[00:03:47]: Reflections on how Jacob Moses has transferred his tech writing skills to real estate development[00:08:22]: Five principles of building good neighborhoods that apply to building good documentation[00:16:09]: Reflections on the idea of lovability Resources discussed in this episode: KnowledgeOwl Owl Analytics Export API documentationKnowledgeOwl import documentationFrom tech writing to building lovable neighborhoods with Jacob Moses (S3:E32)Skill #3: Creating Just-in-Time Documentation (S1:E3)Advocating for docs and choosing tools with Kelton Noyes (S3:E28)Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable by Henrik KnibergDiátaxisThe Seven-Action Documentation Model by Fabrizio Ferri-Benedetti 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    32 min

  3. 19 MAR

    From tech writing to building lovable neighborhoods with Jacob Moses

    In this episode, I talk with Jacob Moses, the founder and original host of The Not-Boring Tech Writer podcast, about how the skills and values he developed as a tech writer have shaped his journey into community development and real estate. We discuss his concept of building "lovable places," how user-centered thinking and empathy translate from documentation to neighborhood development, the power of tight feedback loops and self-service documentation for tenants and clients, and how the Write the Docs Pac-Man rule has changed his life and his work. — Jacob and I discuss his path from studying technical communication at the University of North Texas to founding The Not-Boring Tech Writer podcast in 2016 to his current work as owner of Care Block Development, a real estate development company specializing in historic rehabs in Denton, Texas. Throughout his career transitions, Jacob has carried core tech writing values with him, including user empathy, iterative improvement, and the importance of tight feedback loops. We explore how Care Block's mission of building "lovable places" connects to ideas about product lovability in the software world and why solvency matters for any organization that wants to do good work for the people it serves. We dig into the ways Jacob applies tech writing skills and principles in his real estate and community development work. He walks us through examples like creating onboarding documentation for new tenants with laminated cards and QR codes, offering multiple communication paths for work orders to accommodate different engagement preferences, and providing self-help guides for emergency situations. On the general contracting side, he shares how he uses project management software to give clients real-time transparency into the estimating process, a move that was counterintuitive to others in his industry but aligned with his commitment to centering humans in every interaction. We also discuss the Strong Towns approach to public investment, which centers on humbly observing where people struggle, doing the next small thing to address that struggle, and repeating. Jacob connects this to tech writing's iterative, user-centered mindset and to Elinor Ostrom's concept of "cheap talk," which emphasizes meeting people where they are and letting them communicate in ways that feel comfortable. We touch on AI's role in documentation and the irreplaceable value of human empathy, and Jacob shares the piece of advice that has most impacted his life and work: the Write the Docs Pac-Man rule of always leaving room for another person to join the circle. About Jacob Moses: Jacob Moses is the founder and original host of The Not-Boring Tech Writer podcast, which he launched in 2016 to celebrate tech writers and push back against the stereotype that technical writing is boring. He studied technical communication at the University of North Texas, and his first gig out of college was as a tech writer at Rainmaker Digital (formerly Copyblogger Media). Since then, he's carried the skills and values he cultivated as a tech writer into community development and real estate. Today, Jacob is owner of Care Block Development, a real estate development company that acquires, rehabs, and manages historic buildings in Denton, Texas. Pairing historic preservation with thoughtful improvements, Care Block honors the culture of the neighborhoods in which it works to create lovable places for the people it serves. He's also the owner of Sardinha, a premium tinned seafood pop-up pushing premium tins in Denton. If you need a tinfish plug in Denton, Jacob is your guy. In this episode: [00:01:00]: Jacob's origin story: a chance meeting at a coffee shop that led to tech writing[00:08:06]: From Blue Bag Market to affordable housing to Care Block Development[00:10:11]: Care Block's mission: building lovable places through historic rehabs[00:13:51]: Lovability as a concept for software, documentation, and community[00:24:51]: Tenant onboarding documentation: laminated cards, QR codes, and multiple communication paths[00:27:59]: Self-service documentation and accommodating different engagement preferences[00:31:33]: Using project management software for transparency in the general contracting process[00:37:15]: Tech writing skills that translate beyond documentation[00:40:13]: The Strong Towns approach: observe, do the next small thing, repeat[00:41:20]: Elinor Ostrom's "cheap talk" and meeting people where they are[00:45:38]: Humility, listening, and centering the end user as the expert[00:51:02]: AI, empathy, and what makes good documentation good[00:54:19]: Resource recommendations: Bird by Bird, Death and Life of Great American Cities, and more[00:59:46]: Best advice: the Write the Docs Pac-Man rule Resources discussed in this episode: The Pac-Man Rule at conferences by Eric HolscherStrong TownsBooks:Governing the Commons by Elinor OstromBird by Bird by Anne LamottJoe Jones by Anne LamottThe Death and Life of Great American Cities by Jane JacobsDying and Living in the Neighborhood by Prabhjot SinghThe Mayor of Castro Street by Randy ShiltsThe Book of Hope by Jane Goodall and Douglas AbramsWe Learn Nothing by Tim KreiderJoanne Rohde's "On knowing when to get in, and to get out" (New York Times)Related TNBTW episodes:S1:E1: Applying empathy to your audience analysis with Dr. Chris LamS1:E3: Creating just-in-time documentation with Bri HillmerS1:E5: Getting involved in a community with Eric HolscherS1:E8 and S1...

    1hr 7min

  4. 5 MAR

    Kate sounds off on docs symbiosis

    In this solo episode, I share my latest content updates progress and reflect on my takeaways from Bill Holland’s interview (S3:E30). I also share my attempts to reframe the idea of strategic documentation projects and maintenance as competing for time to the idea of them being in a deeply symbiotic relationship. — I’ve been quietly adding documentation to our Support Knowledge Base for recent releases and to fix some display issues in our API endpoint documentation. I’m also achingly close to finishing the knowledge base change management toolkit I’ve been working on. I reflect on my interview with Bill Holland and how many of the tips he gives for tech writers to communicate with designers are the kinds of work we do all the time. First, provide a brief that explains things in detail, especially any special terminology or acronyms. Define what you want to get out of the project, what its intent is, and what the most important thing you want to communicate is. Assume that the designer knows nothing about the project or industry. Second, share moodboards, graphic samples, or video playlists that have an aesthetic you like so a designer can get a feel for the style you’re after. Third, provide solid, detailed feedback on designs or roughs, tying the criticism back to your style samples or your brief. Tech writers and designers have a lot in common: we all need to educate our clients about how the process works, guide them to what they need, potentially justify the cost of our services and our expertise, and handle the opportunities and disruption that AI is throwing into our respective fields. I’m trying to find new ways to manage the tension between spending time on routine documentation maintenance and tackling large strategic projects. We tend to talk about this tension as a form of competition, that the tasks compete for our time. Instead, I’m applying a narrative reframing I borrowed from Suzanne Simard’s book Finding the Mother Tree, and recognizing that there’s a symbiotic relationship between the two. One can’t exist without the other, and they each help the other. I hope that reframing might be useful for you. In this episode: [00:01:28]: Updates on my change management toolkit[00:04:23]: Reflecting on Bill Holland’s advice for working with designers[00:06:42]: Exploring the similarities between tech writers and designers[00:10:38]: Changing the narrative on “competing” docs priorities to symbiotic docs priorities Resources discussed in this episode: Finding the Mother Tree: Discovering the Wisdom of the Forest by Suzanne SimardKate sounds off on beliefs and maintenance work (S3:E21)Kate sounds off on small things and repairs (S3:E23)KnowledgeOwl API endpoint reference documentation 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    25 min

  5. 19 FEB

    Collaborating with designers and animators with Bill Holland

    In this episode, I talk with Bill Holland, a motion graphics designer and video producer, about how tech writers can effectively collaborate with visual creators. We discuss what to include in a creative brief, how to give constructive feedback to designers, setting realistic expectations for animation types and budgets, and how AI is changing but not replacing visual creative work. — Bill and I discuss how tech writers and other non-designers can effectively collaborate with visual creators. He walks through what makes a good creative brief, including the importance of assuming the designer knows nothing about your field, spelling out acronyms, clearly identifying what's most important to communicate, and providing mood boards or reference examples for style direction. We use the creation of The Not-Boring Tech Writer podcast logo as a real-world example of how the collaboration process works, from initial brief through iteration to a finished product. We dig into the world of motion graphics and animation, where Bill explains the wide range of animation types and their associated costs, from simple text animation to puppet animation to traditional hand-drawn animation. He stresses the importance of investing in pre-production, including style frames and storyboards, to catch problems early before animation work begins. We also discuss how to give constructive feedback to designers: lead with what's working, be specific about what isn't, and reference your original mood board or brief to articulate where the disconnect is. We also explore how to evaluate potential designers or animators when hiring, including what to look for in a portfolio and the trade-offs between hiring experienced professionals versus newer talent. The episode wraps up with a discussion of AI's role in visual creation. Bill shares his perspective as someone actively working with AI tools alongside traditional methods, emphasizing that AI works best as part of a hybrid workflow rather than as a wholesale replacement for skilled designers. About Bill Holland: Bill Holland (also known by his alias Bill Netherlands) is a motion graphics generalist with an extensive background in video production. With an educational foundation in Art and Design, Bill has worked on every aspect of the motion process from scripting through sound mixing. His early career shooting and editing video informs his storytelling, staging, and pacing in motion graphics today. Bill has created motion graphics and editing work for clients including Google, PBS, NASCAR, the American Dental Association, and Hilton Hotels, earning multiple Telly, Communicator, and Davey awards. He previously ran his own company, Middlebranch Productions, Inc., before rebranding under the Bill Netherlands name at a fellow designer's suggestion. In this episode: [00:01:20]: Bill's motion graphics origin story and his current hybrid AI content creator role[00:09:43]: How tech writers often create technical documentation without realizing it[00:14:42]: What to include in a creative brief when working with a designer[00:21:38]: Handling clients who come in with too much or too little direction[00:23:58]: The Not-Boring Tech Writer logo as a real-world collaboration example[00:29:29]: Using mood boards and sketching to establish style direction[00:32:13]: How to give constructive feedback to designers[00:40:22]: Working with motion graphics and animation: types, costs, and setting expectations[00:48:33]: The animation production process: style frames, storyboards, and rough animatics[00:58:58]: What to look for when hiring a designer or animator[01:05:42]: AI's role in animation and visual creation[01:12:19]: Using AI as a research and organization tool[01:20:10]: Bill's favorite piece of advice Resources discussed in this episode: School of Motion: schoolofmotion.comSchool of Motion Podcast: Apple Podcasts, SpotifyThe Not-Boring Tech Writer logo design iterationsKnowledgeOwl Linus animation discussed in this episodeRelated episode: Humor and visuals in technical writing with Dennis Dawson (S3:E22)Bill Netherlands on VimeoBill Netherlands on YouTubeBill Netherlands on TikTokBill Netherlands on Instagram: Bill Netherlands MotionBill Netherlands on Instagram: Mr. Automatic (DJ)Bill’s podcast: Morally Offensive 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact Bill Holland: WebsiteLinkedIn Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    1hr 25min

  6. 5 FEB

    Kate sounds off on process (and LEGO)

    In this solo episode, I share my latest progress updates as I recover from finishing my big project, along with updates on my daily check-in form. I reflect on some of the key takeaways from Kelton Noyes’ interview (S3:E28) and how my love for process makes my life easier as a tech writer. — I’ve been working on catching up on the release tail from finishing my project and getting my docs backlog under control, which has included replacing gifs with short mp4s, creating guidelines for my coworkers to more easily create new pages or update existing pages in the KnowledgeOwl Support Knowledge Base, and knocking out a bunch of low-hanging fruit docs tasks. I’ve also picked up a project I paused in late 2024: updating our API endpoint documentation. I’ve been reworking the documentation to better align with our API’s current reality and requirements and adding some quality of life improvements for myself. I’ve been consistently using the daily check-in form I outlined in episode 27, and I’m largely happy with it, though it hasn’t yet helped me improve my appreciations and high-fives for my teammates. I also reflect on Kelton’s observations about how documentation should help people to not feel dumb, how getting hands-on with tools during the evaluation process can help refine and reshape your documentation hierarchy of needs, and how his success in transitioning from a support role to a tech writing role was about focusing on selling himself as the person to do documentation, rather than on selling the documentation itself. I also reflect on one of my key personality traits that I believe makes me more successful as a tech writer: loving the process to do things rather than the product I create. I share anecdotes about LEGO, jigsaw puzzles, and thru-hiking the Appalachian Trail. Sometimes this strength is also my biggest weakness, so this month I’m focusing on trying to release more even if it feels like the process still wants me to keep working. In this episode: [00:00:58]: My progress updates[00:08:32]: Reflecting on Kelton’s episode[00:14:35]: LEGO, jigsaw puzzles, and thru-hiking Resources discussed in this episode: KnowledgeOwl API endpoint documentationS3:E24: Self-documentation for career growth with Kate PondS3:E27: Kate sounds off on self-documentationBeating the Virginia Blues: Thru-hiking strategies to help you survive your next big projectThe Wild Reeds' song “Fruition”:On YouTubeOn Apple MusicOn Spotify 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    30 min

  7. 22 JAN

    Advocating for docs and choosing tools with Kelton Noyes

    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 ideas Resources discussed in this episode: Sapling Passive Voice CheckerSapling Passive to Active Sentence Rewriter 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact Kelton Noyes: LinkedIn Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    1hr 17min

  8. 8 JAN

    Kate sounds off on self-documentation

    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 writers Resources discussed in this episode: KnowledgeOwl Support Knowledge BaseGoogle Forms for Self-EvaluationS3:E24: Self-documentation for career growth with Kate Pond 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.comLinkedInBlueskyGuest suggestions form Contact Kate Mueller: knowledgewithsass.comLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

    31 min
See All (76)

Ratings & Reviews

About

Some people hear the phrase "technical writing" and think it must be boring. We're here to show the full complexity and awesomeness of being a tech writer. This podcast is for anyone who writes technical documentation of any kind, 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—there's a place for you here. Each month, we publish two episodes: an interview with an amazing guest focusing on useful skills or tools that can help you improve your tech writing skills, and a behind-the-scenes solo episode with host Kate Mueller about what she’s working on, struggling with, or thinking about in her daily tech writing life. The Not-Boring Tech Writer is generously sponsored by KnowledgeOwl, knowledge base software built for people who care, by people who care.

Information

  • Creator
    Kate Mueller
  • Years Active
    2016 - 2026
  • Episodes
    76
  • Rating
    Explicit
  • Copyright
    © 2016-2026 KnowledgeOwl
  • Show Website
    The Not-Boring Tech Writer

You Might Also Like