The Not-Boring Tech Writer

Kate Mueller: [00:00:05] Welcome to the Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills and foster our distinctly not-boring tech writing community. In today's episode, I talk with Marcia Riefer Johnston, a tech writer who's been in the field for the last 40 years. We talk about how things have changed, or not changed, over time, some of the simple grammar tips that Marcia's found most useful, and how to handle conflicting feedback from multiple reviewers.

Kate Mueller: [00:00:41] Hello my fellow not-boring tech writers, I'm Kate Mueller. Today's guest first came on my radar thanks to a guest blog post she wrote for KnowledgeOwl titled 'How to Put the Customer First in Your Sentences'. The post included, what is for me, a totally winning combination. Some great observations about how language works in general, actionable strategies that really resonated with me, and the added bonus of an actual sentence diagram. I'm a total geek about sentence diagrams. That post stuck with me so much that it prompted me to put the author on my guest list, because I wanted to reshare some of that insight in this format. And wouldn't you know, during the preparation for this episode, I've been totally delighted to realize that my initial hunch was correct, and I found a bit of a kindred spirit when it comes to both technical and creative writing and language, and the clarity and power of language in all types of writing. I hope many of you will feel the same way after you listen to this episode. I'm so excited to welcome Marcia Riefer Johnston to the podcast. Marcia, welcome!

Marcia Riefer Johnston: [00:01:46] Thank you Kate! I am delighted to be here.

Kate Mueller: [00:01:49] We are delighted to have you. Since I'm guessing a bunch of our listeners don't know a whole lot about you, can we start with, what is your tech writer villain origin story? Tell me all your dirty secrets.

Marcia Riefer Johnston: [00:02:02] I would say my interest or inclination to what later became the tech writer me goes back to when I was a big sister. I have a sister, Wendy, who looked up to me for learning all kinds of things. For example, I taught her how to tie her shoes, I taught her how to skip. To me, that was a natural part of who I have always been. Wendy, get on your left foot. She does that. Then hop twice. She does that. Now get on your right foot, hop twice. Now do it faster. She could skip, voila. And I had that great feeling of, I helped somebody learn how to do something, and she's excited about it. There you go. What tech writers do is maybe a little bit fancier in terms of the tools and the content that we're talking about, but basically we're helping people understand things. I will fast forward to another kind of origin story. I didn't even know what tech writing was. Finishing up my master's in creative writing, writing short stories, there I am at Syracuse University, studying with the great Toby Woolf and Ray Carver thinking, who's going to pay me to write short stories? A total of zero. Karen Shymansky came into my life, and that's when the tech writer Marcia was born. Karen created an internship at Magnavox CATV cable TV out in Manlius, New York. I became an intern, learned that with technical writing I can make money playing with words, and it was love at first sight. I've been doing it for over 40 years now and thanks to Karen, it's been a dream career.

Kate Mueller: [00:04:10] 40 years ago. What kind of documentation were you producing at that point? Was that paper manuals, PDFs?

Marcia Riefer Johnston: [00:04:20] Yes, indeed. PDFs were not a thing. There was no desktop publishing. We were literally cutting and pasting with scissors, with tape. Tim Voorhees and I were co-interns out at this facility, and our project was to create a user guide for one of the very first remote controls for a box that would sit on top of your TV for people who wanted cable TV, which was new at the time. Remote controls were new, we used to have to walk across the room, imagine it, to change channels. There we are with our paper and our highlighters and our scissors. We had a wonderful woman on the staff named Estelle, who would type things out for us and put them into some kind of a machine. I don't remember if it was Linotype, whatever it was, it would spit out strips that we would paste onto the page, and we made this little mock up of how to use the remote control. Using computers to do our work was new. It wasn't even available then, it was new in the early part of my career. Some people listening will remember those days. One of the best lessons of my entire working life came during that internship on that very project with our little paper mock up of this user guide. I'm telling you, Tim and I, we worked so hard on it. We were so thrilled with it. We just thought, this thing is foolproof.

