My fiction-writing buddy Ciara Knight has a high-school-age son who’s participating in the FIRST Robotics competition, where groups of students get together to create robots that compete on some sort of timed activity. This year, the activity is space-themed, which pleased me. It was also nice to see my friend’s son happily succeeding at what he’s doing. I agreed to help his team with outreach or mentoring, which included the teens sending me questions about my career. They’re good questions about the tech writing profession, so I thought I’d share.
Bart Leahy Questions
- What’s the hardest part of being a technical writer and working with a multitude of organizations?
The hardest part about being a technical writer is usually on the people side of things—keeping customers happy, making sure I’m not doing anything to annoy them, or negotiating things like pay. Given enough time, learning the content is relatively painless.
When it comes to working with multiple organizations, the biggest challenges usually occur when I have multiple jobs/tasks hitting my inbox all at the same time and all having the same or similar deadlines. Sometimes I have to juggle the order I do things to make sure everyone’s work gets done when they need it.
- What skills and characteristics are required to become a technical writer?
At a basic level, you need to be able to write, edit, and organize documents well. In addition, you need to be able to research/read a lot of material, extract the most important points, and explain that content in a way that’s understandable and useful to your reader. That’s the writing part.
To do the writing, you need to be familiar and interact with a lot of technology, everything from Microsoft Word, PowerPoint, and Excel to Adobe Acrobat, the internet, email, and messaging software.
On the people side—what they call “soft skills”—you need to learn how to interact and behave with a variety of personalities diplomatically in multiple situations, including meetings, interviews, and negotiations.
If you’re a freelance (self-employed) technical writer, you also need to learn the basicsof running your own business, including the ability to meet deadlines, bill your clients correctly, pay your taxes, and pay your own bills.
- In our engineering notebook we use documentation to communicate to judges what we have designed and the process that we used to create this design. Because of the various backgrounds that the judges have come from, some have trouble understanding what we designed and how we got to that point in our design. What tips would you give to our team or to anyone who was trying to better communicate their design to other people who may not fully understand the topic?
Great question! One thing I encounter with technical people is that they assume the reader understands as much about their topic as they do. That is not always the case. Don’t be afraid to explain something in simple terms, such as “This robot was designed to lift five tennis balls at a time using a large scoop.”
Another thing to watch for is clearly stating the advantages of your invention. If you just state the facts or statistics about a machine, that doesn’t mean the reader is going to know why that’s important or an advantage/disadvantage.
Lastly, don’t get hung up on jargon. You might be using part numbers or technical terms for something that has a more common term to people not doing engineering. It’s not a sin to say “rocket” rather than “launch vehicle” if your audience is not primarily composed of engineers.
- What is the hardest part about having to communicate with large organizations such as NASA and the U.S. Department of Defense?
The trickiest part is often figuring out who knows what. Some things you can’t look up online or in a book or report. You might need to know, for example, why a design change was made. A presentation might state that the change was made, but not why. In that case, you end up having to send some emails or make some phone calls to find out the whole story. You have to start with the people you DO know and expand your network from there.
Another challenge is protocol. This is more of a concern in the military, though, than a civilian agency like NASA. If you have a question for a specific organization, you don’t need to (and probably shouldn’t) go all the way to the top and ask for the Commanding General. They have more important things to do and might not have all the details anyway. You have to follow the chain of command and work your way through the CG’s subordinates first. Going over someone’s head can be a no-no. Again, you do as much research as you can on your own then figure out whom to ask when you need a specific question answered at a particular level of detail.
- As a technical writer, what would you say are the most effective ways to communicate designs and ideas? Is it through pictures, sketches, paragraphs of writing, or items such as flow charts and diagrams?
Honestly, it dependson what you’re trying to share. If you’re trying to tell a story, such as the background of a program, straight narrative would do the job.
If you’re trying to explain a process, writing things out in sentence or numbered/bulleted form might be best, with a flowchart included if there are multiple “if-then” steps.
For a numerical trend over time, a line chart is your best bet.
If you’re comparing the same measurement across multiple items (say, program cost), a bar chart would work.
If you want to depict percentages, a combination of words, table, and pie chart might work best (some people like to see things depicted different ways).
If you want to compare multiple traits for more than one entity, a table would be best. An example here might be if you were comparing the cost, power source, tools, and speed of multiple robots at the same time.
- When you complete technical writing, does a client give you criteria for what should be included? Or do you decide the outline for your writing and what needs to be focused on?
Whenever I get a new assignment from a customer, I try to get a few things answered up front:
- Who is my audience?
- Why are they reading/receiving this document/product?
- How do I want them to act/respond after reading it?
That covers the content. Then I start asking other questions:
- What format should the deliverable/product be in? Email? Word doc? Website?
- How long should it be?
- How detailed does it need to be?
- What do you (the customer) consider the most important points for the audience to get out of the product?
- What is your process for communicating with engineers and other individuals to obtain the information you need for your writing?
I try to read/research as much as I can about a topic before I ask an engineer or other subject matter expert (often called a SME, pronounced “Smee”) questions. That way, I already know something about the topic and I can ask them for more detailed information. This saves them time because they don’t need to explain the basics. I can explain what I know and ask them something more difficult that isn’t in the literature I’ve read.
As for how I reach them, it depends on what I’m doing or where I’m working. A lot of my work is done from home, so I’ll email or call a SME on the phone. If I’m on site working at a customer location, I can sometimes just walk down the hall and visit their cubicle/office. Other times, especially if they’re a manager and I have more than one question, I’ll have to set up a meeting via Outlook or the manager’s executive assistant.
- How do inform companies of your skills so that they will ask you to do technical writing for them?
Also a good question. Quite frankly, when I was starting out on my own after 20 years of working in large companies, I was having a difficult time marketing myself. In the end, I found it easier to start talking to my friends and former coworkers who still worked for large companies and asking if they needed help with technical writing. That saved me a great deal of time because they already knew who I was and what I could do.
When I need to write a resume for myself now, I highlight the experience and skills I have that relate to a particular job. For example, I’ve done a lot of training writing over the years. If I were marketing my services to a company in need of an instructional design writer, I would highlight my experience there. If I were applying for an aerospace policy job, I would be certain to highlight who my customers were and what sorts of policy-related documents I had written for them. Again, to be effective, you highlight the information that’s most useful to your audience.
- How do you draw the line between too much information and too little information in your writing?
A lot of it depends on the page or word count limitations, which helps me a lot. If I’ve been given ten pages to write about a launch vehicle, and each of the major subsystems requires equal treatment, I can divide the word/page count by the number of subsystems and work backwards from there. If I’ve been given half a page to describe or explain the rocket, I’m going to keep things much briefer. If there is no page or word count requirement, I will discuss the document and its level of detail with the customer so I’m not wasting their time or mine.
- Is there any way that a high school student could practice a specialized skill, such as technical writing, in his free time?
This isn’t a topic I know a great deal about because I didn’t get into technical writing until well after my first college degree. If you’re looking to get some practice, there are scholarshipsavailable.
If you’re looking to get more regular practice, you might talk to any science or engineering teachers in your school to see if they have any in-class processes, rules, or procedures that they need updating. Another potential opportunity might be any club in your school that needs processes written out. That could include the physics club, theater department, or even the various sports teams. You’d be surprised. Teachers appreciate students who take initiative and also take a task off their plate that they didn’t want to do in the first place (not everyone is good at or enjoys writing). This sort of work does a few things for you: it gives you practice writing for specific audiences, gives you experience meeting customer requirements, and perhaps most importantly, gives you experience interacting with potential customers. If you do a good job, you might find other groups or teachers reaching out to you and asking for help. That’s more or less how I built my network over the years. “Word of mouth” recommendations are more powerful than any marketing you can name.
- What first inspired you to go into technical writing? Did ever consider doing anything else? If so, why did you choose technical writing over your other options?
Ha! Originally, I wanted to be a science fiction writer/novelist. When I first went to college, I got an English Literature degree with a minor in history and took almost enough science classes to qualify for a minor there, too. What I discovered along the way was that I wasn’t particularly good at fiction writing—at least not good enough to get people to buy my stories.
Eventually I moved to Florida and got a job writing at Walt Disney World (answering complaint letters). What got me into technical writing was a space exploration and settlement conference that was being held in Orlando that year (the International Space Development Conference). I got excited enough to go back to school and get into the space business as an engineer rather than just write stories about it. I started taking engineering classes and was really struggling with the math and the computer programming. Someone in the guidance office at the local community college suggested I look into getting a master’s degree in technical writing—it would take less time, and there wasn’t any math required! JThis was a fantastic recommendation, as I was able to combine my interests (space exploration, science fiction) with my existing skill (writing).
As for what else I would have done with myself, I suppose I might have stayed in the hospitality/travel industry…probably still writing, just in a different context.