When I started my job as a technical writer, I was scared. Technical writing was like no other writing that I’d done before.

I’d taken multiple fiction, nonfiction, and poetry classes in college, but only one technical writing class. My other writing classes focused on artful prose, hooking the audience with a thrilling first sentence, or drawing an emotion from the reader. Not so with technical writing! The goal of technical writing is to get a point across quickly and efficiently.

I disliked my technical writing class, finding it to be boring and artless. I did all my coursework well enough to earn an A, but didn’t give any of myself to learning the craft of technical writing, and made no attempt to further educate myself within the genre.

Imagine my mixed feelings of joy and distress, then, when I got a job as a technical writer! My job was to write Standard Operating Procedures, or SOPs, for a group of mechanical and solder assemblers. Happy as I was to have a job where I actually got to write, I was scared. I was ill-prepared, and I knew it. On top of knowing that I was completely out of my genre, I was also scared because I felt as though I didn’t know enough about the products I was writing about to write about them well.

But I survived my time as a technical writer, and I learned some tips along the way. I’d like to share them with you.

  • Know your point, and make it. The point of the SOPs I was writing was to teach the assemblers how to make the products, and make them the same every time. SOPs were used to train new employees, to assist unsure employees, and to ensure consistency in the products. Since my goal was not to evoke emotion or even to interest the employees, I quickly learned to give the barest of bare-bones instructions that I could. Assemblers don’t have all day to read long-winded paragraphs. Know your point. Make your point. Move on.
  • Use the simplest language possible. My assemblers wanted to be able to quickly read an instruction and carry it out, without having to stumble over words or look up new vocabulary. You’re not there to impress them with your arsenal of complicated words, so use the quickest, simplest, and most efficient language possible.
  • Break up walls-o-text with bullet points. When an assembler is elbow-deep in flux and solder, the most frustrating thing you can do to them is make them scan through a half-page long paragraph looking for the last set of instructions that they read. Help them out by breaking the text up into quick, bite-sized chunks.
  • For instructional writing like SOPs, use pictures. Pictures not only help break up the text into more manageable pieces, but they are also invaluable for showing exactly what you mean with your instructions.
  • Don’t worry if you are not an expert on the topic you are writing about. That’s not your job. It’s the job of the technicians or engineers. They tell you what needs to be written, and you translate their words from the technobabble they’re used to into plain language for the assemblers. Does it help to know all the ins and outs of the products? Of course. Is it a dealbreaker if you don’t? No. Your job isn’t to be the expert. It’s to take the experts’ words and translate them for everyone else.
  • Test it if you can. Whenever I wrote an SOP, if it was possible, I’d ask an assembler who had never made the product I was writing about before to make it, using only my SOP as instructions. They weren’t allowed to ask for help or look at an example of the finished product. It was my way of testing whether or not I had given the instructions clearly and efficiently. If the assembler got stuck at any time, they could point out exactly where the breakdown of communication had happened. If they were able to duplicate the finished product by my SOP alone, then I had succeeded. I always made sure my guinea pig assembler knew I was testing myself and my SOP, not them. Whenever possible, I left the room so they felt more free to write honest feedback on the SOP draft. Testing my SOPs was a step I didn’t think of until several months into the job, but it was one of the most useful steps to me because it let me know exactly what was working and what was not, and every time I saw an SOP work, it built my confidence up for the next time.

These tips may not be useful for your particular brand of technical writing, especially if your writing is not instructional. Every writer is different, and every writer must figure out for themselves what works for them. Do you have any tips for new technical writers? Let me know in the comments!