The Not-Boring Tech Writer

In this episode, I talk with Heather Zoppetti, a senior technical writer who came to the field through software development and a decade spent running a hand-knitting pattern business. We talk about how technical communication shows up far beyond software documentation, how to recognize and reframe the transferable skills hiding in a nonlinear career, and why being willing to try something matters more than doing it perfectly.

—

Heather and I discuss her winding path into technical writing, which started with a career in software development, took a decade-long detour into running a hand-knitting pattern and yarn business, and eventually circled back to tech. When she returned to job hunting and realized she no longer recognized the skills developers were expected to have, she stumbled on a technical writing posting and recognized the work immediately: writing knitting patterns is technical communication. She applied using her knitting patterns as her writing portfolio, and we talk about why her tech writing instincts came more from designing knitwear than from her years as a developer.

A central thread of our conversation is the idea that technical communication is far broader than software documentation. Heather pushed me to think beyond written text to formats like videos, live workshops, interactive lessons, and animated GIFs, and to recognize that different audiences and learning styles call for different approaches. We dig into her experiments with internal documentation at Vanguard, including running user research cohorts to learn the why behind how people use content, and why metrics alone can't tell you whether someone was genuinely absorbed or just stepped away from their desk. We also explore what happens when a docs team builds its own site using the design system it documents, and how "drinking your own champagne" surfaces bugs and builds trust with users.

We spend much of the second half on transferable skills and how to reframe a nonlinear career for a tech writing role. Heather and I both believe more people have technical communication experience than they realize, whether it's a pet medication schedule, a tax prep sheet, a restaurant menu, or a cheat sheet you wrote so your family stops calling you for help. We talk about treating your resume and cover letter as their own forms of technical communication, mapping your experience to the language in a job description, and why good documentation ultimately leaves your reader feeling confident they can do the thing. Heather closes with a reminder that stuck with me: you don't have to go all in to try something, and the only real way to find out if something is for you is to give it a go.

About Heather Zoppetti:

Heather Zoppetti, from Philadelphia, has a rich background in computer science and technical writing. Her current professional journey has her spending her days programming, creating tooling for engineers, and writing documentation. When she’s not typing away at code or text, Heather’s knitting, painting, or performing some other needle witchcraft like cross-stitch. She loves coffee, cats, and the Oxford comma.

In this episode:
  • [00:01:20]: Heather's origin story: from software developer to hand-knitting business owner to technical writer
  • [00:03:15]: Recognizing knitting patterns as technical writing and using them as a portfolio
  • [00:05:59]: Heather's current UX writing role and the value of not being a lone writer
  • [00:08:51]: How companies value documentation and where it sits in the org
  • [00:12:42]: Why "technical communication" is broader than "technical writing"
  • [00:13:51]: Meeting different learning styles with video, GIFs, workshops, and more
  • [00:18:04]: Experimenting with internal docs, user research cohorts, and the limits of metrics
  • [00:23:06]: How different roles (designers vs. developers) prefer to learn
  • [00:28:13]: Job titles: technical writer, content writer, or documentation engineer?
  • [00:29:52]: Tooling constraints and building a docs site with your own design system
  • [00:31:03]: "Drinking your own champagne": how dogfooding surfaces bugs and builds trust
  • [00:34:40]: The case for transferable skills and the tech comm you already do
  • [00:39:37]: Technical communication everywhere: medicine labels, pet care, tax prep, and menus
  • [00:47:48]: Reframing a nonlinear career in cover letters, resumes, and interviews
  • [00:52:36]: Interviewing, imposter syndrome, and transferable skills
  • [00:58:52]: How good documentation leaves your reader feeling confident
  • [01:01:08]: Resource recommendation: the Write the Docs Slack and community
  • [01:03:15]: Best advice: just try it, and treat new things as experiments

Resources discussed in this episode:

Join the discussion by replying on Bluesky

—

Contact The Not-Boring Tech Writer team:

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

Contact Kate Mueller:

Contact Heather Zoppetti:

Contact KnowledgeOwl:

Creators and Guests

Host
Kate Mueller
Kate is a documentarian and knowledge base coach based in Midcoast Maine. When she's not writing software documentation or advising on knowledge management best practices, she's out hiking and foraging with her dog. Connect with her on LinkedIn, Bluesky, or Write the Docs Slack.
Producer
Chad Timblin
Chad is the Head of Podcast Operations / Co-Producer for The Not-Boring Tech Writer. He’s also the Executive Assistant to the CEO & Friend of Felines at KnowledgeOwl, the knowledge base software company that sponsors The Not-Boring Tech Writer. Some things that bring him joy are 😼 cats, 🎶 music, 🍄 Nintendo, 📺 Hayao Miyazaki’s films, 🍃 Walt Whitman’s poetry, 🌊 Big Sur, and ☕️ coffee.
Guest
Heather Zoppetti
Heather Zoppetti, from Philadelphia, has a rich background in computer science and technical writing. Her current professional journey has her spending her days programming, creating tooling for engineers, and writing documentation. When she’s not typing away at code or text, Heather’s knitting, painting, or performing some other needle witchcraft like cross-stitch. She loves coffee, cats, and the Oxford comma.

What is The Not-Boring Tech Writer?

Some people hear the phrase "technical writing" and think it must be boring. We're here to show the full complexity and awesomeness of being a tech writer.

This podcast is for anyone who writes technical documentation of any kind, 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—there's a place for you here.

Each month, we publish two episodes: an interview with an amazing guest focusing on useful skills or tools that can help you improve your tech writing skills, and a behind-the-scenes solo episode with host Kate Mueller about what she’s working on, struggling with, or thinking about in her daily tech writing life.

The Not-Boring Tech Writer is generously sponsored by KnowledgeOwl, knowledge base software built for people who care, by people who care.

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’re passionate about documentation, you belong here, no matter your job title or experience level. Welcome!

Kate Mueller: [00:00:29] Hello my lovely, not-boring tech writers. Today I am so excited to welcome to the podcast, someone that I connected with almost a year ago at Write the Docs Portland 2025, when she gave one of my favorite talks of the conference, which was called “Knitting Together a Technical Writing Career,” talking about the ways that creating knitting patterns actually is a form of technical communication. And in keeping with this year’s theme of technical writing is so much more than just software documentation, I thought she would be one of the best guests to have on. It’s taken us a year to have her on, but here we are and I’m so excited to welcome to the podcast, Heather Zoppetti. Heather, welcome to the pod at long last!

Heather Zoppetti: [00:01:13] Thank you. Thank you for having me, Kate. I’m really excited to be here. And I know scheduling is always a difficult thing, but we got there.

Kate Mueller: [00:01:20] We got here eventually. It’s happening before, I mean, we’re recording this before Write the Docs 2026, so I still feel like we’re more or less on schedule. It’s fine. It will air after Write the Docs Portland 2026, but that’s okay. This is just how the recording world works. So for folks, Heather, who have never heard from you before, haven’t seen your lovely talk from last year, can you tell us a little bit about what I would call your tech writer villain origin story? How did you get into the technical writing space at all?

