SPEAKER_00 0:08

Hello listeners. If you are curious about technical communications, then this podcast is for you. On each episode, I will interview a guest who will share the unique journey. This is Inside TechCom with Sahara Matavana. Let's get started. I'm honored to welcome today's guest, Ron Gardner. Hey Ron, how are you?

SPEAKER_01 0:33

Good, how are you doing?

SPEAKER_00 0:34

I'm doing really well. Thank you for being on my show.

SPEAKER_01 0:38

Oh, you're welcome. I'm happy to be here.

SPEAKER_00 0:41

So, with that, my first question to all my guests. Tell us a little about yourself.

SPEAKER_01 0:47

So I have been a tech writer for 22 years now. And wow, that sounds like a long time when you say it that way.

SPEAKER_00 0:54

But uh I didn't know you were in the field for that long. Please go on.

SPEAKER_01 0:57

Oh yeah, it was actually my first job out of college was as a tech writer, and I've been doing it ever since. Although there was a six-month gap where I was a project manager for an aerospace, graduated from Texas AM, and my first job out of college was for a little tiny startup in California. And then I've you know had several different jobs since then. I worked for, like I said, like tiny little startups, mid-sized private companies. I've worked for mega corporations and for smaller corporations. So I've kind of run the gamut as far as an environment goes with tech writers. I've used a lot of different tools. Since I've been doing this for 22 years, I obviously enjoy being a tech writer. I enjoy it quite a bit. And uh I just can't imagine myself doing anything different because I just I like what I do. So I'm happy to do it.

SPEAKER_00 1:42

So you're one of those rare uh writers that I have interviewed who has kind of started off their career as a technical writer.

SPEAKER_01 1:49

Yeah, I kind of fell into it backwards, obviously. I didn't plan on being a technical writer.

SPEAKER_00 1:53

So, yeah, let's let's talk a little bit about that. Sure. You know, you said that you graduated and then you started off as a technical writer. What did you graduate in?

SPEAKER_01 2:01

This is a great comment. People never believe me when I tell them what my major was in. I have a BS in agricultural journalism.

SPEAKER_00 2:08

So agricultural journalism. Okay, let that sink in for me. Yes. So and technical writing, but you're not doing technical writing in agriculture.

SPEAKER_01 2:17

No.

SPEAKER_00 2:18

So let's let's talk a little about that.

SPEAKER_01 2:20

Yeah. So when I was in high school, I was really big into Future Farmers of America. Do you know what that is?

SPEAKER_00 2:25

No.

SPEAKER_01 2:26

I grew up in a little town outside of San Antonio and it was kind of out in the country, and so it it was a big thing there. I mean, I raised farm animals. Oh wow. Um, I competed in a lot of FFA is what we call it for short.

SPEAKER_02 2:37

Okay.

SPEAKER_01 2:38

Uh a lot of contests and things. And so I really enjoyed it. And then, you know, when it came time to choose a college, I was already familiar with Texas AM through Future Farmers of America. And so I decided, well, I I like to write and I really liked FFA. So I kind of that was kind of a way of combining the two.

SPEAKER_03 2:55

Uh-huh.

SPEAKER_01 2:56

