Technical Writing

While perusing Facebook one night, I saw that one of my friends had posted an interesting article by Kyle Wiens in the Harvard Business Review. In a nutshell it explores the idea that businesses produce technical manuals that are often riddled with unnecessary jargon and big words. A lot of the time technical manuals contain instructions that the man on the street cannot make sense of. When things don't make sense, more often than not, the job will be performed incorrectly. And that contradicts the idea of having a manual in the first place.

In the artical, Wiens mentions an online book that his company have developed - the Tech Writing Handbook - which is a free guide to writing technical manuals. I've scanned through the site and it offers practical advice on writing manuals that can be understood by everyone.

This site really appeals to me because I like to write and I'm involved in a technical field. A lot of my engineering friends and colleagues have terrible writing skills, down to not knowing how to spell "palletising" (spelt as "pallertising") or "carton" (spelt as "cartoon" by a lot of our artisans). This doesn't bother most engineers, because they usually communicate in graphs and sketches but it bothers me. A lot. However, that's beside the point.

The point is that we don't have many of these manuals in our plant. Recently I've started writing a few troubleshooting guides for my artisans to use so that they don't call my specialists in the middle of the night because a cable has come loose or because an air pipe to a valve is leaking or because a hand valve is closed and the tank isn't filling up. I got called out the other night to help fix a screen. At 12 o'clock. After spending an hour on the phone with my guy (he's new, so he still needs a bit of support) I got to the factory, tried a few things and after about 10 minutes we discovered that the network cable had been unplugged come loose. No one knows how.

On Monday, I'm going to write a technical guide on troubleshooting for screens. I'll use advice from the Tech Writing Handbook to make sure that my guys can understand what I'm saying. Hopefully next time, I won't need to be called out in the middle of the night for a loose cable! And once we have enough of these guides maybe, just maybe, my team will stop getting called for issues that are not ours to fix.

I think the lesson here is that, when writing technically, you need to ensure that your message can be understood by everyone. This will be my aim so that next time an issue crops up, anyone can take a look at the relevant troubleshooting guide and fix the problem, whether they're from my team, finance or a visitor with no working knowledge of our factory.