Heather Zoppetti: [00:01:53] So my origin story really starts with software development. So I was a developer out of college. I did that for many years, and then I fell into this rabbit hole of crafting and knitting, and it just became my obsession in life. I was very privileged back then to be able to quit my full time job and really focus on designing and, of course, like things do, it didn’t stop there. I was designing hand knit patterns. I got into the whole scope of this career where I was like, okay, now I’m going to do yarn. I started distributing patterns and yarn wholesale to shops all over the place. And it was a small business, right? So eventually I had some personal life changes and needed to get what I call “a real job.” I mean, that was definitely a job, it was just more of a hobby business, a small business. I ended up moving to Philadelphia, and it was much more expensive to live here. I was like, I need a little more. But I, as a software developer, I was like, I could get back into tech. Let’s check that out. And I started looking at all these job postings and stuff and not recognizing anything that was listed there as wanted skills.

Heather Zoppetti: [00:03:15] Things move so quickly. It had been almost ten years, and I’m looking at the requirements for these jobs. I’m like, I don’t know what any of this stuff is. I was doing Java and HTML. I mean, they still use HTML, but now there’s all these fancy frameworks and all this DevOps stuff. And I was like, oh, no. I didn’t want to go back to school or to take a boot camp. And I just happened to stumble upon a listing for a technical writer. And I was like, what is this? What is happening here? And I’m looking at it. I’m like, I could do this. This is great. I didn’t know that this was a career. I didn’t know it was something people made money from doing. And one of the biggest, not panic points, but things of course that when you’re job searching is like, do I have the skills for this? I mean, I had been a developer for so long, and that’s what I had felt comfortable doing in the tech space. Then I started thinking writing knitwear patterns is technical writing. This is very similar to what it sounds like they’re looking for. I’m making tutorials, I’m making guides. This is a step-by-step how to create a knitted object. And so I applied in that way using my knitting patterns as my writing samples to apply for that first job.

Kate Mueller: [00:04:40] Ah, so we always talk about the importance of having a good portfolio when you’re applying to tech writing roles, and I totally love that you used knitting patterns as your portfolio. That’s awesome. And what a way to make yourself stand out, right? Like, here’s a completely different form of technical writing, but it demonstrates all of those same skills, right? You’re taking a complicated thing and trying to simplify it. You’re trying to make it a reproducible process so that people can go through step by step and create the thing that they’re intending to create from the beginning processes. That’s fantastic. How long were you doing the knitting patterns? Like, how long did that hobby business last for you?

Heather Zoppetti: [00:05:22] I started it and was still doing that while working, but it was about ten years from writing my first pattern, getting that published, to when I returned to the tech space.

Kate Mueller: [00:05:35] It is an excellent lesson in how rapidly the tech space changes, but how some of the underlying skill sets are still super applicable, depending on which area of tech you choose to focus on. So are you still doing a technical writer role, or have you gone back to form, and are you doing software development? What does your current role look like?

Heather Zoppetti: [00:05:59] Oh yeah. So I am a senior technical writer at Vanguard and it is in the UX space. So it’s a little bit different from the developer technical documentation, but I still work a lot with the developers. It’s not isolated just to UX, and I guess I’m just doing it all. I was a lone technical writer here for a year and a half, and we just hired a second technical writer. So that is very exciting not to be the only one, to have someone at work to chat with some of these topics with and things like that really dig in. So that’s great.

Kate Mueller: [00:06:36] Oh, that is fantastic. As somebody who’s been a lone writer for most of my career, and occasionally I’ve gotten to pull in a secondary person and it makes such a difference to have somebody else to just bounce some ideas off of to be like, “Hey, I’m thinking of solving this problem this way. Do you think that that’s the best solution here? Are there other things?” Or sometimes I’ll do the, “Here is the problem. How would you solve this?” And then I see what the other person comes up with is aligned with what I’m doing, better than what I’m doing. Maybe not quite as good as what I’m doing. Sometimes you just get these ideas from somebody else that you would not get just on your own. And that collaborative element is really nice.

Heather Zoppetti: [00:07:18] Yeah, it’s really interesting. The other person now is from a different background and has different experience. And I think that’s, in any role, it’s like if you can bring people together that have that diversity of past experience, they’re going to bring ideas, problem solving from a lot of different places that you don’t have access to. And I think that’s really what makes a strong team.

Kate Mueller: [00:07:40] Yeah, for sure. And it’s also one of those ways that hiring somebody who maybe doesn’t have a technical communications degree, for example, sometimes there’s huge benefit to doing that because the both lived and work experience that they have is so different than somebody who came up through a university program did sort of like a traditional career path, whatever. Maybe this is my own bias because I have a very non-linear career path, but I think there’s huge value to the folks who’ve been like, yeah, I went and did this other thing for two years, five years, ten years, and from that, I learned these things and I can bring some of that to bear. Has there been anything in that transition for you leaving software development, getting into being your own boss, so to speak, and then coming back to work for an organization and shifting into that technical writer role. Was there anything in there that really surprised you along the way where you were, other than the, I didn’t even know this was a career or a thing that people got paid to do. That’s like a great, happy surprise. But was there anything else?

Heather Zoppetti: [00:08:51] What really surprised me here is that as a developer, being in that user seat gave me the perspective that everyone loves documentation. Everyone loves documentation and they appreciate it when it’s done well, but it didn’t seem like anyone was willing to be the ones to create that great documentation. I say it’s a surprise, but I think the real surprise there was that it seemed like companies were starting to get that right. They had that realization and they were doing something about it. I know technical writing has been around for long before I got started, I’m not saying it was just created. I had just stumbled upon it, but it really felt like that was the time where companies were really leaning in, really dedicating a lot of resources and upping the importance of it. And that was really refreshing in a surprising way to see happening in the technical industry.

Kate Mueller: [00:09:54] It felt, maybe still feels (I don’t know maybe AI changes the equation on this a little bit) but I think it certainly felt to me like there was this larger industry shift where like historically, folks have often viewed documentation as a cost sink, sort of like support, like, oh, it’s a thing we have to do. And it felt like there was a bit of a mindset shift, at least among certain companies that like, hey, this is actually an opportunity for us to more fully develop the product. I think a lot of companies did embrace that idea of docs as product, or at least as an extension of your product, and started to think about what the end user experience was of the documentation in addition to the product and how, maybe not how, but like what the interplay or the relationship between those two things could be or should be, for example. And that means that people actually started to care about the quality of the documentation and to treat it a little more seriously. Not everywhere. There are certainly places that it’s still a cost sink and people don’t want to plow money into it or now where they think, let me just replace all my human writers with AI and what could possibly go wrong there in the next two years, right? But I do think that it is one of those interesting things, that contrast between everybody loves using good documentation, but boy, do we not like bad documentation. Also, making the case to prioritize good documentation can also be trickier.