And so being an ag journalism major, it it's almost a double major, really, because you have all these agriculture classes and then you have your journalism classes. And there's really not a lot of wiggle room in there for um electives. So although I still did it anyway. I took just whatever class I wanted to. But one of the reasons that I also stuck with that major, I mean, everybody I knew changed their major at least once, but I never did. I was an ag journalism major from start to finish. Okay. They were all getting jobs because there were so few of us that people were getting just scooped up left and right. I mean, some people went off to do PR for like an agri firm or whatever. And then I got there and I was kind of trying to figure out what I want to do, what do I want to do, and I was getting near graduation time, and I actually got my job, my tech writing job, through nepotism, I'll freely admit it. My brother gave me my first tech writing job. Oh, nice. He had graduated and met somebody. He was working for the Tandy Corporation in Fort Worth, and he met another developer, and they got in their heads to go off to California and start their own company. Oh, so it was a small little 10-person startup. It was a very small company outside of Los Angeles. And he called me up and said, hurry up and graduate. I need a tech writer. And I was like, okay, I have a job waiting for me. And so I went out there, and sure enough, as soon as I got out there, my brother bailed on me and went back to Texas and left me out there for a couple of years. Yeah, but that was my foot in the door. It was a really, really good experience because I didn't have any sort of I took some computer science stuff in high school, but in college, I was being an ag journalism major, I was kind of locked into what I was taking, so I didn't have a lot of computer science courses. And so getting out there and you know working for the small little company was like just jumping in the deep end of the pool and and figuring things out, you know, playing with software. Because I was actually QA and a tech writer out there because the company was so small. Okay. So I would take the use cases from the developers and then you know write the documentation off the use cases and QA the software at the same time. So it was a really great exposure for both the QA and the tech writing thing.

SPEAKER_00 4:54

The agricultural journalism is still sinking in for me, right? But then why do you use the journalism part? I know, I know. The reason it's sinking in is because although your career might have started off, you might have started off as a technical writer, your training was not in technical writing.

SPEAKER_01 5:12

No, it wasn't. In fact, when I was in at AM, there was a technical writing, there was an English class that was technical writing, and everybody just told me, don't take this course, don't take this course. It's so hard, don't so hard, just avoid it. And so I just was kind of I was scared off by other what other people told me about. Oh, wow. So I didn't even bother with it. So I mean it was you know an available course, but I didn't take it because people said don't. I was like, okay. So I did take some English courses, of course. You know, of course, of course.

SPEAKER_00 5:40

I mean, you're you're majoring in journalism, right? So I'm sure that sort of prepared you to be a writer. And of course, it's a different style of writing.

SPEAKER_01 5:51

It is, right? Yeah, I uh I think it was I was a really good English student in high school, and so I was used to a certain sort of prosaic way of writing, you know, and and putting more out there, more there. It was journalism, it's an inverted pyramid, what they call. Like you get the important stuff out at the top and then kind of trim it down as you go down. I had some issues with that adjusting that mindset, you know. So uh working through the the journalism courses uh as I you know went through my college career, I started to learn to kind of trim out the fat of my writing, you know, and kind of Oh, I like that.

SPEAKER_00 6:23

Trim out the fat. I like that analogy. And actually, you know, I want to take that conversation a little bit further and talk about how that translated to you becoming a technical writer, being trained in journalism. How much more trimming of the fat did you have to do, or how much more fat did you have to add back on to that training of yours?

SPEAKER_01 6:41

Part of being a journalism student was you get the important stuff out there first, and then the add-ons come in later, you know. And so that's how I kind of approached technical writing was get the important stuff that the user needs to know out in front, you know, and then the ancillary stuff can come in later is be as like a note or something like that, you know. So you want to prioritize the steps, you know, how you explain a process to someone, you know. So don't say, Oh yeah, by the way, do this. No, you just let them know they need to do this. Here's when you need to do this, you know. So I have run into a lot of instructions that like just not necessarily anything I've written or a coworker, but just say instruction manual, like putting some together. There's always like, oh yeah, and then do this. And you're like, but already did this. And so it's like, wait a minute, hold on. You should have told me this before I did this other thing, you know.

SPEAKER_00 7:30

So yeah. So in a way, what you're saying is that it sort of did lend value to I think so to your journey as a as a technical writer. And then you did say that you were kind of you just had to deep dive when you started off at the startup. But the advantage was that you were doing QA and technical writing. If I may say so, you know, I've been a technical writer for a while and I have not been in a specific QA role, but as technical writers, you do end up testing the product inadvertently. But you had the advantage of being a QA person. Right. Right. So that I think is it's invaluable in a sense, right? You're you're testing for it and then you're documenting it at the same time. Can you speak a little more to that experience and you know, just share some thoughts on that?