Marcia Riefer Johnston: [00:06:03] We have covered every base, we have illustrated everything, we've followed all the rules of good procedure writing. We had color coded step tabs, it was a thing of beauty. Karen said, let's grab Mary over lunch hour and have her test this thing out. There's no fancy UX. UX wasn't even a thing then. There was no usability testing lab, there was nothing like that. We grabbed Mary, she was keen to help. Karen's instructions to us were this. Tim and Marcia, you sit and say nothing. That was not easy. We watched Mary take our little mockup, she sat there with the set top box, the TV set had this little box on top, and she had the remote control in her hand. She's got our guide in her hands and we're thinking, this is so great, she's just going to love it, and we're going to see what a great job we did. She's looking at our instructions and she's looking at the box, then she's looking at the remote, pushing buttons, and nothing's happening. We are just bursting. Mary, you've got to point it at the TV! She's pointing it at the ceiling. You don't know what your blind spots are as a writer until you get somebody else to come in. You cannot know what you don't know. So that was something I've never forgotten.

Kate Mueller: [00:07:43] It's amazing how quickly, even trying to put fresh eyes onto something, and we think we're doing such a good job, how easily we can take certain bits of information or knowledge for granted. I was imagining you were going to be like, she didn't hit the power button. But not pointing it at the TV, which now is a thing you wouldn't even think to tell someone to do, because we're used to remote controls now. But at the time, an absolutely necessary piece of instruction.

Marcia Riefer Johnston: [00:08:13] Have you heard of the curse of knowledge?

Kate Mueller: [00:08:15] The curse of knowledge? I mean, it sounds like a thing I've heard of, but enlighten me.

Marcia Riefer Johnston: [00:08:21] It's that idea that once you know a thing, you can very quickly take it for granted. You don't even realize that's a piece of knowledge you have that other people might not have. That's one reason that technical writers have always been, since they came into a profession sometime in the 50s, because engineers have the curse of knowledge. They may not be able to imagine that the people they're creating this product for don't know certain things that they just know. Tech writers can fall into that same trap.

Kate Mueller: [00:09:10] Yes, everyone can fall into that same trap. I think the way I've heard it described best is that you reach a level of unconscious competence. You're really good at a thing, you have a good body of knowledge about it, but you aren't fully aware of just how much knowledge you have about that. Therefore it leaves you these big blind spots that you're not aware that you have and you don't know to compensate for. Which is why those reviewers or totally new users are so helpful because they show you exactly where the blind spots are if you let them. You've been in the industry for 40 years, can you describe to me now what your current role is?

Marcia Riefer Johnston: [00:09:52] I am on contract. I have been for about a year and a half with a medical device manufacturer, among other things. That's part of the company that I'm part of at the moment. I had worked with this team 20 years ago as well. I did get away, do a bunch of other things and have come back, to my great delight, really happy to be there, and mostly writing documents that are required by the FDA. There's a whole lot of scrutiny, regulatory oversight, which is a unique aspect to working for this company. I kind of like it, to be honest, because I've also worked for companies that don't really have to care about the quality of their documentation. You have a boss who says, if you're getting all your grammar right, you're spending too much time. Or, don't aim for perfection, aim for good enough. Which yes, that's true, I understand, but very often that's code for, we don't care how good it is, just get it out. I like working in a place where the company has to care.

Kate Mueller: [00:11:21] Legally they're required to care. There are compliance reasons why they have to care.

Marcia Riefer Johnston: [00:11:25] Exactly. Part of the job that I am particularly loving, I get to work with a high end sophisticated content management system with a team that has implemented it well. That has been, for me, one of the reasons that this career has been fulfilling for 40 years. I have absolutely loved every part of the journey as a tech writer, as the tools have gotten more sophisticated. Gone from paper and tape and scissors to working in XML and data and learning about modular writing and content types and reuse all of those things. That is a huge, exciting area of opportunity. My brain, there's fireworks going on all the time just for the thrill of using the tools.

Kate Mueller: [00:12:29] This is one of the themes that seems to come up a lot on the pod, and Janine spoke to this quite a bit in her guest episode. Which is, the folks who really thrive in our roles tend to be people who are excited or interested about learning new things rather than intimidated by them.

