The Not-Boring Tech Writer

Kate sounds off on community

Kate Mueller — Thu, 30 Apr 2026 03:00:00 -0500

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 KB
Building a home for documentarians with Eric Holscher (S3:E34)
How to Make Sense of Any Mess by Abby Covert
The Sensemakers Club
On Tyranny: 20 Lessons from the 20th Century by Timothy Snyder
Life 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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Building a home for documentarians with Eric Holscher

Kate Mueller — Thu, 16 Apr 2026 03:00:00 -0500

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:

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:

Kate sounds off on lovable docs

Kate Mueller — Thu, 02 Apr 2026 03:00:00 -0500

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:

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

From tech writing to building lovable neighborhoods with Jacob Moses

Kate Mueller — Thu, 19 Mar 2026 03:00:00 -0500

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:

Kate sounds off on docs symbiosis

Kate Mueller — Thu, 05 Mar 2026 03:00:00 -0600

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:

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Collaborating with designers and animators with Bill Holland

Kate Mueller — Thu, 19 Feb 2026 03:00:00 -0600

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.com
School of Motion Podcast: Apple Podcasts, Spotify
The Not-Boring Tech Writer logo design iterations
KnowledgeOwl Linus animation discussed in this episode
Related episode: Humor and visuals in technical writing with Dennis Dawson (S3:E22)
Bill Netherlands on Vimeo
Bill Netherlands on YouTube
Bill Netherlands on TikTok
Bill Netherlands on Instagram: Bill Netherlands Motion
Bill 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:

Contact Kate Mueller:

Contact Bill Holland:

Contact KnowledgeOwl:

Kate sounds off on process (and LEGO)

Kate Mueller — Thu, 05 Feb 2026 03:00:00 -0600

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 documentation
S3:E24: Self-documentation for career growth with Kate Pond
S3:E27: Kate sounds off on self-documentation
Beating the Virginia Blues: Thru-hiking strategies to help you survive your next big project
The Wild Reeds' song “Fruition”:
- On YouTube
- On Apple Music
- On 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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Advocating for docs and choosing tools with Kelton Noyes

Kate Mueller — Thu, 22 Jan 2026 03:00:00 -0600

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:

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:

Contact Kate Mueller:

Contact Kelton Noyes:

Contact KnowledgeOwl:

Kate sounds off on self-documentation

Kate Mueller — Thu, 08 Jan 2026 03:00:00 -0600

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:

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

A peek behind the curtain: 2025 clips episode

Kate Mueller — Thu, 25 Dec 2025 01:00:00 -0600

In this episode, I share clips from my conversations with Liz Argall, Dennis Dawson, Sarah Walker, Ryan Macklin, Nick Graziade, Janine Chan, and Kate Pond. The clips include outtakes, sound check moments, and segments we cut for time from our 2025 interviews.

—

This episode is different from our usual format. Instead of a single guest interview, I'm sharing clips that we cut from this year's episodes or captured during our pre-recording sound checks. Most of these clips didn't make it into the final episodes due to time constraints, but they contain insights and moments I didn't want to lose entirely. The clips range from lighthearted sound check banter to substantive discussions that didn't fit the final edit.

Sarah Walker and I dig deeper into the concept of "beginner's mind" and how returning to documentation you haven't touched in a while can be both humbling and instructive. Ryan Macklin extends empathy advocacy to include ourselves and reminds us that understanding where frustrated customers are coming from doesn't mean we have to accept abusive behavior. Nick Graziade and I explore the limitations of hierarchy as the sole approach to information architecture and why metadata-driven organization can sometimes serve users better than deep folder structures. And Kate Pond and I briefly discuss weekly check-ins and the idea of gamifying daily reflection. There are also some fun moments from sound checks with Liz Argall and Dennis Dawson, plus a clip from Janine Chan's episode that I couldn't resist revisiting.

Consider this a peek behind the curtain at how the podcast comes together as well as a thank you to all of our 2025 guests for being so generous with their time and insights!

Join the discussion by replying on Bluesky

In this episode:

[00:00:04]: Kate Mueller’s intro
[00:05:04]: Liz Argall
[00:07:05]: Dennis Dawson
[00:09:46]: Sarah Walker
[00:18:11]: Ryan Macklin
[00:21:17]: Nick Graziade
[00:30:24]: Janine Chan
[00:31:44]: Kate Pond
[00:33:50]: Kate Mueller’s outro

Original Season 3 episodes featuring these guests:

Guest bios:

Liz Argall:

Liz Argall creates empowering documentation and processes; where you need it, when you need it.

She’s a technical writer, program manager, author, and trainer who delivers humanizing, data informed, accessible, and technically complex projects for a range of organizations, from Fortune 500 companies to a community development organization in Uganda.

In a past life, she was a professional artist talent scout and she’s still a professional member of SFWA (now called the Science Fiction and Fantasy Writers Association). She’s a graduate of Clarion Writers Workshop, has been critiqued by multiple New York Times best selling authors, and has critiqued the stories of multiple award winning authors, which is a long way of saying that she likes to give a good portfolio critique!

Dennis Dawson:

Like many baby-boomers, Dennis still hasn't decided what he wants to be when he grows up. He's a technical writer with 40 years' experience in technical communications providing documentation, training, and user support; a sketchnotes artist for Write the Docs; a 3-time Distinguished Toastmaster and Past District 57 Governor who's won District Champion titles in Humorous, Tall Tales, and Evaluation contests; a volunteer Santa Claus at San Jose Christmas in the Park; and a volunteer drawing teacher at local elementary schools.

Sarah Walker:

Sarah's been writing and crafting stories since she was able to put pencil to a Peanuts 3x5 top-spiral memo pad and record her stories in her own scribbly alphabet. Since personal alphabets scribbled on tiny pieces of paper don't pay the rent, she embarked on her career as a professional writer and editor after graduating from St. Edward's University (Austin, TX) in 1998. As an industry editor with Hoover's for roughly seven years, she covered biotech, pharmaceuticals, health care systems, venture capital, investment firms, and other sectors as a member of the Finance and Health Care editorial team. She earned her Austinite bone fides by getting hired by and, 18 months later, laid off by Dell, where she served as a technical editor for the Global Technical Training and Curriculum Team for products and software for consumers as well as small and midsize businesses. Thanks to the Great Recession and other market forces and personal demands, she bounced around a bit from writing and editing features, self-help book summaries, U.S. Pharmacopeia monographs, and other technical-ish content.

She began her technical writing career in earnest at Libre Digital, where she spent much of the second decade of the 21st century documenting procedures for processing various magazine titles as well as a platform for book publishers to distribute their titles to digital marketplaces. After a two-year stint as the managing editor (and lone full-time, non-contract employee) of a local bimonthly magazine targeting affluent residents of "West Austin," at long last (in August 2020), Sarah landed a job that gave her the Technical Writer job title, and she's been writing about the Monetate platform ever since.

Sarah's second career as a yoga instructor (and briefly a Pilates mat instructor) began in 2005, after she completed her 250-hour instructor training with Yoga Yoga (now defunct, just like the college in Santa Fe, NM that she attended for the first two years of her undergrad studies). She taught part-time until 2012, when primary job demands and other responsibilities forced her to give it up.

Ryan Mackl...

Kate sounds off on 2025

Kate Mueller — Thu, 11 Dec 2025 01:00:00 -0600

In this solo episode, I share my latest content update progress. I also reflect on all of 2025 hosting this podcast, offering lessons learned about tech writing and myself alongside gratitude to this year’s awesome guests and listeners like you.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes we rolled out in December 2024. I’ve finished my official punchdown list and am working through some spot checks and searches to verify I didn’t overlook anything in that list.

This episode is my final solo episode of 2025, so it felt appropriate to reflect a bit on how this year has gone. I share seven lessons about tech writers and tech writing I’ve distilled from the year:

Tech writers are really really really not-boring humans.
We like to learn stuff and we’re more or less always learning.
We’re always adapting.
We know a lot of random stuff and it’s not always limited to technical domains.
We’re generous with our knowledge.
Very few of us came into this profession in a linear or “traditional” way.
Care and empathy underlie a lot of what we do.

I also share some lessons I learned about myself and offer a ton of gratitude, most especially to the awesome roster of amazing, talented people who graced me with interviews this year, and also to all the folks behind the scenes who make this possible. We are, slowly but surely, building a solid not-boring community, and I look forward to another year of doing the same!

Resources discussed in this episode:

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Self-documentation for career growth with Kate Pond

Kate Mueller — Thu, 27 Nov 2025 01:00:00 -0600

In this episode, I talk with Kate Pond, a software engineer and former park ranger who turned self-documentation into a career superpower. We discuss her practical system of using Google Forms to track daily work and accomplishments, how this helps with performance reviews and job interviews, and why documenting your own work is essential for professional growth.

—

Kate Pond and I discuss her unique path from park ranger to software engineer and how documentation played a crucial role throughout her career transitions. She shares how creating personal runbooks as a college RA taught her that writing things down once saves countless hours of reinventing the wheel later. We explore how this philosophy extended into her transition to software engineering, where she documented everything she learned at technical meetups.

The heart of our conversation centers on Kate's Google Forms system for self-documentation, which she created to track her daily work, accomplishments, and professional development. She explains how the system uses a mix of checkbox ratings (like "how do you feel right now?" on a 1-10 scale) and free-form text fields to capture what she worked on, who she collaborated with, what she learned, and what she's proud of. We discuss how this creates both quantitative data you can graph over time and qualitative records you can mine for performance reviews, peer feedback, and interview preparation.

We also explore the broader philosophy behind self-documentation, including how it helps combat the reality that we simply can't remember everything we do, the value of having "retro docs" when taking breaks from projects, and how documentation for yourself follows the same principles as documentation for users. Near the end of our conversation, Kate shares practical advice from her career coach about doing "scary hour" sessions with a friend to tackle procrastinated tasks.

About Kate Pond:

Kate Pond is a Seattle-based software engineer, technical storyteller, and former park ranger. With a background in both environmental education and backend engineering, she brings a systems-thinking approach to everything from documentation to distributed systems.

Through her studio, The Pond’s Edge, Kate is building climate-tech and AI-powered tools that support sustainability and reduce waste—most recently focusing on circular economy solutions rooted in local community needs.

Kate is passionate about making complex ideas accessible and mentoring others to grow as thoughtful technologists. She’s spoken at GopherCon, REdeploy, and SeaGL, and actively contributes to the PNW tech and climate communities through events like CascadiaJS and PNW Climate Week.

Recommendation from Kate Pond:

9Zero Climate Innovation Hub is a coworking space and community designed for climate innovators—founders, engineers, scientists, creatives, and changemakers. With locations in San Francisco and Seattle, and expanding to NYC and Los Angeles, it’s a vibrant hub for events, collaboration, and climate-focused work.

If you’re based in or near one of those cities and looking for a supportive, mission-driven space to work or connect, definitely check them out.

✨ Referral perk: If you sign up for a membership and mention my name (“Kate Pond”) as your referrer, we both get a free month (or up to $150 off). Win-win!

Learn more at 9zero.com

Resources discussed in this episode:

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:

Contact Kate Mueller:

Contact Kate Pond:

Contact KnowledgeOwl:

Kate sounds off on small things and repairs

Kate Mueller — Thu, 13 Nov 2025 01:00:00 -0600

In this solo episode, I talk about my latest content update progress. I also reflect on Dennis Dawson’s interview (S3:E22), the ways I'm already using Dennis's tips, and the power of doing small things or repairs to affect larger change.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes we rolled out in December 2024. My previous punchdown list of fewer than 50 articles was wrong, but I do think I’m below 100 now, after I found a chunk of content I’d completely missed.

I reflect a bit on some of the detailed, specific next steps Dennis Dawson offered. Thanks to some of his points, I won’t be including a floating copy of my head in upcoming videos. I’m also starting to think of visual ways I can help give my readers a pause during conceptually-heavy content, to let them shift from focused mind to diffuse mind.