SPEAKER_01 8:14

Oh, yeah, actually, that was that was actually a really good gig. I I really like that because the developers would do their thing and then they would write up some use cases for me to test it. So I would walk through and familiarize myself with the product while I was doing the QA piece. And then, you know, you could always kind of make some notes as you go along to set up the user manuals and then walk through your use cases and test it and see where things are gonna break because when things are gonna break, and then that when I would find something that would break, I would report it back to the developers. So it saved me a lot of wear and tear having to rewrite because I've been in I've been in situations where documentation was used to QA the product, you know, it wasn't QA'd before we got like the developers did it, handed it to the documentation people, and then the QA department used the documentation to test the product. And so the documentation team was having to rewrite and rewrite a lot of things that would break, and it was it was it was crazy. But this situation, my uh the little startup, being the QA person and being responsible for documentation was I could QA the product and get it set and have it where it needed to be before I even started writing it. I mean, I could take notes as I went along, but I wouldn't really start writing the official documentation until it was set and it was not gonna change.

SPEAKER_03 9:29

Right.

SPEAKER_01 9:30

Nothing was gonna break. I went through and I did it, you know, I took my use cases, everything was set, nothing was gonna break, it was user ready before I even started the actual documentation.

SPEAKER_00 9:39

You kind of have both the perspectives, right? You're QAing the product, and then you are reporting that back to the developer. And now once you get the feedback, it's it's a more stable product that you're documenting.

SPEAKER_01 9:51

And you're not wasting any time. I mean, you're doing the QA job that you're already, that's that's part of your job. And then when it's time to write, you're not wasting any time because you can get in there and you can write for a stable product. I've talked to some people in my current job and they're like, wait, what? So and even my brother, who is a big time developer where he works, he was like, That's not how we do it. I was like, Well, so but that was a prior thing, not where I'm at where I'm at now is is good. So anybody looks me up on LinkedIn, we're we have a process where I'm at now.

SPEAKER_00 10:18

So in your unique position, as you were QAing the product, you became an informed writer. You didn't have to run to QA to get the information. So it was actually really a great learning, I guess, for you.

SPEAKER_01 10:31

Oh, it was it was great, you know, like it was it was twofold way of getting information. Like not only were you you you're getting the experience of of QAing the product, right? You know, by the time you were done QAing it, you were really familiar with it. And so by the time you could go through writing the documentation, you had almost like another level.

SPEAKER_00 10:45

Exactly.

SPEAKER_01 10:45

You were you would you fixed everything or had everything fixed with the developers. So you got into kind of a baseline, but then as you go to write about it, then you can really think about the end users. So it's really like almost a two ways of looking at the the uh the product, and it was it was great.

SPEAKER_00 10:58

I totally get that. And I would love to be in that position, right? So that's that's why I kind of wanted to deep dive into this.

SPEAKER_01 11:06

But it was a very small startup, so it would I think that was unique. You wouldn't have that opportunity with most places. I mean, you will have a QA department and you'll have the tech writer.

SPEAKER_00 11:14

Which is true, which is true. But if let's say one of some listener out there ends up being in your unique position, they should not shy away from, you know, if they're offered, would you want to start off as QA? Why not? You can do QA and writing.

SPEAKER_01 11:26

I know I know several people, several technical writers that came from QA that have a QA background before they became a technical writer. And they were a better technical writer because of it.

SPEAKER_00 11:34

I would agree. I think uh that's definitely a valid point. That most, I mean, again, I don't want to generalize it, but many technical writers are either career changers. Nobody thinks about becoming a technical writer. And when you do become a technical writer, you've you've had some past experience. And if you are coming from a technical background like QA, you would definitely become a much more informed writer. Based on what you're sharing, you definitely are kind of validating that experience, right? That it didn't make you an informed writer and gave you a twofold perspective.

SPEAKER_01 12:08

