There’s no such job! – Or, How I ended up with a career in Technical Communications

I can’t spell. I really can’t. I’m terrible at it, always have been. Yet I read voraciously (it just took me three attempts to spell that one right), and I love to write. I’ve wanted to be a writer since I was seven years old, but my poor spelling was always something of a handicap, because I’m so old that when I was at school there was no such thing as spell checkers. Sure, there were dictionaries but the problem with a dictionary is that you have to at least have some basic idea of how a word is spelt to be able to get find it in the first place.
I also liked machines, cars, motorcycles, planes. I enjoyed taking them apart and finding out how they worked (OK I didn’t take planes apart, but I studied aerodynamics so I knew how they stayed up there). Early in my teens, sitting in the careers advisor’s office at school with the oil from the latest engine tear-down fresh under my finger nails, I had a discussion that went something like this:
Careers Advisor: “So what would be your ideal profession?”
Me: “Something that combined Engineering and Writing.”
Careers Advisor: “That’s not a career. There’s no such job.”

He then looked at the file on his desk, and then at my oily hands. “Your report says you have a good grasp of most subjects and can learn quickly, but you are a terrible speller.” Another look at the hands, “But clearly you like machines. Go be an engineer.”

And that was his final word, and that’s the path the school put me on.
Fast forward several years and I have a degree in Marine Engineering in my pocket and I’m working as a Junior Engineer in the British merchant marine on container ships. It wasn’t the life for me, except for one aspect.

nacontrolroom-470x352
During long boring watch rota shifts in the mainly automated engine room I would while away the time reading the tech manuals. You know the things that I’d been told didn’t exist. And my reaction was (1) That idiot careers advisor had been wrong as someone must produce these, and (2) I could do them so much better.
Despite being paid to travel the world (well the Mediterranean and North Atlantic) while staring at a deck full of containers, after a year I decided to head back to land and to University to pursue a second degree in Industrial Technology. As part of the degree course we had to spend two separate six-month periods working in industry. My first industrial-placement was at a computer company, and the second?

At some point I’d been chatting to my girlfriend (now my wife) about potential placements and she suggested I talk to her brother-in-laws, both of whom worked at British Aerospace. Over a pint in the pub later that evening someone casually mentioned that there was a department called Technical Publications at the aerospace facility nearby, and he happened to know the guy who ran it. One introduction later and the following summer I found myself at a desk writing my first piece of technical documentation – a Component Maintenance Manual for an upgrade to the engine intakes on Concorde!

CONCORDE
As for that job that didn’t exist, by my reckoning I am now in my 32nd year of working in the profession in one capacity or other.

Advertisements

10 Commandments of Storytelling Applied to Technical Content.

I originally wrote this blog post back in 2009, but as it’s come up a few times in various conference conversations during the past few weeks – I thought it might be worth an update and repost.

Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie. So I decided to see if I could apply screenwriting guru, Robert McKee’s 10 Commandments of Storytelling to Technical Documentation.

1. Thou shalt not take the crisis or climax out of the protagonists hands. So who is the “protagonist” of your documentation? It could be your product, but the most likely candidate is that your “protagonist” is the person using your documentation. Your documentation should be written in such a way that your protagonist can use the information so that they feel that they have solved the crisis (or put more prosaically, overcome the problem they have) themselves based on the knowledge you have presented. Another story telling trick, often cited by screen-writer Todd Alcot, that is worth remembering – ask yourself “What does the protagonist want?”

2. Thou shalt not make life easy for the protagonist. This seems contrary to the very purpose of Technical Documentation. Isn’t it our job to make life easier? Yes it is. But in certain types of documentation, such as training materials, you may want to include challenges, and then guide the reader through them. This way you can build a sense of accomplishment as the reader progresses through the material.

3. Thou shalt not use false mystery or surprise. Don’t hold back anything that is integral to full understanding of the product or service you are writing about. But also make sure to reveal information in a logical manner that is considerate of the reader’s needs. Make sure they have the information they need to know, at the time they need it.

4. Thou shalt respect thine audience. The first rule of any sort of writing is “know your audience.” Know them, and respect their level of knowledge. If you are writing something for experts, then you may not need to include the basic information that you might use for a more general consumer market. The use of conditional text is a great way to handle different topics and statements designed for different audiences within a common documentation set.

5. Thou shalt have a god-like knowledge of your universe. A joke I often use is “What’s the definition of an ‘expert’?” – The answer is “it’s a person who has read two more pages in the manual than you have.” So what does that make the person who wrote the manual in the first place? We may not know everything about what we are documenting, but we should give the reader the confidence that we do.

6. Thou shall use complexity rather than complication. Most of what we write about in Tech Doc, is by its very nature, complex. We should take that complexity and break it down into logical steps and topics that can guide the reader. We should never use complexity as an excuse for making the documentation complicated.

7. Thou shalt take your character to the end of the line. We learn in grade school that every story should have a beginning, a middle, and an end. The same applies to documentation too. The narrative should guide the reader through the process, or information, in such a way that it flows logically, and that at the end they know more, or have achieved more, than when they started.

8. Thou shalt not write on the nose dialog. Wait, I hear you asking, there’s no dialog in Tech Doc – so how does this apply? Well the definition of “on the nose dialog” relates to the scene when a character says aloud, exactly what he is thinking or describes what is happening around him. So how does this apply to Tech Doc? Do you have sections of doc that are restating the obvious? Try reading your docs out aloud? Is it boring and repetitious? Try altering sentence lengths. Don’t think anyone ever listens to docs as if it was dialog? As a teenager I spent hours working under cars while a buddy nearby would read the steps from the manual for me to follow. How about a visually impaired customer using a reading device?

