Laurel Sutton: Hello, and welcome to another Linguistics Careercast, the podcast devoted to exploring careers for linguists outside academia. I’m your host, Laurel Sutton. This episode is an audio version of a virtual panel held at the Linguistics Career Launch in the summer of 2021. The moderator is Sue Lindner. The title of this panel is “Linguists in Technical Communication.” Technical communication includes not only writing, but editing, training, UX design, and other tasks related to communication. We’ll hear from three linguists with experience in large corporations, freelance contracting and consulting in a variety of different positions about how they plan, execute, and evaluate their work and the special skills that their linguistics training provided. There are three panelists, Joe Devney, Madeline Adkins, and Cate de Heer. Links to the presenters’ LinkedIn profiles and related resources are in the show notes.

Sue Lindner: Welcome to the panel on Linguists in Technical Communication. I’m Sue Lindner, your moderator, and Marcus Robinson is our Zoom producer, and he will help me keep an eye on the chat as well as providing links to useful resources in the chat. In Ginny Redish’s presentation a few weeks ago, I learned all about the “bite, snack, and meal” approach to introducing topics, so I thought I’d introduce this session by giving a bite about technical communication, and our panel will expand it into a meal. So, it turns out that the bite is quite a mouthful. Our professional organization, which is the Society for Technical Communication or STC, devotes a full page to top-level descriptions of jobs in the field. And I have a link to that, but if somebody else could find it, it’s stc.org, about STC and defining technical communication. But here’s my bite: Basically, for me, technical communication is the art of developing an information interface to a technical or specialized product or topic. And my snack would be that technical communication involves expressing relevant information clearly and developing it in efficient and accessible ways, typically to people who need to learn to do something correctly, efficiently, and even safely. Happily enough, this translates into a wide variety of jobs that linguists are well-suited for, such as writing, editing, training localization, and even some overlap into web-design, user experience design, and more. So with us today are panelists who have linguistics backgrounds and who have established careers in one or more job areas of technical communication. Cate de Heer is a Technical Writing Lead at Salesforce, and in this job she has developed writing standards and guidelines that are used by over 200 technical writers. She holds a patent for a system to organize and manage user interface text, and as I just found out, she writes great error messages. Madeleine Adkins has a Bachelor’s and a Master’s degree in Linguistics, and she has worked in technical communications, leadership planning, teaching, and instructional design. She’s also done training and consulting for Japanese and United States, U.S., businesses in the area of intercultural communication. And then Joe Devney has been a technical writer since the mid-’90s, mostly writing about software. In 2008 he earned a Master’s degree in Sociolinguistics at Georgetown University, and since then has considered both technical writing and linguistics as his careers. So, about me. I actually am a Linguistics PhD, and I turned tech writer about 39 years ago. I have written documentation, mostly for software developers and database products and mostly for Silicon Valley startup companies, and I am newly retired. So I think first off, I’d like each of you to tell us about your journey into technical communication. And I’m wondering if we could start with Madeleine. How did you get there?

Madeleine Adkins: Mine was an interesting journey, and perhaps not typical. Right after college, I moved to Japan and I started teaching English, and a friend of mine who was leaving about a year after I got to Japan essentially handed me a job doing technical writing, or more like editing, for Matsushita, which is a big conglomerate in Japan and we know here mostly as Panasonic, but this was their kitchen appliance division, and I worked mostly on rice cookers and toaster ovens. And I got to work on the first bread… Bread machine? Yeah. So that was really cool. So that was just an amazing coincidence that I got that opportunity, and I liked it, but I kind of filed that away because the career I went into when I got back to the States was intercultural communication training, and at some point the company I was working for started to downsize and was sort of heading towards disappearing, and I realized that if I didn’t want to hang my shingle out, I had to move in a different direction, and I basically realized a good career move was technical communication. I’d grown up in a family of writers and editors and people who obsessed about grammar and words, and so, in addition to my linguistics, I knew I had a strong writing background and felt confident making that switch. And I got my first full-time job by going to an STC meeting, I think it was my second STC meeting, and I met a recruiter. And he basically created that job for me because he found out that I had knowledge of French and Japanese and he knew a company that would benefit from that, and so I ended up getting hired by the division of Sony that makes PlayStation, and that… So my first full-time job was actually working on the PlayStation 1, updating those documents for the user manuals, and then working on PlayStation 2 a little bit, and then… It was really key for me, obviously, the networking. I had a backup plan, which was at STC I met somebody and I was going to work with them on some things and they gave me some pointers, and I was going to work on developing my portfolio, and this chance meeting with this recruiter kind of accelerated it, but it was through networking that I really got into the field.

Sue Lindner: And what kind of linguistics experience did you have at that point?

Madeleine Adkins: So I had my Bachelor’s in Linguistics, and obviously at that point I had teaching experience under my belt. I hadn’t… I had probably done a couple freelance things, but I hadn’t really worked as a writer, but again, I had an unusual background. My father was a copy editor, and so I had like more than the average amount of training and good writing, so I had that. And the linguistics trained my brain to be logical, and that’s really one of the keys with the tech writing is being logical.

Sue Lindner: Absolutely! Joe, how about you, how did you get here from there?

Joe Devney: Into technical writing? Back when I was young, back about college age, I took some training in data processing, which was programming and a lot of other stuff. Never got very much of a job in IT, I was a computer tape librarian, which shows you how long ago that was. But then, several years later, at about the same time I graduated from college, I got laid off from my corporate job, so I looked for a new career because I thought it was time to do that. The way I got… I decided that technical writing would be a good fit for me because in college I had done an awful lot of writing, and my teachers liked my writing, and I had the technical domain knowledge to bring to the field. So I won’t go into detail about how I found my first job because you can’t do it anymore, it involves newspapers and postal letters. But yeah, I got a job writing system administrator manuals for a subsidiary of the phone company.