I also reflect on the piece of advice that most stuck out to me from Dennis’s interview: “Get over yourself. Get over your reticence”, and a new practice I have of picking up trash along the main road near my house. Along the way, I tie in quotes from Abby Covert, Ari Weinzweig, and Harrison Gardner.

So much of tech writing boils down to what we might classify as “small things” (Weinzweig) or “repairs” (Gardner). In both cases, these small actions can add up to big change and momentum over time. They’re also one of the ways we can most express care and commitment to a project. This month, I’m doubling down on these small things and repairs, and I invite you to join me in finding small ways to care for your documentation.

Resources discussed in this episode:

KnowledgeOwl Support Knowledge Base
Abby Covert’s How To Make Sense of Any Mess, excerpted from chapter 7: Be the filter, not the grounds
Ari Weinzweig’s Small Actions Matter in Much Bigger Ways Than We Might Imagine: Pint-sized ideas, the struggle of self-doubt, and learning to take action anyway
Harrison Gardner:
- Subscribe to his newsletter on his website
- Build Your Own: Use what you have to create what you need
- Common Knowledge

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Humor and visuals in technical writing with Dennis Dawson

Kate Mueller — Thu, 30 Oct 2025 01:00:00 -0500

In this episode, I talk with Dennis Dawson, a technical writer with 40 years of experience who creates the sketchnotes for Write the Docs talks. We talk about how humor and visual elements can make documentation more engaging and memorable, the science behind why graphics help information stick in long-term memory, practical tools and techniques for adding visual content to your docs, and why you don't need to consider yourself an artist to create effective illustrations that enhance your documentation.

—

Dennis and I discuss his unconventional path into technical writing, starting with an English degree and progressing through roles as an editor, typist, secretary, and eventually desktop support in the early days of personal computing. His technical writing career began at startups in the 1980s, where he combined training and documentation work. Throughout his 40-year career, Dennis has consistently advocated for using humor and visual elements in documentation.

Our conversation centers on the science behind why visual content and humor make documentation more effective. Dennis shares how reading Richard Mayer's Multimedia Learning and Barbara Oakley's books on learning validated many of his instinctive approaches. We explore concepts like how visual information sticks in long-term memory more easily than text, the importance of reducing cognitive load through strategic use of graphics, and how breaking up text with visuals gives readers' brains time to process information by switching between focused and diffuse modes of thinking. Dennis also discusses when to use graphics and shares examples like using whimsical robot characters to represent different software components.

We dive into the practical side of creating visual content, including Dennis's collaborative approach of sketching ideas and working with design teams to polish them into professional graphics, and tools like Gimp, Inkscape, Keynote, and Google Slides that make visual creation accessible. Dennis emphasizes that you don't need to consider yourself an artist to create effective illustrations—the key is getting over your reticence and recognizing that drawing is a skill developed through practice, not innate talent. We also discuss his approach to creating educational videos, including using Doc Detective to automate video updates when UIs change. Throughout our conversation, Dennis stresses the importance of using visual humor and plain language to help make documentation digestible and accessible.

About Dennis Dawson:

Resources discussed in this episode:

Free tools:
- Doc Detective: Manny Silva’s open source tool for testing and validating documentation
  - Doc Detective tutorials that Dennis created
  - As a reminder, we also did an episode with Manny Silva on Doc Detective S3:E14
- GIMP: free alternative to Adobe Photoshop
- Inkscape: free alternative to Adobe Illustrator
Books:
Dennis Dawson’s sketchnotes:
Write the Docs Portland 2023 talks:

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:

Contact Kate Mueller:

Contact Dennis Dawson:

Email: dennis.s.dawson@gmail.com
Website: dennissdawson.wixsite.com/mr--dawson
LinkedIn
Bluesky

Contact KnowledgeOwl:

Kate sounds off on beliefs and maintenance work

Kate Mueller — Thu, 16 Oct 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Fabrizio Ferri-Benedetti’s interview (S3:E20) and the ways exploring models like his Seven-Action Documentation model have helped me interrogate my own beliefs about tech writing, the benefits of self-knowledge in becoming a better writer, and the ways that maintenance docs work helps me recharge.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that we rolled out in December, and I’m finally nearing the light at the end of the tunnel: my initial punchdown list has less than 50 articles remaining! Along the way, I’ve also had to re-update docs I already updated as we rolled out more changes to existing features–ahhh, the life of a tech writer.

In his interview, Fabri mentioned that part of his motivation for creating the Seven-Action Documentation model was a frustration that people were taking frameworks like Diátaxis and just rote-applying them to their documentation. We discovered some very deep common ground: that models and frameworks are useful because they help you, as a writer, surface and interrogate the deeply-held beliefs you have about technical writing. They’re tools for exploration rather than step-by-step guides on what to do. In my case, engaging with the Seven-Action Documentation model helped me realize how strongly I felt about appraisal and troubleshooting as user needs. While I’m not necessarily crafting new content templates to handle this, my site structure has naturally incorporated them, and I’m now exploring the idea of review checklists or user journeys that might help me assure that I’m handling all the user needs in some way.

I’ve also been sick with Covid, which slowed down my velocity for more strategic, creative work and prompted me to return to a lot of maintenance work. Fabri mentioned that maintenance work helps him recharge, and I found the same thing. I often call maintenance work “productive procrastination”, since it’s not usually the single most important thing, but it is something I can do when my energy or focus are low so that I’m still improving my docs every day. Consider this your invitation to spend the next month paying attention to which writing tasks fill or drain your cup, what kinds of energy those tasks demand, and how you can better manage that moving forward.

Resources discussed in this episode:

KnowledgeOwl Support Knowledge Base

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Growing as a technical writer in the AI era with Fabrizio Ferri-Benedetti

Kate Mueller — Thu, 02 Oct 2025 01:00:00 -0500

In this episode, I talk with Fabrizio Ferri-Benedetti about moving beyond strictly following documentation frameworks to embrace strategic thinking, his Seven-Action Documentation model that prioritizes user needs over content types, and how technical writers can grow and adapt in the AI era while positioning themselves as essential strategic partners.

—

Fabri and I discuss his background as a cognitive psychology student who transitioned into technical writing through his love of computers and writing. He shares his journey from academia to becoming an editor at Softonic, and eventually to his current role as a principal technical writer at Elastic working on OpenTelemetry documentation. We explore his concept of technical writers as shapeshifters who adapt to different roles and contexts.

The conversation centers around Fabri's Seven-Action Documentation model, which he developed as a more descriptive and user-focused alternative to prescriptive documentation frameworks. Unlike content-type-focused approaches, his model identifies seven key user actions that address real user needs that are often overlooked by traditional frameworks. We discuss how this model encourages writers to think strategically about user needs rather than simply following rigid content templates, and why starting with user needs rather than content types leads to more effective documentation.

We also explore professional growth for technical writers, particularly in the AI era. Fabri emphasizes the importance of meaningful skill growth, advocating for work that demonstrates strategic thinking rather than just high-volume output. He shares his philosophy of embracing AI as a tool while maintaining critical evaluation of its limitations, arguing that technical writers must understand emerging technologies to maintain credibility and influence in organizational decisions about documentation and AI implementation.

About Fabrizio Ferri-Benedetti:

Fabrizio Ferri-Benedetti is a technical writer and documentation engineer with over 15 years of experience. Through his blog Passo.uno, he shares insights on documentation strategy, API design, and the evolving role of writers in the tech industry. When not championing better documentation practices or contributing to open source projects like OpenTelemetry, he explores ways to make technology more accessible.

Resources discussed in this episode:

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:

Contact Kate Mueller:

Contact Fabrizio Ferri-Benedetti:

Contact KnowledgeOwl:

Kate sounds off on docs as an act of service

Kate Mueller — Thu, 18 Sep 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Sarah Walker’s interview (S3:E18) and the concepts of Asteya, giving great service, and going the extra mile.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that we rolled out in December. I also created about 30 articles for the launch of KnowledgeOwl’s new Owl Analytics feature, taking my total to 618. 🎉

Sarah’s interview gave me a lot to think about, and I spent the bulk of this episode reflecting on some key points from that conversation. First, I focus on the concept of Asteya she shared, in the context of not stealing time and energy from other people. This concept is so central to well-written documentation and is a compelling argument in favor of clear, consistently applied style guidelines. I coined the phrase “Style guide adherence is an anti-theft device” to summarize this idea. Our conversation reminded me so much that creating great documentation is an act of giving great service. I outline the three-step guide to giving great service that KnowledgeOwl uses, which is based on Zingerman’s Guide to Giving Great Service: 1) Find out what your customer wants; 2) Get it for them accurately, politely, and enthusiastically; 3) Go above and beyond, or go the extra mile.

Step one is often the hardest piece of giving great service since people often don’t know how to articulate what they actually want. At KnowledgeOwl, we use Disney’s “What time is the 3 o’clock parade?” example to show our new support and success owls how what someone asks for isn’t necessarily the question they want answered.

Great documentation helps deliver step two by creating the accurate answers your readers need.

Step three ties very nicely back to statements Sarah and I both made—about the idea of crafting a solid experience for others in our documentation, of distilling what they need and making it as streamlined as possible. This discussion builds on the ideas of craft we’ve previously discussed, the idea of care I discussed in Episode 17, and Sarah’s comments about crafting something FOR others. Sharing knowledge is an inherent piece of our humanity and of building human communities. Documentation isn’t merely transactional—it’s also an act of care, a gift of time and knowledge, and a gift of saved time so people can pursue other interests.

Resources discussed in this episode:

KnowledgeOwl Support Knowledge Base, especially the Owl Analytics documentation
Zingerman’s Guide to Giving Great Service
ZingTrain’s The Art of Giving Great Customer Service
Disney Institute Blog’s How Would You Respond If Asked: ‘What Time Is The 3 O’clock Parade?’
The Disney 3 o’clock parade question: Insights from KnowledgeOwl support team

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Yoga wisdom for technical writers with Sarah Walker

Kate Mueller — Thu, 04 Sep 2025 01:00:00 -0500

In this episode, I talk with Sarah Walker, a technical writer and yoga instructor, about how yoga principles like establishing foundations, respecting people’s time, and embracing practice over perfection can transform your approach to technical writing and help you create more mindful, user-centered documentation.

—

Sarah and I discuss her path into technical writing, which began with yoga instructor training where she discovered how much she enjoyed breaking down complex processes into foundational steps. This experience taught her that effective instruction—whether for yoga poses or technical procedures—requires understanding your audience's needs and building from core principles. We explore how yoga's emphasis on establishing solid foundations directly translates to documentation, where starting with fundamental concepts helps both beginners learn and experienced users refresh their understanding.

We explore the yoga principle of Asteya (non-stealing), particularly how it applies to respecting readers' time and attention. Sarah explains how this philosophy shapes her approach to writing clear, concise documentation that helps users efficiently get to their goals. We discuss practical applications like using consistent style guidelines to reduce cognitive load and being mindful of which content is essential to include in your docs.

Our conversation also covers how yoga's concept of practice over perfection applies to technical writing careers. Sarah shares how documentation evolves alongside products and why embracing this constant change rather than striving for perfect static content leads to better outcomes. We explore the parallels between sequencing yoga poses and sequencing information in documentation, the importance of observing your audience's needs, and how both practices require patience, self-compassion, and continuous learning.

About Sarah Walker:

Resources discussed in this episode:

Garbl’s Writing Center
On Writing: A Memoir of the Craft by Stephen King
Sarah’s Elect a Raccoon Overlord article

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:

Contact Kate Mueller:

Contact Sarah Walker:

Bluesky

Contact KnowledgeOwl:

Kate sounds off on cognitive capital and learning