Heather Zoppetti: [00:11:29] Yeah, I think that’s interesting. The company that I worked for originally, my first technical writing role, they actually had the docs team in the marketing team because they saw it as helping brand adoption and trust and repeat customer usage and things like that. And so I thought that was an interesting positioning as well.

Kate Mueller: [00:11:49] It’s an interesting choice. I mean, seeing where docs fit in the organizational hierarchy can be really interesting and really telling. I’ve worked places where it’s part of product or it’s under engineering or dev or I’ve never worked anywhere where it’s been under marketing, but I certainly know people who have. I’ve even seen it under operations because it got grouped with support or it lives under support, for example. There’s a lot of different flavors there. And I do think you can learn a lot about an organization based on where they group it and both the team structure and the reporting structure there looks like. I don’t think there’s a one right answer there. It just depends on the organization and what their goals are for the documentation and how they’re set up. Some orgs just have a very weird hierarchy also.

Heather Zoppetti: [00:12:41] Or no hierarchy.

Kate Mueller: [00:12:42] Or no hierarchy, also, yes, or we’re a small startup of like 5 or 8 people, and everybody just does a little bit of everything and sometimes documentation becomes a piece of that. For me, a lot of my work experience has been, oh, this is one hat among many that I get to wear for the day, and hopefully I have enough time to do some of this today. One of the things I really appreciated in our conversations leading up to this interview was you pushing back a little bit at me, just saying “technical writing,” and instead focusing on broadening that to “technical communication” in a broader sense. So, not just written text, but also perhaps things like TikToks or YouTube videos or other formats. And I’d really love to dig into that a little bit more, because I do think collectively as a domain, we tend to prioritize written words over other things. And I want to dig into your experience here. Did you do video type stuff for your knitting business?

Heather Zoppetti: [00:13:51] Yeah. And I think that’s where I first kind of really embraced this idea is that when I was doing knitting stuff, it was the start of the YouTube era and everyone was scrambling to make a presence. And then of course, it just got bigger and bigger. You have Instagram and TikTok and all these things, and you become the brand personality and all this. But it was more than just showing off your stuff, but people started making these great tutorials or even hosting classes. And I’m like, this is fantastic because everyone has a way that they learn best. And when it comes to technical documentation, whether it be for knitting or recipes or technical developer documentation, everyone has that mode where, okay, yes, they could read a thing and probably figure it out, but maybe that’s not the best thing for them. I started seeing, of course, when I got back into the tech space, I started seeing tutorials even for coding, right? There were all these personalities who were doing either setup for their servers and stuff, but even just coding tutorials where they were showing their code editors and stuff. And I was like, this is really interesting and really amazing to see that platform that we think about as being text, because code is text, and being translated into these other great formats that makes it more accessible. And I think that’s really the crux of it, right, is that we want our information, no matter what the topic, to be accessible by the most amount of people. So if it is through an audio podcast or a YouTube video or a brief TikTok, or even just as simple as making a shift to using more like animated GIFs in your documentation to be able to show a flow or a process. I think these types of things really, even though it’s more work, different skill sets, it really opens that accessibility to other types of learners.

Kate Mueller: [00:15:55] There’s also something to be said for recognizing that different types of content lend themselves naturally to different formats. I’ve been thinking about this a lot in the KnowledgeOwl Support knowledge base because that’s most of the documentation I build and I’m doing some massive updates because we’re overhauling our editor UI, and some of the pages I’ve come across have been like, “oh my goodness, it took me an absurd amount of text here to try to explain this concept that underlies this feature, and this might be a really good candidate for a video instead, because if I could show you this in some way, shape, or form, that’s a little bit more visual and be able to talk about it at the same time, I could probably give you like a 2.5 minute video that would replace these five paragraphs of text that I don’t even want to read, and I wrote them, and I know this feature inside and out.” And I think there is a lot of room to negotiate there to think about what’s the most effective way to try to communicate this information? Is it a video? Is it just visual or graphical in nature? Is it maybe a combination of those things so that you’re using the visual or graphical to help signpost the really important stuff or drive that home? And it does, I think, push some of us outside of the text only, but in a good way, because you’re really thinking more about how other humans consume and access information and how they actually internalize those things. And I am not generally a very good video learner, but there are certain conceptual things that it is much easier for me to wrap my head around it if I can see it, like, show me how you do it, and then the written instructions will make sense to me because I now have the image of what it’s gonna look like. Are you still doing that kind of multimedia content in the work you’re doing now?

Heather Zoppetti: [00:18:04] Yes and no. What I’m doing right now is a lot of text. But then we have, and I don’t want to lean too much into the educational aspects of it, but we do a lot of education for internal users. So these are documents and programs that are for upskilling employees to know how to do their jobs better. And so we’ve been able to experiment a lot, which I’m super grateful for. So I know there’s definitely a difference between making public offerings of your documentation versus internal. And I do like to just point out that when we’re talking about internal documentation, there’s a lot of flexibility there. People are willing to try different things. So we’ve had videos, we do live workshops, we have interactive Figma lessons, like all these different things to try to figure out what’s going to serve our users best. And sometimes there’s not one answer, right? Like you said, there could be something that has the video and a document that says the same thing, but in different ways to visually demonstrate that is going to be very powerful because folks can reference different things and they’re going to get different things out of each of those methods. So being able to experiment, I am very lucky to be in that situation, but it has also given us a wealth of different offerings that we can keep up with simultaneously. We don’t have to pick just one.

Kate Mueller: [00:19:29] And what do those experiments look like for you in terms of how do you evaluate the outcome of the experiment? How do you look at that and say, hey, this worked really well for this thing? Are you getting feedback from those internal users or what does that look like?

Heather Zoppetti: [00:19:44] Yeah, we actually have a program here that we do like small research groups. So we call them cohorts and we bring folks in. Again, our users are internal, but we contact them. We get them to join these, I want to say workshops, but basically it’s user research, even though it’s internal. So we’re sitting down with them. We’re evaluating having them run through, give us their feedback, things like that.

Kate Mueller: [00:20:07] Oh, nice. It’s, I would say in the documentation space especially, it can be very hard to get that direct end-user feedback about like, what was this like for you? Where did you get lost? What was working really well? So the fact that as a company, they’ve committed to that and they’re like, hey, we have this workshop format, let’s use it and you can get feedback. That’s fantastic. Is that normally a very discrete time boxed thing or do you ever have ongoing efforts for it?

Heather Zoppetti: [00:20:39] The ones that we do internally are very time boxed. They are very focused. And each session needs to have a very specific thing that you’re testing for. And I think they’re just wonderful. Again, to have that opportunity to be able to, like you said, ask our users when you see this menu structure, walk through it, talk about what you see, how you’re feeling, what’s confusing, what’s working, that kind of thing is just so valuable because otherwise we are maybe looking at metrics of how people click on things, trying to guess what they were thinking. Did they get confused or did they just have to go to the bathroom? You don’t know. You don’t know the whys of something that’s happening just based on gathered metrics. So it’s really nice to be able to talk with these folks face to face and to be able to hear some of their thought process, too. When you’re using this feature, what are you thinking about? Is it helpful? Is it confusing?