Sue Lindner: And then you kind of added linguistics later?

Joe Devney: Yes, I had a little bit of linguistics background. Before that, I’d been obsessed with language my whole life. I’d read a lot of books about language. In my college days, I took a couple of linguistics classes as a part of my a minor in Communication Arts, but then I had been a tech writer for about 10 years, and I decided I wasn’t really doing anything new and exciting. So I decided I needed some new, some more credentials, and I started looking around for master’s degree programs, and I found one at Georgetown that sounded very interesting, and I realized that if I worked really hard I could get through it quickly and then get back to work. So, I took a year sabbatical and got my degree.

Sue Lindner: Very cool, thank you. And Cate, how about you, what was your odyssey like?

Cate de Heer: I was a French language major, so I took linguistics and translation courses as part of that. My father was from the Netherlands, and nobody speaks Dutch, so Dutch people have to learn different languages, so I was… My father was good at languages, and I was always encouraged to study various ones, so I ended up majoring in French and did a year abroad and so on. And then I didn’t have any special idea what I was going to do except that I… Everyone assumed that I was going to be a teacher, and I knew I didn’t want to be a teacher, and some people would say, “Oh, well, you could be a flight attendant.” And I will just say that I didn’t like wearing polyester. And so, then a friend of mine, I just sort of wandered into this internship in the Publications Department of the Fine Arts Museums of San Francisco, and that introduced me to publishing, and I made a contact there with somebody at Random House had a little office in San Francisco where they did foreign language and biology college textbooks. And so I ended up getting my first real job there and worked there for five years, and that was a really great background for everything else that I did l-… all the technical writing that I did later, I use that background still to this day. And from my linguistics coursework, I got kind of very structured, mathematical sort of notions of language. So you’ve got, if you think of language as an equation where you have vocabulary and syntax on one side of the equal sign, meaning on the other, that sort of way of thinking has been really helpful to me, and I think also the structure implied in linguistics also has been really helpful to me in developing technical documentation, and I have found that not all technical writers have that ability to really understand structure, and so that’s something that my linguistics background has really helped me with. When I graduated from college or even when I left my first job, I could not have imagined the internet, but the internet’s been really good to me and I think you know to everyone here and so I have worked on a lot of websites and for various software companies and now, as you said, I work at Salesforce, and most of my job there is writing user interface text, which, again, that sort of mathematical approach to language has been really useful for that very constrained writing context.

Sue Lindner: Yeah, I often feel like I constructed sentences, I didn’t just kind of author them. I actually kind of put them together so they said what they needed to say. It is a very structured mathematical kind of approach. And also just being able to draw pictures of software, again, it’s that structure, linguists think in terms of tree structures or networks, you know, representing information in that way is pretty natural to us. So my journey was, I actually finished a doctorate, had a postdoc, and then realized I needed to support myself and there were no jobs available, so I went to the career planning and placement office on campus, which did a lot of what this LCL program, the career management track, you know, looking at resumes, understanding your skillset, becoming conscious and aware of your skillset and mapping them onto the skillset that your target career needed, and learning how to talk about that, learning all about informational interviewing, that was a new concept, and they even set us up with some interviews, and giving us lots of good guidance for how to repackage ourselves as non-academics and… But like everybody else, I sort of had that side interest. Mine was publications. I had edited yearbooks and some other kinds of journals, so I’d always liked presenting written information. And it turns out that that, plus the linguistics, was a real helpful thing. And so I became a software writer for 40 years. So I thought maybe it would be fun if we could tell, talk about maybe a project or two that show what it’s like to work, to do the kind of work you do. Joe, start with you.

Joe Devney: The easiest job — I’ve done a lot of different things along the way — easiest one to explain for this audience, I think, is having a regular corporate job as a technical writer in a software development department, which I did for a few years for Vodafone. That’s the big cell phone company based in Europe. They have an office not too far from where I live. This was for technical audiences. The product I was working on was called Vodafone Live. It would have to be ministered in data centers around the world, at the different Vodafone offices in different countries, and that was my audience, so it was technical, and also, many of them did not have English as their first or sometimes even second language, so I had to keep that in mind when I was writing. So my cultural communication classes helped there.

Sue Lindner: How did you learn about your audience, I mean, if they were very technical and you were somewhat technical, but perhaps not in their area of technical expertise?

Joe Devney: You don’t have to actually know how to do your audience’s job. You just have to understand, like the environment they work in, what sorts of things they work with. I knew the concepts, I know what a data center is, I know about [passing 16:12] data and installing applications. So I could not go do their job, but I could explain those aspects of their job that our software helped them do. And so what I delivered was system administrator guides and application administrator guides, pretty technical stuff, my subject matter experts were the software developers who were building the product.

Sue Lindner: So did, you worked primarily with those engineers or software developers, or did you work with other writers, or editors?

Joe Devney: It was a two-person technical writing shop, so me and one other writer. I have only had one job where there was a separate team of editors to what I wrote, and I thought that was wonderful.

Sue Lindner: Wasn’t it wonderful? I had one of those jobs too, I adored it. Yeah.

Joe Devney: But mostly I’ve been a writer/editor for my whole career.

Sue Lindner: Yeah, same here. Good. Madeleine.