Kate Mueller — Thu, 21 Aug 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Manny Silva’s interview (S3:E14), Ryan Macklin’s interview (S3:E16), and Liz Argall’s interview (S3:E13) and the importance of learning even when we don't have explicit reasons to do so.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 15 articles since my last episode, taking my total to 565. 🎉This month’s velocity was a lot lower thanks to prepping for, teaching, and attending KnowledgeOwl’s July 2025 Summer Camp workshop series.

While teaching the classes was fun, it also triggered a lot of issues with my chronic illness, so I finished the month quite depleted on every level. This made me think a lot about the ambient and acute stress Ryan and I discussed in relation to empathy advocacy, and about how all documentation makes demands on readers’ cognitive capital. I share five documentation techniques that helped me get use from docs when I was struggling the most cognitively:

Provide a summary, synopsis, TL;DR, or 1-2 context-setting sentences at the start of a doc or each section.
Use strong page titles and headings, avoiding general catch-alls like “Frequently Asked Questions.”
Format your content consistently using semantic elements like sequential headings.
Use callouts, warnings, or admonitions sparingly but in consistent ways.
Practice screenshot restraint.

I also reflect on how tricky it is to actually accommodate learning as a tech writer if I don’t have a pressing need for it. We learn new tools or domains often since it’s required. We learn new tooling or scripting to make our lives easier or because it’s required. We attend classes, conferences, or certifications. But we often don’t take time on less formal, bigger picture learning. I share how doing research to teach a class on style guides led me to find all kinds of flaws and oversights in my existing style guide. I challenge all of us to carve out 2-4 hours in the next month to dig deep on a best practice or concept we want to learn more about. If you lack the time or discipline and have a professional development budget, you can also consider joining me for the Information Architecture Master Class I’m teaching in partnership with KnowledgeOwl in September and October. Use discount code NOTBORING.

Resources discussed in this episode:

KnowledgeOwl Support Knowledge Base
Our upcoming Information Architecture Master Class

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:

Contact Kate Mueller:

Contact KnowledgeOwl:

Empathy advocacy: Designing docs for all emotional states with Ryan Macklin

Kate Mueller — Thu, 07 Aug 2025 01:00:00 -0500

Learn how Ryan Macklin's "empathy advocacy" framework helps you design documentation that works for users in all emotional states (e.g. anxious, frustrated, exhausted, and curious/distractible) rather than assuming everyone comes to your docs in a perfect state of clarity.

—

Ryan and I discuss his unique path into technical writing, starting from his early computer hacking days and role-playing game writing background. Ryan explains how writing and editing tabletop games taught him that documentation is harder than technical writing because it requires creating user interfaces for "disconnected, squishy brains" while making content engaging enough that users won't simply abandon it for alternatives. This experience, combined with his personal journey through therapy and understanding neurodiversity, eventually led him to develop the empathy advocacy framework.

Our conversation centers around Ryan's empathy advocacy concept, which focuses on writing for users who aren’t calm. These users might be in four key cognitive states: anxious, frustrated, exhausted, and curious/distractible. Rather than designing documentation for the "happy path" or optimal users, Ryan advocates for considering people who may be dealing with high ambient stress, acute stress from urgent problems, cognitive depletion, or distractibility. The "stupid users" developers complain about are often just busy, stressed people whose brains aren't optimally processing information.

We explore practical applications of empathy advocacy concepts, including strategic screenshot reduction to minimize cognitive load, restructuring and tightly scoping FAQs to avoid information architecture problems, and understanding that every element in documentation has a "tax" on your user’s mental energy.

The episode also includes practical advice on social capital management, documentation stewardship, and the importance of "failing forward" rather than getting stuck in perfectionism.

About Ryan Macklin:

Ryan splits his cerebral time between tech writing, UXing, coding, and game design. By day, Ryan writes and edits software and hardware requirements. Otherwise, he works on game or tooling projects, light woodworking, and land improvement projects on his homestead in southern Michigan. Warning: Ask him about UX in games, and he may talk your ear off.

Resources discussed in this episode:

empathyadvocacy.org
Ryan Macklin talk: WTD ECQ Nov '22: 7 doc techniques rooted in empathy advocacy
Ryan Macklin talk: How to avoid "toxic tennis" — empathy in user communication
Other technical communication talks by Ryan Macklin

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:

Contact Kate Mueller:

Contact Ryan Macklin:

Ryan's newsletter: buttondown.com/ryanmacklin
macklin.cc
LinkedIn
Bluesky

Contact KnowledgeOwl:

Kate sounds off on “good” documentation

Kate Mueller — Thu, 24 Jul 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Nick Graziade’s interview (S3:E12) and Liz Argall’s interview (S3:E13) and the ways these interviews highlight some elements of "good" docs experiences.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 43 articles since my last episode, taking my total to 550. 🎉 I’m in the middle of updating our Contextual Help Widget documentation—one of the features I’ve been putting off updating—and I’ve been drafting content for our forthcoming AI Chatbot feature, too.

Nick and I share a tech writer villain origin story of absolutely adoring LEGO documentation, and it’s gotten me curious how many other tech writers also have this early exposure to documentation. And for some reason I’m seeing tech writing everywhere. I share a detailed story of Bont Cycling’s online shoe fit guidance, which I recently used and which has created a fairly positive product experience for me. Good documentation experiences can help create good product experiences.

I also reflect on Liz’s comment that “The best fertilizer is the gardener’s shadow.” She talked about this in the context of just showing up to work on docs, but I extend that metaphor to say showing up working with care. I gave two examples of this. I’ve been struggling with some personal losses, so a lot of my docs work lately has been a blitz of low-hanging docs fruit: a lot of small changes and improvements. None of these updates are substantive, but they’re good iterative improvements and they helped me get back into docs work. I also share a story of building a long-procrastinated-on bench for my entryway, which was more about accepting good rather than great just to get something built. Good docs are dynamic and iterative–they may not be perfect at first, but they’re constantly improving and always striving for a better reader experience.

Resources discussed in this episode:

Our new merch store!
KnowledgeOwl Support Knowledge Base, especially the Contextual Help Widget documentation
Bont Cycling Shoe Size Finder (The docs I referenced in the episode are hyperlinked in the Print Sizing Page section.)

Join the discussion by replying on Bluesky

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Contact Kate Mueller:

Contact KnowledgeOwl:

Docs as Tests: Keeping documentation resilient to product changes with Manny Silva

Kate Mueller — Thu, 10 Jul 2025 01:00:00 -0500

In this episode, I'm talking with Manny Silva, a technical writer who created the "Docs as Tests" concept name and the open-source tool Doc Detective. We discuss how to automatically test your documentation for accuracy, why customer reports of broken docs are actually failed tests, and practical ways to implement automated documentation testing regardless of your tech stack.

—

Manny and I discuss his background as someone who intentionally chose technical writing as a career path, starting with early exposure to computers through his mother's work and developing into roles at Apple, Google, and now Skyflow as Head of Documentation. We explore the core concept behind Docs as Tests—that documentation contains testable assertions about how a product should work, and that customer reports of broken procedures are essentially failed tests that we should catch proactively rather than reactively.

We dive deep into how Manny's strategy works in practice, from the "cupcake to wedding cake" approach of starting small and scaling up. We dig into two different approaches to the technical implementation: creating “detected” tests using Doc Detective, which reads the docs directly and uses them as tests, and creating standalone tests in testing tools like Playwright or Cypress, which you’d create and update independently of the docs. Manny explains how his Doc Detective tool can parse markdown documentation, automatically execute the steps described in procedures, capture screenshots for visual regression testing, and even validate API responses against OpenAPI schemas. We discuss the business case for automated documentation testing, including how it prevents customer frustration, builds trust, reduces support overhead, and can catch bugs before they reach production.

Throughout our conversation, we explore practical implementation strategies, including how to sell the approach to stakeholders, integrate testing into CI/CD pipelines, handle multifactor authentication challenges, and work with QA teams. Manny also shares his philosophy of creating a "zero trust" relationship between docs and product—not out of disrespect, but to ensure everyone stays honest about the behavioral contract that documentation represents. Docs as Tests also encourages technical writers to embrace their unofficial QA role–as writers, we’re often the first to test a new feature or product, and embracing a Docs as Tests mindset can help legitimize and make visible this role.

About Manny Silva:

Technical writer by day, engineer by night, and father everywhere in between, Manny wears many (figurative) hats. He's passionate about intuitive and scalable developer experiences, and he likes diving into the deep end as the 0th user.

Here are a few things that keep him busy:

Head of Docs at Skyflow, a data privacy vault company.
Codifier of Docs as Tests, a tool-agnostic strategy for keeping docs and their products in sync by using doc content as product tests.
Creator and maintainer of Doc Detective, an open-source doc testing framework.
AI development and experimentation.

He's always looking for collaborators on projects, and he loves chatting with folks, so don't hesitate to reach out.

Resources discussed in this episode:

Docs as Tests: A Strategy for Resilient Technical Documentation - Manny's book
Docs as Tests blog - Manny's blog about the strategy and various tools
Doc Detective - Manny's open source tool for testing and validating documentation
Doc Detective GitHub action - Official GitHub action for CI/CD integration
Doc Detective Discord server - Public community for users implementing Docs as Tests
Good to Great book series - Business development books that Manny recommends
Framework laptop - Repairable laptop that Manny built with his children
Vale - Style guide enforcement tool (mentioned as complementary to Docs as Tests)
Playwright - Engineering-level testing tool used by some companies like Docker
Cypress - Another engineering-level testing tool
Ben Perlmutter - Unit Test the Docs: Why You Should Test Your Code Examples - A Write the Docs Portland 2022 talk about MongoDB's unit testing documentation approach
Arazzo specification - Newer OpenAPI initiative specification for workflow testing

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Manny Silva:

Contact KnowledgeOwl:

Connecting permaculture and documentation with Liz Argall

Kate Mueller — Thu, 26 Jun 2025 01:00:00 -0500

In this episode, I’m talking with Liz Argall, a writer I connected with at Write the Docs Portland 2025. We talk about working on open source projects, developing good qualitative metrics, her work with a permaculture nonprofit in Uganda, and the ways that being interviewed by a technical writer can make hidden expertise shine.

—

Liz and I presented in the same Lightning Talk session at Write the Docs Portland 2025 and subsequently discovered a shared love for spreadsheet tools, qualitative metrics, and permaculture. We discuss her work on Project Aria, a combination of hardware, software, and data collection geared toward solving the problems that augmented reality will need to address. Liz stresses the point of writing for poorly informed and/or sleep-deprived audiences. We also discuss the importance of qualitative metrics and some of Liz’s favorite qualitative metrics that help capture the story of the documentation, including impact and saving engineers’ and SMEs’ time.

Liz also tells us about her involvement with Ngombor Community Development Alliance, a non-profit focusing on permaculture development in the West Nile region of Uganda. We also discuss how sometimes just showing up for something–including showing up to work on your docs–has far more impact than we realize.

About Liz Argall:

Liz Argall creates empowering documentation and processes; where you need it, when you need it.

Resources discussed in this episode:

Project Aria
Fabrizio Ferri Benedetti’s Why I became a Documentation Engineer (and what that even means): The source for the phrase “technical therapist”
Write the Docs Portland 2025, Lightning Talk session 1
Liz's portfolio site
Introduction to search term analysis: Liz’s blog post about the Lightning Talk she gave, which includes links and instructions for her spreadsheet
Attend to the work: A blog post by Liz where she alks about permaculture and Diataxis in the context of technical writing
Diátaxis as a guide to work
Lucy Mitchell's website
Ubuntu Summit 2024 | Open source software between Africa and the West: The YouTube presentation that inspired Liz to get in touch with Vince
Ngombor Community Development Alliance: a non-profit focusing on permaculture development in the West Nile region of Uganda
Ngombor Community Development Alliance's sponsor a tree (or chicken) page

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Liz Argall:

Liz's website: includes her blog, which has several awesome spreadsheet matrices you can copy and use for yourself
LinkedIn
Bluesky

Contact KnowledgeOwl:

Documentation as a creative endeavor with Nick Graziade