It just gave me a better appreciation for the end user in writing end user documentation.

SPEAKER_00 12:13

Gotcha. Now, you know, you did mention that you did not have any technical background when you started off. I know that you said that, you know, kind of being thrown into QA, you had to roll with the punches and you had to just figure out technology and you had taken some computer science. Can you share a little more about that? I want to know in terms of what strategies did you kind of apply that somebody listening to us can take away from this conversation?

SPEAKER_01 12:42

Sure. So I mean, I was a little apprehensive about taking the job because it was just okay, do I know what I'm doing? You know, and I'm not a technical person, you know, and and my brother knew he was his degree was in computer science. So he he had that background, right? I didn't, but he said, that's okay, you know, come on out here, we're a small enough company, you know, we'll we'll set you up. So what I did was when I got out there, I started playing with the the product in a test environment, start familiar with the product, and then as things came up, as I was QAing, I would start to make connections with the developers. Like, okay, I don't understand this. Can you explain this to me so I can explain it to the user? And so that's one of the things I do love about technical writing is talking to people and making those connections. And so that was great because there were several developers, as small as the company was, I think it were five developers. And so each one of them had a different aspect of the product they were working on. And so I could go, okay, I need you to explain this to me. And that's that's the thing, is that I I overcame I'm one of those people or that doesn't like to know that I don't know something. And so I was able to get over that. Like, okay, I have to swallow my pride and go to this person, this developer, and say, I don't understand this. Can you talk to me like I'm a four-year-old? And so I can, you know, assimilate it, understand it, and then take it apart, put it back together, QA it, and then write the instructions for it. So I mean, you just have to get, I mean, don't be afraid of not knowing anything. That's my biggest advice. Just learn. I mean, it's it's no one's gonna bite you. I mean, you know, yes. And asking questions, if you ask questions, people will respect you. I mean, they're not gonna make fun of if you don't know something. I mean, in fact, honestly, if somebody comes to me and says, I don't know something, I respect that. I mean, having the courage to admit that you don't know something, I can respect that. I mean, I you know, I'll go out of my way to help somebody with something that they don't understand it, you know. And they just come to me honestly and say, Hey, I don't get this. Can you help me out?

SPEAKER_00 14:37

So Yeah, I think with every interview that I do, this is the one common theme that don't be afraid to ask the questions. That's how you learn. And with you bringing up that point, it it's very important. Don't be afraid. And if somebody comes to you, you kind of develop more respect because they are they want to know and you have that knowledge to provide. Or, and if you don't, there's somebody else out there who can fill in that gap for you.

SPEAKER_01 15:01

Well, and then there is a common goal too. It's like you just you have to understand, like, we're we're all working toward this, you know. We we have to get you know to this this end goal. And so I can't, you know, if someone doesn't want to help you, that's just getting in the way of that goal for almost both both of you, really. So it's just it just it helps everybody. And I really haven't, I've never really had too many roadblocks in my career. I mean, every anybody I go to, they're more than happy to help. And so, you know, I've just I've just been really fortunate. So I mean, even 22 years, I'm still learning things every day. That's one of the things that I love about being a technical writer is not being siloed and getting exposure to all these things because, like I said, seeking out that knowledge and talking to people. And I've been told that one of my coworkers says I have a gift for schmoozing. Uh so I would agree. I can't help it. I just I I like people. So even where I work now, it's it's a pretty good sized corporation, and I will still make connections with people that aren't on my specific teams, like on products that I don't work on. Uh-huh. I will go talk to a developer on another product and just pick his brain and make a connection. It's just, and it doesn't even have to be a connect a technical thing. It could be just some sort of personal, oh hey, I hear you like beer and we can talk about blah blah blah. And then you make that connection and you can always parlay that into helping with your job. Like, hey, and so, you know, hey, hey, so-and-so. I don't want to use people's names, but you know, hey, can you help me with this? And you've already got that connection from something else.

SPEAKER_02 16:27

Yes.