Madeleine Adkins: I’ll mention more than two, but very briefly, just to get, because I’ve done a lot of different Examples of work things. So the first one I want to mention is McKesson. I worked on a project… One of the things that I did was to document the processes inside a distribution center as they were changing the technology they used there, and that was very hard, because all of the subject matter experts or…

Sue Lindner: Experts, yes. Who you get your information from.

Madeleine Adkins: All those people were working at the distribution center setting things up, and they were working 12-hour days, and they were very tired, and they were not reading their emails and answering them. So I ended up flying out there for five weeks to Memphis, and then it was really easy to document because I would catch people during a lull and I could see things for myself and I could get help from other people than the people that were officially assigned to help me. Because that’s actually one of the big challenges, and that’s why I’m mentioning it. With technical communication, you’re often having to work around other people’s schedules and other people’s kind of demanding situations to get the information, so in my case going there was the key. In recent years, I’ve had two contracts at Apple. The first one was a content migration project, so moving content from one old website to a new one. But it wasn’t… Not just moving it, we had to update the content, we had to validate it, we had to make sure it was current. So there was actually a lot of rewriting, and that actually meant just a lot of one-on-ones with the experts, with the SMEs, and just creating a bunch of new content. And so, that’s an example of a situation where I knew… You know, I know some HTML, I can set up a website, so you know you needed those skills to do that, as well as really good interview skills. The second one at Apple was developing a new-hire training program for… This was listed as a tech comms role, but it really, really was very much in my bailiwick of also being a trainer and curriculum developer. So, anyway, developing a new-hire training program for some big data new hires. And the thing about that was, again, there were a lot of different experts, and in that case I often worked with them to document, or I took their documentation or for the soft skills I created it based on knowledge I had. So that’s a different kind of role. Recently, I’ve gotten into UX writing and content strategy, and that’s where I’m at right now. And so I’ve worked with two banks. First one was a little more one-on-one, it was a little more like what I think of as typical tech writing, and the second one, where I’m working now at Wells Fargo, they… I’m working on website content. So we work with teams, and we work with a lot of different people. So, it’s important to be aware of what kinds of jobs — and this is I think more typical of UX writing and content strategy, is working with a lot of people, and having to have a high level of kind of meeting skills, and dealing with personalities, and, you know, all those interesting things that are not technical, but are key to success.

Sue Lindner: What is content strategy as opposed to say, technical writing? I’m actually not clear on the concept.

Madeleine Adkins: It’s funny, because there’s different people in the business world who use the term differently. So apparently that term is also used in marketing, so if it’s content strategy in marketing, very different focus from like what I’m doing, which is, you know, making things accessible on the website so that customers and potential customers have ease of use, you know, helping you to do what you need to do with your bank. Right? So that’s different, and then within UX writing, kind of the UX… If you have a role that’s called “UX writer,” you’re probably focused day to day more on the writing, more on the word-to-word, sentence-to-sentence level, and if you’re a content strategist, you might be doing that, but you also… Or you may exclusively be doing the big-picture, holistic view of what content needs to go where, and it’s a little more like information architecture, and so it’s a little more leadership or advanced role.

Sue Lindner: Thank you. And Cate, what kind of projects have, really kind of typify your career?

Cate de Heer: Well, let’s see. I’ll do…

Sue Lindner: Writing error messages.

Cate de Heer: Yeah. Writing error messages. Yes. Start with… I have a few, and starting with my first actual tech writing project was a, probably about three years after I’d left Random House, I had a different sort of job in-between, and then I got this gig writing a step-by-step guide to wiring classrooms for the internet for a project called Net Day across the state of California. So I had to learn a lot of things. That’s one of the things I love about technical writing is, you learn about all kinds of weird stuff that you would never know about otherwise. So, I’m the only French major I know who can wire Category 5 cable. So the way I did that was, they provided, you know, people who knew what they were doing, and I had interviews, they gave me a photographer as well, and they had… I had interviews with someone who installs cable for a living, and that’s when I learned that part of my job was sorting and prioritizing because… It was a woman actually who, her father had been an electrician and now she does electrician stuff but does internet stuff and installations, and I said, “Well,” and she had been going over some facts, and I said, “Well, which thing is more important?” And she looked at me and said, “It’s all important.”

Sue Lindner: Yeah.

Cate de Heer: But that… So, as a writer, you know that you can’t say it all at once, and you know, people using your stuff can’t absorb it all at once, so you have to learn to sort and prioritize and you… A lot of your job as a technical communicator is just learning to ask questions and sift through what you get back and figure out how to organize it. So that was sort of how I got my start in tech writing, and then people started asking me, “Oh, were you a computer scientist?” No. And then I had several… I worked for Intuit and Adobe and in the late ‘90s, worked for a whole bunch of different startups that don’t exist anymore, and professional associations and so on, and some of the content was technical, and some of it wasn’t. It was for, you know, I did things for educational non-profits, education non-profits, and that wasn’t… That material wasn’t technical, but the ability to kind of gather information and think about it in this new context, social context of, well, websites and the internet, and then put it together for ordinary people who were not in the technology business, that was a, you know, big part of what I was doing, and then continues to be at Salesforce, because most Salesforce users are not technical. They’re salespeople, or shop owners, or, you know… That’s the whole idea is to provide something that’s easy for people to use, even if they’re “not technical.” And at Salesforce I worked on… I have worked on a huge range of stuff, and I mentioned my publishing background before, and so I, like Madeline, have found that background really useful, and so I’ve created a whole series of guidelines and standards for other writers to use, the writing group has grown tremendously since I joined Salesforce and… I work on, you know, written standards for user interface text and for various kinds of documentation. In particular, we went… Salesforce went to DITA, which stands for Darwin… It doesn’t matter what it stands for, but it’s a structured way of creating technical documentation, and when Salesforce adopted DITA somewhat as a standard, writers had not previously written what’s called a short description, a short desc, which is part of what, you need it to make DITA work. And so suddenly we were all supposed to start including this element in our documentation and release notes, and I thought, “Oh my gosh, people are just going to put whatever in that. Between those tags, we have to have some guidelines.” So another writer and I developed Release Notes-specific guidelines that are, you know, still in use now that it’s all about making the release notes work not sort of one topic at a time, but the way the short descriptions and the titles are written help each topic, become, you know, work in the bigger system that DITA is, and explain at every level what is new each release at Salesforce. So that was a key accomplishment.

