When I approach a technical writing piece, I know for sure that it’s to explain an idea, goal, or objective to another party using clear examples and facts. There’s not much room for fiction. There’s a lot of room for tightening up language though.

After writing much more subjectively lately, I was very pleased to receive this task from my employer. It was a nice change of pace.

It had been a while since my last technical writing project, so I sought out the advice of friends and colleagues who had much more experience writing for regulators and decision makers.

Here’s a quick list of some advice that I collected.

Get the lingo straight.

This one is pretty straight forward– just know what the heck you’re talking about. A common thread of advice is to write clearly and explain concepts as simply as possible.

I was told, “You should write as if you’re writing to fifth graders.”

That’s not a knock on any regulator, panel member, or decision maker out there. It’s more of an internal check to make sure that writers don’t write to writers. I’m sure you’ve read an example of this once or twice on the internet, where whatever is being talked about sounds chocked full of jargon and done-up for no particular benefit or purpose.

If you’re writing about a recommendation of a specific product or part, make sure you mention the right part.

Cooking down marketing fluff into actual product goodness.

“Here are some product sheets to refer to.”

If you hear these words, don’t just copy and paste stuff.

To me, it’s like making stock. You throw in the huge, fatty meat bone, a little bit of supporting spices and vegetables, then you cook it down. Cook that sucker down into something tasty that you can utilize.

I’m pretty sure no one wants to read regurgitated marketing fluff in a request for proposal. So, the ability to trim marketing fat from product sheets and get down to the real benefits of that product is a great recommendation.

They don't mention things just to sound cool.

“They’re going to want to see if their concerns are addressed in your proposal.”

Recommend something cool and cutting-edge. If it doesn’t suit the needs of regulators and decision makers, all the cool points are out the window.

Before I even began writing, I took this last tip to heart and pulled out as many concerns as I could from the supporting documents and the original request. I took that list and removed redundant concerns, paring the concerns down to a master list. This was a great standard to upon which to base the proposal piece.

I wouldn’t recommend reiterating concerns to the point of seeming contrived. If the solution is relevant and can help, mention how it alleviates concern. Otherwise, it’s probably a great idea not to make stuff up.

Looks like we’re into our last drafts for this thing. Best of luck! Let me know about your technical writing stories in the comments, if you have any.