9. Thou shalt dramatize thine exposition. Put simply “show don’t tell.” In prose this means have your characters reacting to an event, not talking about it. But isn’t our job to tell people how to do something? Yes it is, but the key word is “how.” Replace long descriptive texts on operational theory with a few active steps the user can take themselves, that demonstrates the product, and they will gain a quicker understanding. People learn more by doing than they do by being told.

10. Thou shalt rewrite. Do I need to explain this one? Plan your schedule with time to write, have someone else review, and rewrite. Best of all scenarios is to write, have someone actually use your draft to accomplish the tasks you have written about, get feedback. Better yet, watch them try to use your docs. Then go back and rewrite based on your observations. They say that any good piece of art is never finished. Writing is art, even Tech Writing. You can always improve on what you’ve done.

Know Your Muppets.

I may have been the only one in the room who noticed, or even cared, but it annoyed me.

During a recent presentation by a top industry analyst they referenced an on-line marketing campaign that had featured The Muppets. On one PowerPoint slide there was a picture of Kermit The Frog.

The analyst proudly said something along the lines of “As you can see this campaign was aimed at children because it uses the characters from Sesame Street.”

My geek-alert radar triggered at the mistake. Kermit is of course not a Sesame Street character, but  the leader of The Muppets. It was an innocent enough mistake, even an understandable one. But it was compounded by the fact that I knew a little about the campaign being referenced, which was in fact not aimed at children, but their parents.

The consultant immediately dropped a couple of notches on my internal credibility monitor.

In fact during the day the same consultant made a few pop-culture references, and I could tell that they didn’t really understand the context of what they were saying.

This got me thinking about my own presentations. I’m a self confessed geek, I even have a T-shirt declaring the fact, so I have a tendency to pepper my conversations with pop-culture references. The same applies to a lot of presentations I do, more so in public conferences than during internal meetings. But, I always make sure those references are related to things I know about; I’d never make an on-line gaming or baseball reference as I have no interest, or reference, for either.

If you do make some sort of external reference when presenting to an audience, then make sure it’s factually correct and applies in context, because if you don’t there is bound to be someone in the audience who will spot your error. And that error will undermine everything else you say.

The same applies to the content you produce and deliver to your audience online. The best content is that which engages the audience and provides value. To deliver that sort of value we often produce content that puts our products or services in the context of the customer’s story and experience. We talk about, and reference, their industry, their process, their culture. If we get any part of that wrong, the customer will notice and it will undermine everything else we claim about our products.

Before you put out any sort of content that makes external references make sure you know your Muppets!

Sheldon Cooper and Brand Deflection

A couple of days ago we were having new carpet laid throughout the house, and at one point during the day I was walking out to my car for a coffee run when the head of the carpet crew looked up and asked me if I liked the TV show “The Big Bang Theory.

The question threw me for a second, not because I don’t like the show – I do. It’s a must watch for my family – but as to why he’d asked in the first place. I must have looked puzzled, because by way of explanation he pointed in my direction and said “Your shirt.”

At the office I may be all dressed up, but the days I’m working from home you are more likely to find me in jeans, sneakers and a superhero logo t-shirt. The thing is I don’t own any Big Bang Theory shirts. Not a single “Bazinga !” adorns my closet space.

I looked down and realized I was wearing a Green Lantern t-shirt. Just like this one.

sheldonshirtThe one that Sheldon Cooper often wears on The Big Bang Theory. – Mystery solved.

On my drive to grab my drink I started to think about what had just happened. In my Content Marketing role at Caterpillar a major consideration is how we build and develop messaging and content that supports the brand message and the brand story. Ideally every interaction with the brand (and that includes the logo – perhaps the most frequent brand encounter) should reinforce the brand’s promise.

Yet my carpet guy had seen the Green Lantern logo, a brand owned by DC Comics and by association, its parent company, Warner Bros., but associated it with a completely different property and message. In this case one owned by CBS.

The more I thought about DC Comics brand placement on The Big Bang Theory the more I realized that as much as it’s cool for me as a comics geek to play spot the reference, I’m not sure Warner Bros. is getting the business value it wants from that relationship.

comic_book_storeThe comic book store featured in the show seems to stock only DC Comics related titles and merchandise (Click on picture above to get a good look at the stock); but whenever comics, or comics characters are mentioned on the show in dialog it is usually a conversation about Marvel characters. Characters and brands owned by the directly competitive comics publisher, who are now owned by Disney.

In a recent episode the girls on the show ventured into the comic book store to see what it was that was so important to their boy-friends/husband; and then spent half the show discussing the physics of Thor’s hammer. Thor being yet another Marvel character.

So what are DC Comics and Warner Bros paying for with this brand and product placement? Is it brand awareness? To me it seems more like brand deflection.

How is your brand message being used and communicated. What channels are you using to spread your brand’s story.?

Is your value message getting through, or is it being deflected?

 

 

 

What Do Stories Look Like?

Book design guru Chip Kidd discusses how designing books is all about using visual design to convey the story contained within. He also makes some great observations about eBooks.

“Much is to be gained by eBooks: ease, convenience, portability. But something is definitely lost: tradition, a sensual experience, the comfort of thingy-ness — a little bit of humanity.” (Chip Kidd)