Kate Mueller: [00:00:04] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we hear from other writers to explore writing concepts and strategies, deepen our tech writing skills, get inspired, and connect with our distinctly not-boring tech writing community. If you are passionate about documentation, you belong here, no matter your job title or experience level. Welcome.

Kate Mueller: [00:00:30] Hello lovely, not-boring tech writers. I'm Kate Mueller, and this is one of our solo episodes where I share things I'm thinking about or working on. I'm recording this episode in the middle of January, right after the main draw for the Australian Open has been announced. And now you know that I will be spending the rest of the month watching tennis. I hope you enjoyed some of the specialty episodes we closed out 2025 with. We certainly had a lot of fun putting them together.

Kate Mueller: [00:00:58] First, my progress update. Since my last episode, I've been working on my release tail from my big 2025 project, so I've been tidying up a few messes that I found while I was doing that, but decided were out of scope. For example, I'm slowly removing all GIFs from our documentation and replacing them with short MP4s. I find these to be a lot less distracting and also more accessibility friendly. And no, I don't want to get into a “gif” versus “jif” pronunciation war. I said what I said.

Kate Mueller: [00:01:31] As I threatened in my last solo episode, I've written some documentation champion guidelines for my colleagues so that they can contribute to documentation. I've done two sets, one for creating new docs and another for updating existing, and I've also scheduled a training session to go over and reinforce those guidelines and provide more explanation of why they exist and what happens if you don't follow them. Oh, that sounds a little ominous and threatening, but I'm doing the training because I really want my team to understand that there's logic and reason behind the choices, not just that I'm being picky or trying to tell them what to do, although I potentially could be doing those two things also.

Kate Mueller: [00:02:14] I have also been very consistently using my daily check-in Google form inspired by Kate Pond, which I shared in episode 27. So far, this has made it much easier for me to complete my weekly check-ins, and it's also provided a nice bookend to the day. So overall, I'd say I'm happy with it. I have made one change, which is for the question, “What's one thing you wish had gone better today?”. I've changed it from being required to optional, because it turns out that there are some days when I'm oddly content with how the day went, and having it required made me feel like I had to find something that I wished had gone better. And that was just a little bit of negativity I didn't want in my day, so I made that change. I would say the one bummer so far is that it hasn't really helped me give better appreciations and high fives to my teammates, which was really one of my big hopes for using it.

Kate Mueller: [00:03:11] But also, my data set is a little untraditional because I started using it before the holidays, and everybody had different schedules with the holiday vacation time off. So I wasn't really working with folks in the same collaborative capacity that I normally would. So really, I guess I would say that the jury's still out on this because I'm not entirely sure that it won't still help in the future.

[00:03:38] I've also been getting my very unruly docs backlog under control, because I almost completely neglected it for most of 2025 while I was working on the big project. I largely just put out little fires and stuff that felt incredibly urgent and then ignored everything else. And so I went through and triaged everything that's been sitting there and piling it up. So all of that stuff now has a priority and an effort estimate. And I've been banging out a lot of the low-hanging fruit updates, small new docs or small changes to existing docs that people submitted that I could have probably been doing in 2025, but I forgot to check. While I was doing this backlog review, I discovered that a pretty sizable chunk of my outstanding prioritized backlog is tied to a project that I actually started in 2024 and then I had to pause on it because of the massive UI update doc project.

Kate Mueller: [00:04:42] So I am now picking back up my project to update our API endpoint documentation. Not my strong suit of documentation by a far stretch. So these docs were originally written by another writer named Deborah, and it was a mountain of work. She did a phenomenal job at the time. So I'm actually really embarrassed to admit that after she finished the contract for them, I did a little bit of maintenance, but I wasn't really giving them a lot of love or care. So they've been a bit neglected and unloved, and I'm trying to remedy that situation now, both to make them easier for me to maintain, but also because Deborah was not as familiar with the product, and so she was doing her best to figure out what was required and some of those things. But I had a few backlog tasks that were “this action on this endpoint says that these fields are required. But actually, if you overlook, if you follow that to the letter, stuff doesn't get created properly or updated properly, can you fix it to add these fields?”, those kinds of things. And so far, I've reordered the endpoints to be alphabetical and switched from JSON to YAML format, because for me that is much easier to read and to work in.