Marcia Riefer Johnston: [00:12:50] I would say that's the only job requirement for being a good tech writer. That, and a commitment to the craft of language. There's a lot to know there. The opportunity to learn things, if you're not excited about that, this is not the career for you.

Kate Mueller: [00:13:10] One other of my standard intro questions, we have some people who really like the role, or the title, of tech writer. We have some people who prefer something a little more general, like documentarian. Where are you on that spectrum? Do you wholeheartedly embrace the tech writer or do you prefer something else?

Marcia Riefer Johnston: [00:13:30] I have thought that term was brilliant from the first time I heard it. Writing and technical together. It just spun my head around from the get go, and it is a highly problematic term. I was sharing with you recently an article from 1990 that's called..

Kate Mueller: [00:14:00] The Case Against Defining Technical Writing.

Marcia Riefer Johnston: [00:14:04] Yes, thank you. Came to my rescue.

Kate Mueller: [00:14:06] I started reading it, didn't make it all the way through, but yes. It opens with this fantastic anecdote about whether or not a cookbook qualifies as technical writing.

Marcia Riefer Johnston: [00:14:17] Exactly. Yes, I do embrace the term technical writer. For me, it's been a great fit because I'm really interested in just about anything, just dive in. I could write about cable TV set top boxes, I could write about medical devices, I could write about software. To me, there's no limit to what I would be interested in writing about. There's no limit to the kind of tools that I could be using to do my job. You name it, it's such an open ended term. That's exactly why it's so hard to define. Does it make you a technical writer if you're using a technical tool to do your writing like a computer? Well, what if you're using paper and pencil? That was technical writing, what Tim and I were doing back in the day. Does it have to do with the content? Does it have to be a piece of electronics? Does it have to be computer related? Obviously not. But yet, if you're writing a procedure about making butter, is that technical writing? It's an impossible term to nail down in any kind of rigorous way, but I do feel like the term has fit me really well because I get to define it however I want.

Kate Mueller: [00:15:54] It's flexible enough, and there's something a little bit empowering about that as well. Marcia, I want to shift gears just a little bit here and get into a bit of the details of what prompted me to bring you on, to invite you as a guest. You did this blog post for KnowledgeOwl that was about putting customers first in your language as you were writing things for them, which I completely and utterly adored. It has an attention and a thoughtfulness to the way that language is used that I think sometimes we lose sight of in the tech writing world. I really appreciated it, there's some really good actionable tips in there. I wanted to talk a little bit about where the idea for that came from. When we were talking about this pre-interview, you said you've had a couple 'aha' moments when it comes to the way that language gets used, and that has led you to do some of the writing or the talks that you've done. I was hoping I could get you to talk a bit more about all of that.

Marcia Riefer Johnston: [00:16:59] The blog post that you're referring to, the 'aha' moment that I had, came from the company that I was working for at that time. From their style guide, one of the guidelines was to avoid using the words 'enable', 'let' and 'allow'. There was no explanation to say why, or at least not the particular why, that came to me. I don't know exactly how this 'aha' moment happened, but I think what happened is, as I was editing and taking those words out, I noticed that what was happening over and over, observing myself as an editor, that I was transforming the structure of the sentence in the same exact way, over and over. Let's take an example, it's the best way to say it. Our company's gizmo enables you, or lets you, or allows you to do this cool thing. That's the structure that those verbs support. I thought, what I keep doing to get rid of those verbs is to put the 'you' at the beginning of the sentence. I noticed I was doing that. I thought, why would we put the company's product as the subject of the sentence anyway? If we're customer centric, we're going to talk about what you, the customer, can do with our product.