SPEAKER_01 16:27

So it's it's always a way of I'm always just looking, I'm not working angle per se, but I'm always looking to make connections with people.

SPEAKER_00 16:33

Yeah, yeah, yeah.

SPEAKER_01 16:34

Because it always helps.

SPEAKER_00 16:35

And you're trying to build bridges here, right? Because it could transform into something else. You're not coming back to the schmoof spot.

SPEAKER_01 16:42

You I don't even realize that you're doing it, but you're well, I was at uh I went to the Mad World, the Madcap Software conference last year, and I was just making connections upon connections, upon connections, and I wasn't trying, I was just talking to people. You know, I saw somebody standing at a table by themselves, and I went, hi, how you doing? And and I still keep in touch with a lot of people I met at Mad World. So it's it's great. Where I was before I came to my current position, when I first started, I felt a little isolated because I was on a very small team, like a very dedicated small team. So I didn't really know anyone else in the company. But the longer I worked there, I started finding those little connections to people, like, oh hey, I hear you vacationed at someplace, and me and my wife like to go there. And you just you make these little personal connections, and then it parlays into helping you with your job in the long run. Because you could be writing a doctrine about something, and like, well, there's this oddball thing that no one on my team might understand, but this guy does, and I can go talk to him about it, or you know, she's doing this, and I can go talk to her, you know, you just gotta make these connections you know, beyond the technical stuff. But it always helps you in the long run.

SPEAKER_00 17:52

So I I think I would agree with you on that. Absolutely. A valid point. You know, you've been in the field as you said, 22 years. 22 years. And I'm sure you have encountered uh a different process at each place that you've been. Can you share, you know, not particularly the process that you may have encountered, but how did you adapt to that process? Uh what were some of the challenges that you may have faced?

SPEAKER_01 18:18

Right. So I think it's it's because I've worked with so many different types of companies, you know, like small, tiny, huge, mid-size. And so I think you just had to find out where you fit in and maximize that. And I know that's kind of a non-answer answer, but let me see if I can elaborate the way I'm thinking. So you can get used to doing things a certain way, and then say you uh move on to another position at another job, another company, and it's a completely different way of doing things. So you have to be uh adaptable and learn. But the back to the learning thing. You cannot be afraid to ask questions, you have to learn. And so it's just don't be afraid of new ways of doing things. And sometimes you can get stuck in a rut doing things a certain way that you did before, and then you go do it this other way, and it kind of opens your eyes, like, oh wait, wow, this is even a better way of doing things, you know, because I was so used to doing this, and I kind of got spoiled and not lazy per se, but just used to doing it a certain way, and then you see another way of doing it, and you just roll with the punches, and it's like, okay, and you can learn new things.

SPEAKER_00 19:22

So I don't know if that answered your question, but no, I think I the point, the bottom line being adaptable, right? The process is not going to be the same. And I think as individual contributors, be it a technical writer or developer, you're going to encounter different processes at different companies.

SPEAKER_01 19:40

Even with teams within like you say with a larger corporation, the even the teams within that corporation could do things differently. There's still a standardization across the board, but the specific ways of doing it within the minor teams could be different. And so you just kind of have to adapt and and then find where you fit in within the process and and make the best of it.

SPEAKER_00 20:02

Everything that you said, I think being adaptable and being curious and being ready to learn is the key there.

SPEAKER_01 20:09

I think so.

SPEAKER_00 20:10

Yeah. Uh now, if I understand correctly, right now, when you shared a little bit about yourself, you said you're a tech lead right now.

SPEAKER_01 20:18

I am. I am a lead technical writer for a healthcare software company.

SPEAKER_00 20:22

How does that feel?

SPEAKER_01 20:24

I really like it. I know that some people it's not their thing, but again, I think this goes back to the schmoozing thing.

SPEAKER_00 20:32

Uh-huh.

SPEAKER_01 20:33