Sue Lindner: Yeah. So your audience there were sort of in-house writers, essentially.

Cate de Heer: Right.

Sue Lindner: Learning how to… And you were helping them do their job. I guess I had a project where I wrote a template for a functional specification for our engineers to use because these engineers — well, or software developers — would be inventing new features to add to our product, and very often, they just would have an idea, they’d just start coding, nothing wrong with prototyping, but they’d get to this place where there would be mission creep, it would start doing different things than they expected it to do, and, or more or less, etc. So we decided to have a functional specification where they could actually sort of prototype on paper, and describe what it is they were going to add to the product, and who was going to use it, and why would they care. They had to address each one of those points before… And then it would get approved by the marketing people and that… Well, all the stakeholders: the engineering group, QA, customer support. You know, did we really think this was a good feature and was it well thought-out? Did it skip any steps? You know, that was another fun thing is reading something for consistency and completeness, which I think linguists can do very well. And you’d say, “Oh, you’ve told me how to, you know, edit this thing, and delete it, and turn it around, rename it, but how do you create it?” You know? “Oh, well, I guess we should tell them that.” But at any rate, the writing for the in-house audience can be just as important. It helps people get their facts straight internally. Well, so, you’ve all kind of touched on these things. Actually, did you finish? You were going to talk about several projects, I think you did.

Cate de Heer: Yeah, no, I hold a patent on… That’s the nice thing about working at Salesforce is they pay for patent applications, and so I hold a patent on organizing and managing user interface text.

Sue Lindner: So I think you all touched on this, but maybe we can talk a little more about ways in which your linguistics background has helped you get your job done. Or put another way, what jobs or tasks have really benefited from your linguistic superpowers? Somebody jump in. Joe.

Joe Devney: I think what has helped me specifically from linguistics is syntax, learning syntax and semantics. And I… Something I did not study formally but I’ve read a lot about is psycholinguistics, which is how the brain actually interprets language and produces it, and that’s really helped my editing a lot, because basic copy editing is just fixing the grammatical errors and things like that, but what I’m doing now is more just, not just untangling sentences but I can explain in detail why this version that you had is harder for the reader to understand, and how the new version is easier for the reader to understand, because there are two important things that technical writing specifically has to have: what you write has to be, it has to be accurate. They can’t misread it and think something else, because that can lead to user error. We don’t want that. And also, it has to be absorbed quickly. The people need to find out what they need to learn, what to do, and go back to their job. They don’t want to read a whole page if they can get something done in half a page. So…

Sue Lindner: They’re busy people.

Joe Devney: They are busy people. And our job, or my SMEs’ job, is built around the software we’re building for the audience, for the people who are reading the book, the software is just a tool to do their, help them do their regular job. So my job is to get the information into their brains quickly and accurately. And so that’s what I focus on.

Sue Lindner: I like your point about this psycholinguistics or the processing speed that people take information in. I used to think of myself as feeding them a rope, gently, you don’t want to like dump the whole rope on top of them. You want them, you know, to get just a little bit at a time so they can kind of ingest it and ingest it. You’re coming up with the explanatory strategy for how this information can be learned by somebody, and you kind of have to start with, “What do I start with first, and then how do I pace the…”

Joe Devney: Yes, what they need to know to do the next step, and actually there, I have an analogy from my work at Vodafone where there was limited bandwidth for getting data out to the people’s phones, and so the engineers had to design things to minimize server [unclear 32:10] phone to stop doing what it’s doing, go back to the server get some new information. So it’s sort of the same thing in my technical writing, trying to make efficiency like that. The more 10ths of milliseconds you can save in cognitive activity, the better.

Sue Lindner: Madeleine, how about you? What linguistic superpowers do you bring to your job?

Madeleine Adkins: I want to give an example, but first, I just want to second or third what you all just said because like right now, especially in UX writing and content strategy, one of my jobs is literally to represent the customer, one potential customer and look at their interests, because not everybody’s thinking carefully about that, and so the designer and I are really the ones who are speaking up for that.

Sue Lindner: Right. Well, you’re looking at the product from the outside in, and not, instead of the inside out.

Madeleine Adkins: Yeah, because there’s only, you know, like, there’s competing products out there, competing companies, so we got to make our product appealing and easy to use. So the example I want to give though is from when I was at Sony working on the PlayStation, and when we started working on PlayStation 2, there was a naming conventions project because you have to name all the buttons and things on the console itself, they have to have names, and this was when things were very new, like we had to have some very original names for things. So that had to be translated into all the languages of all the manuals and to cover all the countries of the world. And I forget if it was like 26 or 36. It was a lot of languages, and so I was in charge of this project, and we used a company that did the translations. And I’ve studied a lot of languages. That always helps if you have that background. But, of course, I don’t know 26 or 36 languages. So, here I was, receiving the translations on these part names, and I remember — and this is absolutely my linguistics training because you’re trained how to look for patterns. You know how to recognize a pattern and you know how to recognize when a pattern is not happening. So what I noticed was, there was mistakes in the Arabic — which I really don’t speak, I don’t even know the writing system — and Swedish, which I don’t speak, and I was able to say, “We have a problem. There are translation errors in the Arabic and the Swedish.” I have to say, at first people didn’t believe me, but I did get my point across that there was a problem, and when it was researched, yes, there was a problem, and we had to get a whole new translation for those languages. And so I couldn’t have done that if I hadn’t had my linguistics training. Or I won’t say I couldn’t have. I think my linguistics training provided me with an excellent background to achieve that.