Marcia Riefer Johnston: [00:18:46] It became a very simple grammatical, incredibly simple, put the person first in your sentence. I don't have to talk about grammar, but you can. You can talk about subject and direct object and transitive verbs and all of that. But it was so clear, it was so obvious to me. I thought, I'm going to share this at Write the Docs, which is one of my favorite conferences. I ended up doing, what they call, an unconference talk. I posted on their board, anybody who's interested, I'm going to share this little observation during the unconference. A half dozen people showed up and I shared my thoughts on this with some examples, and it was electric. People were so thrilled. I thought, this is such a simple thing. It's so easy to share and people can take it away and use it in their everyday writing, and they're grateful for it. That was one 'aha' moment that came from basically noticing there was this underlying simple principle that I could share with people that wasn't obvious to other people. So that was one.

Kate Mueller: [00:20:10] I think the reason it's so powerful is that a lot of us have the feeling that you don't want to be using those words. That there's something about that structure that isn't ideal. I think a lot of us have not gone past that. 'I don't love this, but I'm not quite sure why I don't love this'. Once you identify that, then you have such a simple pattern to apply moving forward, that it becomes a habit at that point. One of the writers I worked with in my last freelance gig had a task to, what she called, squash the allows. Because 'allow' was a word that had come up a whole bunch in the documentation. She was like, I don't want to be using this anymore. And it is that shift. Once you think of it that way, it makes complete sense why you would want to do it, because we do want to center our readers' experiences, because they are here to learn how to do a thing, to solve a problem, whatever that might be. They don't really care that the gizmo enables them to do that. What they care about is, here's how I can use this to solve my problem. If you center them, they align with it stronger. Also, your sentences tend to be a little bit tighter. You're often picking words that have a bit more punch, you can shorten really nicely, you're using stronger verbs. There's a whole lot that comes from that, but it's such a simple switch. It is one of the things I adore about this post.

Marcia Riefer Johnston: [00:21:43] Thank you, I like the word 'pattern' that you used. I think that's the gist of the 'aha' moment was that the pattern just emerged. I think about language and structures and grammar so it was right there for me. And it wasn't a conscious analysis. It was just, there's a pattern here. It boils down to this one super simple thing, that I can give people this one little tiny nugget to take away and it makes a true impact.

Kate Mueller: [00:22:21] I will say, there is a second nugget of true joy in that post for me, which is the trick to identify passive language, which is to add 'by zombies' onto the end of the sentence. If it makes sense, you might want to reword that because it's too passive. I think you mentioned in the post that you kind of stole this idea from someone else, but it is one of the most enjoyable ways for me to identify passive writing.

Marcia Riefer Johnston: [00:22:50] You are not alone in finding that trick especially enjoyable. I can tell you from sitting at that table at the unconference. I'm talking about, of course we've all heard 'avoid passive voice', but people don't know how to identify it. It's easy to think that something is passive when it's not. I can sit there all day long and say, you just notice that there's a 'be' verb. Which is, am, is, are, was, were, being, been, any of the be verbs, and a past participle. Then you know it's a passive voice, to me that's super clear. People are looking at me like they're thinking about what they're going to have for dinner, it's like they're not even really there. But the minute I say there's this little trick, people's faces just light up. The credit goes, as far as I know, to Doctor Rebecca Johnson. I cannot find anything else earlier than this, she tweeted in 2012, I'm reading literally what she tweeted. I finally learned how to teach my guys to identify the passive voice. If you can insert 'by zombies' after the verb, you have a passive voice. Here's an example, we could say 'this podcast is being listened to by zombies'.

Kate Mueller: [00:24:25] Lord, I hope not. They better be some very not-boring zombies, that's all I have to say.

Marcia Riefer Johnston: [00:24:31] It's a wonderful tip, and if it brings you a smile today, our job is done.

Kate Mueller: [00:24:38] Those of you listening, we will have a link to this blog post in the show notes so you can go enjoy it. And if you are a sentence diagraming nerd like me, there is a sentence diagram in there as well. If you don't love sentence diagrams, don't worry, you can skip over that part. It will still make complete sense to you.

