Advertise on podcast: The Not-Boring Tech Writer

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Jenna Jennissary’s interview (S3:E46). I share some thoughts on the collaborative work process she outlines and provide updates on some solo episode themes from 2025. — This month I ignored the article editor docs updates in favor of helping with pre-release testing and docs for our new file import tool, which supports importing PDFs and Word documents into KnowledgeOwl or converting them to articles within KnowledgeOwl. It handles other file types, too, but these were what I focused on in the documentation. This change also renamed our top-level menu item from “Articles” to “Pages,” so I did some work on reviewing and replacing occurrences of “Articles” with “Pages” when it was referring to the navigation (and not when it was referring to the concept or collection of articles, which are still valid). I also reflect on my interview with Jenna Jennissary and our discussion of audio description writers and resources, sharing a few additional resources I found. Jenna’s distinction between collaborative work rather than “group project” work was interesting, as it focused on things like style guide adherence and knowledge management, documenting, and sharing as you go, which feel like key concepts in a lot of lines of work. I close by sharing updates on a few key themes from my 2025 solo episodes, including updating you on how my experiment with Kate Pond’s Google form for daily check-ins is going and my house’s mouse infestation. In this episode: [00:00:46]: My progress update on pre-release docs for the file import tool[00:03:44]: Updating “Articles” in navigation to “Pages” and my find and replace adventure[00:06:43]: My recent and upcoming Wisdom Wednesday sessions[00:09:33]: My reflections on Jenna Jennissary’s episode and the work and resources of audio description[00:12:18]: Reflections on good collaborative work in audio description, as opposed to group project work[00:16:04]: Updates on my daily check-in Google form usage (thanks, Kate Pond!)[00:19:02]: Updates on my mouse infestation (TL;DL: seems to be going well)[00:21:27]: My goal for this month: keep on keeping on Resources discussed in this episode: KnowledgeOwl Support Knowledge Base: Import PDF documentsKnowledgeOwl Support Knowledge Base: Import Word documentsKnowledgeOwl’s Find and replace featureOwlcademy Upcoming webinarsScripting audio description for film, TV, and video games with Jenna Jennissary (S3:E46) The ADNA Presents podcastThe Audio Description Project's Training Sessions and MaterialsSelf-documentation for career growth with Kate Pond (S3:E24)Kate sounds off on self-documentation (S3:E27)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

In this episode, I talk with Jenna Jennissary, a producer at Descriptive Video Works who specializes mostly in video games and still gets to write and perform audio description herself. We talk about how a Reddit post about a scene in “God of War” led her from regulatory affairs into audio description, where the field’s standards come from when no central body sets them, how tight timing makes writers experts at saying the same thing in fewer syllables, and what it takes to break in as a new audio description writer. — Jenna and I start with what audio description is: a scripted narrator who speaks between the existing dialog to describe the visuals for blind and visually impaired viewers. She came to it from regulatory affairs at a pharmaceutical manufacturer after SightlessKombat asked on Reddit for someone to describe an emotional, dialog-free scene in “God of War.” Jenna thought she could do better than the first attempt, and the two of them ended up audio describing the whole game as a fan project, which led to her job at Descriptive Video Works. The heart of our conversation is why Jenna calls audio description tech writing and creative writing smooshed together. No central body sets the rules; standards come from the biggest studios and clients like Netflix. Most of the constraints come down to timing: the narrator can only speak in the gaps, so you become an expert at finding synonyms with fewer syllables. We also talk about working past a sighted writer’s biases, including why, given the choice, it’s slightly better to describe an action just before it happens, so the listener has time to process it. Jenna covers what makes a good audio description writer and what makes an excellent one, the tools and security measures behind the work, how blind players play video games, and how new writers break in, including practicing on YouDescribe. She recommends Netflix’s audio description guidelines and the American Council of the Blind’s Audio Description Project, and closes with her own life advice: if something in your day-to-day bugs you, change it. About Jenna Jennissary: Jenna is a Producer at Descriptive Video Works, the largest Audio Description studio in North America, and the leading studio for video game Audio Description. She has written many of the current industry standards to adapt AD writing to the unique constraints of video games, and advocates for quality above all for her oft-underserved audience. Thankfully, she still often gets to write or perform AD herself for live events. In this episode: [00:01:16]: Jenna’s role: a producer at Descriptive Video Works, specializing in video games[00:02:24]: What audio description is, how it differs from captions, and a few samples[00:03:43]: Pre-scripted, live, and video game audio description, and where to find it[00:05:35]: Jenna’s origin story: regulatory affairs, disability advocacy, and helping blind gamers[00:08:28]: Audio describing all of “God of War” as a fan project, and landing at Descriptive Video Works[00:11:54]: A producer’s day-to-day: wrangling contractors, client review, and live describing gaming events[00:16:24]: No central body: where audio description standards come from, including Netflix’s guidelines[00:18:35]: The shift toward describing characters’ ethnicity and racial appearance[00:20:52]: Picking the synonym with the right vibe, and whether audio description can be standardized[00:21:56]: An advisory committee of blind film critics, and client guidelines that work against accessibility[00:26:00]: Is audio description tech writing? Timing constraints and synonyms with fewer syllables[00:27:59]: Avoiding tongue twisters, voicing subtitles, and casting extra narrators[00:31:48]: Overcoming sighted bias, and describing an action just before it happens[00:35:43]: The skills of a good audio description writer, and what makes an excellent one[00:40:12]: The tool stack: ADR software, captioning tools, and clients’ proprietary platforms[00:42:33]: Security: on-site writing, watermarked proxies, and preventing leaks[00:45:00]: How blind players play video games: text to speech, haptics, and sound effects[00:47:30]: Accessible fighting games, the Blind accessible games wiki, and player-made mods[00:49:02]: Breaking into audio description: surveys, writing tests, and training[00:51:40]: Joining the writer roster, and training programs to diversify the field[00:54:26]: Practicing on YouDescribe[00:55:29]: Resources: Netflix’s guidelines and the American Council of the Blind’s Audio Description Project[00:56:46]: Jenna’s best advice: if something bugs you, change it Resources discussed in this episode: The American Council of the Blind’s Audio Description Project: Jenna’s pick for finding movies and TV shows with audio description and the platforms they’re onVideo games with audio description: The list from the ADP’s video gaming subcommittee, which Jenna serves onThe “God of War” audio description fan project: SightlessKombat’s #TranscribingGames guide to the game, with links to the audio described videos Jenna wrote and voicedNetflix Audio Description Style Guide: Netflix’s public audio description guidelines, which Jenna recommends as a publicly-available style guide you can accessBlind accessible games: The wiki Jenna mentions for finding games that blind players can playYouDescribe: A site where blind viewers request audio description for YouTube videos and anyone can add it, which Jenna recommends for practice 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 Jenna Jennissary: Email: [email protected]