Kate Mueller: [00:21:38] Yeah, it very much is like user experience research, those interviewing moments because it gets at what somebody’s thinking or feeling when they’re interacting with the thing instead of just what did they click on? How long did they spend time on this page? Because what you’re not seeing in the time that they spent on the page is like, oh, it took me a while to read this. I got interrupted four times and I had to keep going back because I got interrupted. And then I realized about two thirds of the way through that this wasn’t exactly what I needed or what I thought it was, but then I had to figure out where to go instead. But I also got interrupted somewhere in there, and I eventually just gave up. And if you look at time on page, it might seem like, hey, they got a lot out of that. But it turns out that they were actually not even looking at the page for a big chunk of that. And then when they were, there wasn’t necessarily the most positive experience coming out of that either.

Heather Zoppetti: [00:22:34] Yeah. But from the numbers, they were super absorbed and they were there for an extended amount of time.

Kate Mueller: [00:22:39] Yeah. It’s what the metrics can’t tell you is all that stuff that’s happening around the usage. As you do those experiments, and particularly if you’re doing stuff with different formats or media, has that allowed you to create sort of a general framework of certain types of content? We do both video and written text for example, or is it not generalizable in that way?

Heather Zoppetti: [00:23:06] It’s a little tough. I feel like there’s definitely trends in role type. So you’ll see UX designers prefer a certain method versus a developer even on the same kind of information. So say that they’re interested in cross-learning the other discipline. Even there, you’ll find differences in role and I don’t know if it is more of a learned habit. So what we’ve seen, like designers obviously, are very visual. They are interested in seeing those pictures, seeing that animation or those videos. They can grasp things very quickly, visually that way. And then of course, developers are very much more text based. Just tell me what I need to know. What’s the thing I need to copy? That kind of thing. But it’s just saying that I feel like that is something that is almost a self-fulfilling prophecy. Or it’s like the more and more we feed into that, the more we reinforce it. So it is interesting and we have not done a whole lot of cross mixing yet. Still doing a lot of research of just finding that. You do catch those folks that are developers who love to watch video tutorials, and designers who would rather read a quick start guide than to have to go through an interactive lesson. So it’s interesting.

Kate Mueller: [00:24:31] Yeah, it’s a thing I think about a bit because doing the KnowledgeOwl documentation, a lot of my readers end up being people who write. And so you would think that a lot of these folks would have a preference for text over other things. But then we periodically get some folks who are like, I would like a video library that I can just binge watch. And at the end of it, I know everything there is to know about KnowledgeOwl. And I’m like, well, we don’t have that yet, but we do have some videos. Here are the ones we have. Here’s kind of what that covers. And it is interesting that there are maybe some general assumptions about roles and people’s learning styles, and whether that’s people became UX designers because they naturally learned more visually so the visual stuff was easier for them, or whether it’s like, because they’ve just been interacting with visual stuff for so long, they just have a more refined skill set evaluating and learning that way. There’s a chicken and egg question there I’m not even going to attempt to answer, but I do think it’s really fascinating, and I think it does put a lot on us to try to think about, there’s not necessarily a single best way to share this, but what feels reasonable for us to maintain what feels like it’s going to provide value to the person who’s engaging with that content.

Kate Mueller: [00:25:53] There has to be a Venn diagram where there’s an overlap somewhere in there. Let’s find that. And then maybe let’s test a couple different things. I ran into this in my documentation recently where I had to dig into a concept that’s been in KnowledgeOwl for a really long time, but has always been really complicated, and I was updating documentation on it and I was like, I don’t clearly explain the complication in any one page. It’s like half-explained in four different pages. And now I’m wondering if part of why people have struggled with this conceptually is that the documentation is just confused. And perhaps if I can explain this better, maybe that reduces some of the confusion people have around this. But first I have to figure out what bits of this are worth keeping. Yeah, documentation is always humbling.

Heather Zoppetti: [00:26:42] It’s an interesting puzzle though, right? Like I think explaining that problem that you’re having and that you saw is just the core of the job, right? It’s like, how do I organize this? Obviously, anyone, AI or whoever can just spew out all the information you know, like, oh, this is everything that I know about this topic. And here it is.

Kate Mueller: [00:27:14] It’s kind of just like a brain dump. Here’s the thing. Let me just tell you everything you need to know about this thing.

Heather Zoppetti: [00:27:20] But being able to take those pieces and say, you know, what? If I reorganize it this way or state it a little differently or add a video, whatever it needs to be to solve that problem of, can I make people understand what is happening here, what they need to do? And I just think that that kind of problem solving is fun.

Kate Mueller: [00:27:43] It is. I mean, I think you have to kind of enjoy that problem or else you don’t enjoy the role, right? Like, if you don’t enjoy that little bit of complication, it does suck a lot of the joy out of doing the role, I suspect. As we’re on the topic of roles, I’ve had a bunch of guests on. Some of them identify as technical writers, some prefer all kinds of other titles. How do you describe the work you do? Do you call yourself a technical writer or do you prefer a different label?

Heather Zoppetti: [00:28:13] So my official title is Technical Writer. I think that’s fine. I think it’s a nice umbrella term that really covers a lot of things. I have been a technical writer, I have been a content writer. I’ve been a documentation engineer, which may be my favorite only because in a lot of these roles that I take, I am doing a lot of the docs site maintenance and coding tasks and tool creations. So I think that really leans into a little bit more of what is actually happening in the role, but I don’t really have a preference. I think that I don’t have a strong opinion about it. I think that the more important thing is that in your role, you understand what your responsibilities and expectations are and that’s clear.

Kate Mueller: [00:29:06] Is there anything in the work that you’ve been doing that there are tools you particularly love using for certain things? So if you’re especially as you’re running these experiments, if you’re whipping together a video or some graphical stuff, is there anything in there that you’ve been like, oh, I really prefer to use X for this if I’m going to use it.

Heather Zoppetti: [00:29:28] Yes and no. I mean, I don’t.

Kate Mueller: [00:29:31] The last time I got asked this question, I was like, now I can’t think of a single tool I use. I have completely blanked. What is the tool? I don’t know, what do I even use? Oh God, do I have to just go open the list of programs on my laptop to try to remember what it is I use? I panic whenever I get asked this question. So if you don’t know the answer, that’s fine. That’s totally fine, Heather.