Marcia Riefer Johnston: [00:24:56] Putting the customer first in the sentence, that to me was just a little knock off thing. Like, here's a cool tidbit I could share, what the heck. By the way, you never know what great things will come of sharing what you know. It's so amazing how that works. If you get nothing else from this blog or this podcast, take that away. Share something that you know. Who knows what it could lead to for other people, for you. Led for me to Marybeth Alexander at KnowledgeOwl reaching out to me. We didn't even meet there but she said, I'd like you to do a blog post on that. Then it led to you inviting me to this. So sharing what you know is powerful, magical. Again, it was something I just discovered through noticing what I was doing in my editing over and over and over, a pattern emerged. Related, I noticed a common thread through all of the writing guidelines that I had absorbed over the years and practiced over the years. Everything in Strunk & White, for example, use active voice, use strong verbs, use fewer nouns, adverbs and adjectives, write concisely. All these guidelines that I had learned and practiced, it just became clear to me. This was back in the late 80s. I had a little baby daughter, Elizabeth, and I thought, I'm looking for 'be' verbs. My eye is just going to 'be' verbs all the time. I have to say, I'm not saying 'beavers' in case that's what people are hearing. After I do a workshop or a talk, I have had people come up to me and say, for the longest time I thought you were saying 'beavers'. No, a 'be' verb is, am, is, are, was, were, being, been.

Marcia Riefer Johnston: [00:27:06] There's a cute little video I've put on my website. Benjamin Chose at Confab in 2015, came up after my workshop and said, I have to sing you the 'be' verb song. Am, is, are, was, were be, being, been, doo-dah doo-dah. You can go find that on my website too. But at any rate, this was an 'aha' moment for me. If you look for 'be' verbs in your writing, I don't care what it is, it doesn't even have to be technical writing. Email, specifications, user guide, long list of whatever it is, whatever you're writing, 'be' verbs will start jumping out at you. Over and over again you will see opportunities to tighten your sentence, strengthen your sentence, get rid of a sentence. It's one simple thing, you don't have to learn anything about grammar, you don't have to learn anything about all these guidelines. That 'aha' moment led to, there's my little daughter playing in the other room, and I wrote a little tiny blurb for a newsletter back then in Syracuse, New York, for the International Association of Business Communicators. Then 20 years later, I turned it into a blog post. I had moved out to Portland and I thought, I've got to start a whole new network and get people to know who I am. I wrote that up as a blog post in 2010, and then I kept blogging about language and I thought, I'm going to write a book. Then it led to doing workshops and doing talks and looking for be verbs. That one 'aha' moment has created so much richness and so much contribution to people who were hungry to write better, and it's been just extremely rewarding. That one tip alone, I've heard over and over what a difference it's made for people.

Kate Mueller: [00:29:20] Which I think goes back to the point you made earlier, that sharing the things that you are knowledgeable about often reaps far different benefits than you think it's going to. The chain reaction from that can go years down the line, it can reach people you never thought you'd reach just because you were interested and excited about a thing, and you actually took the time to share it with others.

Marcia Riefer Johnston: [00:29:45] Yes, absolutely. To you, it might seem like just an obvious thing because you're doing it all the time. It's like, sure, of course. But other people may look at you and say, what are you talking about, tell me more.

Kate Mueller: [00:30:05] This is the little unique contribution you get to bring to the world. I think that is a great note for us to take a break on, so we will take a break and we will be right back.

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

Kate Mueller: [00:30:38] We are back with more from Marcia Riefer Johnston. When I talked about being kindred spirits, we have a number of weird overlaps in our past. Among them, we both have masters in creative writing, though from different programs. We also both went to Syracuse University, though also different programs and different time periods. As we were talking about it, I feel like we discovered another similarity, which is that neither of us really likes that people make this sharp distinction between creative writing and technical writing. I'd love to talk about this a little bit more. Is technical writing a form of creative writing?

Marcia Riefer Johnston: [00:31:22] Instead of answering yes or no, I'm going to reframe that a little bit. To me, any act of language is creative. Generating language, whether it's a short story or a user guide, that's a creative act. There's a reason that the term 'technical writer' evolved to 'technical communicator'. In my brain, I don't distinguish between writing and drawing a sketch. I often need to create a sketch with words, and the visual and the words are a unified creation.