[00:06:02] I've also updated all the available actions on three of our 20 endpoints, and these are the three that get most heavily used. And so those updates could look like a lot of different things. I have added new fields that have been added between the time that Deborah originally created this documentation and now, because apparently I missed a whole bunch in there that I didn't know about, so that was embarrassing. I have made sure that parameters and data types and required fields are all displaying when and where they should. I've added more cross-references to features and tips in the rest of our documentation to try to give people additional guidance beyond what's in the API documentation, and as a result of that, I've been slowly checking off tasks in the backlog.

[00:06:54] I would say right now this is the biggest project that I'm most focused on while I wait for the next big round of UI changes, which I know are coming, probably in the next couple of months. So I'll have another big project to keep you posted on. And this time, instead of viewing it as like a single big thing, I'm tackling one endpoint at a time and then getting that updated. So it feels really good to be able to check off things like, “here's one section that's done,” right? Or as done as it's going to be, I should say.

[00:07:28] I've also at the same time, because it's me, I've been working on a more strategic goal to create a change management toolkit for folks launching new knowledge bases, specifically KnowledgeOwl knowledge bases. I would say that's gone okay. It's been harder than I thought it would be to do, and I have had to be really aggressive in what I'm defining as my minimum viable docs. I've scaled down my expectations quite a bit, and it's still not quite done, but I'm hoping to finish it this month. My goal with this toolkit really is to provide a framework for our customers to use so that they can define their scope for their initial knowledge base launch and communicate effectively about that before, during, and after, and then measure and report on success. This is the hope, anyway. So hopefully this goes well and I'll be able to share more details on that in my next solo episode, because in theory, it will be live by then. I hope.

[00:08:32] And of course, I've also been reflecting on my interview with Kelton Noyes. There is a lot to chew on in that episode, so this might feel a little bit like a grab bag, but I really liked Kelton's observation that people don't want to feel dumb, and they certainly don't want to admit when they feel dumb, and therefore part of what documentation does, if it's doing its job, is to give information that someone needs so that they don't feel dumb about not knowing what that something is. That can be as simple as having on-hover tooltips to define acronyms. That was the example Kelton gave. I think this is something all of us intuitively know, and I think we often intuitively focus on doing this: to look for places that might be causing confusion or friction or places that people might feel dumb, and to boost our documentation so that we explicitly address those places and that friction. I'm not sure it's the most earth shattering of observations, but it's always good to be reminded that nobody likes to feel dumb. I think in software documentation especially, sometimes there's the joke about the dumb user, that the user is actually the problem there. While that is sometimes true, it's also really dehumanizing, and so I prefer to center the empathy of being like, “I don't like feeling dumb. I bet other people don't like feeling dumb. Let me make sure that my docs are helping other people feel smart instead of dumb”.

[00:10:14] I also feel like Kelton did a good job of showing the evolution of your documentation hierarchy of needs as you go through the process of evaluating tools. Some of the examples he gave are: there are needs you don't even know exist until you start getting hands on with tools. And there are things your organization thinks they need that sometimes aren't actual needs, they're more like nice to haves, or they might be things you think you need because of the limitations of your existing toolset. And then once you get into something that has a different feature set, it turns out you don't have that need because it's solved in a totally different way. And then sometimes things that you never thought you needed suddenly become very important, because they help you realize that you have a problem you haven't dealt with before. He gave some great examples of each of those. The episode is really worth a listen for that.