It's just, yeah, I've been doing this for so long, and this this opportunity arose, and I just it sounded great. I adore my team. I love them to death. And so they're a great bunch of uh technical writers. I can't say enough good things about them. And if there's anything challenging per se, it's just always trying to find the new thing, kind of moving the ball down the field, adapting with changes, you know, trying to implement those changes. But my team's been great. They've been they've been very adaptable. I like the bond we formed as a team. It's, you know, we're all we all look up for each other, we will do whatever we can for each other. And I I just really like being a a team lead. I know it's not for everybody, but I really like it.

SPEAKER_00 21:11

Let me elaborate why I asked you that question. It was more to kind of understand the psyche, right? When you're an individual contributor and as you grow in that role, there is a different demand, there's a different ask of you. Right. And what your learning has been from there, and if there's anything at all if you would like to share, I know being adaptable definitely is important. Have you had a mentor or anybody to kind of guide you on that path? Anything that, you know, is something that stands out that you would like to share.

SPEAKER_01 21:43

Well, I mean, I've had tech writing mentors.

SPEAKER_00 21:46

You've had, okay.

SPEAKER_01 21:47

Mm-hmm in the past, and people have kind of goosed me in the right direction, I guess I should say. And and kind of, you know, like really kind of help clean up grammar things here and there, you know, like little things you don't think about and and you know. It's it's it's like little things here and there.

SPEAKER_00 22:02

As far as a leadership role, I guess there doesn't have to be, you know, so for some people it comes naturally. And my reason for asking this is sometimes when you're given that opportunity, let's say you're showing leadership skills as an individual, but you have a lot of self-doubts. How do you get past it? And this question is more to address uh that population of technical writers who are listening and they're like, oh, I want to grow in my role from an individual contributor to a team lead, maybe not a manager, but what are the things that I need to overcome or what are the things that I mean to that I need to cultivate or get mentored on so that I can grow into that? Uh the question was from that perspective.

SPEAKER_01 22:47

Yeah, so basically you're asking me what advice can I give to people who like to be a team user.

SPEAKER_00 22:52

Yeah, yeah, maybe, maybe that, yes.

SPEAKER_01 22:54

Okay. So honestly, the biggest thing that I could suggest is listen, listen to your team. You know, don't dismiss anything out of hand. Everybody has an opinion, I know. Um, and sometimes those opinions are gonna come into conflict. But just just understand where people are coming from. Don't just don't just say it's my way or the highway. That's to me, that doesn't work. Okay. I just and I've had opportunities to do that. I just that I don't think that helps the team at all. So you have to understand that a team is just a group of individuals, all with their own ways of doing things, their own opinions, you know, and their own thoughts. And so you just have to make make that team come together as a cohesive unit. You just have to find a way to just communicate with each person, and then within those communications, uh communicate with the team as a whole. And you know, and it's gonna be sometimes there will be some times where it's you you think maybe it's a lose-lose situation, but if you just talk to everybody, you know, communication is key. Yeah, yeah. I don't really believe there's ever a lose-lose situation. You might think there might be, but I don't think so. You think there's always a way to to make it a win for the team, you know. So and it sounds like a cliche, but yeah.

SPEAKER_00 24:08

No, I I uh you know that sometimes it's these are it might seem so simple or irrelevant, but what you're trying to drive at is that, you know, based on your on your experience, it appears that you have been in these situations. And my takeaway from your answer, your response is listen and then communicate. And that makes you a more empathetic teacher.

SPEAKER_01 24:32

I think so. I think that's I've been told that.

SPEAKER_00 24:34

So that is what makes a good leader is to to listen than to say, you know, it's it cannot be my way or the highway. And I think that that analogy is very true, very right, very apt for in this context. We have been talking, and I feel like, gosh, I've learned a lot more about you, Ron, through this conversation. I should interview you more.

SPEAKER_01 24:56

I'm always here.

SPEAKER_00 24:58

Yes. So we we've we've kind of touched upon how you started and you know how you've kind of uh how you acquired your technical skills and what you've grown into. And is there anything else that you would like to add to this conversation?