Sue Lindner: Yeah, being able to look at paradigms and, you know, understand “Aha! Here’s the regularities and whoa, what’s going on with that?” And maybe it is irregular, but probably it’s not, and at least it’s always worth questioning. Yeah. I’ve certainly experienced that as well. Great example. And Cate, how about you?

Cate de Heer: Yeah, +1 about pattern matching and generalization. You know, it’s really in a multimedia environment, I think that the structure inherent in linguistics, you know, I just agree with Madeleine, it just gives you a, really helps you perceive problems in language, and I… That’s a fascinating example. Madeleine, I know many times I have looked at something and maybe I knew next to nothing about the subject matter, but I could tell from the language that something was wrong, you know, linguistically. And, you know, a number of times, I’ve, you know, pointed out… You know, sometimes if you point out mistakes, people think that you’re just being their older sister or their high school English teacher or something, and they… But, you know, plenty of times people have looked and said, “Oh, that’s a terrible mistake.” I mean, not language-wise, but content-wise, “I’m so glad you caught that.” I only caught their mistake because it showed up as a structural problem in their language. And it’s weird. It’s almost like a right-brain non-language thing to see those patterns and identify them. But yeah, that’s a really interesting part of my job. I’m just seeing if there’s anything else. And then… Oh, just the whole thing about the whole ability to get to precision in language and precision, the precision you can achieve in conveying meaning, you know, when you have a linguistics background is just really important, and I think it’s only going to get more important in the future, you know, working with different technologies.

Sue Lindner: Well, certainly being able to disambiguate sentences, you know, and where you… You often get sentences from, say, engineers that can mean multiple things, or you get them from other writers, even, in bad documentation, and the reviewers will read whatever they think is reality into those sentences, so they don’t necessarily notice it. I would rather write something that was clear and unambiguous and wrong, because then that will get caught by the reviewer. But if it’s kind of, you know, we used to call it lizard dancing, it was just kind of like, “Oh, it kind of looks like this.” And, you know, people can just kind of project into it whatever they want to see. It’s a big Rorschach test. You know, documentation is a Rorschach test. They can read into it whatever they think the truth is, but then the poor reader, you know, user kind of looks at this and goes, “What are they trying to tell me?”

Cate de Heer: Yeah, and that’s a thing that I have fought against. And going back to my mathematical notions about language, if you have vocabulary and syntax, you know, if language is an, meaning is an equation, you got vocabulary and syntax on one side of the equals sign and meaning on the other, you can’t just declare the meaning on the other side. It’s a [consequence 38:40] of the vocabulary and syntax. So that’s kind of what I mean about precision and conveying meaning.

Sue Lindner: Yeah.

Cate de Heer: Yeah.

Sue Lindner: Well, and the fun part too is that you’re actually kind of… I used to characterize my job as being a very high-level language, or high-level programmer in a language called English, and I had a different compiler for every reader that was reading my document. And, you know, if they could all kind of come to consensus about what conceptual model I was conveying, then I had done my job, but if everybody sort of had a different idea of what was going on, then it was time to do a revision, or three or four. Any other good superpowers that linguists offer? Are there any other tech communication career opportunities that we haven’t talked about yet and that seem fairly well-suited to linguistics?

Madeleine Adkins: Definitely the, you know, the area of voice, and I think you’ve had a whole panel on that, but, I mean, definitely the whole voice area offers a lot of opportunity to linguists, especially if they’re either data-oriented or conversation-oriented. There’s a lot you can do that way. You could see it as an offshoot of tech comms, for sure. And I think one thing to — it sort of gets into the next topic maybe, but I think it’s really important for each of you to think about like, “What are the skills I bring other than linguistics?” And often, as the case with my Japanese and French that got me that first full-time gig, often it’s the combination of skills you have that get you there, that get you the job.

Sue Lindner: What kinds of things have you folks had to learn on the job? Joe.

Joe Devney: I try to keep up with technology. I know… I read a lot about science. What I learned on the job is the specifics for that particular company, that particular product. So I talked about Vodafone, and I learned there and elsewhere about what’s involved in getting cell phones to work, things like that. I try not to start at zero when I start a new job. So I know the basics of whatever they’re working on to some level. I will learn specifics about that particular product, how it’s different from others on the market, or what came before it.

Sue Lindner: Yeah, what kind of tools do you guys use, and did you have to learn about those on the job or go off and take courses? What would our career linguists here need to go do?

Madeleine Adkins: I’ve used a lot of Microsoft Word, I have to say.

Joe Devney: Yes.

Madeleine Adkins: And Excel, Numbers, Pages, and… So like, for me, it’s been a lot of the really basic business tools. But, you know, it really depends on the job, and it depends on what’s sort of the corporate culture.