Kate Mueller: [00:32:16] I have a bachelor's and a master's in writing. I remember when I was getting my master's, which was in creative writing, I focused on short fiction and poetry, neither of which I write now, to be clear. I write a lot more nonfiction now than I ever thought I would. The hubris of youth, I suppose. I remember that we did have a technical writing class at the undergraduate level, and it was definitely the redheaded stepchild of the English department. The "creative writers" would look down their noses ever so slightly at the technical writing world. But for my money, there's so much overlap between it and other forms of writing. For example, if you're working in a particular poetry form, there are certain parameters you have to work within. Whether that's structures, whether that's formatting, whatever it might be. Those are skills that you're applying to any piece of technical documentation as well. There are requirements for whatever the genre is. I'm sure for these FDA mandated pieces of documentation you're doing, there are extensive requirements that you're probably having to work within and apply. I think a lot of those same writing skill sets from the "creative side" are equally applicable on the technical side. It's just a different set of parameters, but it's otherwise still, you're operating within those parameters. If you've learned well, maybe on the creative side, you can apply that on the technical side and vice versa. If your entry point into tech writing was, you were a support person or a CX person or a developer who ended up having to write technical stuff. Maybe now you found a little bit more of your own writing voice, and you could slide into some of the stuff that's not purely for a technical purpose.

Marcia Riefer Johnston: [00:34:23] The similarities between creative writing and tech writing. I want to give a hat tip to Carol Hattrup, do you know of her?

Kate Mueller: [00:34:36] Her name is familiar to me, but I can't place it.

Marcia Riefer Johnston: [00:34:40] She's a tech writer of some sort. I met her at the LavaCon conference in Portland last year. I did her poetry workshop, of all things. LavaCon is a content strategy conference. Many people in the content strategy space would not call themselves tech writers, but tech writers also go to that conference. Jack Molisani, who runs that conference and has for 25 years, he's been bringing Carol back and, as far as I know, continues to keep bringing her back to have poetry workshops at this content strategy conference for tech writers and others. She says that there are surprising similarities between poetry and tech writing. I'm reading this from her description of her workshop, including but not limited to structure, brevity, word choice, iteration, attention to detail and tone. For me, the overarching word I would use is 'craft'. These are elements of craft that apply to creative writing, tech writing. There's a lot to learn about the craft of working with words, what works well in sentences. I thought she did a beautiful job there of identifying some of those elements of the craft of language.

Kate Mueller: [00:36:23] Along those lines, since we both did master's in creative writing, I'm assuming that you had a writing workshop format at Syracuse. I think everybody did at that point. One of the things that was always interesting for me to navigate as a participant in a writing workshop was that you're handing out a manuscript to your entire class, usually which is 20-30 people, and everybody's supposed to be giving you feedback on that. Some people will give you amazing, stellar feedback that is exactly what you think you need to do. Other people may also give you stellar, amazing feedback but it is completely contradictory to the first group of people's feedback. This is a thing that I think maps really well into the tech writing world, because very often when we are seeking reviews from subject matter experts or teammates, we can get contradictory feedback from our reviewers as to what we should be improving. If I can pick your brain on this, I don't even know if I have an answer to this question, but how do you handle getting contradictory feedback from reviewers who are really knowledgeable, really good at what they do? You're having to navigate, whose feedback do you implement? How much of it do you use? How do you handle the interpersonal dynamics of that? Anything you can give me here from 40 years of experience, I would love to have.

Marcia Riefer Johnston: [00:37:57] I would say one of the surprises of my career is how little actual writing I do on any given day. Much of my time goes to project management kind of tasks, which would include what you're pointing at here. I'm ushering documents through a process, and I own getting those documents successfully through all of the gates it needs to go through. Getting feedback from people is a key part of managing the documentation project. What it comes down to over and over is that you're managing conversations. And some conversations, like some people, are more difficult to navigate than others. The key thing for successfully figuring out what feedback to incorporate, what to do if there are conflicting comments, which happens all the time, is having the right people in a conversation. You, as the writer, would often be the one to bring the two people together who have given you conflicting input. Identifying who needs to be in the room for a particular conversation so that you get the information you need and people are aligned. That is a real skill that has nothing to do with writing, but getting the information you need in a way that the key people involved all say, yes. That's what we need to say, that's what people need to know, that's how the product works. I think that the main skill required is getting the right people there to talk to each other, and you lead the conversation if possible. Some people won't allow the tech writer to lead a conversation, I've had that happen. They are clearly a boss, they don't want you to try to take the reins, so you have to be sensitive to that. But sometimes you can quietly get two people together and ask them, you said this, you said that, what do we really need to do here?