Kate Mueller — Thu, 12 Jun 2025 01:00:00 -0500

In this episode, I'm talking with Nick Graziade, a technical writer and musician who approaches documentation as a creative endeavor. We explore how his early fascination with Lego instructions and synthesizer manuals shaped his philosophy that technical writing doesn't have to be dry or boring, but can be passionate and innovative work that adapts to different audiences and embraces impermanence.

—

Nick shares his two-part "villain origin story" that led him to technical writing. The first part involves his childhood fascination with Lego instructions, which taught him that visual documentation could guide complex building without narration. The second part comes from his music school experience with synthesizers, where he discovered that the best manuals—like those from Moog—don't just explain how to do something, but also why. This combination of visual clarity and deeper understanding became his template for approaching technical documentation.

We dive deep into the concept of using different "grammars" for different audiences, drawing from Wittgenstein's language games. Nick emphasizes that effective technical communication requires understanding what assumptions you can make about your readers and adapting your language accordingly. We explore how consistency in style and formatting reduces cognitive load for users, and how deliberately breaking those patterns can create powerful contrast for important information like warnings or alerts.

Throughout our conversation, Nick reflects on his philosophy of embracing impermanence in documentation. Rather than being frustrated by constant updates and revisions, he sees the evolving nature of technical writing as aligned with his Buddhist-influenced worldview. We discuss practical approaches to managing documentation workflows, including his use of quarterly revision cycles, just-in-time updates based on development sprints, and how he determines when something is "done enough" to move on to the next priority.

About Nick Graziade:

Nick is a Senior Technical Writer, instructional designer, knowledge management expert, musician, and philosopher from Upstate New York's Capital District.

When not obsessing over the nuances of a web page's navigation sidebar, you can likely find him playing gigs as a professional bassist or practicing Japanese sword arts.

Resources discussed in this episode:

Moog Music user manuals: https://www.moogmusic.com/downloads/

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Nick Graziade:

nicholas.graziade@gmail.com

Contact KnowledgeOwl:

Kate sounds off on Write the Docs

Kate Mueller — Thu, 29 May 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Sue Brandt’s interview (S3:E10) and on the Write the Docs Portland 2025 conference.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 50 articles since my last episode, taking my total to 507. 🎉Most of the updates this month were in our payment and plan-related documents, which needed to be updated for a new Billing page user interface and to include changes from migrating to a Merchant of Record.

My velocity this month was lower thanks to teaching KnowledgeOwl’s Authoring 101 class and attending the Write the Docs Portland 2025 conference with Chad. Write the Docs is always a deeply inspiring conference for me, and this was my first time attending in person since 2019. This year, I even gave a lightning talk about dogs and docs, too!

Much of the episode is spent reflecting on the six things I most love about Write the Docs, which include its support for first-time attendees and presenters, the flexibility and thoughtfulness of its design, and the amazing community of documentarians who form the backbone of this community. This year’s conference had a fantastic selection of talks and speakers, including several previous and upcoming podcast guests.

Resources discussed in this episode:

KnowledgeOwl Support KB: the Payments & subscriptions and Plans & pricing categories
Write the Docs Portland 2025 conference
Kate’s Of docs and dogs lightning talk
Full playlist of recorded talks from Write the Docs Portland 2025

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact KnowledgeOwl:

How to get hired as a tech writer with Sue Brandt

Kate Mueller — Thu, 15 May 2025 01:00:00 -0500

In this episode, I’m talking with Sue Brandt, a former Director of Documentation who’d hired around 60 people when we recorded the episode. We discuss practical strategies for technical writing job applications, what hiring managers are really looking for in resumes and interviews, and how to stand out in today’s competitive job market.

—

Sue and I discuss various aspects of the tech writing job application process, including resumes, cover letters, and interviews. Sue, who has hired around 60 people throughout her career, emphasizes that enthusiasm is often a key differentiator for candidates.

Throughout the episode, Sue shares practical tips based on her experience managing tech writing teams of up to 30 people, including ways to stand out as an applicant, how to handle situations where you may not have the exact technical skills in a job description but can demonstrate transferable skills and a willingness to learn, resume and portfolio best practices, how to honestly address gaps in employment, and more. The episode concludes with a discussion of career transitions and the importance of being open to learning new things.

About Sue Brandt

Sue was educated as a biologist, did postdoc research into marine microorganisms, and named 13 new species! She moved a little closer to the tech field when she worked with computer scientists on a bioinformatics project and found herself in the role of "translator" between computer scientists and biologists. Her tech writing career unofficially started when someone looked over her shoulder when she was job searching and said "You could do that.” Sue worked as a Technical Writer at a UK startup for 3 years, then moved to Denmark and worked at Microsoft for 13 years as a Programming Writer and then Developer Documentation Manager. She was always adamant that she didn't want to be a manager, but she was persuaded to try it and found out she loved it! She became Director of Documentation at Sitecore and managed 30 writers, editors, and developers working on 10 different products in 6 countries.

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Sue Brandt:

Contact KnowledgeOwl:

Kate sounds off on knowledge sharing and docs stewardship

Kate Mueller — Thu, 01 May 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress. I also reflect on Marcia Riefer Johnston’s interview (S3:E8) and on the idea of docs stewardship as opposed to docs ownership.

—

I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes that were rolled out in December. I updated an additional 91 articles since my last episode, taking my total to 457. 🎉 I also reorganized another three Features subcategories, taking me to the milestone of having updated half those categories using content type-inspired information architecture. I also relocated 12 mice from my basement.

Marcia’s episode prompted a lot of reflection for me. Her infectious, unbridled enthusiasm for this work—from learning new tools to new domains— reminded me of all the reasons I love the craft of technical writing, and how thankful I am that for the last year I’ve largely “only” been doing technical writing. I also appreciated Marcia’s exhortations to share what you know because you never know what great things will come from sharing your knowledge. Too often, we don’t share what we know because we don’t think we know “enough” (whatever that is). But sharing knowledge is a gift to others.

Thanks to a conversation with a friend, I’ve started to come around to the idea of docs stewardship rather than docs ownership. “Stewardship” comes from the Old English words for house and guard. Stewards originally managed estates for medieval lords. I extend this into the world of documentation (doesn’t “Guardian of the Docs” sound like an awesome way to describe what we do? Maybe a swag idea, too, non?). Most modern definitions of stewardship include the idea of “careful and responsible management of something entrusted to one’s care” (source), though they may also add sustainability, ethical use, or “a duty to protect and maintain assets which might be natural, financial, or informational” (source). Marcia’s observation that a lot of a tech writer’s job involves project and process management aligns with this approach, I believe. I explore some other ways I like this docs stewardship model and then draw a comparison between tech writers and gardeners.

Resources discussed in this episode:

KnowledgeOwl Support KB, Features category
Merriam Webster’s definition of stewardship
meaningdictionary.com’s explanation of Steward
Chris Drew’s 25 Stewardship Examples
TNBTW Episode 8

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact KnowledgeOwl:

The craft of technical writing with Marcia Riefer Johnston

Kate Mueller — Thu, 17 Apr 2025 12:25:00 -0500

In this episode, I’m talking with Marcia Riefer Johnston, a technical writer who’s worked in our industry for 40 years. We talk about how the profession has evolved since she first started in it, the grammar patterns that have helped her tighten up her writing, and how “creative” writing and “technical” writing are just different expressions of the craft of writing.

—

Marcia and I discuss how tech writing has evolved in the last 40 years as the tooling and field have evolved—from literally cutting and taping printed instructions together to using sophisticated content management systems and modular content. She shares the user feedback from her first set of technical instructions for using a remote control set-top box at Magnavox, highlighting how important user feedback is to help determine what needs to be documented.

Throughout our conversation, we explore practical grammar techniques that have helped both Marcia and me strengthen our writing, such as restructuring sentences to center the reader rather than the tool. We also discuss how adding “by zombies” is a great way to suss out if you’re using passive voice (e.g. “This podcast is being listened to by zombies.”) and the strengths and weaknesses of the be verbs (am, is, are, was, were, be, being, etc.).

We also talk about the value of sharing what you know, and how putting that knowledge out into the world can reap unexpected benefits. And we talk about the fact that the division between “creative ”writing and “technical” writing feels like a false binary: all acts of language are creative, and technical writing shares a lot of overlap with forms like poetry.

We close by discussing how technical writers manage feedback from reviewers and explore how a significant percentage of technical writing involves project management skills such as managing conversations and helping everyone align on what the documentation should do.

For both of us, handling contradictory feedback from reviewers usually involves having a larger conversation about what the problems or issues were, rather than only focusing on solutions. We theorize that part of the value tech writers bring is our ability to identify less-than-desirable user experiences and to not just take suggested edits as gospel but to question and explore the need for those edits.

About Marcia Riefer Johnston

Marcia’s loved tech writing from the time she first heard the words technical and writer together. These days she brings technical and writer together as a consultant for Baxter International. In 2013, she fulfilled a dream by writing her book Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them). Two years later, her pocket-sized collection came out: You Can Say That Again: 750 Redundant Phrases to Think Twice About. Occasionally she posts on her own blog at Writing.Rocks. She lives in Portland, Oregon, where she makes things with scrumptious yarn, does New York Times crossword puzzles with her husband (especially the Thursday and Sunday puzzles), and lures in family and friends to play Wingspan and other games.

Resources discussed in this episode:

How to put the customer first in your sentences - Marcia’s blog post for KnowledgeOwl
Writing.Rocks - Marcia’s website
- To Be or Not To Be — First chapter of Marcia’s book, Word Up!
- Be and Me — Why writers want to watch for be-verbs. Bonus: the be-verb song.
Single Sourcing: Building Modular Documentation by Kurt Ament
Read Me First! A Style Guide for the Computer Industry by Sun Microsystems, Inc.
Garner’s Modern English Usage by Bryan Garner
The LavaCon conference on Content Strategy and Content Operations
Buy the Books - Links to Marcia’s books (You Can Say That Again: 750 Redundant Phrases to Think Twice About and Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them) and how to buy them
Resources for Writers - A more complete list of Marcia’s recommendations than we could discuss in the episode.

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Marcia Riefer Johnston:

Contact KnowledgeOwl:

Kate sounds off on mice and iterating

Kate Mueller — Thu, 03 Apr 2025 01:00:00 -0500

In this solo episode, I share an update on my content update progress, muse about the similarities between mice infestations and docs projects, and reflect more on Kenzie Woodbridge’s interview (S3:E6) and how we choose what we work on.

—

Since Episode 5, I’ve continued my work to update the KnowledgeOwl Support Knowledge Base to align with major navigation and UI changes from December. I’ve now updated roughly 400 pages and reorganized a total of five Features subcategories (one more since Episode 5).

Most of note this month: I overhauled our Search documentation. This work was necessary due to new search settings and major changes to the search configuration pages. It was also the first feature documentation I wrote at KnowledgeOwl in 2018, and I’ve mostly tried to make minor tweaks to it instead of massively updating it. Thanks to some very positive feedback on the content type-inspired reorganization I’ve been doing elsewhere, I was able to make some much better content organization and substance changes.

I’m also battling a mouse infestation in my rented house, and I spent some time in this episode comparing that process to working on documentation projects.

This leads me into ruminating on the ways we can try to make the world a better, more inclusive place. I’ve been including a lot of Kenzie’s suggestions in my style guide content updates in this audit:

Use actual headings. (Not usually a problem in our docs, but a good review item anyway!)
Use sequential headings and make sure no levels are skipped. (This one does occasionally slip in, especially in older docs, so it’s been good to review.)
Use link text that has more meaning than "See more" or "Click here". (Again, not a steady thing, but a good review item.)
Add alt text to images. (Doing a lot of this!)

I like the idea that, as content creators, content accessibility is well within our area even if we don’t feel qualified as experts in it. These accessibility areas are also solid best practices for content, information scent, wayfinding, and search engine optimization. I encourage you to try these or other small, iterative improvements that will make your docs a better place to be in the next month.