Heather Zoppetti: [00:29:52] In my current role, there are a lot of security restrictions, so our third party tools are somewhat limited. And I don’t want to make that sound like, oh, we can’t use anything. It’s just, we definitely lean in on how we can maximize the tools that we have. So a lot of things are okay using Teams, sharing. We all have Macs, so the screen recording. And then luckily because I’m in the UX organization and the designers, having a reliability on that Adobe suite, things like that are really helpful. But the interesting thing is, so I don’t think I said this before, but I work on a team that develops our design system. And so one of the things that I thought was really important when I first joined was that we use our design system in our documentation, our site, and all that kind of stuff. Like we’re talking about it, we’re giving usage guidelines, and it was an effort to convince folks that we should build our own site using our product versus using a prepackaged documentation tool or suite or CMS or anything like that. And so when you ask about tooling and things like that, I think my situation is a little bit different, obviously, as a design system writer, but that we would use our own tools for this work versus something that’s already prepackaged.

Kate Mueller: [30:55] Did building your site using those tools lead to any changes to how the system worked?

Heather Zoppetti: [31:03] Absolutely. And I thought that was one of the biggest learnings, findings for our developers, where they actually found bugs in some of the components. And it was like, yeah, because you’re using them, you’re seeing them in an environment that would be reasonable to expect our user developers may have to run into this as well. Now you see what it’s like to use them, how to use them, like any kind of difficulties or stumbling blocks. And so that was really cool. And I think that’s just part of the experience and gives us more trust within our user base as well to say, look, we use this, too. We understand what it’s like. This is how we can explain this or that, or when troubleshooting or anything like that, it gives us a little bit more of that authority and trust to be able to say, we know.

Kate Mueller: [31:54] “Yes, I have run into that exact same issue and it also drives me nuts. But trust me, we haven’t found a better solution for it yet. We still are trying.” Yes. KnowledgeOwl is a knowledge base platform, and so I write in it. But it also means that a lot of times I’m like, I’m frustrated about this. I’m gonna put this in the backlog. Can we change this thing? Here’s exactly why this is a pain point for me. And the more I can get more of our team actively writing content in it, using the features, it does surface things where people are like, that does not make sense. I know why we built it that way at the time, because we had some technical limitations and this was the best we could do. But now we have not the same technical limitations, and this was really hard for me to figure out how to use, even though one of us built it three years ago and it’s a great opportunity. We call it drinking our own champagne, just because that sounds more appetizing than eating your own dog food.

Heather Zoppetti: [32:58] I love that.

Kate Mueller: [32:59] Because you’re building a quality thing, but you also need to taste it, right? To see where you need to keep iterating. And I think that metaphor just works a little bit better for us. But I think there is huge value to that. To the extent you can do it to get your team using the system you built, the product you built, whatever that is, to the extent that it makes sense to do that. If you’re building really bespoke stuff that your team has no valid reason to be using, you don’t necessarily want to do that because it might skew the direction you take the product. But for things like this where like, hey, I can put our developers directly in the seat that our user developers would be in and we could get them to experience those same pain points and feel where there’s friction still in that experience, there’s tremendous value in that. And what a delightful thing to have your documentation be the way that that gets facilitated. Like, “Hey, we’re going to build this using our system. Oh, this part was really hard. Does it have to be that hard? Could it be a tiny bit easier? Would that be possible?” And actually, this might be a great note for us to take a break. So we will take a break and we will be right back.

Kate Mueller: [34:17] 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: [34:40] All right, well then we are back. So, Heather, I will admit to having a slight ulterior motive in having you on the podcast, which is that I am incredibly interested in transferring skills into different roles and the ways that we can do that, can showcase how those skills are useful, can maybe play them up in our resumes. And your career path is just like a freaking masterclass in doing some of this, I think. And so I really wanted to have you on the podcast in part for this reason.

Kate Mueller: [35:19] So for a little context of some of what inspired this focus for 2026 on the podcast, I had a friend that I went to grad school with reach out to me last fall. She was a library and information science masters, that’s what she was getting when we were in school. And she had done a whole bunch of work on the library side in the government sector, etc. and she was out of work thanks to cuts in funding. And she was starting to look at developer advocate roles. And she had reached out to me. She was like, “A lot of these developer advocate roles say that I need to have tech writing experience or information architecture experience, and I don’t really know what those things are. And I want to know how I get experience in that.” And I was like, oh, you already have experience in that. Talk to me about what you have done to support your library patrons. Talk to me about what you have done to try to figure out how to best architect your library site. You’ve helped develop visualization tools, and you’ve written documentation on those tools and how to use them. Interesting.

Kate Mueller: [36:32] And suddenly she realized that she had this mass of work experience that directly tied to those skills, she just didn’t have the words to say, “Hey, I have experience doing X.” And so I have this theory because one of my theories is there’s a whole lot more forms of technical writing than most of us think about. But my secondary theory is a lot more people have skills in technical communication than realize they have those skills. And so I’d really love to hear about the pivot for you from your knitting business into the technical writing world and how you approached that because you seem to have been very successful in doing that. Maybe I’ll just leave it there, leave it really open ended. Talk me through it, and then I can figure out what else I want to ask you about it.

Heather Zoppetti: [37:26] Sure. And I think what it really comes down to, at least for me, is that it’s all about communication, right? So anytime that you are trying to communicate to somebody else an intent, instructions, or just information in general, I think that can be converted into these skills that we use every day at work. And for me, I know some people will look at my background and be like, “Oh, well, you were in software, you were a developer that’s skewing your idea of this.” And I tried to point out, at least in my talk and in other ways too, that I think that the skills for technical writing really came from my knitwear design rather than my developer sense. So when I was developing, I have to say, the internet was young. We didn’t have as many resources readily available. And so I felt like if you would have asked me about documentation back then, I would have had a negative view. It would have been like, oh, this is not really helpful. For me it’s more helpful just to like, do it, try it out, that kind of thing. And of course, it depends. Please do not mean that I am saying that all documentation was terrible back then. It was the products that we were using and just putting that out there as a disclaimer.

Kate Mueller: [38:51] To contextualize this, this is more than a decade previous. So the internet has grown significantly during that time. YouTube and other social media platforms have grown significantly in that time. Just the maturation of the content forms we have has been significant in that time period. So I’m with you. I don’t think that is an offensive statement. It’s just an acknowledgment of history.

Heather Zoppetti: [39:20] But so I think for me, it’s about how you organize your thoughts and how you convey that information. And if you can do that successfully, then you have communicated technically.

Kate Mueller: [39:34] You have technically communicated, well done.

Heather Zoppetti: [39:37] But it really comes down to, I mean, we think about different things that we consume all the time, right? So whether it be drugstore labels, bottles, like instructions on how to take your medicine, this is just something that I’m very familiar with right now. I have a dog who’s elderly and she’s prescribed medication and reading that confused me. Oh, when am I supposed to give this, like, what are they? It has to be very brief. That right there is just like a form of technical communication. You’re telling someone how to do something, how to administer or how to give something, and being able to do that clearly so people understand is very important. It could make someone ill if they’re not going to do it. Right?