SPEAKER_01 25:15

I I want to just kind of touch back on something that I I I mentioned earlier, was just what I love about being a tech writer is that just connecting with people, be it even maybe even a salesperson that you wouldn't ordinarily I mean, because we're given it a unique opportunity, being tech writers, to we have a reason to reach out to people that we wouldn't normally talk to in another position. Like a developer may not talk to sales, but there could be a reason for a tech writer to talk to a salesperson to get another angle, you know, to get another perspective that could help you with the documentation. And so I just I really enjoy that talking to people, meeting people, reaching out, schmoozing, okay. So and just getting other perspectives. I think that is really a big thing with with technical writing, is be open to other perspectives. You know, just don't get your blinders on and just do it in one way. Listen and because I've been in positions where there was like a feedback mechanism, and you could get one little simple concept, five conflicting feedback items about it, and you're like, okay, well, why did you think this? Why did you think this? And so each one of them you reach around and find out all of them, and you just work through it and say, Okay, so I see where you're coming from. And so you just work it through and just find the common ground.

SPEAKER_00 26:35

You know, so that's actually I I'm glad you shared something that I think many writers will see themselves in that situation where you're getting conflicting input. And you said you find the common ground. Have you done anything to resolve such a situation? And this might sound like a classic interview question, but I'm not trying to hire you, obviously. But is there any any strategy that you can share that you have developed over time that our listeners could take away from?

SPEAKER_01 27:02

Well, you just go to each person and you say, Why do you think this? And so you just you hear them this person through, and you have to weigh the validity. Uh, you know, it's you got to figure out not so much who's right, because sometimes it can be gray, it can be a gray area. Sometimes things can be kind of abstract enough that you know, in theory, all five of them could be correct. And so you have to find a way to basically just take a best practice, take a middle road, and and maybe just take pieces of each one. Good point, and then you know, make a a stronger whole than you had before.

SPEAKER_00 27:37

So I like that. Very diplomatic answer. But it's a reality that I have run into, and it's something that, you know, even in this phase of my career that I'm working on, so that's a good piece of advice that take the middle road, right? Try to take some from all the inputs to make it a whole.

SPEAKER_01 27:55

Well, I know it sounds like a cliched safe answer, but you know, sometimes you're gonna be in those situations. Well, okay, this person is right, but this person's right also. And so you have to kind of fuse the two.

SPEAKER_00 28:05

And that's an art. And that's and I think you have to kind of grow that mindset. I'm trying to dive a little deeper because you've been doing technical writing for so long. You have some valuable insights for anybody that's listening in. I've talked to recent grads who want to do technical writing, but they don't know what technical writing looks like from within. Right. And I'm trying to share that perspective with them. So this is this is all great, Ron. This is all good stuff. The question that comes to my mind is of course, on the job, you learn about the product and you stay current with what's going on. What advice would you have for somebody out there who is trying to keep up with the trends of technical writing outside? What advice would you provide?

SPEAKER_01 28:48

Well, I just try and some user groups out there, and you know, be it LinkedIn, I know has some things out there, there's some Slack channels, just try and find some sort of technical writer enclave, for lack of a better word, you know, and and see where what those people are talking about, what they're focused on. And again, I mentioned being at Madworld last year. I just started talking to people like, well, how are you guys approaching your documentation? What are you doing? And what kind of processes are you doing? And and that was that was very eye-opening. I learned some new things and even just on little minor things on ways to improve our documentation that we're working on. Just little I met a woman from I believe it was Cleveland that gave me some JavaScript to plug into the back end of our HTML to enable a tooltip for something we couldn't enable, you know, in the doc tool. And just little things like that.

SPEAKER_00 29:37

Nice, yeah. Yeah, you run into these interesting relationships, you never know what you'll find out there. So never hesitate to talk and to schmooze, right?

SPEAKER_01 29:46