In this solo episode, I share my latest content updates progress and confess to finally jumping on the Claude Code bandwagon. I also reflect on my takeaways from Katie Cox’s interview (S3:E44) and some of the instructional design concepts she shared that most resonated with me. — I finally finished my Minimum Viable Docs (MVD) list from the article editor layout release, four months later. I also finally gave in to using Claude Code when I needed to overhaul and update our OpenAPI spec file for our API documentation. My usage began innocently enough, trying to catch issues upgrading from version 2.x to 3.0 of the OpenAPI spec, but eventually included upgrading to version 3.1, updating Redoc, and overhauling a lot of the structure. Along the way, I still relied a lot on human expertise, in the form of API docs feedback from our developer Sue and OpenAPI technical expertise from Lorna Mitchell. I ultimately created a Claude skill that checks for valid YAML, validity against the OpenAPI spec file, validity against the Redoc linter CLI, and a few style guide choices. I also reflect on my interview with Katie Cox, noting that there are a ton of ways that instructional design and technical writing overlap in terms of the skillset, the day-to-day work, and the focus on end-user needs. The primary difference, to me, lies between what a reader expects versus what a learner expects. I appreciated Katie’s focus on encouraging self-directed learning and not gating content behind clicks and required interactions. And I’m most looking forward to pairing learning objectives with a compelling narrative, one of the key tricks she uses in her work. In this episode: [00:00:28]: Kate’s progress updates[00:01:42]: Kate’s long tangent about using Claude Code to update her OpenAPI spec file[00:16:48]: Kate’s reflections on Katie Cox’s episode Resources discussed in this episode: KnowledgeOwl’s API endpoint reference documentationDeveloper collaboration with Lorna Mitchell (S3:E2)KnowledgeOwl’s API keys documentationMaking the leap from tech writing to customer education with Katie Cox (S3:E44)The Accidental Instructional Designer by Cammy Bean 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

