The Not-Boring Tech Writer (Kate Mueller)
Explorez tous les épisodes de The Not-Boring Tech Writer
| Date | Titre | Durée | |
|---|---|---|---|
| 06 Feb 2025 | Kate sounds off on content types | 00:16:04 | |
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:
—
Contact Kate Mueller: Contact KnowledgeOwl: — Transcript
Kate Mueller: [00:01:41] I've also been updating screenshots. We're moving away from PNG format and into WebP format, just to try to keep our file sizes a bit smaller and maybe give our SEO a tiny bit of boost. That change came out of me writing our 'image best practice guide' for customers and actually researching image best practices. So that's been a fun change. And last but not least, after years of having a fairly vague style guide, or no style guide, I've written a clear one. So as I make all of these updates, I'm bringing the text into alignment with the new style guide. All of that has already been in flight for a few months. I also recently finished leading a Knowledge Management masterclass with KnowledgeOwl. And as the old saying goes, the best way to learn something is to teach it to others. So I'm thinking a lot about things like content types, information architecture, information scent and findability and good metrics for success. Teaching the class was really humbling to say the least. It's kind of impossible for me to teach a class on this stuff without feeling mildly embarrassed at all the ways my own docs don't follow the best practices I'm talking about. And to be honest, this was the first time I've really had the time and space to sit down and critically view my documentation through some of these lenses, these big pictures. Kate Mueller: [00:03:12] I'm usually so busy trying to keep things up to date that I don't really take that step back to look at the big picture. And now that I have, I'm overflowing with ideas on how to improve my docs. So many ideas, and I've had to really sit down and evaluate and try to pick just one to focus on. So top of mind for me today is one of those ideas, content types. The masterclass really made me research and discuss content types, and I find that I keep thinking about them and thinking about how I haven't been intentionally or consistently using them to structure our content. I mean, clearly our docs have survived this long without me doing that, but I've been thinking about ways to make it easier for more members of our team to contribute to the support KB. The style guide standardization has been a big piece of that, but I believe content types with templates are the next step. They would make it much easier to onboard another writer, or to ask other owls to update docs in my absence. Kate Mueller: [00:04:15] For those of you familiar with content types, I'm thinking mostly about the common information types used in frameworks like Dita. The content, task and reference. Or the four types that Diataxis uses, explanation, how to guide, reference and tutorial. And for those of you who've never heard of content types, I'l... | |||
| 23 Jan 2025 | Developer collaboration with Lorna Mitchell | 00:43:46 | |
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:
—
Contact Kate Mueller: Contact Lorna Mitchell: Contact KnowledgeOwl: —
Kate Mueller: [00:00:01] Welcome to the Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills and foster our distinctly not boring tech writing community. Hi, I'm Kate Mueller. In today's episode, I talk with Lorna Mitchell. Lorna is 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, and the best ways to build successful collaboration with developers. Welcome everyone! My guest today is a woman who I first discovered through a 'write the docs' talk, who made open API and API documentation actually makes sense and seem like a reasonable form of documentation. And as somebody with no background in API stuff, I figured, you know, if I need to interview somebody who qualifies as not boring, anyone who can make API docs feel not boring feels like someone I should have on the show. So I'm very delighted to welcome Lorna Mitchell to the show today. Hi, Lorna. Welcome. Lorna Mitchell: [00:00:54] Hi Kate! That is a great intro, thank you so much for having me. Kate Mueller: [00:00:57] You're welcome. I'm sure you never thought you'd be starting off thinking, wow, what a compliment to be called 'not boring'. But here we are, welcome to the pod. For our listeners, I came from the writing world and accidentally ended up in tech and have ended up writing a fair amount of software and product documentation and a variety of other things. But for me, that was always like an accident. I just sort of ended up here and it's worked. My sense is that you've had the opposite experience, where you started more on the tech side and have accidentally ended up writing some documentation sometimes. Is that true? Lorna Mitchell: [00:01:35] I think that's a really good reflection. I've always liked words, but I have worked my entire career in software engineering of one kind or another. Along the way, it always seems to be, I've been in charge of multiple docs platforms, and there's a thousand posts on my blog, I wrote some books. This technology thing is amazing, it's easy when you know how and I just can't stop telling people how. Kate Mueller: [00:02:00] It's a good problem to have. One of the things I've learned is, if you are really excited about the thing you're talking about, people will show up and listen to you. I don't understand how this happens. I've done these half hour sessions at KnowledgeOwl, walking people through new features or whatever. People will be like, I love listening to you talk. I'm like, why? Why do you love this? I mean, it's great, I'm happy you showed up. Here I thought I was just talking into the void, and here we are. Can you talk a little bit about your technical background then since it's, I'd imagine, a little different from a lot of our user's? Lorna Mitchell: [00:02:43] Yeah, definitely. Actually, confession time, my degree is in electronic engineering, so I'm actually not at all qualified to do what I do. But along the way, we did a bit of software. This is back in the day, obviously I have been doing this for a long time. Maybe you can't tell on a podcast. Anyway, I have been doing this quite a long time. My first job was in software. I wrote games initially, which was a lot less fun than it sounds. It's not the most humane end of the industry, and I have worked in a bunch of other different technical disciplines. I've mostly been in open source, mostly as a back end developer. I also have some accessibility needs. I acquired an arm injury, it's just a horrible tendonitis, in a workplace quite a long time ago. Although my background is in PHP and web development, I became an API specialist because I can't work the front end dev tools. Those all require a mouse and I am keyboard only and I have been for a really large number of years. I'm API and data specialist kind of by necessity, but also this stuff is amazing. I've worked a lot on making computers talk to each other. The humans should not have to take the information and put it in again somewhere else. This exists in the world in digital format, make it happen. In the time that I've been doing this, we've gone from overnight batch jobs to real time streaming data integrations. I have worked on all of that and everything in between. Kate Mueller: [00:04:22] Wow, that is quite the career and personal life arc. This makes me feel so much more normal because mine has also been equally, how did I get there from here? Actually, it made total sense at the time, but here we are. Lorna Mitchell: [00:04:38] If I'd ever had a life plan, none of this would have happened. From each place, you just have to take one more step forward. The overall map looks a little bit winding, but I think everything is part of the picture. Kate Mueller: [00:04:52]... | |||
| 09 Jan 2025 | Introducing The Not-Boring Tech Writer Reboot | 00:12:46 | |
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 Kate Mueller: Contact KnowledgeOwl: — Transcript
Kate Mueller: [00:02:26] These are all valuable technical writing skills, but I still kind of felt like an imposter offering to host a podcast about tech writing. I can't really say why I didn't feel technical enough to host this podcast. I guess, I don't write code, so there's that. I've never created a DOCSIS code pipeline from scratch. I'm not very good with using automating tools or anything that involves code, especially conditionals and loops, and I haven't been formally trained on it. I didn't go get a certificate or anything in technical communications. I just feel like I'm always aware of how much I don't know and all the deep expertise I don't have. I'm not a wizard with analytics, I've updated API docs, but I've never created them from scratch. I feel like I have a pretty good depth of knowledge, but a lot of my knowledge has grown only when I had some kind of immediate, urgent problem to solve, rather than in a methodical, systematic, or formal way. Kate Mueller: [00:03:34] But the more I thought about it, the more I realized that a lot of the writers I know feel this way. There's this slightly nagging feeling all the time, because I'm not an expert at literally the entire domain, I'm somehow not a real tech writer, and everybody else is. I've shied away from using the phrase 'tech writer' to describe what I do. Sometimes I've called it support documentation or product documentation. Sometimes I call myself a documentarian. I've also called myself a product champion. When I dug into other podcasts on tech writing, it felt like there were good podcasts for technical communication and good podcasts for general writing tips, but it didn't feel like there was anything fitting what I needed. Where's the podcast for those of us who don't feel like real tech writers, but who are, nonetheless, writing technical or support or product documentation on a regular basis? You're listening to the answer. That's what The Not-Boring Tech Writer is now, or at least that's what I hope it becomes. My focus in relaunching this podcast is on carving out a space for writers like me. If you feel like you write pretty good docs, but you dread when someone asks you to set up analytics, or you want to roll your eyes when marketing requests, SEO changes, or writing docs is just one of many hats you wear and you're worried you're not good enough at it. Or maybe you're secretly convinced you aren't qualified enough for your role. You found the right place, welcome home. We'll get to feel like mild imposters together. And together, we'll be exploring topics and hearing from guests to help inspire us, make us feel less alone, and teach us more about the skills and areas we don't feel as confident in. Kate Mueller: [00:05:29] Here's what you can expect from The Not-Boring Tech Writer moving forward. I'm aiming for a two episodes per month schedule. One of those episodes will be, what I'm affectionately calling, the 'Kate Sounds Off' episodes, kind of like this one. You'll get to hear me talk about what's top of mind for me and my tech writing journey, what I'm working on, what I'm anxious about, whatever. My deepest, darkest tech writing secrets. Then the other episodes will stay true to the existing Not-Boring Tech Writer format, where I'll interview guests about the things I, and hopefully you, want to learn more ... | |||
| 16 Mar 2016 | Skill #2: Transitioning from Tech Writing to Marketing | 00:23:14 | |
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:
| |||
| 09 May 2016 | Skill #3: Creating Just-in-Time Documentation | 00:30:07 | |
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: | |||
| 16 May 2016 | Skill #4: Understanding UX Design | 00:25:01 | |
Where should user experience (UX) design fit in the technical writer’s toolbox? Well, think about how your users experience your documentation:
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: | |||
| 19 May 2016 | Skill #5: Getting Involved in a Community | 00:33:13 | |
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:
The Show Notes: | |||
| 28 Jun 2016 | Skill #6: Bridging the Gap Between Documentation and Support | 00:24:39 | |
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:
The Show Notes: | |||
| 09 Jul 2016 | Skill #7: Preparing for the Future of Tech Comm | 00:29:08 | |
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:
The Show Notes:
| |||
| 02 Aug 2016 | Skill #8: Acquiring the Three Types of Knowledge Tech Writers Need to Succeed | 00:38:02 | |
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:
The Show Notes: | |||
| 07 Oct 2016 | Skill #9: Creating a Human Connection in Your Documentation | 00:19:38 | |
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:
Show Notes:
| |||
| 12 Dec 2016 | Skill #10: Implementing Single-Source Authoring | 00:28:46 | |
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:
Show Notes: | |||
| 01 Jan 2017 | Best of 2016 | 00:25:17 | |
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: | |||
| 07 May 2021 | Documentarians for Diplomacy: Bringing the Mirth with Kat Stoica Ostenfeld | 00:50:44 | |
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 | |||
| 16 Feb 2021 | How to Infiltrate a Hackathon in Iowa with Philip Kiely | 00:46:23 | |
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: | |||
| 27 Feb 2020 | Skill #34: Crowdsourcing Technical Communication | 00:37:04 | |
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: | |||
| 10 Feb 2020 | Skill #33: Getting Started with Open Data | 00:43:26 | |
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: | |||
| 20 Jan 2020 | Skill #31: Choosing the Right Knowledge Base Software for Your Organization | 00:50:09 | |
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: | |||
| 30 Sep 2020 | Skill #35: Understanding Basic Design Principles | 00:40:30 | |
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: | |||
| 19 Mar 2021 | Marrying skillsets and existential googling with Caity Cronkhite | 00:36:12 | |
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. | |||
| 03 Nov 2020 | Skill #36: Creating Usability Tests for Your Organization | 00:46:42 | |
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: | |||
| 03 Jan 2021 | A Fond Farewell (Yet Warm Welcome!) | 01:22:13 | |
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. | |||
| 14 Jun 2021 | Tech Writer Advocacy and Managing Write the Docs with Swapnil Ogale | 00:37:31 | |
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. | |||
| 26 Jan 2020 | Skill #32: Understanding Translation and Localization | 00:31:03 | |
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: | |||
| 17 Sep 2019 | Skill #24: Finding Your Content DNA | 00:29:39 | |
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:
Show Notes: | |||
| 01 Mar 2016 | Skill #1: Applying Empathy to Your Audience Analysis | 00:22:23 | |
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 | |||
| 01 Oct 2018 | Skill #11: Surviving in the Dev World | 00:36:28 | |
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:
Show Notes: | |||
| 30 Oct 2018 | Skill #12: Teaching Technical Writing | 00:25:52 | |
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:
Show Notes: | |||
| 12 Dec 2018 | Skill #13: Getting Your First Job in Technical Communication | 00:29:33 | |
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. | |||
| 28 Feb 2019 | Skill #14: Contributing to Open Source Projects | 00:27:48 | |
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:
Show Notes: | |||
| 24 Mar 2019 | Skill #15: Transitioning into Instructional Design | 00:21:36 | |
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:
Show Notes: | |||
| 30 Mar 2019 | Skill #16: Using Cognitive Science to Make Your Technical Writing More Interesting | 00:31:43 | |
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:
Show Notes: | |||
| 30 May 2019 | Skill #17: Branding Your Work | 00:39:41 | |
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:
Show Notes: | |||
| 22 Jul 2019 | Skill #18: Embracing the Long Game of Technical Writing | 00:29:41 | |
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:
Show Notes: | |||
| 29 Jul 2019 | Skill #19: Writing for Nonprofit Organizations | 00:25:01 | |
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:
Show Notes: | |||
| 12 Aug 2019 | Skill #20: Understanding Content Marketing | 00:28:12 | |
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
Show Notes: | |||
| 19 Aug 2019 | Skill #21: Mentoring Prospective Tech Writers | 00:30:15 | |
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
Show Notes: | |||
| 26 Aug 2019 | Skill #22: Using Your Detective Skills as a Technical Writer | 00:35:51 | |
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:
Show Notes: | |||
| 30 Aug 2019 | Skill #23: Transitioning into Tech Writing from Very-Much-Not Tech Writing | 00:30:52 | |
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:
Show Notes:
| |||
| 24 Sep 2019 | Skill #25: Nudging Users to Action Through Contextual Help | 00:23:14 | |
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:
Show Notes: | |||
| 01 Oct 2019 | Skill #26: Getting Started in API Documentation | 00:38:19 | |
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: | |||
| 24 Oct 2019 | Skill #27: Contributing to GitHub | 00:25:39 | |
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: | |||
| 31 Oct 2019 | Skill #28: Researching as a Tech Writer | 00:27:36 | |
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: | |||
| 18 Nov 2019 | Skill #29: Understanding Your Reader (as a Whole) | 00:35:16 | |
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: | |||
| 30 Nov 2019 | Skill #30: Landing a Tech Writing Internship | 00:34:51 | |
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. | |||