Joe Devney: I use whatever my employer or my client is using, and yes, a lot of times that does mean Microsoft Word, and sometimes I will tell people, you know, “You want a very complex document here. Word is not really the tool, you might want to switch to a publishing platform like Adobe FrameMaker.” And they say “No. Everybody knows Word, we’re going to keep that.” So I’ve learned a lot about how Word works just because I’ve had to, but I did have to take a class to get started with Adobe FrameMaker. FrameMaker seems to be fading now and is being replaced by MadCap Flare, and maybe one or two others out there. So those are the tools that I use the most often.

Sue Lindner: Guess I’ve used… Like, I adored my years using FrameMaker. I think it is such a sane package, but I agree, it’s been kind of fading out for reasons I don’t quite understand, maybe cost. But yeah, Flare seems to be taking its place. Dreamweaver, I guess? I don’t know if that’s still happening, but…

Joe Devney: Only on subscription now. But if your job involves making websites, you should really know Dreamweaver, yes.

Sue Lindner: And I’ve also used Markdown, I guess for…

Joe Devney: Markdown is fairly new, at least I haven’t heard about it except for the last year or so, but it’s super easy. There’s not much to it, so you can probably learn that in an hour or two and then say, “Yes, I’m qualified to do Markdown.”

Madeleine Adkins: In the UX world, you have to know… You don’t have to be an expert, but you have to get comfortable with things like Sketch, or Figma, InVision, those kinds of tools, which designers develop their images in and share them. So you have to know a little bit, at least get comfortable with using their tools.

Cate de Heer: Well, at Salesforce, my experience was similar to what Joe and Madeleine have described when I was consulting. At Salesforce, we have pretty different… It’s been a really different thing, we have a lot of in-house tools. Some of them are bespoke. We use something called Perforce for checking documentation, checking in documentation into the code, we use Oxygen. We use a lot of Google… I haven’t used Word in a long time. Only the legal department seems to use Word and so forth. So we use a lot of Google Docs and Google Spreadsheets, which makes it possible to collaborate with other people, other writers and other people, on things… I don’t know how we would operate without that, you know, people just being able to just go in and work on a document and not be thinking about version management and what version is saved where, and so on. So we do a lot of article drafting and finalization of things in applications like that. And then of course there’s Salesforce, which is huge, and no one knows how to use it all, but depending on which features I’m working on, I’ve worked on various features during my nine years there, with, you know, different teams developing different parts of it, and so I have to use it at least to some degree to do documentation. It’s just sort of a… It’s a constant learning process. “How does this feature work? How does that feature work? Why am I not able to do this? Oh, because this other setting.” So there’s a lot of troubleshooting and just figuring things out that we have to do in-house. I mean, there is, you know, some support, but it’s not just down to sort of simple tools. And then I’m going to put something in the chat here. It’s my, one of my favorite quotes by a Zen abbot, who is also a writer. I mean also, yeah, he’s a poet and he’s an abbot here in the Bay Area. As quoted in Wired Magazine, he says, “The real technology behind all of our other technologies is language,” and I just like that because it’s so true. There’s all this… All these other tools come and go and, you know, but you as a writer know the basic things that you want to do and, “Okay, this year I’ll use this tool and, you know, for the next client I’ll use this other tool,” but you know as a writer the kinds of things that you want to do.

Sue Lindner: Yeah.

Joe Devney: I want to jump in with one other comment about Microsoft Word. For attendees who want to move into technical writing, if you’re going to consider yourself a professional tech writer, you need to know more about Word than just how it’s like a typewriter. You have to understand how to use paragraph tags and character tags, things like that, because that’s how you format the document, that’s how you make it consistent all the way through, that’s how you can make changes more effortlessly than going through and… It helps you organize the document. So…

Madeleine Adkins: Something else which in the last decade, no matter where I go, they’ve got some kind of CMS, content management system.

Sue Lindner: Oh, yeah, talk about that.

Madeleine Adkins: They were around before that, but really it just… Everywhere you go, there’s a CMS now. It’s, often in my experience, something like Confluence but it can be other things. They’re not hard to learn, but that’s actually one of the challenges, is, they hope you already know that, that you don’t need to spend a lot of time learning that.

Sue Lindner: Basically, a content management system exists to manage the various versions of the various pieces of documentation, and code for that matter (right?) I mean, so you can put together combinations of the correct versions of things.

Madeleine Adkins: Certainly, originally when I used them like Sony, that was the objective, but now it’s like everything’s on the CMS. That’s kind of the file box. Well, I shouldn’t say that, because there are other ways to… But it can happen that that becomes also the general file box or information source about different groups and projects and stuff, so learning the CMS and learning it quickly, really important.

Sue Lindner: Probably my last question of the panelists is, what advice would you have for linguists who are perhaps thinking about a job in technical communication? What kinds of things should they… How should they prepare themselves, build their portfolio, use STC resources, anything that seems useful?

Joe Devney: STC is a good resource, and what I would recommend is, find the closest STC chapter, and go to their meetings, because typically at an STC meeting — my chapter has them once a month — there’s always a guest speaker talking about some aspect of technical communication, so you’ll learn something that way, and you also get a chance to talk to and network with and learn from veterans in the field who can tell you what tools you need, what companies you might want to talk to about jobs, where you can pick up new skills. For the last year or so, of course, everything’s been on Zoom, where you miss a lot of that, but I hope everything goes back to in-person, because that’s a much richer experience.

Sue Lindner: Certainly, building up a network is essential. It’s how I got my first job. I had prepared like crazy, but then what really made the difference was running into an old college pal who said, “Oh, you know, the last job I worked at, the tech writer there is hiring, so why don’t you, you know, submit an application?” STC chapters are a great way to build your network as well.