In this episode, I talk with Katie Cox, an instructional designer who has spent her career in customer education and now builds an entire product Academy as a team of one. We talk about what customer education actually means and how it differs from documentation, how she partners with technical writers and has them review every course before it ships, the skills that transfer if you're a tech writer thinking about making the pivot, and why feedback is a gift you shouldn't take personally. — Katie and I discuss her winding path into customer education, which started with a kinesiology degree, moved through a content editor role at an e-learning agency, and led to a Master's in education technology and her first customer education job at a software company with a pretty advanced program and a manager who became a formative mentor. We talk about what "customer education" actually means, why there's a push toward calling it "product education" instead, and how the content she builds gets used by customers, partners, and internal teams alike. Katie draws a clear line between learning content and documentation: people come to an Academy expecting to spend time learning, while people come to docs with a specific question and want out. That difference in expectations changes what you can ask of your audience and how you design the content. A central thread of our conversation is how Katie's work and technical writing overlap in practice. She works out of her company's docs repo, repurposes screenshots and text from her technical writers so there's a single source of truth, and never releases a course without having a writer review it, because they know their topics well and they catch things. We dig into her approach to building courses: backwards design starting from learning objectives, a running scenario with fictional companies to anchor the content, and hands-on activities because people learn by doing. Katie is emphatic that clicks are not engagement, and that gating content behind forced interactions is the fastest way to lose a learner. As a team of one, she also pulls in colleagues to build courses using a template she created, which means she's used learning design to teach other people learning design. We spend the second half on what it takes for a tech writer to move into instructional design. Katie, who has hired for these roles, says she'd hire a technical writer without hesitation, because the core skill of taking something complex and breaking it down is the same skill, and it's the thing she sees newcomers without that background struggle with most. The biggest difference she points to is scale: tech writers work page by page, while learning designers have to build a thread that runs through an entire course. We also cover whether you need a formal degree (she has one and learned more on the job), why the tooling matters less than the design thinking behind it, portfolio expectations and take-home assignments, and resources like Julie Dirksen's books, Cammy Bean's "The Accidental Instructional Designer," and the Customer Education Org Slack community. Katie closes with the best advice she's received: don't personalize it, because feedback is a gift. About Katie Cox: Katie Cox is an instructional designer who loves learning about learning, providing engaging courses for life-long learners, developing relationships that allow the learning design process to come to life, and nerding out over process optimization. Great educational experiences make a difference in people’s lives, and she's all about making those experiences the best they can be. In this episode: [00:01:43]: Katie's origin story: from a kinesiology degree to a content editor role to customer education[00:04:56]: What "customer education" actually means, and why it depends who you ask[00:05:10]: The push from "customer education" to "product education"[00:07:14]: Proactive support: prepackaged content that lets customers self-serve[00:08:25]: Learning content vs. documentation, and the different expectations people bring to each[00:10:19]: Working out of the docs repo: Astro, the LMS, and Arcade product walkthroughs[00:12:29]: Why every course gets reviewed by a technical writer[00:14:39]: Learning checks, activities, and scenario-based questions[00:17:03]: Being a team of one and sitting in product marketing[00:18:48]: Owning the Academy's voice while soliciting contributions from others[00:21:25]: Backwards design: starting with objectives, goals, and audience[00:22:39]: Fictional companies and running scenarios as a way to anchor content[00:27:26]: The review process for colleagues building their first course[00:29:30]: Job titles: instructional designer, learning designer, or product education manager?[00:36:37]: Why Katie would hire a technical writer, and the core skill that transfers[00:37:53]: Page-by-page writing vs. building a thread through an entire course[00:39:30]: Keeping a learner's attention, resisting gated content, and why clicks aren't engagement[00:41:03]: Resources for learning instructional design: Julie Dirksen and "The Accidental Instructional Designer"[00:42:14]: Do you need a formal degree, or can you learn instructional design on the job?[00:45:06]: Tooling: SCORM files, Articulate Storyline, video editors, and why the design thinking matters more[00:49:01]: Portfolio expectations for instructional design roles[00:51:25]: Take-home assignments, what makes a good one, and one big red flag[00:54:50]: Writing first, chunking content, and deciding when something needs a video[00:58:56]: Resource recommendations: Cammy Bean, "The Customer Education Playbook," and "Badass: Making Users Awesome"[01:00:17]: The Customer Education Org Slack community[01:01:23]: Katie's best advice: don't personalize it, because feedback is a gift Resources discussed in this episode: Books:The Accidental Instructional Designer by Cammy BeanDesign for How People Learn by Julie DirksenTalk to the Elephant: Design Learning for Behavior Change by Julie DirksenThe Customer Education Playbook: How Leading Companies Engage, Convert, and Retain Customers by Daniel Quick and Barry KellyBadass: Making Users Awesome by Kathy SierraThe Customer Education Org - A community for customer education professionals, including a Slack you can request access to from the main siteArcade - The tool Katie uses to create product walkthroughsKatie's portfolioRelated TNBTW episode: S3:E40: Mapping your technical writing skill tree with Vladimir Izmalkov Join the discussion by replying on Bluesky ...

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Mat Patterson’s interview (S3:E42). I also share how my content in the Support KB has evolved over time and reflect on treating emails and other content forms as an invitation into someone’s space. — Due to some medical things in the last month, I haven’t made significant progress on the article editor updates, but I have been keeping up with new releases. The Okta SCIM integration I mentioned in episode 41 was officially approved and released by Okta. 🎉We also released updates to our glossary term importer and URL checker tool, so I updated docs on those. And I finished part one of my productive procrastination task, replacing all hard-coded references to our HTML templates with references to a single code file for each. I reflect on my interview with Mat Patterson. I love the central idea behind his business, More Human Content, that if you're a small company, you shouldn't act like a large company in the language you use. Keep the rough edges and the playfulness as long as you can. I believe this is great advice both for small and medium businesses but also for tech writers ourselves, both in the documentation we write and the way we present our services. One of the surprising takeaways for me from this episode was recognizing how much my own sense of appropriate content and voice in the Support Knowledge Base has evolved over time. In the early years, I avoided best practice or prescriptive guidance. But as I got to know our customer base better, I learned that this was guidance they really wanted from us, and so I’ve gradually incorporated more of it, just as Mat’s own newsletter writing experience evolved. My other lingering takeaway from this conversation was Mat’s idea that when someone receives your newsletter, they’re inviting you into their inbox, very much like inviting you into their home. I love the idea of treating some forms of content and interactions like an invitation or like you’re a guest in someone’s space. I don’t write our newsletters anymore, but it has me thinking about at least reviewing some of my longform content–like best practice guidelines–to make sure it feels I'm properly respecting my readers and treating the topics and their attention with dignity and respect. In this episode: [00:00:46]: Kate’s progress updates[00:02:26]: Mat Patterson’s stance that you shouldn’t talk like a big business until you have to[00:05:26]: My evolution into adding best practice guidance into the Support KB[00:11:26]: Defining and describing your own freelance services[00:12:17]: Email communications are an invitation into someone’s inbox[00:14:42]: Centering human dignity in our documentation Resources discussed in this episode: Writing more human content with Mat Patterson (S3:E42)Kate sounds off on making things better (S3:E41)KnowledgeOwl’s URL checkerKnowledgeOwl’s glossary term importerJoin 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