Resources discussed in this episode:

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact KnowledgeOwl:

KnowledgeOwl.com

We’re all responsible for content accessibility with Kenzie Woodbridge

Kate Mueller — Thu, 20 Mar 2025 01:00:00 -0500

In this episode, I’m talking with Kenzie Woodbridge, a documentarian and self-taught accessibility advocate. We talk about how feeling “not expert enough” is no reason to skip content accessibility, four ways you can make your content more accessible right now, and ways you can serve as an accessibility advocate as you review content and work with contributors.

—

Kenzie and I discuss why content accessibility is something we all need to think about as we create content. You don’t have to be an expert to improve your content’s accessibility. We discuss four areas you can focus on right now:

Use actual headings (h1, h2, etc.)
Use sequential and hierarchical headings (for example, don’t skip straight from h1 to h3)
Use link text that’s actually descriptive, rather than “Click here” or “See more”
Add alt text

We also discuss some dos and don’ts with alt text, providing feedback to content contributors who aren’t following accessibility guidelines, tools or processes to help identify accessibility bugaboos in your content, and so much more. Check out the resource list below to sponge a ton of useful resources from Kenzie, too.

About Kenzie Woodbridge

Kenzie works at the British Columbia Institute of Technology (BCIT) in British Columbia, Canada, as a Tech Writer, Trainer, and Knowledge Strategist, and is currently a co-chair of BCIT's Accessibility Committee. They have spoken about documentation and other topics at multiple technical conferences, including Write the Docs (their favourite). Kenzie is also a parent, a tuba player, chronically ill, a crafting dilettante, a gamer, and all around nerd who wrote their Master's thesis about prosocial community in multiplayer Minecraft.

Kenzie is awesome and you totally want to have them as your friend (offer of friendship void where local laws do not permit, not guaranteed in all circumstances, skill-testing questions required).

Resources discussed in this episode:

Screen Reader Demo - The video Kenzie mentioned by Marc Sutton at U of C
Digital Accessibility Toolkit from the Government of Canada
What is Accessibility? (MDN docs)
Digital Collegium (formerly HighEdWeb) Accessibility Summit 2025
Sa11y & Editoria11y: Straightforward content accessibility at scale - The conference talk Kenzie mentioned comparing two tools for promoting and checking accessibility within content management systems:
- Sa11y Accessibility Quality Assurance Assistant - One of the two tools discussed in the talk, available for Joomla, WordPress, or as a bookmarklet in your browser
- Editoria11y Accessibility Checker - The second tool, available for Drupal, WordPress, and Squarespace
WAVE Web Accessibility Evaluation Tools - The WAVE browser extension is Kenzie’s go-to tool for a first pass on accessibility questions. It gives a lot of complex info, which can be overwhelming, but a) if you're seeing a lot of actual errors and contrast errors, you don't have to understand all of those errors to know that there's likely a problem, and knowing there's a problem is the first step 😉, and b) the "Structure" tool quickly shows you a list of the headings on the page and makes it easy to spot skipped levels, etc.
Pericles screen reader - Not as fully featured as JAWS or NVDA, but useful for quick checks in your browser (Chrome, Edge, Firefox)
NVDA screen reader - Downloadable for free, because accessibility really means something to them, but if you're able to donate, please do
JAWS screen reader
BCIT's Knowledge Base - About Web Content Accessibility

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact Kenzie Woodbridge:

Contact KnowledgeOwl:

KnowledgeOwl.com

Kate sounds off on docs hierarchy of needs and how we talk to ourselves

Kate Mueller — Thu, 06 Mar 2025 01:00:00 -0600

In this solo episode, I share an update on working with content types, muse about the idea of a Documentation Hierarchy of Needs, and reflect more on Janine Chan's interview (S3:E4) and how we talk to ourselves about being tech writers.

—

I may have overcommitted myself in Episode 3. I have been incorporating content type work into my massive content audit, but after working on four of the nineteen Features subcategories, I realized it was taking too much time and I had to refocus on my main task of updating content to match our UI and navigation releases. However, I like the information architecture decisions this has helped me make and the clarity it’s bringing to the docs themselves and how I organize them, so it’s a project I intend to continue.

Making these kinds of priority decisions is something we all have to tackle all the time. But the content type work got me thinking: I’ve used an intuitive content type sense for a long time. I suspect I’m also using an intuitive decision-making framework for prioritizing my docs work. What would an explicit framework for that look like? In talking this over with a colleague, I realized I wanted a Documentation Hierarchy of Needs. I discovered that MongoDB created exactly this for their documentation overhaul once upon a time and wrote this blog post about it. I briefly run through their Hierarchy of Needs and how my decision to temporarily deprioritize content types might fit within it.

I also reflect more on Janine Chan’s episode (S3:E4) and her point about reframing the way we talk to ourselves from “I’m not technical enough” to “I don’t know how to do this… yet.” And I share my own suggestion for handling that narrative problem.

Resources discussed in this episode:

KnowledgeOwl Support KB, Features category
MongoDB blog post: Applying Maslow’s Hierarchy of Needs to Documentation
TNBTW Episode 3 and Episode 4

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Join the discussion by replying on Bluesky

Contact Kate Mueller:

Contact KnowledgeOwl:

KnowledgeOwl.com

Bridging the gap from “not technical enough” to “technical” with Janine Chan

Kate Mueller — Thu, 20 Feb 2025 01:00:00 -0600

In this episode, I’m talking with Janine Chan, a technical writer and Write the Docs community moderator. We talk about how feeling “not technical enough” is as much about attitude and approach as it is about knowledge and ways you can bridge the gap to a more technical future.

—

Janine and I discuss the fact that there’s no defined/established set of skills or training to become a technical writer. This lovely flexibility can also lead to a lot of imposter syndrome or feeling like you’re “not technical enough.” But through continuous lifelong learning, changing your attitude or the story you tell yourself, asking for help, and letting go of perfectionism, you can transition to a more empowered, technical version of yourself.

Along the way we discuss the wonders of indoor plumbing, the fact that growing up to a be a tech writer isn’t typically on kids’ radar, our tendency to get curious when we’re frustrated about something, the importance of trying to answer a question before you seek help, how to be generous in requesting help, how generally awesome and generous with knowledge people are, how the experience of knowing little makes us more empathetic writers, and so so much more.

About Janine Chan

Janine is a technical writer based in Calgary, Canada. When she's not writing software documentation or shoehorning sociolinguistics into conversations, she's usually either outside, or hunkered down trying to make room in her lap for both a knitting project and her cat. (She recognizes that "not-boring" is a relative term.) You can find her on LinkedIn and the Write the Docs Slack, where her inboxes are always open for more tech writing chats! She promises she won't write in third person like she is now.

Resources discussed in this episode:

Write the Docs

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Contact Kate Mueller:

Contact Janine:

Contact KnowledgeOwl:

KnowledgeOwl.com

Join the discussion by replying on Bluesky

Kate sounds off on content types

Kate Mueller — Thu, 06 Feb 2025 01:00:00 -0600

In this solo episode, I share what I'm currently working on, reflect a little on teaching my first Knowledge Management Master Class with KnowledgeOwl, and dig into why and how I'm going to start using content types.

—

My current in-flight projects include updating nearly all of our documentation to reflect major changes to our user interface, which includes changes to screenshots, navigation options, and section/subsection labels. I’m also working on my long slog to convert all our screenshots from .png to .webp format. As I make all of those updates, I’m bringing our content into line with our current style guide (the first time I’ve used an explicit style guide in the KnowledgeOwl Support Knowledge Base).

I recently finished teaching my first Knowledge Management Master Class with KnowledgeOwl. This was mostly a success, though it was a sharp learning curve for me and I’m already full of ideas on what to do differently next time. It also humbled me since it made me view my own docs through the lens of all the best practices I was suggesting people employ–and realizing how often my docs fell short.

For me, the most fascinating takeaway was really digging into the concept of concept types or information typing. I’ve never done this as an explicit, intentional exercise. After researching various approaches, I’m sold on the underlying concept. My plan is to create some templates for each major content type, using The Good Docs Project’s templates as a starting point). I’m then going to use those templates as I update content in our Features category to test and refine the templates before gradually applying them to the entire knowledge base. I’ll be using tags to track my progress and identify the content type for each page, too. In Episode 5, I’ll report back on how I’m doing in my endeavors!

Resources discussed in this episode:

KnowledgeOwl Support KB
Diátaxis content types for software documentation
Dave Gash’s A Painless Introduction to Information Typing, which is a pretty solid introduction to Information Typing as it’s used in DITA and other frameworks
The Good Docs Project
Wisdom Wednesday on Use tags + Manage filters for fast docs updates/audits: Kate’s quick walkthrough on how she uses tags and Manage filters in KnowledgeOwl for content audits and updates

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Contact Kate Mueller:

Contact KnowledgeOwl:

KnowledgeOwl.com

Developer collaboration with Lorna Mitchell

Kate Mueller — Thu, 23 Jan 2025 03:00:00 -0600

In this episode, I’m talking with Lorna Mitchell, a technology leader, published author, tech blogger, and developer experience expert who is passionate about APIs and developer tools. We talk about why developers writing docs is good for both your devs and your docs, the best ways to build successful collaboration with developers, and more!

—

Lorna and I discuss her background as a developer who started doing documentation for her own resources and gradually moved into developer relations, developer advocacy, and developer experience. We chat about the wide range of writing she’s tackled–including books, readmes, and her blog–and why developers need to write to improve their skills.

We also discuss strategies tech writers can use to facilitate good collaboration with developers, including treating their role more as editors rather than writers; having a clearly-defined process with discrete, well-scoped requests for contributions; creating content type templates to streamline contributions; and having a second, shorter style guide for developers.

About Lorna Mitchell:

Lorna is based in Yorkshire, UK; she is a technology leader and developer experience expert who is passionate about APIs and developer tools. She is also a published author and regular blogger, sharing her insights on a variety of tech-related topics. Lorna serves on the OpenUK board, is on the Technical Steering Committee for OpenAPI specification, and maintains open source projects.

Resources discussed in this episode:

Lorna’s developer style guide
Diátaxis for content types
Write the Docs’ Docs as Code resources
Tanya Reilly’s Being Glue

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Contact Kate Mueller:

Contact Lorna Mitchell:

Contact KnowledgeOwl:

KnowledgeOwl.com

Introducing The Not-Boring Tech Writer Reboot

Kate Mueller — Thu, 09 Jan 2025 03:00:00 -0600

Meet our new host Kate Mueller and get the inside scoop on how The Not-Boring Tech Writer (TNBTW) will work moving forward.

—

Kate Mueller is the Documentation Goddess of KnowledgeOwl, a seasoned technical writer and owner of knowledgewithsass, a knowledge management coaching service. She’s written and maintained documentation for companies in broadcasting, financial services, IT, and software for 15+ years. She’ll be hosting TNBTW moving forward.

In this episode, Kate discusses her vision for TNBTW: a podcast dedicated to everyone who is writing technical documentation, 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—the TNBTW reboot might be your new favorite podcast. Kate talks about her own imposter syndrome using the tech writer label and recounts her tech writer villain origin story.

We plan to release two episodes per month: one episode will maintain the traditional TNBTW format of interviewing a guest and focusing on useful skills or tools that can help you improve your tech writing skills; the other episode will be a behind-the-scenes look into what Kate’s working on, struggling with, or thinking about in her daily tech writing life.

—

Contact The Not-Boring Tech Writer team:

We love hearing your ideas for episode topics, guests, or general feedback:

Contact Kate Mueller:

Contact KnowledgeOwl:

Tech Writer Advocacy and Managing Write the Docs with Swapnil Ogale

Jerrard Doran — Mon, 14 Jun 2021 00:59:20 -0500

In this episode I’m talking to Swapnil Ogale, a Technical Writer Advocate for Redocly based in Melbourne, Australia, who is also a Community and Conference Manager for Write the Docs. He gives us the inside scoop on arranging Write the Docs events conferences both in-person and online, and talks to us about the importance of advocacy for technical writers.