Kate Mueller: [40:24] This is a fantastic idea actually. So I had a very special needs dog. She had a seizure disorder. She had a bunch of neurological stuff. And so it was very hard for me to travel and have anyone care for her. And so at the time, I put together a pet guide of like, okay, here’s when you give her the meds, here’s how you give her the meds. She was super routine-oriented, so here are the times of days and what you need to do. And as I’m thinking about it, I’m like, this would be a great writing portfolio addition because I’m taking a really complicated, messy being and trying to give you care instructions for that. And boy, that would be an interesting portfolio addition to something in the same vein of how do you administer these meds? Like is it with food, not with food? Am I doing this twice a day? Does it have to be 12 hours apart? Exactly. What does that look like? There’s a lot of nuance there. So that’s a fantastic example. Thank you. I’d never thought of that as a form of technical communication before. So I’m really excited.

Heather Zoppetti: [41:32] Yeah. I mean, it’s the same thing with kids, right? So I used to do a lot of nanny work and babysitting and stuff of course, when I was younger, and just having that information about the kids need to be at this place at this time. Make sure you pack this or that. This child needs more attention for homework. All these different things add up and how you communicate that is going to really impact the success of the person who’s reading it and trying to deliver that service. And so, yeah, I think that that is, I don’t know, you can find these little examples in so many ways all over and you don’t even realize it. I feel like my husband is kind of going through that discovery now because he knows my job, what I do. And now it’s a constant, almost weekly occurrence where he’s like, “The documentation was so bad, I couldn’t do this or that.” And he works with machining big machines that do like milling of metals and stuff like that. And so he’s always telling me like, I couldn’t set this up. The documentation was not great, all this kind of stuff. And I’m like, “Have you considered making a guide for your shop yourself that actually makes it useful for you and other people that work there?” And so he’s starting to lean into that more.

Kate Mueller: [43:01] So that you don’t run into that same hurdle 80 different times and you have to re-learn every time how to do it. So much of what I consider the technical documentation I made before I called myself a tech writer was cheat sheets on how to use particular programs or how I’ve adapted recipes that I cook that like, here’s the original recipe, but here’s the stuff I changed and why. Or I change it under these circumstances, but not these. Like if it’s winter, I make these adjustments versus summer. And that is technical documentation. If you’re saving yourself time from having to troubleshoot how to fix a particular thing on a machine because you wrote yourself a six-step guide on this particular issue, you’ve created very valid, useful technical documentation at that point.

Heather Zoppetti: [43:55] Yeah, absolutely. And I think one of the more timely examples that I’m just staring at right now, because it is April 13th when we’re recording this, is tax preparation, right? So I have someone who, thankfully, because I had owned a business, had used their services to help me file my taxes properly and we just continue to use them. But that process is complicated. A lot of people get really stressed out about it, and so they give me a sheet that’s very helpful. For this form, you need to do these things. You file it here, you write…I’m like, oh, this is awesome technical documentation. They’re walking me through this process and trying to make something that is stressful, as simple and easy to follow through. So it gives me confidence. And I think that’s a really important part of it. So you want to give your user, your reader, your watcher confidence that they can attempt this thing now. And so that is really kind of the goal of not just conveying the information, but then setting someone up for success.

Kate Mueller: [45:01] Yeah. Yeah. I mean, I think about the value of giving somebody a checklist of what the steps are, not even necessarily how to do them, but just these are the things, the steps you’re going to need to do. For an experienced user, that’s often all they need is a checklist like that. But we overlook that as a form of technical documentation, but it totally is. That was a huge change in the medical industry when they started having pre-op, during surgery, post-op checklists to make sure that each team was doing stuff the same way, there were significant improvements in people not dying during surgery or getting the wrong thing amputated. Like, oops, we took the wrong one off. Things that seem wild now, but they largely don’t happen because there is now a checklist that is like confirm with the patient which limb it is or which organ it is, or have them verbally tell you/summarize what they’re having done that day, so you can be sure that somehow you didn’t mix up the chart of them and somebody else. Even those simple things, if you’ve created checklists for your coworkers, if you’ve created cheat sheets for yourself or somebody else, you’ve created technical documentation. I also like to use the example with some things, like people hear the phrase information architecture and they think that it’s big and complicated. And I’m like, have you looked at a restaurant menu? That is an expression of information architecture. What’s an appetizer versus an entree? That’s a decision. They felt that those labels were meaningful. Or you go to a tapas place and they’ve got small plates versus large plates. Those are labels that seem meaningful in the context, but they do often have to explain it to somebody who’s never been to a shareable plates restaurant before, right? So we all have a lot more experience with a lot of technical communication concepts than we think we do.

Heather Zoppetti: [47:09] Absolutely. I love that you brought up menus because I think this is super important. I’ve been to some restaurants where I’m like, oh, their menu is a book. There’s so many things. And then just thinking about how that’s organized, what things do you want to bring up front, you’ll often see a special sheet, right on the front, you want people to see that first and then things like desserts and sides or beverages maybe come at the end. So even just thinking about that kind of organization is definitely information architecture. And it’s something that, again, you encounter all the time and you don’t think of as technical documentation, but it is.

Kate Mueller: [47:48] Yeah, it totally is. Now, how did it play out for you when you were applying for roles after the knitwear business? You said that you used your knitting patterns as your technical writing portfolio, but what did it look like for you when you were submitting resumes or doing interviews at that point? Because I’m assuming you had to do some work to connect the dots between what was officially in the job you were applying for and your historical experience. And I think this is where people sometimes panic. “How do I make the connection or persuade somebody that this experience is relevant to the role in question?”

Heather Zoppetti: [48:28] For me at that time and I would do the same now. It’s a little trickier now because of all the automated processes with applications, but at that time the key was the cover letter. So being able to write a cover letter again, like you said, to connect those dots, to tell the story of what I was trying to convey, to do. Again, probably a piece of technical documentation to say, starting here, this is what happened, this is why it matters. And I think that is really the opportunity. Now again, some application processes now are so automated that some don’t ask for a cover letter or don’t give you the opportunity for that. I think two things. First, that is an opportunity to make that personal connection. They say networking and making that connection matters more than any of that automated stuff that’s going to just read your resume with a robot. But if you can reach out to that hiring manager and then tell that story there. So it’s not a formal cover letter, but that does two things. It does the networking, and then also you can tell your story. But I think there are things that you can do in your resume to really help that dot connecting where you’re saying I did this thing, I provided concise instructions to construct complicated patterns. So the language that you use there, I mean, I feel like a little bit of that is businessese or jargon or whatever, but that’s your audience, right? So if you’re trying to get hired at a technical writing position and these folks are not necessarily interested or know anything about knitting, how do you meet them where they are and speak that language to convey the things that you’re doing? And there’s definitely ways to do that.

