ITauthor

I haven’t got round to doing a podcast for a while. I’ve been using up the remainder of my holidays recently, having lots of long weekends, which should have given me plenty of time to do one, but instead I’ve been doing … well, hang on a minute, what have I been doing?

I’ve been interviewing technical writers recently and it’s set me to wondering about the fundamental requirements for a tech writer. Here’s what I’ve come up with.

This is my list of skills, abilities and personality traits that no self-respecting tech writer should be without:

1. Communication skills

So much of the job is about communicating in one way or another – not just writing. Before you ever put metaphorical pen to metaphorical paper you’ve first got to be able to talk to people. You’ve got to be able to understand what people mean – which is not the same as understanding what they’re saying – and then you’ve got to be able to process information, digest it, store it up, remould it, present it, verify it and rework it.

2. Writing skills

You must be able to deliver a high standard of written English. This doesn’t mean you have a vocabulary to rival Anthony Burgess’s or you’ve memorised Fowler’s Modern English Usage. The tech writer's job is to take complicated things and make them easier to understand. Sometimes you’ll do this using diagrams and videos, but mainly you do this in writing. So the key skill here is being able to write in such a way that people can read what you’ve written, just once, and understand what you’re saying.

In technical writing we have little use for nuance and colour, light and shade, or even humour. It’s no good if what you’re trying to explain is open to interpretation, especially if it’s open to misinterpretation! Clarity and simplicity are everything.

Novice tech writers will often try to write in a way that sounds technical. Maybe they’re intimidated by being surrounded by developer gurus speaking a language they find difficult to understand. And they compensate by using technical words and long sentences. So  they’ll say “utilise” when they mean “use”. But the best technical writers are the ones who cut through the jargon, pare down the language and make complex procedures easy to comprehend by breaking them down into easy-to-digest chunks, framed in simple, well-formed English.

The motto of the help author is: "Make the reader feel smart." You want the reader to pull up a help page, find what they need to know,
read it quickly and understand it completely, and go away and do what they need to do, successfully. You want to send them away feeling good about themselves.

One of the keys to being able to do this is knowing your audience. Hopefully, you have a good idea of who your audience are. But most likely you’ll have several audiences. So, another of the writing skills you need is the ability to write at the appropriate level for an identified audience.

3. Attention to detail

It’s those little things that make all the difference. If you’re writing technical manuals for Boeing, or pharmaceutical guides for Pfizer, you will get the detail right because people’s lives depend on it. But even in other sectors, you can’t afford to make little mistakes. One small mistake in a help system and the person who went there looking for help will lose confidence and will probably decide that next time they have a problem there’s no point looking for assistance from the help system.

And it’s often those little things that people often only pick up sub-consciously that make them decide whether something is professional and dependable, or amateurish, and therefore unlikely to be reliable.

4. Interviewing skills

This is very much tied in with Communication Skills but I wanted to pull it out separately because I think it’s very important. By and large when you’re documenting software, you’re assigned to work on something that’s already in production. Other people know about this thing, and you need to find out all about it and quickly. So it’s very important that:

1. you can talk to people
2. that you can identify who you need to talk to
3. you can ask the right questions

You also must be able to listen. The art of the interviewer isn’t just in his clever questions, it’s in his ability to let the other person answer the question.

And you mustn’t waste people’s time. This is a law of software development: there is never enough time. Of all the subject matter experts you need to talk to, developers especially always need to get back to doing their job and you need time to write the documentation. So you can’t afford to waste your time – or theirs – by asking unnecessary questions. Avoid turning the discussion into a general chat, because next time you ask to speak to them they’ll assume it’s going to take a whole chunk out of their morning and you might find they are less willing to talk to you.