Kate Mueller: [00:40:29] So bringing a little bit of, I'm going to call it, collaborative transparency into that process. You're bringing those potentially dueling voices together and having them see and absorb the feedback that the other person gave and then figuring it out. I would see this in writing workshops also, that sometimes people would give totally different suggestions on what to do, but they were actually stemming from the same problem. They just solved the problem in a different way. If you can get those voices together to realize and clearly articulate the problem that those suggestions or that feedback is trying to address, sometimes then the solution you come up with is completely different from either of those, but it's because you now have a much firmer understanding of what the underlying problem was to begin with.

Marcia Riefer Johnston: [00:41:23] That is such a good point. It's one thing that distinguishes a junior writer from a senior tech writer, and we've all been the junior writer. Early in your career as a writer, you may feel a little intimidated by the subject matter experts and be inclined to do what they say literally. If they make a comment and their comment is, put in the word 'whiz bang' right here, you may just do it because they're the ones who supposedly know. The longer you're in the career, I think the more confidence you gain. To say, why did you want that change made? Maybe they're pointing to, as you say, what is the real problem here? If you explore with them, they may be the first one to say, you're right, just putting that word there doesn't really solve it. Then you may come up with a suggestion, what if we put a picture here instead? There's a million ways that you might fix the problem differently, and that person will be thrilled, and you've now brought value. You're not just a mechanic doing what people tell you to do, you're digging in. That's a thing you want to gain in your confidence to bring that kind of value.

Kate Mueller: [00:43:01] It is maybe a little bit the difference between being a mechanic or an order taker. That's what my partner calls it, an order taker. Versus being someone who's honed a craft, you're a crafts person and you're trying to apply that craft. There's a lot of talk in the community always about, how do you demonstrate your value as a tech writer? I think sometimes that's part of how you demonstrate the value. You get enough experience to be able to step beyond just doing exactly what a subject matter expert says, and instead you move into a place that is more, how do we collaboratively improve what our reader's experience is going to be when they're working through this document?

Marcia Riefer Johnston: [00:44:44] I would say it goes beyond craft, at least in this context we're talking about handling feedback. Yes, you do bring craft so you may suggest a different way of phrasing it from what the person said. That would be an example of bringing your craft to bear, but also the questions that you ask on behalf of whoever's going to be using these instructions, that is a huge value. If you question beyond just, how should we word this, but should we be saying this at all? Or, do they need a whole new task written up because there's a gap? You're pointing to a gap here that just this one phrase won't fix. Maybe we need a whole new topic. So asking those probing questions on behalf of what customers need is another big value that we can feel confident in bringing.

Kate Mueller: [00:44:50] We've thrown out a bunch of resources along the way, which we will capture in the show notes and link to, but are there any other resources that have sprung to mind for you that you really want to be sure that we share with the not-boring pod listeners?

Marcia Riefer Johnston: [00:45:04] In no particular order, one that I discovered is this book called 'Single Sourcing: Building Modular Documentation' by Kurt Ament. It came up out of the blue on Amazon years ago, decades ago, as I was searching for who knows what. I didn't know what single sourcing was, I didn't know what modular documentation was, and I just ordered it. Amazon had a smart thing going on there. This book changed my life in terms of how I approached technical writing. Some kind of resource on single sourcing and modular writing, it's tool agnostic. Has nothing to do with using a content management system, but it lends itself, of course. That is a fabulous resource that really made a difference in my mindset about technical writing. A fabulous book, it's called 'Read Me First: A Style Guide for the Computer Industry'. This book is so helpful and it has so many examples of writing procedures. There's a wonderful book just in general on the craft of writing and any questions that people have. It's encyclopedic, it's huge. It's 'Garner's Modern English Usage' by Bryan Garner. I cannot say enough about this book. For the most part, you don't sit down and read it, although he does have some really great essays in here. I'll stop there. There's just so many wonderful things out there.