The Not-Boring Tech Writer - feedback survey

Twitter - Swapnil Ogale

LinkedIn - Swapnil Ogale

Write the Docs

Documentarians for Diplomacy: Bringing the Mirth with Kat Stoica Ostenfeld

Jerrard Doran — Fri, 07 May 2021 00:13:10 -0500

We’re back after a short and unexpected break! Sorry to keep you waiting!

This episode you’ll hear Kat Stoica Ostenfeld, an accomplished tech writer living in Copenhagen in Denmark. A linguist by credential, she says diplomacy is the key to being an effective documentarian, and shares how her translation and applied linguistics background helped her find common understanding and success in the world of technical writing.

Additional topics: Beautiful limestone buildings; puppy chat; spouse sacrifices; documentation as its own pillar; language proficiency vs successful communication; the meaning of “documentation”; linguistics applied; the diplomacy of being a tech writer; full stack teams; writing rage; linguistic detective work.

The Not-Boring Tech Writer - feedback survey

Twitter - Kat Stoica Ostenfeld

LinkedIn - Kat Stoica Ostenfeld

Medium - Kat Stoica Ostenfeld

Write the Docs

Tekom

Kat's talk from WTD Sweden 2020

Marrying skillsets and existential googling with Caity Cronkhite

Jerrard Doran — Thu, 18 Mar 2021 22:41:36 -0500

In this episode, I’m excited to be speaking to Caity Cronkhite, Seattle-based founder and CEO of Good Words LLC.

We talk about her experience of starting up as a tech writer both in-house and freelancing, before starting and growing her own successful business in the technical writing industry, and the successes and struggles of operating Good Words LLC in these strange and unpredictable pandemic times.

Additional topics: U-Haul montage; Something Big and Impactful; (not) going the way of the startup; nurturing your network; adult, painstaking colouring.

Read the full transcript for this episode here.

Show notes:

How to Infiltrate a Hackathon in Iowa with Philip Kiely

Jerrard Doran — Mon, 15 Feb 2021 22:15:22 -0600

In such a complex and fast-moving industry as tech writing, it can be interesting to see how burgeoning tech writers get started - and become successful.

Enter Philip Kiely, author of Writing for Software Developers and owner of PK&C, the world's smallest conglomerate. He graduated from Grinnell College in May 2020 with a degree in computer science, and has only gone onwards and upwards from there!

This week I speak to Philip about being a new(-ish) entrant to the tech writing game, becoming a first-time author of a successful book, adventures during his time studying abroad in Budapest, Hungary, and how he managed to infiltrate a hackathon in Iowa during a blizzard!

Read the full transcript for this episode.

Show notes:

A Fond Farewell (Yet Warm Welcome!)

Jacob Moses — Sun, 03 Jan 2021 15:09:24 -0600

After four exciting years hosting The Not-Boring Tech Writer—the podcast that gives listeners the skills to break the stereotype that technical writing is a boring career—I’ve passed the podcast along to longtime sponsor KnowledgeOwl, a knowledge base software company.

This sobers me, admittedly: What began as a medium to connect with colleagues whom I’ve admired since university gradually become a resource for new and seasoned technical writers alike to learn the skills they need to break the stereotype that technical writing a boring career.

Now, as I begin a new career, KnowledgeOwl—who, as you’ll learn in this episode, has a relentless commitment to supporting the technical writing—will ensure the philosophy you’ve impressively fostered through this podcast continues.

In this episode, Chief Executive Owl at KnowledgeOwl Marybeth, joins the podcast to share her vision for the podcast. In addition, upcoming host and KnowledgeOwl employee Jerrard Doran joins to share how he’ll further the philosophy while adding his own unique approach.

Thanks, all, for your support of The Not-Boring Tech Writer—and hope you enjoy this episode.

Read the full transcript of this episode.

Skill #36: Creating Usability Tests for Your Organization

Jacob Moses — Mon, 02 Nov 2020 18:52:28 -0600

Technical writers must ensure their help resources, such as documentation and video tutorials, are useful for their users. Therefore, they study language, design, and Support tickets—gathering all the context they need to ensure users can accomplish their task.

But get this: Through feedback loops such as quizzes and interviews with subject matter experts, you can create usability tests that transform the way in which you measure the effectiveness of your documentation.

That’s why in this episode, we have Mariana Moreira on the podcast: Technical Writer at Zup Innovation and Community Manager of Brazil’s budding technical comm community, Tech Writing BR.

Joining us, as well is Jerrard Doran at KnowledgeOwl—longtime sponsor of The Not-Boring Tech Writer—to discuss usability tests from a knowledge base software company’s perspective, as well.

In this episode, you’ll learn everything you need to know to begin creating usability tests for your organization.

Show notes:

Skill #35: Understanding Basic Design Principles

Jacob Moses — Tue, 29 Sep 2020 19:18:41 -0500

Technical communicators wield the power of plain language to ensure their readers find and understand the information they need to complete a task—no matter how complex.

Basic design principles, such as alignment, contrast, and other principles you’ll learn in this episode, give your documentation that extra lift it needs to engage readers throughout your documentation.

That’s why in this episode, we have Laci Kettavong on the podcast: Marketing and Member Coordinator at Stoke, a coworking space based in Denton, Texas—and also a former technical communicator in both industry and academia, deploying design principles for several different mediums.

Joining us, as well is Jerrard Dorran at KnowledgeOwl—longtime sponsor of The Not-Boring Tech Writer—to discuss design principles from a knowledge base software company’s perspective, as well.

In this episode, you’ll learn everything you need to know to begin using basic design principles in your documentation.

Show notes:

Skill #34: Crowdsourcing Technical Communication

Jerrard Doran — Thu, 27 Feb 2020 08:00:00 -0600

Folk working in technical communication—whether they’re academics or practitioners—through their own unique skill sets, perspectives, and experiences, often discover best practices to excel at their job. These hard-earned insights would likely benefit others facing similar challenges; however, silos often keep folk in technical communication from quickly disseminating what they’ve learned.

That’s why Dr. Chris Lam—technical communication professor at the University of North Texas—created CrowdsourceTPC: a crowdsource platform that gives folk in technical communication and opportunity to share their insights and little wins—giving others an opportunity to use and adapt them for their own needs.

In this episode, Chris joins us on the podcast to discuss the inspiration behind CrowdsourceTPC and how others can make the most of the platform.

Show notes:

Skill #33: Getting Started with Open Data

Jerrard Doran — Mon, 10 Feb 2020 08:00:00 -0600

For the civically-mind technical writer, there’s a growing movement in cities across the world where technical writers can use their skills to better their community. It’s called Open Data Day: an annual celebration of open data groups around the world partnering with local governments to use open data to achieve a shared goal in the community.

From analyzing environment data to tracking public money flows, open data day gives citizens—from data folk to advocates—an opportunity to get the data they need to take action in their communities.

As a tech writer, you may not initially see how your skills fit into open data. However, as you’ll learn in this episode, success open data day’s need compelling narratives to complement outcomes, tutorials to teach people how to access the data for their own uses, and much more—all areas in which the tech writer succeeds.

That’s why, in this episode, I have Jesse Hamner and two-time guest on the podcast—longtime open data advocates who’ve seen first-hand the value of the tech writer.

In this episode, Jesse and Kyle help us understand the value of open data and how the civically-minded technical writer can get plugged into this exciting movement.

Show notes:

Skill #32: Understanding Translation and Localization

Jerrard Doran — Sun, 26 Jan 2020 14:38:31 -0600

As products and services reach markets outside of their geographic origins, organizations must consider how to translate and localize their existing documentation. It’s a must, as these new users will need to refer to a knowledge base.

But how exactly do organizations translate their documentation? Do they copy and paste all of their content into Google Translate? Do they hire technical writers who speak and write the language of the new market?

As you’ll learn in this episode, successful organizations partner with translation and localization vendors, who ensure users in new markets understand the content.

To help us dig deep into this skill, we have Mike McDermott on the podcast: Director of Language Translations at MadTranslations, a translation service created by MadCap software. For nearly eight years, Mike has helped clients translate their content into several different languages.

In this episode, Mike share insights he’s learned along the way to ensure any organization has a seamless, successful translation process, including how to research the right translation service, who to get involved in the research process, and how to create content optimized for translation.

Show notes:

Skill #31: Choosing the Right Knowledge Base Software for Your Organization

Jerrard Doran — Sun, 19 Jan 2020 18:49:38 -0600

No matter your industry—tech, nonprofit, marketing—your organization likely needs a knowledge base software, a dedicated place to capture essential knowledge.

However, choosing the right knowledge base software can be challenging—and takes much more work then a quick Google search. You need to understand the core knowledge problems within your organization; compare softwares that, on the surface, may look a lot alike; and get buy in from key players who’d actually use the knowledge base.

That’s why in this episode, we have Kate Mueller on the podcast: Support Sorceress and—I kid you not—cheese monger at KnowledgeOwl: a knowledge base software that, as they share on their site, makes one thing - awesome knowledge base software.

Kate has worked with several different knowledge bases throughout her career and, at KnowledgeOwl, works with current and prospective customers across the world to help them discover how knowledge base softwares can help address their needs.

In this episode, Kate reflects on her career—both as a user of and support member for knowledge base software—to share the criterion you should consider as you choose the right knowledge base for your organization, including how to get started in your research, how to get company buy-in, and which essential features you should look for in a knowledge base.

And, in the end, Kate shares a few of her favorite knowledge bases—KnowledgeOwl and beyond—to jump-start your research.

Show notes:

Skill #30: Landing a Tech Writing Internship

Jerrard Doran — Sat, 30 Nov 2019 10:51:34 -0600

As prospective tech writers look for ways to get into the tech writing field, many pursue internships. And understandably so: internships give prospective tech writers hands-on experience in tech writing, giving them an opportunity to boost their skills and get a feel for the industry.

However, finding that tech writing internship can be challenging, especially if you aren’t pursuing a tech writing related degree in university. That’s why, in this episode, we have German tech writer Joachim on the podcast, who’s six weeks into his first tech writing internship.

Joachim has learned several lessons about how to find and thrive in a tech writing internship, which you’ll find helpful no matter where you live.

Skill #29: Understanding Your Reader (as a Whole)

Jerrard Doran — Mon, 18 Nov 2019 11:16:45 -0600

One of the most important skills tech writers can have is the ability to analyze their audience—researching who’s using the product their documentation, understanding how they it, and most important, ensuring their goals are reflected in the documentation.

But as tech writers research their audience, digging deep into insights such as demographic and preferred device, tech writers can, admittedly, get caught up in the technical side of audience analysis and dismiss opportunities to understand their reader as a whole.

That’s why in this episode, we have Alexander Yant on the podcast: occupational therapist turned tech writer advocate who, as he’s searched for tech writing opportunities for himself, has reflected on his career in healthcare to share must-have insights for tech writers hoping to better understand their audience.

In this episode, Alexander shares how you can understand your readers as a whole, including why empathy is one of the most important aspects of audience analysis, how tech writers can boost their audience analysis skills, and how effective audience analysis can demonstrate your value as a tech writer.

Show Notes:

Skill #28: Researching as a Tech Writer

Jerrard Doran — Thu, 31 Oct 2019 09:40:40 -0500

All of the help resources tech writers create, such software documentation, video tutorials, or blog posts, require research. Imagine creating a document to explain a new feature before, say, even understanding how customers actually use the feature.

Tech writers use several different resources to research the information they need, including conversations with developers and support and reviewing support tickets. But, if you’re like many writers, we’ll often seek too much information and face information overload, uncertain what to document.

Or, as we’ll learn from this episode’s guest, we miss an opportunity to research the domain in which we work—a must for any tech writer, no matter their industry.