I met a writer from Canada and showed him how to implement a feedback button in his HTML documentation. So it it comes around, you know, we pay it forward and this thing's that. So it's great. And it's everybody I've met in the technical writer community has been been fantastic. So that's a great warm community.

SPEAKER_00 30:00

And like I say, in the interest of time, one last question. All right. Any advice, any you know, wisdom that you would like to share with our listeners, resources?

SPEAKER_01 30:12

Uh let's see. As far as resources go, I guess I just you know uh piggybacking onto the uh technical writer, user groups, the STC, that's a great resource. Even just learning even basic skills such as you know, HTML, CSS, JavaScript, jQuery, whatever, there are resources out there to learn these things. So you're always gonna be this is such a fast-paced and and quickly, rapidly changing industry that you're always gonna be learning something new. I mean, be it tools. I mean, I've gone, I can't lost count how many different documentation tools I've used. I mean, I've gone Microsoft Word to Adobe FrameMaker to RoboHelp to you know Magcap Flare. So it's just even the tools sometimes are gonna change. Very true. And as far as the tools, I would say just you know, if you're looking, thinking about getting into this, I would look at some of the job boards and see what kind of tools there they want you to know. I mean, do they want you to know Microsoft Word? Which I hope not. Anyway, I mean know it, but not use it for new big user manuals. But you know, it's just find out what what the tools that are like really on the horizon that people are looking for, they want you they want you to use.

SPEAKER_00 31:18

Yeah, I think what you suggested, right? Looking at the job boards to really figure out what's out there and then how can you develop that skill to land a job and then being connected. I I think the word you use was enclave, which I really like. Sounds very sounds very fancy. But you're right, reaching out to those people. You can find your community. There are many at um avenues today that you can find. It's not just one community, there are many communities out there. So there's definitely find that.

SPEAKER_01 31:46

I was just thinking, um, like well, your podcast, there's things on the internet that you can find and just you know, podcasts or or even blogs, you know. Um so there's a few out there I've found that have been great. I mean, just even just little things here and there. It's like, oh, I didn't think about doing it this way. And so just always be just looking at the new ways of doing things, you know, like just because this is such a fast-paced industry, don't be afraid of change because it's going to change.

SPEAKER_00 32:13

Yeah, I think I think that should that should be like a tagline. It is a fast changing field, and you you've got to stay on on the front lines of it.

SPEAKER_01 32:21

I think so. I agree. It's it's sometimes it can be like a little like, oh wow, it's not overwhelming, but it's kind of like wow, you get a little caught up on it, you know. It's like, wow, it's like things are changing so fast. But if you just you know, don't be overwhelmed by it. It's I love being a tech writer, you know. I I enjoy the challenges keeping up with innovations and new ways of doing things and always learning.

SPEAKER_00 32:44

So you know, because it's changing so fast, there is always something for somebody out there that they can do.

SPEAKER_01 32:49

Oh, true, right? I told you, yeah, absolutely.

SPEAKER_00 32:52

On that note, Ron, this has been a fantastic conversation.

SPEAKER_01 32:56

I really enjoyed it.

SPEAKER_00 32:57

Yes, me too. This is, I think I have had quite a few takeaways here and like things that I've already heard, and then some new things that I got to know from you is you're one of those rare riders who started off as a technical communicator and you've adapted and your strategies on how you've adapted, all that I find invaluable. There is always something that we can learn from each other's stories. So thank you for sharing your story with us.

SPEAKER_01 33:22

Absolutely. It was my pleasure.

SPEAKER_00 33:23

Yes, absolutely. It was my pleasure interviewing you, and thank you for being on my show, Ron. Oh, you're welcome. Thanks for listening. If you enjoyed this episode, please share on your social media to help me reach a wider audience. Subscribe to the podcast on your favorite app, including Apple, Google, or Spotify. Follow us on Twitter at InsideTechcom or visit us at www.insidechcom.show for the latest updates. Catch you on another episode.