Madeleine Adkins: Yeah, I absolutely want to agree that networking and making personal connections is key. I’ll tell you one reason for that. Obviously in my case, it literally got me a job right away, but even when it doesn’t do that, if you’re applying for something — and with the internet, you know, maybe 1,000 or 5,000 people are applying for that same job — if you know somebody in that company, you know somebody who’s friends with somebody in that company, through your network you can get your resume on the right person’s desk. And that’s how you get hired a lot of times, because…

Sue Lindner: Very true.

Madeleine Adkins: … there are too many resumes coming in. So it’s… I can’t say enough for personal connection, so build that. I may have missed it, but did you mention like volunteer at STC or volunteer at some other organization. That way you can, for example — and that was, again, my plan before I got that offer at Sony — but, you know, if you volunteer, I think I did it anyway but, you know, if you volunteer at STC or I guess, Write the Docs, or whatever organization, then you have the opportunity to make closer connections to people, you can have something that’s for your portfolio, and you have these people who can be your recommenders.

Sue Lindner: Right. Some companies want references, right? They’ll ask for references and so…

Madeleine Adkins: So do something for free just to build up your portfolio or help out a startup that can pay you either nothing or very little or whatever. You know, don’t be picky about your first job, because that’s not your end game. Doesn’t matter. Just get some experience. That will help you build your career, especially if you’re right out of school. And I also want to say it’s really important to be really generally kind of open-minded and saying “yes” to opportunity, because you don’t know where it’s going to lead. So, just really always be learning, always be exploring new things. In the Bay Area, I can’t speak for every city, but, you know, before COVID, there were like after-work lectures in the city and sometimes in Oakland. You know, you could learn new aspects of the field or some other field, so not only is that a networking opportunity, but, you know, you just… A technical writer is somebody who’s always learning. You have to learn whatever you’re writing about, so keep working on those skills and keep developing your expertise. And the other thing I want to say is that tech writing jobs are not always called “tech writer,” so it’s really hard in a sense to look for work, because if you just look at jobs that say “tech writer,” “tech editor,” that’s going to be a percentage of the jobs that are really that. So, as I said, you know, the UX subfield has its own titles, “UX writer,” “content strategist,” or “content designer” is kind of where it’s moving to. But in tech writing in general, it can often come under a whole lot of names. And the other thing I’ll really say is, get your resume in shape, get somebody to review it who knows the field, and LinkedIn is almost everything nowadays. Really have your LinkedIn profile solid, and that will help you get jobs.

Cate de Heer: I echo what Madeleine says about flexibility. Be curious and open and flexible. Don’t say “no.” Say “thank you,” because you may think that somebody’s idea or suggestion, “no way,” but you’re learning, you don’t know, so just really be open and flexible and that’s what… You need to be flexible in these jobs, too, yeah, and that’s just a key requirement at Salesforce, I think, is to be able to do different things and turn on a dime when the company’s, or the department’s priorities change. You know, and that’s, it’s a good thing, really, you know, many companies get stuck and are dysfunctional or, you know, or just are, don’t… You know, turning them is like turning an oil tanker, and so they can’t respond well to changes in the market. If you work for a company that does respond well to changes in the market without there being complete chaos — there is a middle point, there’s a middle ground — you want to work in a company like that because it’s good for your job, it’s good for the product, it’s good for the people who, you know, the customers to, for the company to be responsive in that way, so think of that as a good thing. And then I was going to mention there’s an organization called Write the Docs, which I don’t know much about. I know it’s popular with some of the other tech writers at Salesforce so, and it’s at writethedocs.org. And then the other thing I want to say is, do informational interviews. Meet, as Madeleine said, volunteer, go to STC meetings, find find people in the field and ask them, you know, for informational interviews, ask them if you can spend 15, 20 minutes, half an hour asking them questions, and most people are really happy to share what they know, and if they like you and there are openings at their company, they will be happy to recommend you.

Sue Lindner: Yeah. If you’re still in school, in college, you might be able to contact a writing professor and see if they can help plug you into internships. And I certainly hired several interns through the writing professor at Santa Clara, and they went on to become professional writers, technical writers, after that, and they started out by doing sort of… There’s always a layer of of activity, tasks that have to that are, you know, you don’t need a lot of expertise to do, but it gets your feet wet, and I’ve hired several people to do production work, just basically, you know, converting a bunch of files from one software formatting package to another. And they started out by doing that on a temporary basis, and then pretty soon got to know the product a bit better and then was in a position to be hired, so starting in even at kind of low-level repetitive tasks can kind of get your foot in the door.

Madeleine Adkins: I want to add a couple things about informational interviews because I want to second, that that’s — or third, that that’s a great thing to do. Some people don’t understand informational interviews as a concept, so I think it’s important to be clear that if you ask somebody for an informational interview, often they will say yes, we’re very generous in that way, but two things: One, it’s good etiquette to thank them afterwards. That will make a good impression, and two, in the interview, and right after, don’t ask for a job. Don’t say, “Is there a job at the company?” That’s not what an informational interview is. It’s to talk about the field and to talk about that person’s expertise, and they’re doing you a favor. Don’t put pressure on them by… It’s considered bad form if you ask about jobs in that interview. So they may, as Cate said, they may think of you later and go, “Oh, you know, there are some openings.” You know, they might bring it up, but don’t ask directly, because that’s not the point of the informational interview.

Cate de Heer: I want to echo about internships, that that’s just such an important way to get experience and find out whether you’re interested in a field, and Salesforce uses a lot of interns, and a lot of those interns end up, you know, coming on staff.