That’s why, in this episode, we have Margaret Eker on the podcast: tech writer at Magento, an Adobe company, and somewhat longtime friend since our days hiking in the forests of Portland Oregon for Write the Docs 2016.

Margaret prides herself as a researcher. And, countless times, has witnessed her work and relationships with her colleagues flourish when she dedicates herself to understanding the domain in which her company exists.

In this episode, Margaret shares how you can boost your research skills as a technical writer, including how tech writers traditionally research new features, why tech writers should research the domain in which they work, and which steps you can take today to boost your research skills.

Show Notes:

Skill #27: Contributing to GitHub

Jerrard Doran — Thu, 24 Oct 2019 12:40:47 -0500

As tech writers consider how to stay relevant in the field, many look to GitHub—the git repository service where people host their open-source projects, allowing others to contribute as well. And understandably so: as the demand for tech writers specialized in developer documentation grows, GitHub gives tech writers low-lift opportunities to ramp up their skills.

That’s why, in this episode, we have Tad Dieken on the podcast: two-time guest on the not-boring tech writer podcast and tech writer at Accuray, who recently completed a week straight of GitHub contributions, ranging from creating onboarding guides for new tech writers to translation.

In this episode, Tad shares how to get started contributing to GitHub, including how to find projects that interest you, how to overcome imposter syndrome in GitHub, and which new skills you may learn in the process.

Show Notes:

Skill #26: Getting Started in API Documentation

Jerrard Doran — Mon, 30 Sep 2019 19:41:02 -0500

As tech writers consider how to stay relevant in the field, many consider getting started in API documentation. And who can blame them—it’s one of the most trending and highest paying roles in tech writing.

But getting started in API documentation can be intimidating, especially if you’ve never worked with code.

That’s why, in this episode, we have Tom Johnson on the podcast: creator of the tech writing site, I’d Rather be Writing, and technical writer at Amazon.

In this episode, Tom shares how to get started in API documentation, including where the tech writer fits in the API documentation process, what skills tech writers need to excel at API documentation, and where to find the best resources to ramp up those skills.

Show Notes:

Skill #25: Nudging Users to Action Through Contextual Help

Jerrard Doran — Tue, 24 Sep 2019 09:10:08 -0500

As technical writers, we help users learn processes or complete particular tasks. And we offer this help in several ways, including documentation, video tutorials, or learning management systems.

But get this: through gentle nudges and clues throughout the users’ journeys, technical writers can help users achieve their goal without sending them straight to the help site.

How? Through contextual help: the micro-copy, in-app guides, and info tips that developers and user experience designers include in their product to nudge users to action.

You’ve seen examples of contextual help. Think the copy that appears below free form fields, instructing you to enter certain content; or guided steps introducing you to a new interface.

This is contextual help. And you—the technical writer—are best equipped to create it for your company.

That’s why, in this episode, we have Kacy Ewing on the podcast: fellow graduate of the University of North Texas and tech writer out of Austin, Texas—though soon moving to Brooklyn, New York to begin a new tech writing job with Bloomberg.

Kacy has created several forms of help resources—including contextual help—and, in this episode, shares the skills you need to excel in creating contextual help for your employer, as well, including:

how to position yourself in the user experience process
how to practice your contextual help writing
Where to find the best examples of contextual help

Show Notes:

Skill #24: Finding Your Content DNA

Jerrard Doran — Tue, 17 Sep 2019 09:42:36 -0500

John Espirian—technical copywriter and author of the soon-to-be-released book Content DNA—describes content DNA as the "shape" of your brand and then using the power of consistency and congruence to create content that gets remembered and acted on.

As technical communicators, the content DNA could take several forms: a freelance technical writer could use their content DNA to own their niche; a content marketer could discover their employer’s content DNA to create compelling, sales-boosting content.

In this episode, John shares how you can find your own content DNA, including:

how to find your niche as a writer
how to market that niche to prospective clients
how to use your niche to win big clients

Show Notes:

Skill #23: Transitioning into Tech Writing from Very-Much-Not Tech Writing

Jerrard Doran — Thu, 29 Aug 2019 20:11:43 -0500

Think back to the early years of your career as you considered pursuing a career in technical writing. Unless you happened to pursue a formal education in technical writing; and perhaps land an internship, it’s a challenging period—just like any career change.

You have to learn the jargon of the technical writer; the networks with which they mingle; and the skills they use.

For people working in very-much-not technical writing hoping to make the transition, all of it can be overwhelming.

That’s why, in this episode, I have Chad Sterling on the podcast: Product Technical Communications Specialist at Kuka, an Austin-based robotics company. Before Chad joined Kuka, he worked as a hotel security director across the united states.

He enjoyed—and excelled at the work—however, after discovering his skill for writing and interest in technology, he made the switch to technical writing and has an excellent story to share about the process.

In this episode, Chad shares how you can transition to technical writing from very-much-not technical writing including:

Where to find a tribe of technical writers
How to use your existing skills to transition into technical writing
How to ramp up your skills to find your first gig

Show Notes:

Skill #22: Using Your Detective Skills as a Technical Writer

Jerrard Doran — Mon, 26 Aug 2019 08:55:06 -0500

As technical writers, we often wear many different hats within an organization: we write documentation that teaches people how to use a product; we test new features to ensure they’re working properly; we write marketing copy that encourages people to research a product.

But, as you’ll learn in this episode, we wear another hat that perhaps haven’t considered but is essential to the technical writers’ skill set: the detective hat.

That’s why, in this episode, I have Jamie Roddy on the podcast: Manager of Technical Communicators who leads a team of global technical communicators who, from her love of detective shows, has found that the detective and the technical writer have a lot alike.

In this episode, Jamie shares how you can use your detective skills as a technical writer, including:

which detective skills are most useful for technical writers
how to ramp up those skills
how detective skills can help you transition into other fields within a software company

Show Notes:

Skill #21: Mentoring Prospective Tech Writers

Jerrard Doran — Mon, 19 Aug 2019 09:00:00 -0500

All technical writers can look back on their career and likely think of a specific person or two who helped them advance their career. It could be a former professor who encouraged them to take technical writing courses; a friend who introduced them to the field; or a boss who invested time into their work.

For prospective technical writers, these mentors are essential to professional development—and landing that first sweet, sweet tech writing job—because they take the time to understand the mentees hopes, dreams, and struggles (and come alongside to help throughout the process).

That’s why, in this episode, I have John Paz on the podcast: Senior Content Designer at Atlassian and mentoring wizard, who’s helped several current and prospective tech writers navigate the field and make the most of their skill sets.

In this episode, John shares his experiences as a mentor to prospective tech writers, and how you can do the same, including

how to find prospective mentees
how to foster a relationship with mentees
and how mentoring can boost your own technical writing career.

Show Notes:

Skill #20: Understanding Content Marketing

Jerrard Doran — Mon, 12 Aug 2019 09:00:00 -0500

As technical writers, we excel at turning technical information into documentation that helps users understand complex concepts. We write software documentation that helps users understand a product; we create video tutorials that teach users how to use a feature.

Software documentation is the technical writers’ bread and butter; however, perhaps unknowingly, technical writers could also thrive at content marketing: a form of marketing that shares a company’s story and expertise in an interesting, sales-boosting way.

To help us unpack this skill, we have Chad Lott on the podcast: Senior Copywriter at Zenreach, who, everyday works in the full suite of content marketing—from corporate blog writing to Google Ad Words.

In this episode, Chad shares his experiences as a content marketer, plus, shares tips on how you can transition into the field, including

How content marketing differs from technical writing
How content marketers succeed
And how to use your existing skills to transition into technical writing

Show Notes:

Skill #19: Writing for Nonprofit Organizations

Jerrard Doran — Mon, 29 Jul 2019 09:00:00 -0500

Throughout technical writers’ careers, they may find themselves working in several different industries: they could start their career writing end-user documentation for a software company; shift to healthcare to write white papers; maybe transition into marketing to write web copy.

And this shouldn’t surprise us: technical writers have several skills that transfer well to different industries.

That’s why, in this episode, you’re going to learn how to write for an industry that you perhaps haven’t considered—or, if you’re like me before I recorded this episode, you had a limited understanding of its opportunity.

And that’s writing for nonprofit organizations.

Turns out, technical writers have far more opportunities to contribute to a nonprofit’s mission beyond grant writing—and it this episode, you’ll learn how to use your technical writing skills to capture those opportunities.

To help us unpack this skill, we have Kathleen Franks on the podcast: recent graduate of Auburn University’s Tech Comm Masters program and—throughout university— used her technical writing skills to assist several nonprofits.

In this episode, Kathleen shares how you can use your skills to start writing for nonprofit organizations, including:

Which technical writing skills best assist nonprofits
How to use your skills to advocate for nonprofits
How to use your skills for more than just grant writing

Show Notes:

Skill #18: Embracing the Long Game of Technical Writing

Jerrard Doran — Mon, 22 Jul 2019 07:45:37 -0500

Anyone who’s been in technical writing for a few years or has attended a technical writing conference has witnessed how quickly the field has evolved. Technical writers have had to shift from Microsoft Word docs to single-source authoring; they’ve had to learn how to become project managers; they’ve had to learn basic programming skills.

In short, technical writers have had to learn how to be flexible—shifting their skills and focus as needed to prepare themselves for shifts in the industry.

It’s essential to surviving the long game of technical writing; however, it’s not easy. It can require continuing education outside of your 9 to 5; it can mean feeling very uncomfortable in a new setting; and, most important, it can mean, understandably, forgetting to create a enjoyable life for yourself outside of work.

That’s why, in this episode, we have Jody Winter on the podcast: Auckland, New Zealand based technical writer of 15 years who’s faced all the struggles that come with embracing the long game of technical writing—and, thankfully, has lived to tell the story with insights that will help any technical writer prepare for and embrace the challenges of growing and fostering their career.

In this episode, Jody shares how you can embrace the long game of technical writing, including:

How to observe changes in the field and how to respond
How to respond to seasons of burnout, where you feel like your technical writing career really isn’t going anywhere
And how to find opportunities to ramp up your technical writing skills

Show Notes:

Skill #17: Branding Your Work

Jerrard Doran — Thu, 30 May 2019 11:00:00 -0500

As a technical writer, you’ve likely not considered branding yourself and your work—and understandably so: your documentation—no matter how masterful and easy to understand—often isn’t associated with yourself.

You don’t get a byline; you don’t get a image of yourself below the headline; instead, it’s just another piece of content created by “the documentation team.”

However, that doesn’t mean there’s value in creating your brand as a technical writer. And you can do so in ways that align with your philosophy and perspective of the industry.

Take Tom Johnson, for example, who’s built a brand for himself around his tech writing site, I’d Rather Be Writing (which, I highly recommend, as you’ll sense in this episode); or Sarah Maddox at Google Maps, who’s built a brand through her site, Ffeathers, combining her interests in technical writing and science fiction.

You have a unique perspective on technical writing that could build your brand while helping your peers lead more fulfilling careers—and in this episode, you’re gonna learn how to do it.

We have Ash Blankenship on the podcast: former fellow podcast co-host at Parskify podcast, where we first met, and today, is the founder at Acme Design: a web design agency that helps entrepreneurs and creatives build their brand.

In this episode, Ash shares how you can find your unique perspective on technical writing to brand your work, including:

How to use content to build your brand
How to choose the right platform to build your brand
How to build a tribe that believes in your approach to technical writing

Show Notes:

Skill #16: Using Cognitive Science to Make Your Technical Writing More Interesting

Jerrard Doran — Sat, 30 Mar 2019 10:41:48 -0500

As a technical writer, what does it mean to make your writing interesting? It’s a question you perhaps have never pondered—and understandably so: you spend your time ensuring that your docs are correct and easy to understand for users—not so much that the work is interesting to read.

It’s a comfortable approach to technical writing that’s easy to get stuck in—however, to the detriment of our work. Enter Anne Janzer: this epsiode’s guest and author of, well, several great books, but as we’ll highlight today, Writing to be Understood.