Kate Mueller: [50:14] Oh for sure. I think this is one of those moments where there’s an opportunity for you to look at the language that they’re using in the job description and the requirements versus nice to haves and figuring out ways to reframe the experience you have through the lens of that language to say, “Okay, well, I would not have called what I did at that job information architecture, however, conceptually it is information architecture. And so I can say I used information architecture best practices to create a blah blah, blah, blah, blah.” You didn’t know that that’s what you were doing at the time. But now that you have learned a bit about what information architecture is, you can make those connections and you should explicitly make those connections because both between automated review, but also if you’ve got a recruiter looking at that who doesn’t know jack about what technical writing actually is, they need you to spell it out very explicitly: my experience maps here in this way, let me use the phrase you used in your job description, but then I will play up the actual experience I have. And it’s wild to me that people who think that they’re really good technical writers often don’t do this in their resumes.

Kate Mueller: [51:34] The resume is itself a form of technical communication. Apply all those best practices here. You’re making decisions about what work you showcase and what work, what do you lead with, what ends up being at the bottom of the page or gets bumped onto page two, if you believe that two pages are okay. You’re making choices there about what you’re putting forward. It is the same concepts as what you’re doing in your official technical documentation. This is just you technically communicating about yourself instead of other things. Yeah, the cover letter, man, it’s a dying art at this point, I think. So much of the automated reviews don’t do them, and there’s so much value in them, I think. And then I’m assuming you also did that similar explicit mapping once you got to the interview stage, because usually the interview is a cover letter on steroids in terms of, let me map my experience to what you’re talking about. Can you talk to me a little bit about how that was for you?

Heather Zoppetti: [52:36] Trying to think so, like back to that first job. I remember being very nervous about it because I’m like that imposter syndrome or whatever. But yeah, I think it’s just what you said. It’s really trying to emphasize the experience as relevant and that you have transferable skills and that they apply. I have to say that I was very lucky. I mean, luck has to do with so much in life. But the company that I did start with was very open to not having the formal degree, not being in, having five years of only software development experience or that kind of requirement. So I feel like my answer is a little bit biased or skewed in that way, because I was lucky enough to have a hiring manager and team that was more open to that. So that’s definitely not going to be the case everywhere. I feel like because of that, I felt that it was easier for me to maybe not be as jargony or that business influence type role, but I mean, obviously there was still a lot of that.

Kate Mueller: [53:54] I guess I’m also a little curious. So you successfully ran your own business. You were your own boss for about a decade. And as a self-employed freelancing person, there’s a lot of logistics that I know go into that and a lot of problem solving that goes into that. You were the person deciding, what tools do I use? Which vendors do I work with? How am I going to build my website? Am I building it? Am I hiring somebody to build it? What does that look like? And so many of those experiences I think are very marketable experiences when you are job hunting because you can demonstrate, hey, I am an independent worker, right? I’m good at doing analysis to select vendors or software or whatever that might be. I guess I’m curious if there’s anything that was not explicit, how do I even ask this question? I guess I’m curious if aside from the knitwear patterns that you had worked on, were there other skills that you felt really served you well once you made the pivot into technical writing or technical communication?

Heather Zoppetti: [55:12] Yes, but not necessarily even things that I thought of at that time to list on my resume. You have to be very selective, right? We talked about how a resume is one of the ultimate demonstrations of your technical writing expertise. You have IA, you have the content and all this kind of stuff. So being very selective now. But I mean, I think there’s so many experiences looking back that I think I would like to take on the challenge if I’m ever looking for another job. It’s like seeing how I can connect some of these other things as well. I mean, so obviously the business stuff: management, time management, project planning, all that kind of stuff. These are obvious things, but even things like helping folks debug their networking things. Maybe this is silly and maybe this is too much, I don’t know. Again, it would be like a challenge to see at this point how I could bring some of these things in. But say like you are your neighborhood block’s person that people go to for help, are there any artifacts that you’ve created for folks to help so that you’re not on call 24-7? So like that kind of situation, or like, maybe you’re the family tech go to person and created some things that you can point to that have helped folks that way.

Kate Mueller: [56:34] Yeah, great example of this in the solo episode, my first solo episode of this year, when I kind of announced, hey, we’re looking for people who do technical documentation but don’t call themselves tech writers. One of the examples I gave was, have you created troubleshooting steps for your aging parent who consistently locks themselves out of Facebook, or their bank account, or can’t remember how to use their printer? That counts as technical documentation. You were helping a very struggling user figure out how to do a thing, and you’ve probably done it so that they stop calling you at like every hour of the day, every time they lock themselves out. But nonetheless, you have created a useful artifact here that’s helpful documentation. Maybe if you can get them to use it, but it might be a good example. You’re the person in the family who helps troubleshoot X. In my household I’m the one who troubleshoots the printer. I hate troubleshooting the printer. This is my least favorite external device on the planet, but I am the person who does that. I have now learned how to clean the ink cartridge printer heads when something goes wrong and fix the alignment and whatever else. And mostly I’ve done that through documentation, but I’ve also left myself notes about the next time this happens, this is the thing you do. So in case that page disappears from the internet forever, and the instructions I stole for it don’t exist anymore. But yeah, it does encourage you to think about both the artifacts you’ve created, but probably also the process you used to create them.

Heather Zoppetti: [58:13] Yeah, absolutely. I think any of these things, if you think about how you were thinking about it and the way that you organize that information for yourself and then convey that, I think that’s the key, right? You’re taking something that’s complicated, whether it’s complicated to you or not, right. Your reader, your user, your watcher is thinking, this is complicated to me. So you’re taking something that is complicated and you are trying to convey that information in a way that makes it approachable and doable and setting someone up for success.

Kate Mueller: [58:52] I love that so much of what you’ve talked about has been around that good documentation leaves your end user feeling confident that they can do whatever it is you’re trying to get them to do. That you have taken something that could feel complicated, overwhelming, intimidating, whatever, and you’ve instead broken it down in a way that leaves them feeling confident that they can do it. And sometimes I think that point gets lost somewhere along the way. Like if I’ve given you the steps to do it and you don’t feel good about it, that’s on you, not my documentation. And I really like the centering of that idea of, let me help you build confidence and agency in doing this thing, and that’s not a thing I could ever effectively measure using metrics. But it is such a fantastic goal to try to have for your documentation.

Heather Zoppetti: [59:49] Yeah. I mean, even something as simple as I’m trying to think of like the most absurd example, but even something as simple as that easy button, right? It’s a big red button. So imagine you have a big red button that you want people to press, but even just the color and the importance of how big it is and stuff, people will approach that and be like, this is intimidating. I don’t know what’s going to happen when I press this button. What does that say about me? What is, like, all these things? And so I can imagine someone having a little sign or whatever be like, it’s okay, don’t panic.

Kate Mueller: [01:00:23] Just because it’s red and in every movie where there’s a big red button, bad things happen after you hit the big red button, right? And we’ve already talked about design. We can’t make it not red. That’s the whole point. But we can make you feel better about the fact that it’s red.

Heather Zoppetti: [01:00:37] Exactly. Give people confidence. It’s okay to press that if you need to.