Kate Mueller: [00:46:53] You can toss me the rest, we'll still throw them in the show notes for folks who really want to go down the rabbit hole with us.

Marcia Riefer Johnston: [00:46:59] Also, can I just put in a plug for, in addition to books, conferences are a fabulous resource for growing in the profession. There's LavaCon, Jack Molisani has been doing that for 25 years. Just a great place to learn and meet people.

Kate Mueller: [00:47:21] Also, you have two books, Marcia. Do you want to do a little plug for the two books while we're here?

Marcia Riefer Johnston: [00:47:28] Well, sure! My favorite labor of love of my life, I have one big book and one little book. My bigger book is called 'Word Up: How to Write Powerful Sentences and Paragraphs and Everything You Build from Them'. It's not narrowly a book on tech writing, it's really the craft of writing. I do have a chapter in there on procedure writing. It's called, 'How Not to Do, How To'. I do have a chapter, 'Everything I Know About Writing Good Procedures'. It's basically an eclectic book of all the things that I have learned over the years that I thought might be valuable for people.

Kate Mueller: [00:48:22] You've got some stuff on the 'be' verbs in there as well, right? So if you found that part of the podcast episode interesting, it's probably worth checking out the book. And then what's your little book?

Marcia Riefer Johnston: [00:48:34] The little book is called 'You Can Say That Again', and it is basically a list book. It's a list of redundant phrases or terms, such as BFF4EVER. Best friend forever forever.

Kate Mueller: [00:49:03] You are trapped until the end of time!

Marcia Riefer Johnston: [00:49:06] That's right. That's my little book, it's a list. My husband and I had made a game of noticing redundant phrases. Just in the air, they're everywhere. They're on signs, they're on the radio, they come out of our own mouths. English is just full of these redundant phrases like 'free gift'. It was just kind of a private sport. We had fun with it and at one point I went to a workshop and they said, if you want to get your name out there, you should make a little calling card book. I thought, this is perfect, I've already got 750 redundant phrases on my list. I'll make a little calling card book. Then my son Brian, who's a graphic designer and illustrator, at times he did little drawings for me. It's just a fun book, stick in your bathroom and entertain yourself from time to time.

Kate Mueller: [00:50:06] I love that it was also kind of a family affair. That's fun. Last but not least, Marcia, if people want to get in touch with you or follow you, what is the best way for them to do that?

Marcia Riefer Johnston: [00:50:18] I would point first to my website, which includes a blog. It's called Writing.Rocks because it does. And I'm on LinkedIn. Not many people have the name Riefer, which never got me teased in high school, forget about it. It's Riefer Johnston, no hyphen.

Kate Mueller: [00:50:48] Beautiful. We will have a link to Marcia's website and her LinkedIn profile in the show notes, so don't feel you have to take notes on that, it is all there for you. Marcia, thank you so much. This has been an utter delight. I'm so glad that Write the Docs prompted the connections that created the blog post that prompted me to invite you on. This has been a lovely conversation.

Marcia Riefer Johnston: [00:51:16] I am just thrilled to be part of what you're creating here. I think this is a fabulous read brought to life podcast, and I can't wait to follow all the other not-boring writers that you bring on.

Kate Mueller: [00:51:35] Thank you so much.

Kate Mueller: [00:51:38] The Not-Boring Tech Writer is produced by the lovely humans at Astronomic Audio. With editing by Dillon, transcription by Alan, and post-production by Been and Alex. Chad Timblin is our podcast head of operations. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can check out KnowledgeOwl's products at knowledgeowl.com. And if you want to work with me on docs, knowledge management coaching, and revamping an existing knowledge base, go to knowledgewithsass.com. Until next time, I'm Kate Mueller and you are the not-boring tech writer.