In this episode, I talk with Mat Patterson, a CX professional turned technical marketing writer who spent nearly a decade each at Campaign Monitor and Help Scout before going freelance and founding More Human Content. We talk about why content that keeps its personality connects better than content with all the edges sanded off, how he treats an email newsletter as an invitation into someone's inbox rather than a transaction, why small companies shouldn't voluntarily start sounding like big ones, and how years of putting his own name and face on his work shaped his move into freelancing. — Mat and I discuss his winding path into writing for a living, which started with tech support out of university and a stint as a web designer beginning in the late 1990s, when one HTML course was enough to qualify you. He shares the moment he noticed someone had copied his company website, not the design but the copy, which he took as a sign he should probably be doing more writing and less web design. He joined Campaign Monitor as a support person, a role that called for web design skills and that he came to as an existing customer, and we talk about how being a user first gives you a real feel for how a company thinks and treats people. Over nearly ten years there he handled email support while also writing content for the knowledge base, the blog, and eventually giving conference talks, and that combination led him to a customer evangelist role at Help Scout for another decade before he went freelance and founded More Human Content. The heart of our conversation is Mat's case for keeping personality in the content you write. He describes the frustration of finding a company whose voice you like, then opening their documentation and discovering every bit of life has been sucked out of it. We talk about the gravitational pull that draws growing companies toward a middle ground of corporate language that makes everyone sound the same, and why small companies and individuals shouldn't voluntarily give that up when they don't have to. Mat also reframes email newsletters as something closer to an invitation: when someone hands you their email address, they're letting you into their house, so the least you can do is be interesting. We discuss why a newsletter can feel like a conversation rather than a transaction, why the small risk of putting personality into your writing is worth the connection it builds with the people who do respond to it, and how putting his own name and face on a decade of content built a following that followed him when he left. We spend the second half on the practical side of going freelance, including the fact that Mat left Help Scout full time and immediately signed a contract to keep making their content, how he decided what other work to offer, the difference between the ideal client he'd love to find and the writing that pays the bills in the meantime, and why marketing yourself while you're already busy matters more than waiting until you need the work. We both land on the value of a "one-page menu" instead of trying to be a cafeteria, and Mat shares how Greg McKeown's Essentialism gave him permission to get better at the things he's genuinely good at rather than trying to learn everything. He also makes a case for reading broadly, including libraries and secondhand bookshops, where he turned up a 1952 book called How to Write Technical Books that worries about many of the same problems we still have. Mat closes with the advice he keeps coming back to even though he doesn't always manage it: stop talking and start listening. About Mat Patterson: A former SaaS customer support team leader, Mat spent years teaching people how to deliver better online support before founding More Human Content, creating customer-centric content for people-centric businesses. In this episode: [00:01:57]: Mat's origin story: why he calls himself a writer in tech rather than a tech writer[00:02:43]: Getting his website copy stolen, and taking it as a sign to write more[00:04:27]: From a Sydney zoo to Campaign Monitor, and joining a company whose product you already use[00:07:09]: Wearing every hat at a small company: email support, knowledge base, blog, and conference talks[00:10:47]: Marketing posts vs. problem-solving posts, and finding the answer in his own forgotten blog post[00:12:08]: Joining Help Scout as a customer evangelist by tweeting the CEO[00:16:37]: The newsletter rule: don't be boring[00:17:52]: An email inbox as permission to come into someone's house[00:20:19]: Why newsletter replies beat responses on social media[00:22:53]: Why documentation doesn't have to be desiccated[00:24:14]: The small risk of writing with personality and the connection it buys you[00:25:27]: Leaving Help Scout: company size, creative work, and avoiding spreadsheets[00:30:27]: More Human Content: not anti-AI, but anti-acting-like-a-big-company[00:33:58]: Sanding off the edges: the gravitational pull toward corporate language[00:37:42]: Building a company's voice and the risk of getting trapped in your own[00:38:49]: Leaving full time, contracting back, and picturing the ideal client[00:45:01]: Analogies as the secret to his whole career[00:49:46]: What you can say under your own name that a company wouldn't[00:53:21]: How a personal following follows you when you leave[00:55:16]: “Essentialism” and getting better at what you're already good at[00:59:05]: The one-page menu: offering fewer things and saying no[01:00:17]: Reading broadly: libraries, secondhand bookshops, and a 1952 book on technical writing[01:04:52]: Mat's best advice: stop talking and start listening[01:08:32]: How he generates weekly content from a running list of notes Resources discussed in this episode: More Human Content newsletter - Mat's weekly newsletterYour fridge is running - The fridge newsletter Mat mentions in the episodeThe Supportive Weekly - The Help Scout newsletter Mat writes each weekMuseum of Customer Support: The World's Oldest Complaint Letter - Mat's post about Ea-nāṣir, the copper traderThe complaint tablet to Ea-nasir (and his apology to Nanni) - The video version of that postThe Supportive - The Help Scout podcast Mat still works onDocumentarians in a self-service-first world - Mat's article for the KnowledgeOwl blogObsidian - Where Mat keeps the running list of notes and phrases he mines for newsletter ideasBooks:Essentialism by Greg McKeownThe Art of X-Ray Reading by Roy Peter ClarkHow to Write Technical Books by John Gloag - The 1952 book Mat found in a secondhand bookshopJoin the discussion by replying

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Vladimir Izmalkov’s interview (S3:E40). I also share my definition of productive procrastination, a documentation jobs board maintained by Adam Pugh, and our new “Hire a tech writer” program here on the podcast. — I partnered with Sue, one of our developers, on an Okta SCIM integration project, doing some of the integration testing and creating the documentation so we could submit our integration to the Okta Integration Network. I made some article editor docs updates, but we released a number of new editor features and further interface changes, particularly to the versions functionality, so I’ll have a lot of new work and revisiting already-updated pages in my future. I’ve been battling burnout on the article editor docs, so I decided it was time for a little productive procrastination. This time, I decided to review our usage of Prism for code syntax highlighting and discovered it had new plugins we didn’t have, so I upgraded our installation, wrote docs on how to do that, and tested using a new plugin to load code blocks directly from files, which looks like it will streamline a lot of redundant work on my side! I reflect on my interview with Vladimir Izmalkov, both in the utility of his tech writer skill tree but also how we both want our documentation to make someone’s life better or, as Vladimir put it “making [complicated things] simpler for people to enjoy them with less effort and less time spent.” Vladimir and Heather’s episodes complement each other well, both discussing nonlinear ways that skills can be developed and/or matched to new job opportunities. And in the vein of job opportunities, I share two resources that may help you if you’re looking for work or looking to hire. The first is Adam Pugh’s good documentation jobs sheet, which is free and available to the public. He updates this periodically using tools that evaluate the content of a job, rather than just the title, and he gave me permission to share it on the show. The second is a new program we’re launching here on the podcast called Hire a tech writer, designed for those of you looking to hire awesome not-boring writers to share your open positions with our listener base in the hopes we can connect awesome listeners with each other. There’s a lot of uncertainty in our industries and roles right now, and we hope these resources help you navigate some of that uncertainty. In this episode: [00:00:54]: Progress update on the new Okta SCIM integration and article editor updates[00:04:23]: My definition of productive procrastination and updating Prism[00:11:31]: Reflecting on Vladimir Izmalkov’s user advocacy stance and experiences[00:14:33]: Adam Pugh’s good documentation jobs sheet[00:17:18]: Introducing our new Hire a tech writer program Resources discussed in this episode: Mapping your technical writing skill tree with Vladimir Izmalkov (S3:E40)The Technical Writer's Skill Tree - Vladimir's talk, delivered at an online meeting of the ISTC London Area Group on 21 January 2026 Knitting together a technical writing career with Heather Zoppetti (S3:E38)Adam Pugh’s good documentation jobs sheetWorking Notes, Adam Pugh’s Substack in which he shares more of the journey behind the good documentation jobs sheetHire a tech writer and advertise a job opportunity on The Not-Boring Tech Writer 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