[00:11:11] And in this, I am 100% aligned with Kelton. I think that signing up for a trial and getting hands-on is the absolute best way to evaluate a tool. In my experience, the marketing materials or documentation can say all kinds of things about what a tool is capable of, and even other writers can really heavily recommend it, but to really understand if it's a good fit for me or my team or my customers, I have to get in there and try it. And for me, that hands-on experience sometimes is a very fast way to realize that a super promising tool is actually really unintuitive or confusing to me. And so I might rule it out of the running way faster than I thought I would. And then sometimes tools that I was a little bit “eh” about before I started using them end up feeling like a much better fit and a lot more intuitive and make it much further in the evaluation as well. I don't know how people pick tools without using them. I feel so sorry for y'all if you have to do that.

Kate Mueller: [00:12:15] And in talking about his experience of making the shift from support person to tech writer, well, first of all, I was a little bit in awe of Kelton for this because it took me years and years and years to get out of wearing four different hats and to officially just be doing docs. And even now I say I'm just doing docs and I'm slowly letting other things creep in. So I am a very terrible guardian of my own roles. But I really liked his insight that he realized quickly that he didn't have to sell the importance of documentation because it was really easy for people to say, “Oh yeah, of course, documentation is important.” And it was just a nonstarter. And that the reason that he was ultimately successful in shifting roles was because he focused on selling himself as being the right person to do the documentation.

[00:13:12] We are so often told, or we say to each other, that we need to make the case for docs. Internally at KnowledgeOwl I'm called The Lorax, in part for my advocating for documentation. And so there's definitely some truth that we need to be making the case for docs. But sometimes we forget that in doing that, we also need to be making the case for our own abilities in writing documentation. Kelton, I think, is a lovely example of this, that he took initiative to create documentation or overhaul training programs, kind of on his own or as a scoped side project, and then used those successes to showcase his abilities. And it didn't end up helping him make the transition at the company where he did it. They became things that he showcased during interviews with other companies that led to the door opening for him to be a full time writer. It’s just super smart.

[00:14:12] This episode is sponsored by KnowledgeOwl, your team's next knowledge base solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30-day trial at knowledgeowl.com.

[00:14:35] Kelton's interview also tied in nicely with something else that I've been thinking about a lot lately, which is that as a tech writer, you have to be a bit in love with process instead of product. And in typical Kate fashion, the way I started thinking about this had very little to do with documentation. I shared a job posting on LinkedIn for a writing role with LEGO in the UK. Full disclosure: I adore LEGO. If I lived in the UK, I might have been very tempted to apply for this role. And I also wasn't surprised when someone in my network replied that it was also a dream job for them.

Kate Mueller: [00:15:16] I think there's something about tech writers in particular that we kind of get into LEGO for adults. And that prompted a little fun comment thread conversation between us about how much we love LEGO and what we do. And, you know, how we interact with our LEGO and whatever. And I feel like there's two kinds of people in the LEGO world, and I could be wrong about this. So on the one hand, there are the folks who are into LEGO who build the sets and then leave them up on display or as decor. And LEGO's really doubled down on this the last few years in creating sets for adults that are inherently decorative. So there's certainly plenty of reasons to do that. But I will say I'm the second class, which is that I rarely, if ever do this, even with stuff that's designed to be decorative. I pretty much build a set, smile at it when it's done, and then almost immediately take it apart and put it away. And then a few months later, I'll repeat all of that over again. Actually, there is one exception to this, which is the LEGO version of Vincent van Gogh's “The Starry Night,” which was given to me by a friend. I don't know if I was having a particularly brain foggy day the day I put it together or what, but I really messed up the background color interpretation of the instructions the first time I did it, and I got like 80% done with the back and realized my mistake and had to rip the whole thing apart and fix it. So it was not an enjoyable process for me. And because of that, that one stays together. It is actually up as decor in my home.

