 |
The Not-Boring Tech WriterSome people hear the phrase "technical writing" and think it must be boring. Author: Kate Mueller
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 contentand whether you deal with imposter syndrome, lack formal training, or find yourself somewhere in the gray area between technical communications and general writingthere'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 shes 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. Language: en Genres: Business, Careers, Technology Contact email: Get it Feed URL: Get it iTunes ID: Get it |
Listen Now...
Kate sounds off on lovable docs
Episode 33
Thursday, 2 April, 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