Kate Mueller: [01:00:43] I love that. And maybe in the vein of big red easy buttons, are there any resources that you found super useful that you would love to share with our audience? They don’t even have to be technical writing related. Sometimes people are like, oh, I just watched this Ted talk and it was great. Is there anything top of mind for you that you’d like to share that might feel like a big red, easy button for folks?

Heather Zoppetti: [01:01:08] I mean, I think for me, probably the biggest and best resource that I can recommend is joining the Write the Docs Slack. The community, right? So it’s about community building, but there are so many folks there that are so willing and eager to share experiences, to talk shop, to get into the details, but also just to be there to support each other, which I think is so important, especially when a lot of us are either working from home or we’re maybe the lone writer at work. Having that community that you can ask folks about: this problem came up, or I haven’t encountered this, or what is your thinking? It’s just so valuable. It just really helps you feel like one, you’re not alone. Other people are seeing the same problems that you are or having the same questions. And it really just, I don’t know, builds confidence.

Kate Mueller: [01:02:03] It’s a nice full circle moment because it’s really taking us back to your comments around finally having another writer to work with that there is that value in just that professional dialogue around it. And since a lot of us are lone writers, we don’t have that necessarily with coworkers, but places like Write the Docs Slack give us that opportunity. We often talk to other lone writers, but we’re still all trying to solve the same problems. And sometimes you get perspective from people who are on large writing teams and have different problems to solve because of that, and it’s incredibly valuable. There’s such a wealth of experience in that community. Also, a lot of advice on resumes and cover letters and other things if you are in the job hunt scene. There’s a lot of folks who will help there. That’s an excellent suggestion. And I guess, Heather, is there a great piece of advice that you’ve been given that you would love to share with me? Because I like to steal great advice from other people. It does not have to have anything to do with writing. This could be life advice, knitting advice, cooking advice.

Heather Zoppetti: [01:03:15] Really, I think probably the best advice that I both have gotten and given is that you should just try it. If you’re interested or, this just sounds so basic, but it’s I feel like especially now with all that’s going on in the world, with everything that’s bombarding us every day in social media and the need to be somebody or be an influencer or whatever, I just ignore all the things and say, you know what? I’m interested in learning, doing, acting, whatever it is, and give it a go. You don’t have to make that your whole life. I think that’s something that in this social media age, people say, “Oh, if I make a TikTok, then I have to go all in. And that’s who I am now. And if I don’t do well, then I failed.” And it’s just like, you know what? That’s not the case. You are not cementing yourself, you’re not pouring a mold that you have to stay in. Give it a try. If you are interested in technical writing, get out there, talk about it, meet some other folks, give it a go, maybe start a blog. All these kinds of things that, I don’t know, it feels like…this is very ironic. It feels very both low effort to dip your toe in, but also like an intimidating first step. And my advice is just to ignore that voice in the back of your head or that fear that this is a big step. It doesn’t have to be.

Kate Mueller: [01:04:57] It can just be an experiment. The thing I like to tell people is if you think about true scientific experiments, the only failed experiment is one in which you didn’t successfully test your hypothesis, so you didn’t learn what you were hoping to learn. You don’t have the expectation of success, as in, I’m going to get the exact result that I want or expect. Success is just I got a measurable result and it gave me useful information. And I think we in this modern age, particularly with the amount of social media presence, we don’t see all the messy failures and starts and stops that people do. We often just see the curated success at the end of that. And I think that means that we sometimes forget that a lot of the early stages of anything are really messy. You’re trying something, it doesn’t work the way you thought it was going to work, or it’s harder than you thought it would be or it turns out that you thought you could do it without this particular tool, but you actually need that particular tool because it’s really hard when you don’t have the one custom tool for that thing, right? And like, it’s okay for that to be a deeply imperfect, flawed process because it’s so much more exciting than not trying a new thing, right? It’s so much better than just being stuck wherever you are.

Heather Zoppetti: [01:06:27] It’s better to try something and find out maybe it’s just not for you then…now you know.

Kate Mueller: [01:06:33] And you can stop having it take up any mental space for you. It’s no longer cluttering up your head because you’ve answered the question right? I’m not cut out to do X. I went skydiving once. I only needed to go once to tell you that I didn’t want to do it again. But it was a really useful piece of information to be like, oh, this isn’t my jam. Like, I enjoyed parts of it, but it’s not a thing I would prioritize in my life. But if I had gone into that being like, this is going to be my whole personality now and then it feels like I’ve set myself up for failure if I don’t totally love it. And instead, it could just be like, oh, this isn’t really my jam. I’m glad I did it though. And I guess just to close, Heather, if anybody listened to this and was like, “Oh, I have found a kindred spirit, I would like to connect with Heather in some way, shape or form.” How would you like them to do that?

Heather Zoppetti: [01:07:26] I admittedly am not very social media focused anymore. I used to do that for my business and stuff because you became the personality, like, your brand. But I do have a very infrequently used Bluesky account, and I think you can just look me up by name if you put my name.

Kate Mueller: [01:07:45] We’ll link to you in the show notes also, so people don’t have to think about it. And I’m assuming you’re also in the Write the Docs Slack, so anybody who’s in that community could probably ping you directly there if they’ve got questions. Beautiful. Well, thank you for this. This has been a fantastic conversation. I’ve had a delightful time. I hope you have as well.

Heather Zoppetti: [01:08:07] Very much so. Thank you.

Kate Mueller: [01:08:08] And also props for leaving software development and doing a craft-based business and making it work for any amount of time, like the number of people I know in tech for whom that is like a, oh my gosh, I wish I could do this, but I couldn’t possibly. It’s fantastic. That is in and of itself an inspiring story, leaving out the, oh, and then I decided I wanted to a) I needed to make more money, and b) I was kind of ready for a new thing. I came back into tech, but in a totally different capacity. I think this is really good for a lot of us to remember that life is a very fluid, amorphous, nonlinear thing and more of us need to share that.

Heather Zoppetti: [01:08:52] Yeah, everyone’s going to make their own path. And I think that’s what makes it interesting. And again, to circle back to that initial topic that we had started with is that I really, truly believe that all of our backgrounds, as varied as they are and all of our experiences, everything adds to what you’re doing now. So and then you have folks, if you have a team, different experiences, it’s just going to make your team stronger.

Kate Mueller: [01:09:19] Yeah, it really is. That sort of, uh, I don’t know that I like the melting pot metaphor, but it is very much that none of those experiences get wasted. They all inform who you are now. They inform the toolkit that you have, the opinions that you have. All of that is stuff that you fall back on when you’re presented with something new or novel, or particularly a complicated problem to solve. And there’s a lot of value in having a huge diversity of experiences when you’re facing adversity or difficult decisions. And that’s probably a fantastic note for us to end on. So thank you so much, Heather.

Heather Zoppetti: [01:09:59] Thanks, Kate.

Kate Mueller: [01:10:07] 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.