In a software company subject matter experts come in all sorts of guises. They’re often the developers, but they can also be product managers, QA engineers, support engineers, maybe (if you're lucky) they might be tame customers, or they might sometimes be your fellow technical writers. You need to be able to identify who the real subject matter expert is, and not just interview the person nearest you, or the person who talks the most.

5. The ability to grasp new information quickly

In my experience developers or subject matter experts are happy to tell you the stuff you need to know, provided you approach them in the right way and you don’t constantly bug them. However, they have no time for people who ask them the same question more than once. If they explain something to you once, they shouldn’t have to go over it again a couple of weeks down the line.

You need to be able to get to grips with how things work, assimilate new information and be able to extrapolate from what you know to make educated guesses which you can then verify with the experts. Good tech writers pretty much always like new stuff.

Part of the fun of being a tech writer is getting to work on new stuff, finding out how it works, and getting to explain it to other people. So the next must-have for a tech writer working in the software business is: 

6. An interest in (and preferably a fascination with) technology in general and software in particular

You have to be technical to a degree, although you don't need to be an expert. It helps to have an understanding of the technology you'll be working with, but it's also good not to have spent too much time in the minute detail of it, because it also really helps if you can think like someone who's never seen the system before. That way you can identify which bits of the system are likely to be difficult for non-technical people to understand. When I'm recruiting tech authors I always look for people who like to find out how things work.

7. The ability to structure information logically

Technical writers often deal with huge amounts of information. Manuals may have hundreds of pages, help systems may have thousands of topics. So you need to be able to analyse, plan and structure your documentation.

You’re going to have to think about how the information you’re supplying will be used, both by the reader (who may be reading this paragraph in isolation from anything else – or they may come to it after reading a couple of hundred pages before it) and in terms of how that information is used by you and your fellow tech writers (for instance, being shared between documents). You possibly also have to consider how the content you supply will be used by other departments within your company.

One of the key concepts in documentation over the past 10 or 15 years has been the idea of single source: writing something once, in one place, and then reusing it in different contexts, in different publications and in different media. For example, you might write a little section of text that will appear in several manuals, several help systems and on your company’s corporate Web site.

8. Patience in problem-solving/troubleshooting

Technical writers are usually working with things that are still in the process of being built. So, often, these things don't work properly, or they get changed without much, or any, warning. Sometimes technical writers get upset when this happens. They get stressed out because the fact that stuff doesn't work makes it hard for them to do their job. And sometimes they might get grumpy and narky because nothing ever seems to go smoothly.

These guys may be good technical writers, but they tend not to love their jobs.

So, if you’re not a technical writer right now but you’re reading this because you’re thinking it might be a job you’d like to have, think about how you’d react to working with immature, first-pass, partially built software. If you think it would annoy you being asked to document something and having to go through repeated attempts at installing, tweaking, uninstalling, reinstalling, reconfiguring, finding the right people to ask for help, figuring out the right questions to ask, try-try-trying again (Robert Bruce style) before you can even start to figure out what you need to document … If that's likely to annoy the hell out of you, then technical writing really isn't for you, because, in my experience, as a tech writer if something you’re working on is broken you usually can't just get someone to fix it for you. Generally you’re going to have to fix it yourself.  So you should have the ability and willingness to install and reinstall software, sometimes time and time again, without picking up the PC and throwing it at the wall when, at the fourth or fifth time of trying, the software still doesn’t work.

Basically, you need to do what you’re documenting. This means that if you’re writing instructions for how to install some software, you need to install the software several times, as you write,  and then when you think you’re finished you have to need (for your own peace of mind) to go through it all again (with your user’s hat on) and install it again, hopefully one last time,  doing only what it says in your instructions, and check that it’s easy to follow – and it works.

9. Graphic design skills

The first documentation manager I ever worked for had this habit of drawing diagrams. Whenever I went to ask him to explain something, he would, as likely as not, reach for pen and paper and start drawing me a diagram. At first this seemed really odd behaviour to me. Documentation was all about words, wasn’t it? Someone who had been a technical writer for years should surely be well able to explain things in words.

But after a while I realised how effective it was as a way of explaining things. And, more than that, I started to suspect my brain worked better in pictures than in words because I found that the habit was rubbing off on me. I realised that whenever I was struggling to get to grips with a concept – or just to piece things together in my head and make connections, and make sense of something – invariably I would feel the urge to sketch the thing out as a diagram.

Technical communicators are increasingly required to produce diagrams, annotated screenshots, videos with accompanying narration or even cartoons and animation. And if you don’t believe me about the cartoons, go and take a look at the work of commoncraft.com. Now, you definitely don’t need to be a designer to be a technical communicator. But I certainly think that you’ll be a better technical communicator if you have some sense of design and a facility with images and diagrams.

10. The ability to review other writers’ work

Technical writers often have to work alone. There are a lot of little software companies out there for whom hiring a full-time tech author is one of the first signs that they are taking the business seriously and thinking about user experience and they’re more than just a band of coders and a sales guy. However, tech writers perform better when two or more of them are working alongside each other, or at least: they’re working in the same organisation. Personally I hate sending my work out into the big wide world without it being checked by a fellow technical writer.

Product managers and project managers,  who review your work, will tell you if you’ve targeted your documentation incorrectly, or if you’re making false assumptions about the end users, and developers will pick up on details if you’re claiming the software does something it doesn’t. But there’s a level of editorial review that a fellow tech writer can give you, that no one else can. Because sometimes you just can’t see an obvious mistake for looking at it, and that’s where a peer review process can save you from looking like an idiot for letting something daft slip through to the customer.

So those are my ten must-haves for tech writers. Do you agree? What would you add to the list? Drop me a comment.

Note: This is an adapted extract from a talk on technical writing that I recorded earlier this month for The Writing Show podcast.

Podcast: Play in new window | Download

The voices in this podcast belong to: Graham Campbell and Alistair Christie.

This time round, Graham and I discuss the best way of interviewing technical writers.

Skills/attributes we mention as being things we’d look for in a candidate for a technical writer position include:
1. Evidence of solid English language skills (particularly competency in written communication)
2. A genuine enthusiasm for technology (and preferably a fascination in software)
3. Signs that the candidate would fit into the team, provide effective peer review and would be able to interact with the developers
4. The ability to review the work of colleagues effectively – and to have your work reviewed

Podcast recommendations:
The Best of MySpace – http://www.bestofmyspace.uk.com/
Mostly Tunes – http://www.mostlytunes.com/

Note: The song I play at the end of this show is one I heard on a recent Mostly Tunes show:
Be OK by Ingrid Michaelson – played here by grace of the Podsafe Music Network.

Listen to more of Ingrid’s songs.

Application recommendations:
Adobe Buzzword – http://www.acrobat.com
Google Calendar – http://www.google.co.uk/intl/en/options/ 

Tips:
Press Q on Google Calendar for a quick, natural language way of adding an appointment.

What I’m listening to:
Graham is (still) listening to the music from the Transformers movie.
 

Oops! – a note about the sound quality
Despite a quarter century of podcasts (if you see what I mean) I still managed to make a couple of schoolboy errors with the recording of this podcast:
1. I didn’t check the levels properly, so Graham is too quite and my mic is maxing out
2. I accidentally recorded in mono. Usually I record with each mic into one side of a stereo recording so that I could remix the levels.
So apologies if I sound worse than usual in this recording and you’re struggling to hear Graham.   

The music I play at the beginning and end of the show is by Amplifico. You can hear more of their music at Podshow.

I’ve just started the challenging task of hiring a new technical writer.

As a result I’ve been reviewing our interview process, researching what other bloggers have had to say on the subject and generally thinking about the challenge of getting the right person.

As chance would have it, Writer River dropped an email in my inbox on Monday with a relevant article: 
The Interview Question You Should Always Ask

This is one of those blog posts where the comments are as interesting as the actual article. The question referred to in the title (you might want to stop reading here and go and read the article first … no?, okay let’s continue) is “What do you do in your spare time?” I’ve never asked this question but I thought it was a good one. If an applicant says he/she writes a blog, contributes to open source documentation projects and creates instructional videos and posts them on YouTube, then they probably immediately elevate themselves into the contender bracket.

However, some of the comments warned of potential HR headaches, or nightmares, arising from asking this question.

I would never ask this question.
1) It might take you somewhere where you do not want to go:

What do you do in your spare time? - I sing in the choir at my church.
or
I take care of a disabled husband.
or
I meet with the therapist that is helping me to battle my addiction.

Another commenter added the following grim warning:

Should this candidate reveal something in their answer that could be viewed through the lens of being "protected", and you elect not to hire the candidate, you may find yourself spending significant time with your legal counsel.

This also made me think that maybe I should consider getting our HR person involved in the interview. I’ve always preferred not to have the HR person sitting in through the whole interview, but maybe I should, I’m not sure. I tend to think that HR problems generated from interviews (other than for internal candidates, which is a more complicated situation) has got to be more something that happens in the more litigious US, not here in the UK. But maybe this is an accident waiting to happen and we should be less easy-going/conversational in our approach to interviews, which would be a shame.

Some good resources on interviewing are:

• The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky
• Thoughts on Interviewing by Gordon McLean
• Interviewing by Gordon McLean
• 10 Alternate Tests for Evaluating Technical Writing Job Candidates — A List for Hiring Managers by Tom Johnson 
  This is another one where you really need to read through the comments.
  

Graham pointed out this scandalous slight on our profession:

Whenever I'm asked I usually say: "I work for a software company".

This is pretty much as good as conversation stopper as the above but it has the benefit of not building you up for a fall. If I say: "I'm a technical writer" or worse still: "I'm a technical author", the other person doesn't have a clue what I'm on about but they do catch the word "writer" or "author" which sounds quite interesting and they hopefully ask me to elaborate. This just leads to disappointment and antagonism, as if my first reply had been a deliberate trick to fool them into thinking their line of questioning could have led to an interesting conversation.

I always thought "wheel tapper" sounded an intriguing job.