Latest / The Not-Boring Tech Writer / Kate sounds off on building confidence
Transcript
- 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! [00:00:29] 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 early June, right before the World Cup begins. So first, my progress update. In the last month, I spent most of my time prepping for and delivering five webinars on our change management toolkit. I delivered these over the course of about two and a half weeks. The first four covered steps in the framework and provided more detailed examples and explanations of how to work through those steps. And then the last one was just a fun little add-on that was a behind-the-scenes of how I built some of the interactive elements or the graphical elements in the toolkit. I really loved prepping for these webinars, actually delivering the webinars, and we got some generally very positive feedback from attendees, especially those who attended the whole series. And the mixed blessing of this was that prepping for them made me really review the toolkit with fresh eyes and helped me realize some places where it had gaps or it felt really repetitive or redundant. As the saying goes, there's no better way to figure something out than to have to teach it to someone else. And it definitely helped me figure some things out. Kate Mueller: [00:01:50] And now that those webinars are done, I can return to creating a version of the toolkit that I can share with you, not just KnowledgeOwl customers. And so hopefully one of these episodes, I can actually share that with you instead of continuing to tease you that it's coming. I promise. It will be a faster delivery than Apple's Siri upgrade, I hope. I've also been kicking around some ideas for more webinars or trainings for the rest of this year, and if any of these feel applicable to you rather than KnowledgeOwl users specifically, I'll keep you posted on them. And I also continued to plug away at updating content to match our article editor redesign. That's my big project right now in the Support knowledge base. And in the last month I updated about 37 articles. Most of these updates were for our synced and shared articles, categories, and knowledge bases, although there were a few little one-offs too. And as I was making updates to the synced content especially, I realized that these were the pre-feature subcategories content hierarchy content types overhaul. So I also restructured the subcategory layout here to be more consistent with other places in the knowledge base. And through doing that, I realized we had some really obvious content gaps, so I also created 14 new articles to fill some of those gaps. Kate Mueller: [00:03:15] In terms of my punchdown list, I think I have about 86 articles left in my original punchdown list for these editor layout changes, but as I've noticed with a lot of these, who knows how much restructuring or other work that will entail. It'll be an adventure. I'll keep you posted, but it does feel really good to be making slow and steady progress, and I don't feel the burning pressure of being behind on this because we are continuing to make updates to the new editor layout still. And so I am returning to some pages that I've already updated as we make additional updates, and in fact, we are in the midst of redesigning the version interface, which was the last big piece of documentation I still had to update. So now I'm like, maybe I'll just wait till that redesign is done and then I'll do it. I think I'll tackle it either way this month, but I'm hoping the redesign comes out first. But because I know I'm going to have to come back to these a few times, it also has given me a little bit more explicit permission to take the time to do some of the restructuring and identify those content gaps, because I know that I'm going to be touching these pages generally again, once for sure when we sunset the current editor, which I'm calling the old editor, but some of them 2 or 3 times as we release smaller UI updates. So it encourages me to take a little more time and be a little more thoughtful in the structural updates, I think. Kate Mueller: [00:04:48] And of course, I've also been reflecting on my interview with Heather Zoppetti. I always love hearing career stories where someone was doing something else, and then discovered that technical writing was a job title and role, and not only that it existed, but that it seemed to describe something that they liked to do naturally. And that's definitely true in Heather's case, but I especially love that her path went from software developer to knitwear business owner for a decade before she returned to tech, but as a technical writer instead. So she was able to make this pivot through a few techniques. She used her knitwear patterns as her technical writing portfolio. Then she explicitly connected the dots between the job description and her experience in both her cover letter and her interview, and she also lucked out a little bit. She had a fairly open minded hiring manager and company in that first time around, so she was able to get her foot in the door of the tech writing world. Kate Mueller: [00:05:54] Heather combines some skills that I believe make for good technical communicators. She has an openness to exploring what's out there, what other folks are doing, what types of content they're creating, and to evaluate how effective those are and consider using them for herself. In doing this, she seems to want to keep an open mind about what different end-user roles or experience levels might want in terms of medium or format. As she said, sure, a lot of designers do seem to prefer visual assets, but so do some developers. While there may be some trends overall, declaring that you don't need video because your docs are for developers can be a self-fulfilling prophecy because it makes it so that your product really only keeps and supports developers who don't want video. She also seems to prioritize testing new formats and methods and iterating on what she has, and I think this is a fantastic approach generally. I guess the one thing I will caveat it with is that I don't think you have to physically be constantly iterating to be a good technical communicator, I mean, that would be exhausting, but you do need to be open to iterating and learning and consistently looking for ways to improve your documentation. That openness to change, I think, is kind of a requirement for being a good technical communicator. Kate Mueller: [00:07:15] I also really appreciated her comments about the usefulness of kicking around ideas with another writer. Heather has spent a lot of her tech writing career as a lone writer, but recently became one of two writers on her team, and she spoke really positively about the power of collaborating with someone else who's also living and working in this space, and mentioned that when she was a lone writer, Write the Docs Slack was part of how she filled that gap and need for collaborative feedback or input. Kate Mueller: [00:07:47] And that broadly mirrors my own experiences. I've spent a lot of my career as a lone writer, but the times when I wasn't a lone writer gave me a bit more confidence in the choices I made. I learned new skills. I learned new ways to think about the problems facing me. I also just had somebody to bounce ideas off of. And while I'm generally still a lone writer now, I'm lucky to have some solid technical writing friends who I can bounce ideas off of even though they don't work directly with me. And those moments have either helped me abandon bad ideas faster, or flush out nuances I hadn't thought of, or make a decision between two very different approaches, or just generally feel more confident that the approach I'm taking makes sense. So find your people, whether that's somebody in Write the Docs Slack, whether it's somebody you've connected with on LinkedIn or somebody you met at a conference and really hit it off with. I mean, for me, I have this ever deepening pool of previous guests whose expertise I also try to go back to. And most of them have shared their contact information on the show. So feel free to reach out to them if it feels like there's an overlap between what they're great at and what you need help on. Kate Mueller: [00:09:03] Heather and I also talked about the variety of non-text forms that technical communication can take, including things like short form TikTok-style videos, animated GIFs, audio podcasts like this one, live workshops, longer videos, and interactive Figma lessons. As Heather noted, some of these do require very different skill sets. And if you come from a traditional writing background, you might not be comfortable tackling all of them. But this is a place where having a varied background can be really useful. If you've had experience editing video or creating video content, or you've been a podcast guest, or you just really like playing around with Photoshop to create animated things, those experiences can all be brought to bear, and giving some thought to both the best ways to communicate the content and the media or methods that you have available can push all of us to be a little more creative in how we're creating and sharing materials. And in the end, I think the communication itself only benefits from that exploration. Kate Mueller: [00:10:15] And that conversation reminded me of how I tried out some different formats and elements in the change management toolkit docs. The toolkit really presents a framework and then provides detailed examples and step by step guidance to walk you through it. And it's some of the, I think it is the longest form content in the Support KB, the most tutorial-type content in the Support KB and we didn't really have a style guide for those kinds of pages. The one thing I knew was that I felt pretty adamant about each step in the framework being a single page, and as I was working on it, I wanted to provide detailed examples and scenarios, and I realized that that was creating this giant wall of text. And so just that giant wall of text prompted me to come up with, “Oh, I want to add just like some little visual delights here and there, maybe some tabbed sections or expanding sections, some of those things.” And I'm still kicking around like, maybe we'll add the recordings from the webinar series into the toolkit, as well. I'm not sure yet. I wouldn't say there's a single best approach. I tried to get Heather to commit to that and she was like, “No, actually, a lot of it depends,” but I think that's true. I like to try different things, and like Heather, I like to see what feels like the best path forward or what my readers seem to respond to the best, rather than to just assume that a particular format is the way to go. Kate Mueller: [00:11:50] In the last couple episodes, I've talked a lot about how good technical documentation helps reduce stress, whether that's stress for your readers or stress for your fellow contributors. But I really liked how Heather framed this more positively as giving someone else confidence: confidence to complete a task or try a thing or whatever. And I'm really trying to work to reframe it in my head this way, too, because removing something negative can be motivating–I think we all want to remove negative things from our lives–but providing something positive is in many ways way more motivating. So if we can remove stress and build confidence at the same time while clearly communicating potentially complicated things, I mean, that seems like a win on every level for everyone involved. And I think I personally find it a slightly more inspiring goal just because there's this qualitative distinction. So for example, some documentation can be a bit confusing or outdated, and that documentation can technically still help your reader solve their problem. And because it helps solve the problem, you could argue that it removed stress, but because it was confusing or outdated, it might have required them to do some additional work in order to actually solve that. And that additional work, in essence, levels out or offsets whatever stress reduction you had. So the stress reduction goal here might not be as useful in this context because somebody did still solve their problem, but they didn't feel as great about the way that they solved it. And it's fairly safe to say that confusing or outdated docs won't make your reader feel confident; they're not going to leave feeling amazing about that experience. So confidence-building feels like a better aspiration to have for our documentation, even if it's harder to measure. But for me, I often like to keep that overall goal or aspiration in my mind as I work on docs, and this feels like a more inspiring goal than just reducing stress. Kate Mueller: [00:14:05] 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. Kate Mueller: [00:14:28] The other thing Heather's episode has had me reflecting on a lot is all the places that technical communication shows up in our lives. In the episode we shared a few very specific examples, things like medication instructions, pet care or child care instructions, and restaurant menus, especially subheading labels and specials inserts. Over the years, I've encountered a wide range of definitions for both technical communication and technical writing. Some folks use the terms interchangeably. Some focus almost exclusively on writing. Some, like Heather, lean into the fact that communication can take many forms that may not have much to do with writing. Some include nearly every form of professional or business communication. Some expect that the subject matter is technical or scientific in nature, especially documentation for hardware, software, infrastructure, and research. Pick your flavor. There's a bunch of different definitions, but the common threads in most definitions include the idea of breaking down complex or technical details into smaller pieces, and the ultimate goal being to support or encourage someone to complete a specific action or task. So they are generally inherently transactional in some way. We are expecting a reader to take action, and we're hoping that we get them to feel a certain way as they're taking that action, even if it's just that they complete the thing or feel competent doing it. Kate Mueller: [00:16:08] My own bias on this is that there's a whole wealth of types of technical communication out there. And by extension, there are a ton of folks who are technical communicators or technical writers who would never call themselves that. As you've noticed, if you've been here for any episodes, really, this year, part of my goal this year is to dig into that poorly defined, but no less technical area of communication. I trace part of the seed for this focus back to my episode with Marsha Reifer Johnston, which was, I think, episode eight, where she shared an essay debating whether a cookbook qualified as technical writing. Spoiler: I believe it does. I will link to that episode in the show notes if you want to go back to the source or just refresh your memory. But my somewhat broad definition of technical writing and communication isn't to say that everyone is a good technical writer. [00:17:05] I've wondered a bit if some listeners may have felt like I was cheapening or devaluing the field by arguing that you can do this work without formal training. And as I've thought about this, I think I feel like I'm a bit like the chef in Ratatouille, chef Auguste Gusteau, the dude who's dead, but the one who proclaims that “anyone can cook.” Most of the characters spend most of the film assuming that he means that everyone can cook, but really, instead, he means that amazing chefs can come from any background or experience. I believe technical communication is the same. I've met skilled technical writers with degrees in technical communication who've clearly benefited from that formal education path, but I've also met amazing technical writers who have no formal education in tech comm who came from, you know, they were software developers. They were tabletop game developers, they were support people or customer experience folks or marketing or sales, or they were doing instructional design and kind of realized that they were good at technical writing. So these folks have no formal education in tech comm, but they've picked up things as they went along. They learned from great mentors and they just continued to push their craft forward. And I like to take a democratic approach and assume that anyone can develop the skill set if they enjoy the core work of it. As Heather noted, so much of the work we do isn't about spewing out everything we know about a topic on the page, but about choosing how to organize and present that information so that it helps your end user, your reader, or your watcher to have confidence to complete the task they're hoping to accomplish. Kate Mueller: [00:18:54] And if those are interesting problems for you and you like solving them, then how you get the experience or training is more a matter of your idiosyncratic, nonlinear life path than it is a prescribed set of steps. And I had a really lovely interaction recently that drove this point home. So indulge me, I'm going to tell you a story. I have a couple t-shirts for this podcast that say on the front, “I'm a not-boring tech writer.” And then they have the full podcast logo on the back. And I just happened to be wearing one of these t-shirts last week while I was out running errands. And my local natural and organic foods shop has just opened their second branch ever. And I stopped in at that branch for the first time to kind of scope out what they had and to pick up a couple things and just to see what the space was like and what was different. And when I went to check out, the gal behind the register read my shirt and, and she said, "You're a not-boring tech writer? I have to ask, what's that about? What does that mean?" And so I explained to her that I host a podcast about technical writing, and we do two episodes a month, one's an interview and one's me reflecting. And usually this is about the point in the conversation where the person I'm talking to tries to find an elegant escape or change the subject. Trust me, the only thing people assume is more boring than tech writing is a podcast about tech writing. But instead she surprised me. She said, “So what are SOPs in relation to technical writing?” And I said, “Oh, well, SOPs are a type of technical writing.” And she said, “Really? Because I write SOPs.” And I broke out in a huge smile and I said, “Well, congratulations, that means you too are a not-boring tech writer!” And she smiled and kind of giggled to herself a little bit. And as I finished paying and I went to leave, she said that she'd really try to check the podcast out. And who knows, maybe she did. Maybe she's even listening to this episode right now. That would be amazing. But it was such a timely reminder that all sorts of folks with all sorts of job titles are creating all sorts of technical communication every day. And my hope is that we keep drawing in these different perspectives and different listeners and different guests so that they can recognize they're part of this much larger community and find ways to deepen their skills, or even just feel more comfortable saying they have those skills, to be able to put, I've done technical writing, or I've written SOPs or whatever on the resume. Kate Mueller: [00:21:40] And also, this is probably a great time to remind you that we sell stickers, t-shirts, and other not-boring merch through Teepublic. You can access that on thenotboringtechwriter.com, and just open the Merch tab, because you too could be having some conversations just like this one with totally random strangers asking you about being a not-boring tech writer. Anyway, all these interactions in the last month–my conversation with Heather, the change management toolkit webinars, even my interaction with the SOP-writing cashier–they've left me with a clear intention for this month, which is to continue to double down on being thoughtful about the formats and media I use to communicate the concepts I'm working on. And I don't expect to spend this month adding a ton of non-text resources into the support KB. But what I am doing is I'm using my article editor content review as an excuse to add to my docs backlog, and I'm capturing a list of pages where additional resources or other formats or media types or methods would feel like they'd really improve the reader experience and more effectively communicate whatever concept or idea I'm trying to communicate. And my hope is that once I get through this round of the editor layout updates, I can start to tackle this list, but right now it's mostly just aspirational. I just want to capture those ideas so that future me can come back to them. And so I hope you can join me this month in at least laying the groundwork for some future thoughtful, non-text additions to your docs to make them a little more accessible to different learning types, maybe a little bit more engaging. And as always, if you have 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. You can also hit up thenotboringtechwriter.com and select Suggest a guest to recommend yourself or someone else as a new guest, or pick up some merch. Kate Mueller: [00:24:01] 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.