The Not-Boring Tech Writer

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.

Note from Marcia:
"I’m promoting kindness. A few years ago, I put heads together with a developer friend and created the Kindness Map. My son created a logo for it. I invite everyone to go to kindness-map.com. Drop a heart and a brief story on the map from anywhere in the world. And keep seeing kindness."

—

Contact The Not-Boring Tech Writer team:

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

• Email: [email protected]
• thenotboringtechwriter.com
• LinkedIn
• Bluesky

Join the discussion by replying on Bluesky

Contact Kate Mueller: 

• knowledgewithsass.com
• LinkedIn
• Bluesky
  
  

Contact Marcia Riefer Johnston: 

• Writing.Rocks
• Linkedin
• Bluesky
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com
• LinkedIn

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:

1. Use actual headings. (Not usually a problem in our docs, but a good review item anyway!)
2. 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.)
3. Use link text that has more meaning than "See more" or "Click here". (Again, not a steady thing, but a good review item.)
4. 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:

• KnowledgeOwl Support KB, Search category
• KnowledgeOwl Support KB, Features category
• TNBTW Episode 5 and Episode 6

—

Contact The Not-Boring Tech Writer team:

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

• Email: [email protected]
• Bluesky
• LinkedIn

Join the discussion by replying on Bluesky

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com

Contact KnowledgeOwl:

• KnowledgeOwl.com

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:

• Email: [email protected]
• Bluesky
• LinkedIn

Join the discussion by replying on Bluesky

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com
  
  

Contact Kenzie Woodbridge: 

• Website
• Linkedin
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com

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:

• Email: [email protected]
• Bluesky
• LinkedIn

Join the discussion by replying on Bluesky

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com
  
  

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:

• Email: [email protected]
• Bluesky
• LinkedIn
  
  

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com
  
  

Contact Janine:

• LinkedIn
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com

Join the discussion by replying on Bluesky

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:

• Email: [email protected]
• Bluesky
• LinkedIn
  
  

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com

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:

• [email protected]
• Bluesky
• LinkedIn
  
  

Contact Kate Mueller: 

• knowledgewithsass.com
• LinkedIn
  
  

Contact Lorna Mitchell: 

• Lorna's website
• Linkedin
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com

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:

• Email: [email protected]
• Bluesky
• LinkedIn
  
  

Contact Kate Mueller: 

• LinkedIn
• knowledgewithsass.com
  
  

Contact KnowledgeOwl:

• KnowledgeOwl.com
• LinkedIn

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

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