Kate Mueller: [00:16:55] But I would say that's the exception. I think that my habits and how I do LEGO are illustrative of something bigger about my personality, which is that while I like the end result of something, and I am often motivated by the end result and proud of it, really the process of getting there is the thing that I love. So for LEGO, that's a methodical process of getting all the pieces out, sorting them, following the directions to put it together. Woohoo! It's done. And then disassembling it and putting all that stuff away. Once I started thinking about that, I was like, “Oh yeah, there's 8000 examples of this from my life.” When I was a kid, my sister and I spent a lot of our childhood years doing jigsaw puzzles, and the process was very similar to how I've just described LEGO. So we had like 20 jigsaw puzzles that we did repeatedly as kids. We never got tired of them and we would get a new jigsaw puzzle at Christmas. That was the big thing, which we would always do either Christmas Day or the day after Christmas. But then the more and more we did a puzzle, we would then come up with additional challenges to how we would do it.

Kate Mueller: [00:18:11] So once we knew it well enough, we would stop doing the edges. We would save the edges to last. We would set them aside and just tackle the actual body of the puzzle. And we were very democratic about it. There were always sections of the puzzle that we both really loved, and we would divide those up equally. So we each got to do some fun stuff, and we were very collaborative. If I was looking for pieces for my section and I saw them for her, I would grab them and hand them to her and vice versa. It was probably one of the most harmonious sibling things we did. And we liked seeing the finished puzzle. We'd spend a couple minutes looking at it and enjoying it before we immediately took it apart. And so it was really not the rush of completing it, because most of these we'd done so many times, we knew what they looked like. There was just some kind of joy in the rhythm of doing the thing, of putting them together. And it's great because the vast majority of your time with a puzzle is spent in the process of doing the thing, of turning the pieces over and maybe sorting or organizing them a little bit and then putting it all together just as with my LEGO set example.

Kate Mueller: [00:19:26] And so it may be that my love of process started really young and has been reinforced. But I also really doubled down on it as an adult. The biggest example of this preference for process over end product has to be when I thru-hiked the entire Appalachian Trail on my own in 2018. It was just under 2200 miles at that point, and I really can't invent a better metaphor for finding ways to embrace a long, slow, seemingly never ending process toward a very distant and honestly, in some ways, anticlimactic, reward. I mean, I spent 163 days on that hike, much of it in soaking wet clothing, all of it but the first 200 miles with nerve pain in my feet, which sometimes meant that it felt like I was walking on hot coals and sometimes meant that they were numb. And I just had that weird pins and needly feeling, or not even pins and needly. And it was just like I had these bricks strapped to the bottom of my legs. So 163 days of that, and you summit Mount Katahdin and you finish in a single day. And it's an incredible achievement, but you're immediately like, “Oh, what do I do with my life now?”. You really have to love the process or find ways to love the process.

[00:21:02] I gave a talk on the strategies I use to survive that process at Write the Docs Portland virtually a few years ago, the talk was called “Beating the Virginia Blues: Thru-hiking Strategies to Help You Survive Your Next Project.” I'll drop a link in the show notes if you want to learn more about the mindset I use for these kinds of things, where the process itself is maybe not the most enjoyable, but you have to find ways to enjoy it.

[00:21:31] Process is kind of my bread and butter, I would say. As I was compiling my notes for this episode, it kept making me think of a song by the band The Wild Reeds from their album The World We Built, which is called “Fruition.” And for me, this song is a lot about enjoying the process of the day to day instead of constantly seeking happiness or bliss. Anyway, I'll link to that in the show notes too. Apparently I'm just like a show note queen this episode. So let's just say I had process on the mind already, and had already been thinking about talking about it in this episode. And then when I listened to the edited version of Kelton's interview, he really handed me a lovely bit of synchronicity that made me realize I had to talk about it this episode.