In this episode, I talk with Vladimir Izmalkov, an experienced technical communicator who has built and managed documentation teams and worked across open source and enterprise software in both English and Russian. We talk about his RPG-inspired "skill tree" for technical writers, how mapping your skills into different "classes" can help you make sense of a nonlinear career, and how to build a personal grading system that lets you evaluate yourself against a job's requirements and pitch your adjacent skills with confidence. — Vladimir and I discuss his winding path into technical writing, which began at a Russian research institute where he worked on information and communication systems for emergency response, before he realized that his mix of technical breadth and a knack for working with documents pointed toward technical writing. We talk about his move to the UK to work at a London startup documenting an open source database, the tension he felt blending honest technical documentation with marketing, and his current role at Canonical, where the team calls themselves "technical authors" to reflect their authority over documentation and their collaborative, guidance-focused work with engineers. The heart of our conversation is Vladimir's RPG-inspired "skill tree" for technical writers, a model he developed to capture how nonlinear and multidimensional our careers really are. He explains how the many skills a tech writer can develop behave like independent dimensions, and how thinking in terms of "classes" (like a linguistics-focused writer, a tech-curious engineer, a "docs tool sage" who loves automation and tooling, a marketer, or a team leader) can help you make sense of your own experience. We discuss visualizing all of this on a radar chart, and why the real value isn't the picture itself but the deeper understanding it gives you of your strengths and gaps. We also dig into the practical grading system that makes the skill tree useful for job hunting. Vladimir walks through how to build a leveling scale from a job posting's requirements, grade yourself honestly against it, and then identify where adjacent skills can compensate for gaps, using the example of pitching Docs as Code experience when a role calls for DITA. We close on AI as its own branch of the skill tree, including why Vladimir is cautious about generating documentation from scratch and why his most reliable results come from using AI to build deterministic, testable scripts he can automate rather than automating the AI itself. About Vladimir Izmalkov: Vladimir Izmalkov is a technical writer with 15+ years of experience creating developer-oriented documentation in Russian and English. A docs-as-code advocate, he has documented NoSQL databases, cloud platforms, and distributed systems, and takes a thoughtful, cautious approach to AI in technical documentation. In this episode: [00:01:12]: Vladimir's origin story: from a Russian research institute and emergency response systems to discovering technical writing[00:05:34]: Realizing technical writing is a named profession, and how broad the field can be[00:08:26]: User advocacy and user-centric communication as the heart of the work[00:10:09]: From overcomplicated academic writing to simplifying complex products for users[00:13:41]: Relocating to the UK and documenting an open source database at a London startup[00:15:31]: The tension between honest technical documentation and marketing content[00:19:28]: Joining Canonical and why the team calls themselves "technical authors"[00:21:12]: Job titles: technical writer, technical author, or documentation engineer?[00:23:38]: Where the skill tree idea came from and viewing skills as independent dimensions[00:26:40]: Building the RPG-inspired technical writer skill tree[00:28:03]: Skill tree "classes": the writer, tech-curious engineer, docs tool sage, marketeer, and team leader[00:29:40]: Using a radar chart and building a grading system to level yourself[00:31:16]: Tooling as an example: mastering your own tools vs. what a role requires[00:32:37]: Projecting adjacent skills onto job requirements (Docs as Code vs. DITA)[00:37:37]: AI as a branch of the skill tree and why "competing" against it misses the point[00:41:16]: Using AI for automation rather than generating docs from scratch[00:43:10]: Why generating docs from scratch is the worst-case use of AI[00:50:34]: Vladimir's best piece of advice: ask whether you're doing the wrong thing Resources discussed in this episode: The Technical Writer's Skill Tree - Vladimir's talk, delivered at an online meeting of the ISTC London Area Group on 21 January 2026Communicator journal, Volume 1, 2026 - The issue containing Vladimir's articleDocumentation Engineering - Vladimir's YouTube channel, which includes a video on ways to use AI in technical documentationVladimir's ADPList mentor profile 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 Vladimir Izmalkov: izmalkov.netLinkedIn Contact KnowledgeOwl: knowledgeowl.comLinkedIn

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Heather Zoppetti’s interview (S3:E38). I also share some thoughts on shifting from focusing on reducing stress to building confidence and share an anecdote about how my podcast t-shirt helped me discover a local tech writer in the wild. — I wrote and hosted a series of five webinars on our Change Management Toolkit this month, which seemed to go well and which gave me a sense for where the gaps in the toolkit still are. I’m still hoping to create a publicly accessible version of the toolkit I can share with you. I’ve also been continuing to update docs as part of the article editor redesign, this month focusing on our synced articles, categories, and knowledge base documentation. This prompted a partial reorganization and the creation of 14 new articles as that reorganization identified content gaps. I reflect on my interview with Heather Zoppetti, a former software developer and knitwear business owner. I love how Heather combined her software developer tech chops with a decade of crafting knitwear patterns and content to get her first tech writing job. I reflect on the similarities in our approaches and outlooks around getting feedback from other writers and viewing varied or unusual experiences as beneficial for a technical communicator. I’m trying to embrace her idea of technical communication’s goal of building confidence in your end-user, reader, or watcher, which I think is a much more positive way of framing my whole “reduce stress” goal. I close by talking about all the different forms that technical communication can take, and therefore all the different paths and roles that technical communicators have. I share a story of a woman at a local natural foods store asking me questions about my podcast t-shirt, which culminated in me pointing out that if she writes SOPs, she’s a technical writer, too. In this episode: [00:00:29]: Progress updates on my change management toolkit webinar series and Support knowledge base content updates[00:04:48]: Reflecting on Heather Zoppetti’s career path, skills, and collaboration techniques[00:11:50]: Reframing the idea of docs as stress reduction to docs as confidence builders, thanks to Heather[00:14:28]: The variety of technical communication types and paths[00:19:10]: My podcast t-shirt in the wild: a story of discovering a tech writer in the wild Resources discussed in this episode: Support knowledge base: Shared & synced contentKnitting together a technical writing career with Heather Zoppetti (S3:E38)The craft of technical writing with Marcia Riefer Johnston (S3:E8) 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

