- Categories:
- Communications and Media
- Technical Writer
Desiré Hendricks
“Technical writing is like putting a puzzle together every day. If you like puzzles, you would enjoy technical writing.”
Technical writing is explaining how something works in its most rudimentary form. When you're doing technical writing, you want to ensure you write with clarity, are concise, and provide education for instruction. Those are the three things that are needed in every kind of technical writing, from picture instructions for a piece of IKEA furniture that use images and as few words as possible to educate you about how to put something together, all the way to aerospace technical writing where you get volumes and volumes and volumes of instruction.
I work for a manufacturing company that makes conveyors. When I heard it was a conveyor company, I initially thought, “Conveyors, like at the checkout line in grocery stores?” That's what most people think when they hear conveyor, and in another time they may have thought of conveyors running up into the sky carrying coal, corn, or wheat into silos. However, a lot of conveyor work today is automotive-related: creating conveying systems to put cars together. For example, the conveyor can carry the chassis to the tires, and to the next station on the assembly line. Our company manufactures all of the machinery and parts for those conveyor systems. We help with baggage handling systems in airports, too, which includes carousels carrying people’s luggage when they come off the plane or before they go on, and behind-the-scenes conveyors that go through security. Lastly, we manufacture conveyors for commercial applications, which are oftentimes conveyors that carry materials or other things. You would be amazed at all the kinds of conveyors out there, and that's part of the reason I enjoy my work.
I currently write manuals for conveyor systems, primarily for automotive company customers, that tell the customer how to use the conveyors they request us to assemble. These manuals name each part of the conveyor, explain how they work, and give instructions for all the ongoing and preventive maintenance processes required. And, then, of course, there's warranty information in there, too. Currently, I'm working on a manual for a couple of airport jobs.
There's a wide range of fields you can work in as a technical writer. For example, there’s technical writing for software, a field I’m personally interested in. One of my coworkers once worked for a cosmetics company, whereas a technical writer you are explaining the ingredients in a product, how it's safe, how it's not, where it should be used, and where it shouldn't be used.
Sometimes the most difficult parts of the job are the parts that require soft skills and pertain to collaboration. Everybody has their own role to fulfill during the day. As a technical writer, your involvement in a given project may be very far down the line, while the rest of the team is heavily involved at the beginning and middle stages of a project. Technical documentation, out of necessity, tends to fall at the end of the process. It begins after a product is already done. At that point, we know what we have, and now we can explain it in full and can deliver the technical documentation to the customer. As a technical writer, the most challenging part is being consistent and present throughout the process in a way that is productive, meaning you're not getting on somebody's nerves, not being confrontational about it, or not making the work more difficult through your own lack of perspective. That doesn't mean that technical documentation should be ignored early on in the process, or that a person who is a technical documentation writer should necessarily sit and wait to contribute until the end stages of a project. That’s why I said the challenging part is the soft skills part. To do the job well you need to think, “How do I continue to participate in a meaningful way so that I get the information that I need without it becoming a hardship for our team?”
I enjoy the opportunity to assemble or put things together. Most of the time, I'm writing a task instruction sheet or a manual. Sometimes, though, I have to put together an illustration, as well, and that gives me an opportunity to be creative.
I love seeing real world examples. When I first started my job, my team took us out to several plants to see exactly how the machinery and robotics we manufacture work. If you're a technical writer and you can see how a thing works in person, it helps a lot and actually can be kind of fun. Even though the machinery was fenced in, being up close with those giant robotics was a little nerve-racking, walking through the plant and seeing the giant robot arms picking up a piece, laying it down and dancing it around. It was amazing. Through your writing, you're helping your company’s customer enjoy what your company produces.
Technical writing is like putting a puzzle together every day. If you like puzzles, you would enjoy technical writing. It’s all about solving problems, but they're not elusive problems. They're problems with all the pieces in front of you that you assemble to make a whole, and that’s fun. If I was a researcher trying to make some type of totally new scientific discovery, that would be an elusive problem, but technical documentation allows me to interact with concrete problems that have the answers in front of you.
I knew when I entered technical writing that there was more to it than what I'd done previously, but I didn't know what. Recently, I learned that one of those missing pieces for me was using structured content, which basically is a coding tool that allows me as a technical writer to program a template that can then be used to move and embed bodies of text interchangeably across different platforms, whether that’s print, digital, video, which is awesome. So, there's always going to be something new with technical writing depending on what your company needs and what industry you're in. It's not limited or boring at all. It can be a little tedious, though, but that's true of anything with formatting, right? If you’ve got to put something together, you’ve got to put it together and do it piece by piece, but it can also be fun. One other new thing I picked up during my time at the company is using AutoCAD to make illustrations, as well as using Inventor and Photoshop. Those weren't tools I was working with before, but because my company needs different types of illustrations, I learned some aspects of those tools.
I like technical writing, too, because I'm a bit of a tech geek – I'm not deep into it, but I do like shiny things! I like to look at tech and say, “What does it do? How does it work? That's so cool!” Going back to my love of books, I'm a science fiction fan, and my work has brought together my love of words and technology in a way that resonates with my love of science fiction. In life and in work, you will often see interests like this coming together. I don't know anything about robotics, but since robotics are used in the automotive plants we work with, I have been exposed to learning about robotics in a way that I wouldn't have expected.
So, technical writing is not a dry experience, if you don't allow it to be. Anybody can get in their little niche and stay put, but there are lots of opportunities to experience many different things because technical writing is required across so many different industries. If there's something that somebody makes, there has to be a book to go with it. That’s the enterprise standard when it comes to technical documentation, and companies have to comply with those standards if they want to be taken seriously.
I was born and raised in Kansas City, Missouri. I lived in Louisiana for a few years during junior high and in South Carolina for late elementary school, but elementary school and high school were here in Kansas City. I spent college in Connecticut. I went all over the country! I spent early adulthood in Los Angeles. I worked there for Teach for America, and then for Xerox for a while. Then, after I had my kids, I came back home because I didn't want them growing up so fast. You grow up fast everywhere, and forgive me if I offend anyone, but when you grow up in LA or New York, you grow up a little bit faster, in my opinion. I didn't necessarily want that for my kids, and my family was here in Kansas City. People say, “Oh, you should travel internationally,” and I agree completely. I also think that it's important to get a lot of lived experience in different parts of our country, because they're so different. If you do that, it helps grow your point of view. I wish more people were able to do that.
Looking back, I was that kid that wanted to go out of state for school, and was on a mission. So, I took the college track. I walked into my counselor's office and said, “These are the classes that I want to take.” And he was like, “Oh, she just made my job so easy,” and he checks them off. I took foreign language for four years, but I don't think I ever took any AP courses, though I went to I went to a very good local school at the time. It's okay to achieve and take challenging courses, but I learned that you have permission to choose something other than what seems like the most difficult path, as well. My senior year, I had the choice to take trigonometry or not, and I was like, “I don't know if it’s really necessary for me to kill myself if I'm not going to be a STEM major, an engineer or anything else in that vein,” because that wasn't on my mind at the time. “Do I need to kill myself my senior year taking trigonometry just to prove that I can?” And the answer was, “No! Absolutely not.” That didn’t make me less. What I did instead was take a math theory class from a really cool teacher – he had a faux Mohawk and was a football coach, but he was really smart. By taking that class, I felt like I wasn't shunning math. I was still learning new ideas, just without the pressure of trigonometry during my senior year. I would say the math theory experience I had with that teacher and the discussions I had in that classroom helped me grow my ability to think, my ability to group ideas together logically, to think systematically versus just crunching numbers. Sometimes it's good to look for the same subject matter, but just through different experiences - it expands your mind.
I graduated college as a film studies major. My intention was to go into film in some way, but I tend to be a bit of a wanderer, so I didn't. I considered being a teacher in elementary schools, and I also worked in community organizing. When you like lots of things or are good at lots of things, you often spend a lot of time wandering because you feel like you have got to find “THE thing,” right? So, that's where I started off. The teaching just never worked out due to timing. In retrospect, that's probably a good thing, because eventually I had kids, and that’s a lot. While my kids were young, I worked for a food bank nonprofit for several years. After I left that organization, I became a yoga teacher and freelance writer for a while, because one of my other passions is holistic health. Those two roles, believe it or not, work very well together. I got to express a creative, spiritual side with the yoga, and then I had the more logical, tangible stuff that goes with writing, especially when you're doing business-to-business writing.
Eventually, through freelance writing, I got the opportunity to write scripts for software. At first, I didn't really understand what they wanted me to do. Then, it slowly began to make sense: the videos that people watch for instructions on how to use software all started off as scripts, that a technical writer like me writes. My first technical writing experience was writing these kinds of scripts for a company. I had to go through my company’s software myself, write technical instructions, and follow the format provided to me by my employer, which is very important. There's format and style guides wherever you go and whatever type of writing you do. If someone were to say, “Well, I'm a creative writer – I couldn't be a technical writer,” regardless of how you come to the words, words are words and writing is writing. I worked with that company for almost a year, often writing a colloquial or conversational version of the user script over on one side, and then on the other side writing step-by-step instructions: “click this button” and “hit enter three times.” Later, my employer assigned me script-writing for PowerPoints on using and implementing our software. Basically, as a technical writer, depending on who you're writing for what you're writing, you're going to continually pick up new skills.
I'm a worker bee, so looking back on my work, it's hard for me to say, “Look what I did!” I am proud, though, of my current company’s transition from printed documentation to digital formats. I think I was kind of instrumental in that transition, and I'm proud of that because it shows forward movement and that we're looking at other more 21st century solutions. When I first joined my company, I didn't know anything about what they necessarily expected of a technical writer. When I was hired, one of the people in my interviews came in and dropped this tome on the table and said, “This is the writing that we do. Are you okay with that?”
My immediate response was, “As long as there's a style guide, I can do it.” This interviewer then says, “I am the style guide,” and I was like, “Oh, okay!” When I joined the company, that senior employee was basically the style guide, because he'd been there for many, many years. It was him doing all of the work, and they were expanding and needed more people to help support his role. So, I listened, I took notes and I was able to pick up quite a lot in a very short amount of time, because that senior employee was very knowledgeable, and I was willing to learn. In that same very short timeframe, one of our customers decided that they wanted to change the format in which received technical documentation from us. They went from receiving manuals to requesting “task instruction sheets”, which are a kind of technical documentation formatted in Excel. Through this shift, I was able to pick up more Excel skills and was able to keep up and turn out quite a few of those task instruction sheets. Instructions that were previously formatted as manuals now had to be formatted into an individual sheet. Through this change, those instructions needed to still get the information to the maintenance people in the plant in a very brief format, but in such a way that helped ensure the work would be done right and that those workers wouldn't get hurt, because that's a big concern. That's one of the reasons technical documentation is important. Even when you’re just explaining how to put something inert together, those things can possibly hurt the people that work with them or the people who receive or consume them, so technical documentation is important.
My father wanted me to be an electrobiologist or something like that. And I was not interested. He always saw me in a technical role, but I did not. And, here I am. My father influenced me, or my family influenced me. They always come back to haunt you!
Believe it or not, my job consists of quite a few meetings. I'm in kickoff meetings when a project starts to get a general overview of what's going to be required. As the project goes on, I am requested to attend weekly meetings, which is when they share what documentation they’re going to need specifically for this job. We have some standard documentation that we can use as a starting point for these specific needs, so after that overview meeting, I create a digital directory in our company library of existing items might be needed as reference points for this new project. The other technical writer on the team and I pull from our standard library, put those starting materials in the directory, and begin making job-specific modifications to that standard documentation. If there are modifications that are required, we talk to the engineers that are making the product. We ask them, “How does the product work? How does it look? What would be the best perspective to illustrate this particular item that you're building?” Then, we run the modified documentation past them, and there's a little more back and forth to massage it and make sure the language is appropriate: “Am I using the right term, is this in the right order, etc.?” Then, the engineers give it back to us, we finish formatting it, and it goes out to the customer. Those kinds of collaborative meetings are most of my day, and then actually sitting down, putting those items together, and preparing them for digital shipments and occasionally for print.
I am currently finishing up an airport baggage handling system manual. Today, I finished formatting the cover, the revision page, and tabs and a spine for making a print version. I'm also sorting through the drawings that were given to us by a subcontractor and then filing those again in our appropriate digital folders. For this project I recently finished reformatting the current chapters we have for two different types of conveyors to use our newest branding. Because we recently updated our brand and because the company has turned 50, I need to reformat everything so that they meet the company's brand requirements. I'm also starting on a new airport job, so I'm consolidating the drawings, spare parts list, and other items that are coming in from our subcontractors to put them into the next manual.
When we use software like Word to create a text draft, we tend to kind of touch a single chunk of text multiple times when we don't necessarily need to. It's just the nature of the software, right? It's word processing. By contrast, when you use structured content, you’re using XML or Extended Markup Language, which is a format for storing data or text in information packages that can be automatically reconfigured more efficiently. Say that I know our company is going to manufacture a new forklift transfer machine, and we need technical documentation for it. I know that all of the forklift transfers that we make are going to consist of a rectangular frame with forks extending along a plane and two engines at the bottom, and that's what it is going to be every single time.
So, knowing that, I can use software for markup language to box that information in and make an information package that captures these basic characteristics. Then, wherever I need to talk about a forklift transfer, in my manual or elsewhere, I can just drop that package of text in using the code for that information package. If I want to put that text in a PowerPoint, I can type the code in there for that package, and then when I run it, the text just populates. If you want to do that in a document instead, it’s the same deal – you would put in the code for that package describing the forklift transfer, and it will pop up on every page where that forklift transfer was mentioned if that's the text that you want to use. Another often-used example to explain structured content is to say the text becomes like Lego blocks. Imagine you’re trying to describe the ways we can interact with a cup. You have text that tells you how to pick up a cup, you have text that tells you how to wash the cup, and you have text that tells you how to dry it off and put it away. Each one of those bits of text is captured by a Lego block of code - wherever you want to talk about each of those things, you just pop in the block, and the text populates.
Hopefully, as I said, as we continue to drive forward, eventually we'll also be able to use XML and develop systems for structured content to make our work more efficient. That’s my hope.
It's nice! They recently did a full renovation of the office. The company was founded in 1972, so the office has had several different incarnations, but when I showed up, it had very 70s and 80s vibes – there were cubicles, there were only little windows the size of my laptop monitor along the wall, and it was dark and gray. Now, they have completely renovated the space and opened it up. We have skylights, alternating stairwells, conference rooms linked to Microsoft Teams, and breakrooms with Keurig machines that give you 150 different types of lattes and hot chocolate – I’m getting all excited now! They’ve got microwaves that can also be convection ovens. I'm kind of scared of those - I'm like, “How does that work, convection oven, and microwave, as far as technical documentation?” Kidding aside, they made it a point to make it a nice place to come work. My personal workspace is along the wall, and I have a huge window with a shade, which helps me because I am not a morning person – all that light early in the morning is much needed. I have two monitors at my desk, a computer tower, and a bookshelf behind me, and that's it. Very neat, and very simple. I'm not saying that I don't ever touch paper, but I touch very little paper.
My hardware setup also includes a headset, a mouse, and a 3D mouse, as well. The 3D mouse comes into play when I'm using AutoCAD and Inventor to create illustrations. Because they are technical drawings and because it's machinery, sometimes you have to tilt the image or be able to do a 360-degree rotation of the model that you're using to eventually create the image. We start with a model that the engineers have been to trying to generate. Then, once we tilt the model and find the right angle, we translate that into a line drawing that we then label and then place into the text. As far as software goes, I use PowerPoint, Excel, AutoCAD, Inventor, and Word.
The only bias or presumption that I might have had about technical writing previously was that it didn't necessarily require as broad a skill set as it does. “Oh, you’re a technical writer? You just sit down and explain how things work?” Well, no, I have to talk to the person who made that product or machine. Then, if I'm not able to illustrate it, I have to communicate with the illustrators to illustrate it. I have to then integrate it into the explanatory text. I think that there's a presumption or myth about technical writing that it requires a limited skill set, and that's not true at all. People might think technical writers might know how to code and put some words together, and that's all they do. No, it gets much more involved than that – it’s multi-layered. To dispel that, I would say I'm an example of how that's not true! As my story has illustrated, I meandered around quite a bit. The skill set that comes with writing was always there for me. When I went into freelancing, technical writing emerged for me. So, the myth busted. You don't have to go through a certification program. I’m not saying that you shouldn't, but if you have a certain skill set, you just need to simply illustrate that you can apply those skills now to technical writing. Technical writing doesn’t necessarily have to be your major to enter the field, but you need to be able to learn and adapt and grow as a technical documentation writer at each stage because technology is ever-changing. It's not like you have the luxury of not seeing something, learning something, or doing something new, because technology is not going to stop.
Because I took a nontraditional path, this question is something that's challenging for me to answer. I would say as far as prerequisites are concerned, you need to write a lot. You need to have a strong handle on the English language if you're writing in English, but that's true for any writer. I collaborate with people a lot, so you need a willingness to listen and a willingness to adapt because you have to be able to summarize what someone has shared with you. I didn't know anything about making conveyors before I started doing this, so I had to learn the terminology for this industry. I had to listen to my subject matter experts, who are the mechanical and electrical engineers on site, and then summarize what they shared with me in a form that is understandable for a non-engineering audience or an engineering audience that isn't necessarily the type of engineer that they are. On one side of a product are the engineers that conceptualize, do the math and put everything together on paper. On the other side are the engineers in the field who break it down and put it together every day. These are two different perspectives, so you have to be able to write in a way that addresses that engineer in the field and is much more concrete and not as theoretical. It's greasy - literally.
You can major in technical documentation and get a certification in technical documentation, if you choose, but if you want to give it a go, you can look at the technical writing jobs that are available and see if you know or understand or can learn the things the employer is asking for. When I look at the application for a technical writing job, I see everything from jobs requiring Word, Excel, and Photoshop as the only required skills, to jobs requiring knowledge of FrameMaker, which is a structured content program, requiring a security clearance and requiring you to be able to use Photoshop, as well. So, many jobs can range between two different extremes: one that’s basic, as far as the technology you have to be able to put your hands on, and one that's a lot more advanced. For example, what you might see for more of the military-technical writing jobs is S1000V, which a structured content program built according to military specifications. Like with any profession, you can choose the more traditional route, which is, “I'm going to apply to this college, I'm going to get a technical documentation degree and then I'm going to look for a job.” Or, you can say, “I am proficient with Microsoft 365, I am proficient with the Adobe Suite, I write well and I know about being concise and being clear, so I’m going to apply for a technical documentation job.” You just need to choose your path.
Choose subject matter, too, within an industry that interests you. I enjoy technology, but if I were to be honest with myself, would I enjoy writing about how all types of software work? Writing about Microsoft Office or something that you work with every day is very different from talking about some high-end niche piece of software all the time. Would you really want to do that? If you enjoy chemistry, would you want to write technical documentation for a company like Procter and Gamble behind the scenes? When you think of technical documentation, think of an industry where you might genuinely enjoy the aspects associated with doing technical documentation within that industry, because it'd be very easy to walk into something that for, lack of a better description, just wouldn't hold your attention. Some people would say, “It's your job, just sit down and do it.” I, on the other hand, think that type of work has an expiration date. If you don't want your work to have an expiration date, then choose an industry that you find interesting – even though I walked into my industry accidentally, so to speak. I could probably say it was synchronicity – I walked into it because it was there for me. It interests me, it holds my attention. I like hearing about how the different types of machinery work together. I like learning about how they're built. I like seeing them work. I like seeing the end product that our customers are able to share with the world. I like going to the airport and understanding how that machinery works. I think if you view it that way, technical documentation can give you a greater connection to the world around you.
You can do it. You can do anything you want – that's my advice to my younger self. Don't be so hard on yourself. I'm going to make an assumption about who becomes a technical writer: even though you have the creative side, you also don't mind analyzing quite a bit. As a matter of fact, it appeals to you. With that type of mind at work, we can be a little overly critical of what we can do. As someone who has that kind of mind, I tell myself to not be so critical. You can do much more than you think.
To those reading this, I’d also say that you belong where you are, and you belong where you choose to be. I'm going to make the assumption that the people who are reading this are making plans for themselves and are pursuing those plans. If part of what your plan includes is someplace where you're not quite sure you belong, you belong where you are. You always get to choose where you want to be, meaning you don't have to stay. If you got there, you earned it. If you want to leave, you can. Don't feel out of place, and don't feel stuck.
- Categories:
- Communications and Media
- Technical Writer
“Each other’s lives are our best textbooks.”– Gloria SteinemSign Up