In her book, Anne discovered the essential techniques to making nonfiction writing more interesting for readers, including how to use analogies effectively to illustrate unseen concepts, appeal to readers’ innate curiosity, and balance humility with credibility.

In this episode, Anne shares takes her research on making nonfiction writing more interesting and shifts the focus to how technical writers can apply the concepts as well. We discuss:

where technical writers may currently miss the mark in their writing
how technical writers can use cognitive science to make their writing more interesting
small steps technical writers can take today to make their writing more interesting.

Show Notes:

Skill #15: Transitioning into Instructional Design

Jerrard Doran — Sun, 24 Mar 2019 16:17:45 -0500

Instructional design, as described by my guest, instructional designer Katie Price, means you create courses to help people—whether it’s students at a university or end-users for a product—learn a new subject.

Take Lynda, for example: the career development website from LinkedIn. You visit the site to learn a new skill—and you find a course that, through videos, powerpoints, graphics, and good ole’ written content, teaches you that skill.

That’s instructional design and—as you’ll learn in this episode—it’s a wonderful career move for technical writers hoping to transition into a new field.

To help us unpack this skill, I’ve got Katie Price, instructional designer at Azusa university, on the podcast to share with us how technical writers can transition into instructional design, including:

what types of projects instructional designers work on
what skills you need to learn to excel in instructional design
how to use your existing skills to transition into the field

Show Notes:

Skill #14: Contributing to Open Source Projects

Jerrard Doran — Wed, 27 Feb 2019 20:40:10 -0600

An open source project is a software program that’s open for anyone to use or modify as they see it. For example, a developer—anywhere in the world—could create an open source project that gives users real-time updates on the location of, let’s say, city buses.

The developer had the idea, coded the software, then released a rough version to the world. It likely has bugs and missing features. But because it’s open source, anyone who’s interested in the project can use their expertise to make the project better—including technical writers.

As you’ll learn in this episode, documentation is essential to a successful open source project. However, for developers actually coding the software, documentation is an afterthought. The result: possible users don’t know what the software does—and even if they do—they struggle to figure out how to use it.

This is where technical writers—both new and seasoned—can use their skills not only to contribute to the beauty that is open source projects, but also challenge themselves to learn new types of documentation.

To help us unpack this skill, I’ve got Kyle Taylor, solutions architect at FFW and President of a Denton-based technology nonprofit TechMill, on the podcast to share with us how technical writers can contribute to open source projects, including:

how to choose the right project to contribute to
how to translate your contributions into your portfolio
how to create open source documentation that developers will love.

Show Notes:

Skill #13: Getting Your First Job in Technical Communication

Jerrard Doran — Wed, 12 Dec 2018 09:45:52 -0600

Thaddeus Dieken – Technical Writer at Accuray – shares how you can get your first job in technical communication, including how to effectively search for jobs, market yourself as a qualified entry-level candidate, and how to navigate the workplace.

Skill #12: Teaching Technical Writing

Jerrard Doran — Tue, 30 Oct 2018 18:51:12 -0500

The technical writer has a variety of valuable skills – such as making documents enjoyable to read and complex topics easy to understand – however, the skill that I think is most valuable for the technical writer is the desire to stay relevant and advance their career.

So we pick up a programming language; we get continued education; we dig into API documentation, hopefully through Tom Johnson’s course on his site, I’d rather be writing.

But there’s another way to advance our career in technical writing – one that many of you in industry have perhaps never considered: teaching technical writing.

Jobs in teaching technical writing are rising – a great opportunity for the new and seasoned technical writer alike to make a career shift – and in this episode, our guest, Kim Campbell, professor and chair of Technical Communication at the University of North Texas, will tell you how to make it happen, including:

how to gain the right skills
how to adopt the right mindset for teaching
how to enjoy a fulfilling career in academia

Show Notes:

Skill #11: Surviving in the Dev World

Jerrard Doran — Sun, 30 Sep 2018 19:41:53 -0500

We all know that successful technical writers are more than writers: they’re designers; they’re knowledge managers; they’re support. However, for technical writers in the dev world, they’re expected to gain new skills, particularly, understanding (and writing) programming languages.

That’s a challenging next step for technical writers – and understandably so: We can create docs, but introducing programming languages can make technical writers wonder what it really takes to survive in the dev world.

In this episode, I chat with Michal Skowron and Pawel Kowaluk – technical writers at Guidewire Software in Kraków, Poland – about how you can survive in the dev world, including:

the technical writers’ role in a development company
how technical writers can gain trust and respect from developers
how technical writers can start learning programming languages

Show Notes:

Best of 2016

Jerrard Doran — Sat, 31 Dec 2016 18:36:00 -0600

2016 was a lovely year for The Not-Boring Tech Writer podcast. We had 10 episodes with 11 guests, covering a variety of topics that truly captured the theme of the podcast: how technical writers can break the stereotype that technical writing is a boring career.

This episode includes my favorite segment from each of the 10 episodes. So if you hear a segment that interests you and haven’t dove into its episode – now is your chance.

Thank you, listeners, for supporting The Not-Boring Tech Writer, and I look forward to bringing you more episodes in 2017.

Show Notes:

Skill #10: Implementing Single-Source Authoring

Jerrard Doran — Mon, 12 Dec 2016 14:49:00 -0600

Paul Stoecklein knows documentation: As Documentation Manager at MadCap – the industry leader in documentation software – and longtime technical writer, Paul understands what does and does not work for documentation teams.

A methodology that Paul believes is essential for documentation teams is single-source authoring: to use a single-source of documentation for multiple outputs.

In this episode, Paul shares how you can implement single-source authoring in your organization, including:

how single-source authoring can add value to your organization.
why all documentation teams should consider single-source authoring.
what tools and processes can help you succeed.

Show Notes:

Skill #9: Creating a Human Connection in Your Documentation

Jerrard Doran — Fri, 07 Oct 2016 14:43:00 -0500

We’ve all read (and perhaps written) a boring document: the robot-like language, the walls of text. And we’re all familiar with the result: a disengaged reader who’s likely missed the message.

Enter John Espirian, freelance technical writer and Director at the Society for Editors and Proofreaders.

John believes the difference between a boring and a not-boring document comes down to one essential element: a human connection.

In this episode, John shares how you can create that human connection in your documentation, including:

how to better understand your end-users.
why your documentation tone must match the brand.
what simplicity means (and doesn’t mean).

Show Notes:

Pen Portraits
John Espirian (Twitter) (LinkedIn) (Facebook)
John’s site

Skill #8: Acquiring the Three Types of Knowledge Tech Writers Need to Succeed

Jerrard Doran — Tue, 02 Aug 2016 13:50:00 -0500

Knowledge – as technical writers, it’s one of our greatest assets.

However, amid the information overload technical writers often face, it’s also one of the most difficult assets to acquire.

Enter Tom Johnson and Lisa Meloncon. Today’s guests and tech comm. advocates that have graciously shared how you can filter the information overload and shift your focus to the three types of knowledge you need to succeed:

Product knowledge
Technical knowledge
User knowledge

The Show Notes:

Skill #7: Preparing for the Future of Tech Comm

Jerrard Doran — Fri, 08 Jul 2016 20:37:00 -0500

As the tech comm industry develops, technical writers must embrace a sobering truth: As Dr. Stan Dicks writes in Digital Literacy for Technical Communication, “Technical communicators who add value to their organizations do not merely write and edit documents.”

So how do we prepare for the future of tech comm so we can ensure we’re adding value to our organizations?

Preparing for the future is difficult without a compass – but fortunately – Ted Hudek, Senior Programming Writer at Microsoft, knows the way.

In this episode, Ted shares his tips on how you can prepare for the future of tech comm, including:

why you should always have a side learning project.
why you should not freak out about tools.
why you should actively build relationships with your colleagues.

The Show Notes:

Skill #6: Bridging the Gap Between Documentation and Support

Jerrard Doran — Tue, 28 Jun 2016 15:34:00 -0500

Documentation and Support teams share a common goal: to give customers the information they need to get the greatest value from a product.

But despite a shared goal, consistent communication rarely follows.

The result: tech writers missing out on content-rich customer feedback, thus, as our guest Neal Kaplan phrases it, “creating documentation in a vacuum.”

In this episode, you’ll learn how to bridge the gap between Documentation and Support, including how to:

build rapport with your Support team.
use the relationship to create better documentation.
measure the efficiency of your documentation.

The Show Notes:

Skill #5: Getting Involved in a Community

Jerrard Doran — Thu, 19 May 2016 18:46:00 -0500

We’ve all experienced the joy of community: colleagues mentor you; friends encourage you; strangers point you towards their favorite pizza shop downtown.

For that moment, whether you had previous ties to each other or not, you feel that sense of community.

And while every community is unique, one concept is constant: As urbanist Charles Montgomery defines it, “people gathering, talking, and helping one another everyday.”

Eric Holscher (today’s podcast guest) and Troy Howard have captured that concept and created a community for us – the tech writers.

The community: Write the Docs.

In this episode, Eric shares the story of Write the Docs and describes the power of getting involved in a community, including:

why tech writers need community.
how to Write the Docs empowers tech writers.
how to get the greatest value from community.

The Show Notes:

Skill #4: Understanding UX Design

Jerrard Doran — Mon, 16 May 2016 14:05:00 -0500

Where should user experience (UX) design fit in the technical writer’s toolbox?

Well, think about how your users experience your documentation:
Are they following a workflow path, following a series of pages to complete a series of tasks sequentially?

Are they following nav links, jumping around to find task-specific information?

Understanding how your users experience your documentation is understanding UX design – which can make or break your docs’ usability.

As our guest and UX designer Autumn Hood describes it: “You can’t have good technical communication without good UX design.”

In this episode, you’ll learn how to think like a UX designer so you can create an effective documentation experience for your users.

The Show Notes:

Skill #3: Creating Just-in-Time Documentation

Jerrard Doran — Sun, 08 May 2016 22:08:00 -0500

Face it: sometimes, documenting software can be tricky.

Not because we don’t understand the software – we get that. Nor because we can’t articulate it in layman’s terms – we’ve got that covered, too.

But because feature guides – the traditional style of software documentation – isn’t enough to ensure your end users can find the information they need to accomplish a specific task.

Enter just-in-time documentation: a new methodology of documentation that complements feature guides by creating task-oriented documents, as our guest Bri Hillmer describes it, “just in time, when the customer asks the question.”

In this episode, you’ll learn about the power of just-in-time documentation and how you can apply it to your documentation today.

The Show Notes:

Skill #2: Transitioning from Tech Writing to Marketing

Jerrard Doran — Wed, 16 Mar 2016 04:41:00 -0500

What’s the ultimate stereotype of technical writers?

Easy: that once you begin your career as a technical writer, you’re caught in a documentation vortex. And worse – that there’s no way out.

But just like all stereotypes, they’re meant to be broken.

As communication experts, our skills – analyzing an audience; writing crisp, clear, concise copy – surpass documentation into an industry many technical writers like yourself once deemed “in someone else’s wheelhouse.”

The industry: Marketing.

In this episode, you’ll learn how your skills translate to marketing so you can – if desired – get out of the documentation vortex and transition into marketing.

The Show Notes:

Adam’s Twitter
Adam’s blog
Blue Steele Solutions
Blue Steele Solution’s Twitter

Skill #1: Applying Empathy to Your Audience Analysis

Jerrard Doran — Tue, 01 Mar 2016 09:24:00 -0600

Once you’ve found your end-user, think about how you find his or her truest needs for the product or service.

For many technical writers, it looks something like this: compile a series of fairly generic questions – “how old are you?”, “how familiar are you with the technology?” – and hope their responses unveil their needs.

Sometimes it works; but other times, you’re left asking yourself, “What did I miss?”

The answer is simple: Empathy.

In this episode, you’ll learn how to apply empathy to your audience analysis so you can get greater insights on your end-users’ needs, and in turn, create more effective content.

The Show Notes