In this episode, I talk with Heather Zoppetti, a senior technical writer who came to the field through software development and a decade spent running a hand-knitting pattern business. We talk about how technical communication shows up far beyond software documentation, how to recognize and reframe the transferable skills hiding in a nonlinear career, and why being willing to try something matters more than doing it perfectly. — Heather and I discuss her winding path into technical writing, which started with a career in software development, took a decade-long detour into running a hand-knitting pattern and yarn business, and eventually circled back to tech. When she returned to job hunting and realized she no longer recognized the skills developers were expected to have, she stumbled on a technical writing posting and recognized the work immediately: writing knitting patterns is technical communication. She applied using her knitting patterns as her writing portfolio, and we talk about why her tech writing instincts came more from designing knitwear than from her years as a developer. A central thread of our conversation is the idea that technical communication is far broader than software documentation. Heather pushed me to think beyond written text to formats like videos, live workshops, interactive lessons, and animated GIFs, and to recognize that different audiences and learning styles call for different approaches. We dig into her experiments with internal documentation at Vanguard, including running user research cohorts to learn the why behind how people use content, and why metrics alone can't tell you whether someone was genuinely absorbed or just stepped away from their desk. We also explore what happens when a docs team builds its own site using the design system it documents, and how "drinking your own champagne" surfaces bugs and builds trust with users. We spend much of the second half on transferable skills and how to reframe a nonlinear career for a tech writing role. Heather and I both believe more people have technical communication experience than they realize, whether it's a pet medication schedule, a tax prep sheet, a restaurant menu, or a cheat sheet you wrote so your family stops calling you for help. We talk about treating your resume and cover letter as their own forms of technical communication, mapping your experience to the language in a job description, and why good documentation ultimately leaves your reader feeling confident they can do the thing. Heather closes with a reminder that stuck with me: you don't have to go all in to try something, and the only real way to find out if something is for you is to give it a go. About Heather Zoppetti: Heather Zoppetti, from Philadelphia, has a rich background in computer science and technical writing. Her current professional journey has her spending her days programming, creating tooling for engineers, and writing documentation. When she’s not typing away at code or text, Heather’s knitting, painting, or performing some other needle witchcraft like cross-stitch. She loves coffee, cats, and the Oxford comma. In this episode: [00:01:20]: Heather's origin story: from software developer to hand-knitting business owner to technical writer[00:03:15]: Recognizing knitting patterns as technical writing and using them as a portfolio[00:05:59]: Heather's current UX writing role and the value of not being a lone writer[00:08:51]: How companies value documentation and where it sits in the org[00:12:42]: Why "technical communication" is broader than "technical writing"[00:13:51]: Meeting different learning styles with video, GIFs, workshops, and more[00:18:04]: Experimenting with internal docs, user research cohorts, and the limits of metrics[00:23:06]: How different roles (designers vs. developers) prefer to learn[00:28:13]: Job titles: technical writer, content writer, or documentation engineer?[00:29:52]: Tooling constraints and building a docs site with your own design system[00:31:03]: "Drinking your own champagne": how dogfooding surfaces bugs and builds trust[00:34:40]: The case for transferable skills and the tech comm you already do[00:39:37]: Technical communication everywhere: medicine labels, pet care, tax prep, and menus[00:47:48]: Reframing a nonlinear career in cover letters, resumes, and interviews[00:52:36]: Interviewing, imposter syndrome, and transferable skills[00:58:52]: How good documentation leaves your reader feeling confident[01:01:08]: Resource recommendation: the Write the Docs Slack and community[01:03:15]: Best advice: just try it, and treat new things as experiments Resources discussed in this episode: "Knitting Together a Technical Writing Career": Heather's Write the Docs Portland 2025 talkWrite the Docs Slack 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 Heather Zoppetti: heatherzoppetti.comLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Florian Lefebvre’s interview (S3:E36). I also share some thoughts on how documentation leads can reduce stress for contributors or reviewers. — I’ve been continuing to update docs as part of the article editor redesign, though somehow despite updating a lot, the total number hasn’t changed much. I've also helped with docs on a few new features, including small updates to our API endpoint documentation, writing some best practices for using URL redirect articles and categories, major changes to our URL checker, and writing some guidance on robots.txt customizations to prevent certain types of user agent traffic. I also reviewed docs someone else updated when we finally transitioned Advanced search to being a full find-and-replace feature. And, of course, I kept quite busy with Write the Docs Portland, serving as the Writing Day Coordinator! I reflect on my interview with Florian Lefebvre, co-maintainer of Astro. I love Florian’s story arc of going from someone who self-described as “lazy” and “not enthusiastic” about docs to becoming someone for whom docs are an essential part of building a feature. And I love how Astro Docs uses "talking and doc-ing" meetings to work through core concepts rather than turn them into grammar nitpick fests, lowering the barrier for non-native English speakers and folks who aren’t professional writers to produce clear, accurate documentation. I close by reflecting on the ways that the processes Sarah Rainsberger, docs lead at Astro Docs, has built processes that have reduced stress for her contributors, including the talking and doc-ing meetings but also the single page for experimental features, taking on the responsibility of content hierarchy, multiple pages, and cross-references for herself. I use a vaguely similar approach here at KnowledgeOwl but I haven’t tried the single page approach, and I may have to try this out with my team. In my own experience, decisions about naming pages and deciding where they live in the content hierarchy are some of the most stressful tasks for my team, and removing those as tasks has made them a lot more excited to contribute to documentation. In this episode: [00:00:44]: Progress updates[00:03:25]: Reflections on Florian’s story arc[00:05:06]: Reflections on Astro Docs’ talking and doc-ing meetings[00:07:59]: Reflections on how we can reduce stress for SMEs, contributors, or reviewers Resources discussed in this episode: Writing docs as an open source developer with Florian Lefebvre (S3:E36)Empathy advocacy: Designing docs for all emotional states with Ryan Macklin (S3:E16)Kate sounds off on cognitive capital and learning (S3:E17)Astro Docs Docs (AD2) 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

