Couverture de The Not-Boring Tech Writer

The Not-Boring Tech Writer

The Not-Boring Tech Writer

De : Kate Mueller
Écouter gratuitement

À propos de ce contenu audio

 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.© 2016-2026 KnowledgeOwl Economie Réussite personnelle
Épisodes
  • Kate sounds off on lovable docs

    Kate sounds off on lovable docs
    Apr 2 2026
    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 lovabilityResources 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-BenedettiJoin 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
    Afficher plus Afficher moins
    32 min
  • From tech writing to building lovable neighborhoods with Jacob Moses

    From tech writing to building lovable neighborhoods with Jacob Moses
    Mar 19 2026
    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 ruleResources 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 ...
    Afficher plus Afficher moins
    1 h et 7 min
  • Kate sounds off on docs symbiosis

    Kate sounds off on docs symbiosis
    Mar 5 2026
    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 prioritiesResources 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 documentationJoin 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
    Afficher plus Afficher moins
    25 min
Aucun commentaire pour le moment