[00:22:22] So in the second half of his episode, as we were having the conversations about tool selection and how those things evolve, the overarching story there is going from no documentation to then the company he was at was using KnowledgeOwl, and then they transitioned from KnowledgeOwl to using Madcap and now post-acquisition and merger, they're in the process of selecting and shifting to yet another tool. And all of those changes have been driven by both content and authoring needs and the experience that they want to give customers and the experience they want to have as authors. And so much of technical writing is this kind of thing, is being okay with things that never feel done, or of constantly revisiting things that you've written before or decisions you've previously made. So that might be revisiting tooling decisions, or it might be reevaluating your information architecture or your content hierarchy, or even just looking at the content or the structure of a single page or a category in your documentation, right? And as I've thought about it, I've realized it's an interesting position to be in, particularly in software or just tech generally, because the software and tech industries often are aggressively chasing the bleeding edge or the next big thing. And as tech writers we're sometimes living in that world, but we're also constantly trying to improve existing things or revisiting stuff we've already done. And yes, we embrace new tools or technology to make our jobs easier or to stay relevant. Kelton's story is illustrative of that. That's three major tool changes in a series of years. But underlying that is this work where we're returning, reevaluating, revisiting, making a new decision with fresh eyes or new insights or more customer empathy.

Kate Mueller: [00:24:36] And I think one of the superpowers of tech writers is our ability to embrace the process of doing those things, even though we recognize that it means we're going to have to produce a product all over again that we've already done. And I think it helps if you can prioritize process over product in what you enjoy. So I treat my documentation as a permanent work in progress. I like the distinction between the idea of pages being complete but not necessarily done. They're done enough, is often how I think about them. They're not permanently done. I always know I'm going to have to come back and update this thing repeatedly as our product changes, as our customer base changes, as my writing abilities or our style guide change, all kinds of things will prompt that reevaluation or reconsideration. I suspect that I'm a lot happier as a tech writer than someone who prefers the dopamine rush of completing things. I imagine that I live my work life with less frustration at having to go back and do something over again, or revisit things, because I have that love of process but also the expectation that I'm going to have to come back and do it again. I think it just really helps that I'm somebody who loves process.

[00:26:07] But I also know that that love of process, which is one of my greatest strengths, is conversely, also one of my greatest weaknesses. And so this month, I'm trying to balance those things, because sometimes that love of process means that I spend more time on things than I probably should. Think back to my sister and I making puzzles a little bit harder as we did more of them because it was more fun for us that way. I know that I have this little bit of an Achilles heel, and so I'm trying to give myself permission to release products–like this change management toolkit I've been working on–that don't feel even remotely close to being done or perfect, but feel complete unto themselves, complete enough that they feel like an improvement over what I've already had, to get those out into the world to hopefully get some feedback from my readers, and also maybe to break a little bit of my obsessive love with the process and focus on the product. If you're not a process person, I hope this month that you can find a way to embrace the process a little bit more. Or as we would say in the endurance community, you find a way to embrace the suck. And if you are a process person like me, and that's not the suck for you at all, I hope you can find a way to let go of a little bit of process, and maybe celebrate those products just a little bit more. Get a couple more of them out the door.

Kate Mueller: [00:27:43] And as always, if you have other ideas for topics or guests, if there's a bit of the tech writing world that your life would be improved by hearing an episode on, or if you'd just like to tell us what you're getting out of the show, please message us on LinkedIn or Bluesky @thenotboringtechwriter or email tnbtw@knowledgeowl.com. Also, we've made a slight tweak to thenotboringtechwriter.com. There's a new Suggest a Guest tab. You can fill out a form there to recommend yourself or someone else as a new guest. Please, please, please go do it. I'm very excited to welcome some new faces and some new voices to the pod.

[00:28:28] The Not-Boring Tech Writer is co-produced by our podcast Head of Operations, Chad Timblin, and me. Post-production is handled by the lovely humans at Astronomic Audio, with editing by Dillon, transcription by Madi, and general post-production support by Been and Alex. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can order The Not-Boring Tech Writer t-shirts, stickers, mugs, and other merch from the Merch tab on thenotboringtechwriter.com. You can check out KnowledgeOwl's products at knowledgeowl.com. And if you want to work with me on docs, knowledge management, coaching, or revamping an existing knowledge base, go to knowledgewithsass.com. Until next time, I'm Kate Mueller and you are the not-boring tech writer.