In this episode, I talk with Florian Lefebvre, a core maintainer of the open source Astro framework, about what it looks like to write and contribute to docs as a developer. We discuss his mindset shift from being reluctant about docs to seeing them as essential to shipping a feature, how he collaborates with a dedicated docs lead through "talking and doc-ing" calls, the importance of writing changesets from the user's perspective, and how reviewing community contributions doubles as a way to teach new contributors your project's docs conventions. — Florian and I discuss his path into the Astro core team, which started with answering questions on the project's Discord as a user and eventually led to being invited to join the core team. He shares how he was initially reluctant about writing docs, but his perspective shifted as he came to see docs as inseparable from shipping a feature. As Florian puts it, if you build something and nobody knows it exists or how to use it, your feature doesn't really exist. A central thread of our conversation is Florian's collaboration with Sarah Rainsberger, the Astro docs lead. We dig into their "talking and doc-ing" calls, where Sarah reads back her understanding of a feature and the two iterate together until the docs are technically accurate. Florian highlights how having a dedicated docs lead removes a lot of pressure, especially as a non-native English speaker. He can focus on getting the technical content right and trust Sarah to handle phrasing. We also discuss the value of asking "Is this what you meant?" as a confidence check, rather than making edits based on assumed understanding. Beyond the collaboration with Sarah, we also cover the practical side of contributing docs as a developer, including reviewing community PRs, writing user-focused changesets, and handling docs for experimental features. Florian explains his approach to coaching new contributors through review comments rather than pointing them to guidelines, why he writes changesets focused on what the user cares about rather than what the developer did to fix something, and how Astro keeps experimental feature docs as a single page until the feature stabilizes. Florian closes with a small but powerful philosophy from the Astro Docs team: every contribution just has to be "not worse than what we had before." About Florian Lefebvre: Fullstack developer. Freelancer. Astro core maintainer & TSC member. Open-Source lover. French. Two-time winner of the Astro Community Award. In this episode: [00:01:38]: Florian's origin story: from coding his high school orchestra's website to joining the Astro core team[00:03:22]: Astro's governance: maintainers, core maintainers, and how community involvement leads to those roles[00:05:19]: Astro features Florian has contributed: Astro Env and the Fonts API[00:11:01]: From reluctant docs contributor to seeing docs as essential to shipping a feature[00:13:50]: How Astro's docs work: a dedicated docs lead plus community contributions[00:14:58]: Community contributions and the "banner everywhere" problem[00:17:10]: Astro Docs Docs and coaching new contributors through review comments[00:22:44]: Writing changesets that focus on what the user cares about, not what the developer did[00:32:57]: Docs for experimental features: the single-page approach[00:40:44]: Using existing pages as templates for new docs[00:42:45]: Writing docs as a non-native English speaker[00:46:55]: The "talking and doc-ing" call process: drafts, iteration, and confidence checks[00:52:51]: Resource recommendations: Astro Docs Docs, Diátaxis, and Sarah's 50 docs tips[00:54:21]: Florian's best advice: every contribution should be "not worse than what we had before" Resources discussed in this episode: Astro DocsAstro Docs Docs - Astro's docs about contributing to and writing for their docsAstro Env - The environment variables feature Florian contributed to AstroAstro Fonts API - The fonts feature Florian worked onStarlight - A docs framework built on top of AstroThe Diátaxis framework50 docs tips in 50 days - Sarah Rainsberger's blog series Also recommended by Florian: Supporting the future of Astro 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 Florian Lefebvre: florian-lefebvre.devLinkedInBluesky Contact KnowledgeOwl: knowledgeowl.comLinkedIn

