This article is the last of three in a series. It’s based on my presentation at the STC Career Day and describes the six basic principles to follow for both job interviewing and informational interviewing.
5. Get another job.
No, I don’t mean quit your job. Instead, recognize that there are aspects of many other professions within ours. You need to take on these other jobs during interviews, especially informational interviews.
Elementary, My Dear Watson
Firstly, you need to be a detective, a true Sherlock Holmes. Before a job interview, research the company and study their financial information. During the interview, look for clues that this may or may not be the right job. Arrive at the interview early, read any company literature in the lobby and observe any activity. During the interview, take note of how the interviewers behave, and listen carefully to what they say. How old is the documentation software they are using? Is documentation considered an integral part of the product development process, or is it just an afterthought? Do the questioners seemly overly anxious to hire you? Gather these clues to make an informed choice if you’re presented with an offer.
For informational interviews, recognize that the product you are documenting is a mystery that you must solve. All sorts of questions will arise as you create your documents, and the answers are not always clear. For example, a database I was documenting contained a field that no-one seemed to know about. After considerable investigating, I found out it was only present to ensure backwards compatibility, and documented this accordingly. On another project, I couldn’t figure out why I was unable to delete a user record. It turned out administrative rights were required. Again, this had had never been clearly documented. Follow the clues and the truth will be revealed.
Investigating the Truth
Similarly, you need to be a journalist, or better still, an investigative reporter. A good reporter always questions the status quo, and is healthily skeptical. That is how they are able to reveal the hidden truths that those in power wish to hide. You need to practice doubting, which is a skill like any other. A good way to develop it is study viewpoints that are diametrically opposed to your own on such controversial topics as politics, abortion, the Middle East, and the wars on terror and drugs. Reasonable people can hold opposing view on these topics. By studying alternate views, you are training your mind to question things.
Being an investigative reporter applies mostly to informational interviewing, including interviews about the documentation in general. For example, my co-worker and I questioned whether our ReadMe files really needed to be in text (.TXT) files, which is a very limited and cumbersome format. We investigated and discovered we could change them to the much more flexible RTF and PDF formats, with all of their inherit advantages. Had we not questioned this, we’d still be stuck with the old formats.
Trust, but Verify
During your investigations, recognize that ultimately you can only know what you can verify. For everything else, you have to trust others, so consider the source and their interests.
For example, there was an unusual documentation issue at the 2008 Olympics in Beijing. Some of the female gymnasts appeared to be below the age limit. As “proof,” passport documents of the athletes were presented showing their birthdates. Who issued the passports? The Chinese government. Who benefited from this? The Chinese government. How do you say “conflict of interest” in Mandarin?
In software, a developer may be reluctant to tell you something is not working, if they are going to have to be the one to fix it. A product manager may not like being told that the instructions on a screen are unclear, if the product manager wrote them. A good technical writer rises above all this, and does what’s best for the end user.
Dealing with conflicts such as this means you also have to be an ambassador and diplomat. As an ambassador, your job is to bring two groups of people together: those who create the applications and those who use them. In doing so, you help solve misunderstandings and miscommunications between these two groups, just as a real ambassador does between two countries. You may even prevent a thermo-nuclear war.
Interpreting the Results
You also need to be an interpreter, which is quite different from a translator. An interpreter extracts the real, intended meaning from something, and this can often involve a complete rewording. For example, there may a screen that says, “Click here to enter application.” Does this mean click to type in the name of the application or click to actually open the application? It’s not clear from the wording. As an interpreter, you would reword this text to remove all ambiguity. Interpretation is also an important skill to have when working with error messages, which are often unclear and do not state a solution.
Finally, you need to be a psychologist. You need to understand the mindset of both the users you are writing for and the people you are interviewing. For example, developers are, for lack of a better word, autistic. (I have a son with autism, so I know a bit about it.) Autism is a condition of the mind in which a person is able to have incredible focus on specific details but is unable to connect with others or see “the big picture.”
To illustrate this, imagine a child named Alice holding a ball. She places the ball inside the first of two boxes in a room, closes the lid, then leaves the room. A second child enters the room, moves the ball to the second box, closes the lid and then leaves. Alice returns and is looking for her ball. The question is: where will she look for it? The obvious answer is the first box, the one that she left it in before it was moved.
However, when you describe this scenario to an autistic child, they will answer that Alice will look for the ball in the second box. When you ask them why, they will respond “because that’s where it is.” Incredibly, the autistic child does not realize that what they know is different from what others know. That is why autism is called a form of mind blindness, because it causes a person to be unable to comprehend another’s point of view.
Calling All Developers
Developers often exhibit these tendencies. For example, a developer may be asked to create a work phone number field for a customer information screen. They will neglect to leave room to enter a phone number extension, even though the developer’s phone has a phone number extension. They are not stupid – they simply cannot make the connection.
Therefore, your job, as a psychologist, is not to be mind-blind, but mindful. Stop and see the big picture when gathering information. Is there anything missing? Is there something there that shouldn’t be? Is this something an end user can actually use and understand? By being mindful of your SMEs and end users, you will create documents that are much more usable, accurate and complete.
6. Go to 11.
1984 was an interesting year. It was the year George Orwell’s dark novel was named after. On a lighter note, it was also the year that the film This Is Spinal Tap was released.
The film is an mockumentary of a fictitious, aging British heavy-metal band named Spinal Tap. The band members are hilariously portrayed as dimwits. In a classic scene, the lead guitarist, Nigel, shows off an unusual amplifier to the interviewer, Marty DiBergi:
Nigel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and…
Marty: Oh, I see. And most amps go up to ten?
Marty: Does that mean it’s louder? Is it any louder?
Nigel: Well, it’s one louder, isn’t it? It’s not ten. You see, most blokes, you know, will be playing at ten. You’re on ten here, all the way up, all the way up, all the way up, you’re on ten on your guitar. Where can you go from there? Where?
Marty: I don’t know.
Nigel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty: Put it up to eleven.
Nigel: Eleven. Exactly. One louder.
Marty: Why don’t you just make ten louder and make ten be the top number and make that a little louder?
Nigel: [long, awkward pause] These go to eleven.
The expression “going to eleven” has come to mean giving it that little bit extra, or as we say in the business world, giving it 110%. Often a little difference makes all the difference. It can mean the difference between winning a gold medal and winning nothing.
In a job interview, go beyond the minimum by following all of the principles described in this series. Dress sharp. Practice your responses and your questions. Show passion for the job and your work. Describe how technical writing is not just your job – it’s your religion. Talk about how you are involved in outside activities and groups that involve technical writing, such as the STC or Editors’ Association of Canada. If you’ve done volunteer writing for charitable organizations, describe it. Most of all, show how you’ve gone the extra mile in creating and improving your documentation.
For example, our FrameMaker templates used to be an odd size: approximately 5” x 9”. This is because we used to send our documents to a printing house, and that was the size of the manuals they produced. Later, we stopped having them printed this way, and simply created PDFs, but they were still at this odd size. Customers were wasting paper because they were printing the files on letter-size paper. I decided to change the templates to letter size, or 8 ½ x 11. That’s right – my templates do indeed go to eleven.
These are the six basic principles of effective job and informational interviewing. If you study them, and practice them, then everyone will say of you, “there goes a great tech writer, because that tech writer goes to eleven.”