Sue Lindner: Are internships generally advertised, or how do you find them? I always kind of found them, as I say, by going through, say, a professor, so I don’t, I’m not sure how would you just go out and find an internship?

Cate de Heer: I know that Salesforce targets certain universities, like Carnegie Mellon has a technical writing program, so we get a lot of interns from there, and certain other places. So, yeah, definitely talk to your counselor.

Sue Lindner: Any other questions, comments?

Joe Devney: Before we go, I want to recommend two books that this audience might be interested in. The first one is the first book about technical writing that I read when I entered the field. It’s a good basic explanation of how technical writing is different from other writing, what you should do, and that’s How to Communicate Technical Information by Jonathan Price. And the second author is Korman with a “K,” I forget what his first name is. And there is a forensic linguist named Roger Shuy, S-H-U-Y. He has a book called Fighting over Words, and he tells the stories of a number of court cases he’s worked on as an expert witness, and several of them involve things like owners manuals and warning labels, the sorts of things that technical writers produce, and he has pretty thorough linguistic analyses of those things and why they work or why they don’t. So those are two good perspectives on the field.

Sue Lindner: Great, thank you. Yeah, I forgot to ask about your forensic linguistics branch of your career there.

Joe Devney: I just gave a one-hour talk about forensic linguistics, it’ll be on YouTube sometime soon.

Sue Lindner: Oh good.

Joe Devney: I’ll let you know about when that happens.

Sue Lindner: Thank you. Nancy, do you have any questions or comments here to add?

Nancy Frishberg: I always ask the same question in these sessions. How do you evaluate your own work or does somebody evaluate it for you? How do you know it’s effective?

Sue Lindner: From my point of view, I think that depends on the size of the company and whether they actually have resources to do any kind of evaluation. One company I worked for, actually, we did put out a survey of the various users. I mean, we were a small company and there weren’t very many users at that, customers at that point, but we did kind of change our direction of what manuals we decided to put resources into, based on what they wanted. Sadly, in terms of actually, you know, doing usability studies of the actual document, that did not happen. Anybody else?

Madeleine Adkins: I’ve been in situations where we do A/B testing, peer review, editors as part of the team, KPIs, which is a business metric to evaluate the effectiveness of something in the market. There’s a lot of different ways that can be evaluated.

Sue Lindner: We certainly did reviews when there were more than one of us in the department.

Cate de Heer: Well, for documentation, you can track page views, so that’s one metric, but it doesn’t really, doesn’t tell you why people looked at a page, whether it was, you know, a good thing or bad thing or…

Nancy Frishberg: Everybody could have been saying “Can you believe what the writers said?” Everybody, and so there’s big traffic to this one page.

Cate de Heer: Right.

Nancy Frishberg: Not very clearly done.

Cate de Heer: You can collect non-quantitative, if you can collect qualitative data from users on your documentation, that’s really helpful and important and, you know, looking at it regularly and you know and incorporating that “feedback” into your content strategy. Yeah, analytics, any analytics that you can apply to your documentation and to your, you know, you can instrument your user interface as well and see, you know, how people are moving through your user interface.

Nancy Frishberg: Right, and then you can identify patterns there too. I was just going to mention two more qualitative methods that I’ve been involved with. When I was at Sun, we used to do usability testing on sections, not whole manuals because that was too much, but on newly revised sections, so you get a few people in, one at a time, you show them the stuff, you ask them, you know, the questions, or you ask them the questions, “How do you know if you’ve got the syntax right for such and such a format?” And they go in the documentation the way they knew, “Wait a minute, you reorganized things. Where is it now? Oh, now, I found it. This makes much more sense,” or, “This is a crazy place to put it.” You know, that kind of thing. And then another case we actually did remote usability unmoderated. Have you been involved in any of this stuff with user testing or user…

Madeleine Adkins: I’ve been involved with that, and that’s a really interesting process because you can get some qualitative and some quantitative.

Nancy Frishberg: Yeah.

Madeleine Adkins: I like to do the in-person qualitative. Right now, that’s not a good option.

Nancy Frishberg: Right. I love to do in-person, and even I love to do one-on-one full-hour sessions, but that sometimes is not economical. So I recall when I was at Financial Engines, this is maybe eight or nine years ago, where we had a little animation that was going to last about 30 seconds or one minute. The question was, for the end-users who were likely the target audience for the animation, and so we said, “What was the message you got out of this? What did this mean for you?” And then at the end, ask them to you know, which of the summaries retold the story the best. So, you know, with a very brief time, 15 minutes’ contact with an individual, you can do a lot of things that will reveal to you where in your message things are weak and need to be more clarified or, you know, they don’t hang together or whatever. So I want to encourage our audience also to recognize that there are both quantitative and qualitative ways to measure your work, and you’ve named about 16 of them, and I’m offering two more.

Sue Lindner: Yeah. Sadly, though, I think very small companies tend not to devote their resources to doing that, even though it would be so useful and it’s arguable it would leverage their scarce resources, you know, so that you’re spending money on things that really reach your users.

Nancy Frishberg: And have an impact on the end-user experience. Right?

Sue Lindner: Exactly. Yeah.

Laurel Sutton: Linguistics Career Launch 2021 was a one-month intensive program intended to familiarize linguistic students and faculty with career options beyond academia in business, tech, government, and nonprofit organizations. Videos of all our recorded sessions are available on our YouTube channel. LCL 2021 was organized by Nancy Frishberg, Alexander Johnston, Emily Pace, Susan Steele, and Laurel Sutton. You can get in touch at linguisticscareerlaunch@gmail.com.