In this solo episode, I share my latest content updates progress and reflect on my takeaways from Eric Holscher’s interview (S3:E34). I also share some thoughts on supporting institutions we care about and how to keep “community” from being an unpleasant word. — KnowledgeOwl just released a major redesign of our article editor, so I’ve been spending a lot of time testing that redesign and preparing documentation updates for its release. Since the editor is initially opt-in for existing customers, I had to handle both the existing editor layout and the new editor layout in our documentation. I chose an introductory snippet to explain the difference and then manually built tabs for the instructions for each editor layout. I believe this gradual rollout before we move everyone over is a great experience for our authors, but it has definitely made the documentation process a lot more involved, since I know I’ll have to revisit these pages and update them again once we complete that forced rollout. I reflect on my interview with Eric Holscher, co-founder of the Write the Docs conference. The conference had very humble, minimal roots: the founders all wanted a space for people passionate about documentation to come together and share ideas and then just decided to launch a conference. It grew organically over time. I finally tracked down where I got the idea of “supporting the institutions you care about” from my interview with Eric. Turns out it came from Timothy Snyder’s book On Tyranny: 20 Lessons from the 20th Century, from his lesson titled “Defend Institutions.” Volunteering for something like Write the Docs is a form of defending an institution I care about, and I hope you can similarly find ways to defend the institutions you care about. I also dig into the idea of community, especially on the fact that community exists on a spectrum between value-adding and value-extracting, which Eric mentioned in his interview. I introduce some ideas from Ari Weinzweig’s newsletter that recast this dichotomy as making and taking, and I explore ways that building community is like building documentation, tying these ideas to a quote from Wendell Berry. In this episode: [00:00:44]: Progress updates[00:06:40]: Reflections on how Write the Docs first began[00:09:46]: Reflections on supporting the institutions we care about[00:12:42]: Reflections on the idea of community and building communities centered around making rather than taking Resources discussed in this episode: KnowledgeOwl Support KBBuilding a home for documentarians with Eric Holscher (S3:E34)How to Make Sense of Any Mess by Abby CovertThe Sensemakers ClubOn Tyranny: 20 Lessons from the 20th Century by Timothy SnyderLife Is a Miracle: An Essay Against Modern Superstition by Wendell Berry “What It Means to Make Democracy in the Day to Day: Why the power of making tops the power of taking” by Ari Weinzweig 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

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: [email protected]

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