The following article contains much wisdom:
All I really need to know I learned in kindergarten.

I would this reword to:
All I really need to know about technical communication I learned from the letter C.

C is the first letter of all the important concepts, practices and other things that you’ll ever need to know about our profession.

We must, of course, excel at Communication, and not just the written kind. We must be excellent visual communicators, with a firm eye for the design and layout of images, diagrams, and text. This includes a good knowledge of typography, graphics, and effective diagramming – for example, formatting screen shots so that each part is clearly identified. We must be effective and Competent informational Craftspeople, taking great Care in every word we write.

We must strive for Clarity in our work. This means being Childlike, with an endless Capacity to ask foolish questions, and thereby obtain the answers our readers Crave.

Clarity includes being Comprehensible. If our readers (or Clients) cannot understand what we’ve written, why did we write it? We must therefore be Customer-focused. Ideally, we should observe our readers attempting to use our documents. At a minimum, we should provide a simple way for them to directly send us their Comments and Criticisms. This involves having Compassion for our readers. They are often stressed when they reach out to our guides. Our job, therefore, is to Care about our readers and create documents that gently guide them onto the right path.

The Content we develop must be Complete and Comprehensive. A document is a puzzle, but one in which you may not know the number of pieces. Knowing that you don’t know what you don’t know is the first step in knowing what you need to know, you know?

At the same time, our documents must be Concise. We should use as many words as required, but no more. We can achieve this balance through the Chunking of information. For example, we can create a simple overview page that contains links to various topics, rather than listing the entire contents of all these topics on one page.

Organizing and chunking the information involves Curating, the active management of all our informational objects. A museum curator decides what pieces should be displayed, where and how; we must do the same.

As we curate our information sets, we must be Cost-Conscious. This involves effective time and project management as we juggle all our guides. It also involves Content reuse at the topic, paragraph, sentence and even word level. Common copyright information, procedures and tasks, and templates are just some of the things that should only exist in one place. This will lead to greater Consistency in all our documents.

Consistency is extremely important. You should not call the same thing by different names, nor describing different things using the same name.

Our documents must be Credible (or believable). If there is an error in a document, its credibility is destroyed. Also, we must be credible. Others must believe what we say when we give our advice on content and design and trust that what we say is true – this relates to Confidence.

As you grow in your career, your confidence grows. A junior writer asks others: What should I do? A senior writer is asked by others: What should I do? The difference between the two is confidence, which comes with experience.

Confidence enables you to deal with Conflict, of which there is no shortage of in the business world. When two SMEs disagree on the contents of your document, it is a conflict that you will have to work to resolve with them.

Confidence also enables you to deal with Change. Change happens on so many levels – in people, in companies, and of course, in our documents and the way they get created. Accepting and managing this change is a critical skill to have, and requires Courage. I remember a tumultuous time when, as a result of various mergers, the company I worked for changed about every year. It was a stressful time, but also exciting, as everyone worked to manage the change.

Of all the C-skills to have, Creativity is the most important, because it encompasses all these other ideas. People who win at job interviews do so because they show how they have creatively solved documentation problems. Both your resume and in your interview should overflow with samples of your creative genius. It’s great that you know FrameMaker, but so do hundreds of other people. Instead, focus on how you improved the documentation and the documentation process in a creative way.

Creativity also involves working Colloboratively with others. We tech writers are an introverted lot, a habit we need to break. No person is a cubicle. The more we interact with other writers and non-writers, the better. Have you ever stopped and asked a code developer what they do? What they like? What they think of your documents?

Practicing all these skills enhances your Career. Career management is a whole other discussion. Managing your career and network of Contacts is like tending a garden. It takes time and care, but the end results are worth it. I owe my current job to the contacts I had carefully maintained.

Now, there is one C-word that is not a skill, but a shape: Circle. The letter C is like a circle with a gap:

C

The gap is symbolic of the gap that is present in all documentation: the gap between what the reader needs to know and what is actually in the document.

Salespeople have a saying: A.B.C.: Always Be Closing. Whenever they interact with clients, their entire manner and tone assumes the sale has been made – they just need to “Close” it.

Technical communicators need to practice A.B.C. We must come full circle and close the gap. Because when it comes to us and our readers…

…we are all Connected.

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.

Document Diplomacy

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.

Mind Games

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?
Nigel: Exactly.
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.

Going Beyond

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.

Letter Perfect

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.

Summing Up

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.”

This article is the second of three in a series. It’s describes the six basic principles to follow for both job interviewing and informational interviewing.

3. Honestly, Now

I remember a strange incident at my workplace years ago. A manager kept popping out of his office, bursting with laughter. He was fact-checking a job applicant’s resume, and discovered that almost everything on it was a lie: where the applicant went to school, where he worked, the groups he belonged to, and so on. Each time the manager confirmed another lie, he couldn’t wait to fly out of his office and laughingly inform the other managers.

I often thought about that job applicant. What was he thinking? Was he thinking? What if the manager hadn’t checked the resume, and the applicant had been hired? For the answer, we need to look to history.

King Pyrrhus vs. The Romans

Many years ago, a Greek King named Pyrrhus defeated the Romans, the superpower of the time. This was an incredible feat – it would be like Mexico beating the United States. (Can you imagine what would happen? There’d be millions of Mexicans living in America and the government would be trillions of dollars in debt…OK, bad example.) In any case, although Pyrrhus defeated the Romans, he did so at enormous cost – many of his men were slaughtered. That is, he won, but he lost, hence the expression Pyrrhic victory; a victory that really isn’t much of a victory.

So it is with applicants who lie their way to a job. They get the job – now what? They’ve got a job that they are not qualified to do, that requires skills they don’t have, at a place they don’t want to be, working with people they can’t stand – congratulations! When you lie or embellish the facts on your resume or in an interview, you’re only lying to yourself.

Therefore, in an interview, always be honest. If you don’t know how to use a particular piece of software, say so, but also describe how you are a quick learner. If you worked on a project that went bad, be honest about it, but say what you learned from the experience. A little honesty goes along way.

For example, if asked, “Why should we hire you?” answer the question honestly. State how you sincerely believe that you’d be a good fit for this position, and that you have much to offer.

Another question that will test your honesty is: Tell me about a time you failed. Without hesitating, state the failure, but then explain how you learned from it. For example, perhaps you were rushed and released a user guide that you later discovered was missing certain procedures. Talk about how you learned from this, and more carefully planned your schedules and reviews, so that the next release was better than ever.

By the way, this question is a good example of a stress question, where the interviewer wants to see your reaction, and is not just concerned with the content of your response. Be strong and show how you can easily handle the pressure.

Fool Me Once, Fool Me Again, Please!

Honesty also applies to informational interviewing. Often times, when interviewing the SMEs, we’re too embarrassed to admit we don’t understand something. Just remember – it is your job as a professional informational developer to go from not understanding something to understanding it. If you are not initially confused and bewildered, then you’re not doing you’re job. If you don’t understand something, say so! You may look foolish – so what? It’s better to be a fool in private that to create foolish documents, documents that may come back to haunt you – then you’ll really be the fool.

Chaos Theory

All great products and services got to be great by having people ask dumb questions. There’s so much chaos that we don’t see. If you’ve ever been backstage at fashion show or a play, you’ll see it’s often total mayhem – people yelling and screaming at each other, doing dumb things, and asking dumb questions. But the audience never sees this– they just see a beautiful show, or a beautifully complete and concise document.

4. Don’t Be Anti-Active; Be a Pro

It’s no coincidence that the words professional and proactive both begin with the same three letters. To be a professional, you need to be proactive. Proactive should really be called pre-active, to indicate that you take action before (pre) there is a problem, and thereby pre-empt the problem.

Explosive Issues

Being proactive means being responsible, and responsibility is something you hear about in the news all the time. In 2008, there was a huge explosion at a propane facility a few kilometers from our home. We were far enough away that we weren’t directly affected, but we did hear it. Afterwards, almost on queue, no-one wanted to take responsibility for this disaster. The city blamed the licensing facility. The licensing facility blamed the city. The province blamed the city. The city blamed the facility owners. The owners probably blamed the employers. No one wanted to take responsibility.

Compare this with the disaster that followed shortly after, in which various meat products at the Maple Leaf processing plant became infected with listeriosis and several people died. Incredibly, the president of the company, rather than blaming others, took full responsibility. He did not blame the government. He recognized that the buck stopped with him.

Responsibility is an important issue for us, because it relates to the question of who ultimately owns the documentation. The very definition of a senior technical writer is someone who owns, and is therefore ultimately responsible for, the documentation, in the same way that senior coding developers own the code.

Pro-Active Interviewing

Being pro-active and showing responsibility applies in two ways during a job interview. First, you need to be proactive before the interview. Carefully study the company, its history and products, and the position itself. Secondly, show during the interview how you have been proactive in your job. Examples include redesigning the templates, improved the indices, and enhancing the documentation development and review process. Bring samples to indicate the changes you made. Show how you avoided documentation explosions before they happened.

A question you may be asked that will show how proactive you have been is: Why do you want to work here? To answer this question effectively, you must have proactively researched company and the position, and reviewed your skills and work history so that you can clearly state why you’d be a good fit.

Finally, you may be asked: What is the purpose of technical communication? You might think the answer is to instruct the reader on how to use a product. That’s true to some extent, but the real purpose is to reduce technical support costs by creating documents that people actually use, and thereby help avoid the users from having to call in. Therefore, you need to show how you have proactively done this. Examples include creating a detailed troubleshooting section, adding critical missing content, developing training guides, and writing a glossary.

For informational interviewing, being proactive means planning your questions carefully before you sit down with the SME. It means creating documentation plans and schedules, and reviewing and testing the product to find all the hidden and potential problems. It means recognizing that a SME’s time is valuable, so you want to be able to zoom in and get clear answers to your questions by having used and tested the product you are documenting. It also means constantly following up with the SMEs to ensure they answer all your questions and review every draft.

First of three in a series

This article is based on a presentation I gave at the STC Career Day, held at Seneca@York, September 22, 2003. It describes the six basic principles to follow for job interviews and informational interviewing, including asking and answering the right questions, of the right people, at the right time.

The DNA Interview

The science fiction film Gattaca envisions a future where everyone is genetically engineered to be a perfect match for their job. For example, a classical pianist is bred to have an two extra fingers so that he can play more notes. (I presume he would also give good back scratches.)

In a scene from the film, the main character is applying for a job as an astronaut. A lab technician scans a sample of the applicant’s blood to verify that the applicant is who he says he is. (He’s not really, but that’s another story.) The technician tells the applicant he’s hired. The applicant asks, “What about the interview?” to which the technician responds, “That was it.”

Ah, if only it were that simple. If only there was some magical machine that could scan our minds, determine if we were the right fit for the job, and spit out a message: “Technical writer – level 4 – please proceed to your workstation.”

The UnSystem

Alas, there is no such system. Instead we have the following “system”: you enter a room with one or more people, answer a series of questions, and based on how well you respond, you get the job. (Your portfolio, while important, cannot salvage a bad interview.)

Now, does this so-called system make any sense? What have you really proven? You haven’t shown you’re the best person for the job – you’ve simply shown that you can answer a series of questions, and that you can find the company’s building.

What companies should do, after weeding out the candidates that have truly rotten resumes, is temporarily hire the various applicants to see how well they perform on the job – in other words, apprentice them. This is, in fact, done for certain professions, but not often for technical writers, as it’s a very expensive and cumbersome option.

So we’re stuck with the system where the best interviewee (and not necessarily the best candidate) wins the job. Therefore, excellent job interviewing skills are critical. However, as important as these skills are, you’ll only need them several times in your life.

Assuming you work about 40 years in your life, for an average of 4 years per job, you’ll have experienced ten interviews on ten separate days. On the other hand, while on the job itself, you will be conducting informational interviews all the time, hundreds, if not thousands of times, during your working life. Therefore, good informational interviewing skills are also very important.

Master of Disguise

Job interviewing, is, in fact, just a form of informational interviewing in disguise. Interviewers are trying to obtain as much information about you as possible, and you’re trying to get as much information about them, the company and the position as possible, all in a limited amount of time. That’s why these interviews are so stressful.

Also, informational interviewing isn’t used just for finding out information about documentation, but about how things work at your company. The company I work for was recently acquired by Oracle, and we’ve all been receiving vast amounts of information about the company, the new people and the many new policies and procedures. I’m thankful that as an information developer, I can sort through it all.

Indeed, you can use informational interviewing to find out about anything, including what’s really going on at your company, your family and colleagues, with technology and our profession, with your finances – anything. So you will find it is an extremely useful skill to have, and not just at work.

Let’s now look at the six basic principles of effective job and informational interviewing.

1. Shhhhh – The Audience is Listening

The first principle of interviewing is also a basic principle of information development. It is that before you write a single word of a document, you must know who the document is for and its purpose. In other words, you must know your audience. For example, the readership for a digital camera guide is quite different than for an administrator’s guide that describes how to set up a complex network. You need to target the language, structure and organization of the document accordingly. Ideally, you should imagine that you are that audience.

So it is with interviewing – you need to target your questions and answers to your audience.

The Three Musketeers

In a job interview, you’ll typically encounter three different types of interviewers:

1. The HR (human resources) specialist
2. The person you’ll potentially be working for
3. The person (or people) you’ll potentially be working with

You need to carefully craft your responses for each of these three types.

HR – Humane Responses

HR personal are generally non-technical, and therefore know little about technical writing. Do not talk over their heads with mindless techno-speak. For example, if asked to describe your best accomplishment, don’t respond with something like: “I effectively single source with FrameMaker using a complex combination of text insets, conditional text and variables.” The HR interviewer will silently nod in agreement but will have no clue as to what you just said. Instead phrase your response to their level, for example:

“We had lots of text that kept repeating throughout our documents. Every time it changed, we had to manually find the text in the various documents and change it, which took a lot of time and effort. I was able to fix this problem by storing this recurring text in a single file, and then using references, or pointers, similar to a Windows file shortcut, to repeat the same text in different locations. Now whenever there is a change, I just have to change one file instead of many, and the change magically propagates throughout the entire documentation set, greatly lowering the maintenance…..(Can you dig it? I knew that you could….)”

Don’t Boss Me Around

If you survive the HR gauntlet, you’ll be interviewed by the person you could be working for. This is the most important person who will interview you, because it is they who will usually make the final hiring decision.

The person you may work for will be one of two types:

1. A technical writer – e.g., documentation manager, publications manager, technical writing team lead, etc.

2. Not a technical writer – e.g., a development manager, QA manager, product manager, marketing manager, etc.

Again, if they are not a technical writer, don’t use heavy tech writing industry jargon; talk at their level. If they are a technical writer, you can be a bit more technical, but don’t overdo it, as they may think you are trying to mask other problems.

Whether or not your potential boss is a technical writer, what you want to emphasize in your responses is that you are:

• flexible and adaptable
• a team player – you play nicely with others
• friendly and approachable
• intelligent, organized, knowledgeable and resourceful
• able to hit the ground running with minimal ramp up type – a quick learner
• honest and responsibleJust One of the Guys (or Gals)

  When being interviewed by the people you may be working with, typically other tech writers, it’s very important not to come across as a condescending, obnoxious, know-it-all. Recognize you are at their level, and act accordingly. Share horror stories of tools. Get their advice on a challenge you face. Have a sense of humour – tell them you still have troubling spelling XML and PDF. Show them you can work with them by actually working with them in the interview.

  Be Afraid, Be Very Afraid

  Be aware that behind every question you’ll be asked is fear – fear that you are not one or more of qualities just listed. Fear that you are unqualified (or overqualified), difficult to get along with (and therefore manage), a liar, a cheat, dishonest, irresponsible, arrogant, stupid or just generally psychotic. You must allay these fears in the interview by giving concrete examples of what a fantastic worker you are. Talk about how you enjoy working with others, how you have made great improvements to the doc set and the doc process, and how you are always learning new things. Most of all, you need to show a genuine and solid interest in the position. Studies show that the candidates who win interviews came across as most passionate for the job.

  Be Yourself, Not

  As described previously, the principle of knowing your audience obviously applies to informational interviewing, because you have to ask questions that get the answers the typical reader needs. That’s why it’s best if you can imagine you actually are the end user – with all of their needs, wants, fears and neuroses.

  This principle applies another way: to the person whom you’re interviewing. You need to understand them and what level they are at, so that you can ask relevant questions.

  Nuts and Bolts
  
  Imagine you’re developing the user manual for a car. You go down deep into the assembly plant, walk along the vast assembly line, and ask the big, burly factory worker, the one who tightens the bolts on the engine, “Hey there – do you know how the radio works? And what sort of person typically drives this car?” You won’t exactly get warm responses, or even accurate ones. This is because it is not the job of the assembly worker to know these things. They just have to know how to put the cars together so that they won’t fall apart or explode too much when you drive them. (Ford and GM notwithstanding.)

  Conversely, can you imagine asking a car salesperson how much torque should be applied to the engine bolt to tighten it? Again, that is not their job to know. Recognize that subject matter experts (SMEs) are on a spectrum, from the most removed from the end user (developers), to less removed from the end user (QA testers, technical writers) to those in direct contact with end users (product mangers, business analysts, salespeople, technical support.) They are all various parts of the food chain, like amoebas, snakes, leprechauns and other creatures.

  Therefore, when asking questions of SMEs, ensure the questions are relevant and appropriate. For example, I would expect the developer who created the multiple N-up printing field (the one that allows you to print several smaller images of pages onto a single page so that you use less paper), to know how it works, and the mechanics of it. I would not expect them to know specifically why a user would use it, or that the user should use larger fonts to make the printouts more legible. However, I would expect the product manager or business analyst to know why ths field would be used.

  The challenge when conducting interviews is to find out the ultimate, true reason for a procedure, element or thing. Therefore, your questions must match the SME.

  2. Know thyself – know what I mean?
  
  Everyone is like a computer program: they are hard-coded with certain likes, dislikes and personality traits. They blossom in some environments and wither in others. It is therefore absolutely critical that you know the contents of your “program”, so that you can recognize if it is compatible with the job you are applying for.

  Just as you have a unique personality, the job you’re applying for has one too. It has strengths, weaknesses, skills and other characteristics. If you don’t know yourself, how can you know if you’d be a good match for the job?

  Why We Write
  
  One of the questions you may be asked in an interview that will quickly indicate if you know yourself is: Why are you a technical writer? I’ve been asked this, and have asked it of candidates I’ve interviewed. You need to know the ultimate reasons why you’re a writer, and it’s not enough to say it’s because you like working with documentation – that’s obvious. Why do you like working with documentation? Is it because you like helping others? Is it because you enjoy making order out of chaos? Is it because you’re an end user yourself and get frustrated when you encounter a guide that is incomplete? Is it because your parents used to beat you with dictionaries? Know yourself to know these reasons.

  The ultimate question where you must know yourself, is Tell me about yourself. Because this is such an open-ended question, most people dread being asked it. It is not an opportunity to spout your life story. The question really means: “Tell me about yourself in relation to this job, what you’ve done, what you’re doing now and what you hope to do, to show me that you’d be the best person for this position.” You must practice your response to this question. It may be something like:

  “I’ve been a technical writer for over 10 years. I work mostly in FrameMaker, WebWorks Publisher and Adobe Acrobat, to create a wide variety of documentation including user guides, online help, technical guides and Release Notes. I like doing what I do because I enjoy the entire process of gathering and organizing information from a wide variety of sources, and putting all this into a guide that people can actually use. Finally, I’m very much a believer in content management so I’ve been studying it quite a bit, especially XML and DITA, and hope some day to work with these areas.”

  Other questions you may be asked where you really have to know yourself and why you do what you do include:

• Name three things you like about technical writing. Have a list prepared!
• What are your greatest strengths? – Are you a good multi-tasker? Are you persistent? Do you have good interviewing skills? If so, say so, and give examples.
• What is your biggest weakness? State a weakness and show how you overcame it. For example, you may say you find it stressful rushing a project, so you have developed a good system of creating a doc plan with tasks and dates, and ensuring everyone follows it to avoid a rush.
•  
• Why are you interested in this position? You can only answer this if you know yourself, skills the job, and the company to show that there’s a match.Passionate Documents

  It’s important to know yourself and exactly why you’re a tech writer because this will help motivate you when gathering information for your docs. One of your ultimate passions should be to help – change won’t happen unless you are passionate about it. You need to be as passionate as the followers of Obama, and say:

  Yes we can – create great documents.
  Yes we can – convince management that documentation is important
  Yes we can – convert all our docs to XML

  Because we are the track changes we believe in.

  Andrew Brooke – abrooke@primus.ca

I have given a name to my pain, and it is: Salary Negotiation. It is the most painful form of pain that there is. Root canal? No problem. A dislocated shoulder – hey, bring it on. Listening to politicians during the current election campaign? Slightly more painful, but I’ll survive. But salary negotiation? Pure torture; a fate worse than death, death being quicker, and only occurring once.

Salary negotiation is one of the final phases of the job hunting journey. You’ve determined what it is you want to do and where, updated your résumé, networked with others, researched companies, perhaps approaching some of them directly, applied to various jobs, and survived the interview. You’ve reached the POP: the Point of Pain, the point of negotiating your income.

To help make this a less painful process, I offer the following tactics, adapted from “What Color is Your Parachute?” Note that unless you are a car salesman, negotiation is a very tough skill to master, and takes much hard work and practice.

So, if you really want to learn how to negotiate, stop reading this article, go to your TV and watch the “The World Poker Tour”. You will not find a more engrossing or educational show. Salary negotiation is the ultimate poker game. And like “The Gambler” says, you got to know when to hold, when to fold, when to walk away and when to run like hell.

Tactic #1: Avoid Talking Salary Before an Offer
Ideally, you should not discuss salary until you have received a firm job offer. Now, I know that this is a very hard thing to do. Most employers, quite rightly, will want at least a rough idea of how much you’ll cost them before they hire you. In fact, given that they may have several qualified candidates to choose from, often the choice will come down to salary.

However, from your point of view, the best thing you can do is not talk about salary until there is an offer. If the interviewer raises the issue of salary before then, a good reply would be something like: “Until you’ve decided you definitely want me, and I’ve decided that I would be able to help you with your work here, I think it’s too soon to talk about salary”

What if that doesn’t work and they still want to know your expected salary? You go to your second response, which is “I’ll be happy to discuss salary, but first can you help me understand more what this job involves?”

After that, if the interviewer still insists on knowing your salary (can’t you just feel the pain?), you can state a range, for example, “I’m looking for something in the $NN,000 to $NN,000 range.” More about ranges later.

Tactic #2: Avoid Being the First to Mention Numbers
The general rule is: whoever mentions a figure first loses. So another strategy, if you are asked to state your salary (either before or after a job offer) is turn the question around and say “What kind of salary did you have in mind?” You can also say: “Since you created this position, I assume you’d have a figure in mind, and I’d be interested to know what it is.” It can take nerves of steel to do this, which is why it’s important to practice this with friends or family if you can.

Tactic #3: Research Your Range
Before you can state a range, you need to have a good idea of what other people at your level are making. Fortunately, the STC produces a very detailed salary survey for both Canada and the U.S.
If you look at page 6 of the last survey (from 2003), you’ll see the average salary figures based on a variety of factors: employment level, education, sex, age, and years of experience. The most important factors are employment level and years of experience. You can use either of these as a basis to determine your salary range. The employment level is probably the most relevant and useful, and has the most number of ranges.

Let’s say you are applying for a mid-level, non-supervisory position. This has an average salary of $51,490. The average salary of the next level up is $58,200. Therefore the range is $51,490 to $58,200.
But you would never state such precise numbers in a range – generally you would round to the nearest thousand, or in some cases, the nearest 5,000 or 10,000. So you could restate this range as $52,000 to $58,000 or, for even more flexibility, $50,000 to $60,000.

Other sources for salary ranges include business publications, want ads, the STC job bank and fellow writers.

Tactic #4: Hone, Hone in the Range!
What you want to do is “hook in” your range to the one that the employer has in mind. If the employer is expecting to pay $45,000 to $50,000, the range you’d want to give is around $42,000 to $53,000. The lowest end of your range is lower than their lowest number, but the highest number in you range is higher than their highest number.

Now, if you can get the employee to state a number (or range), it will often be at the low end of the range you had in mind, or even below it. This is where the tough negotiating skills come into play. You need to state your range and explain it is justified because:

• you are so productive
• you’ve always improved the quality of the projects you’ve worked on
• you’ve streamlined processes and procedures
• you’re such a wonderful human being, a great humanitarian, and you smell nice

That is, you need to say you deserve more money because you’ve lowered costs. As tech writers, we may not be able to increase revenues much (at least not directly) but we can have a direct effect on cutting expenses. That’s why it’s critical to list your cost-savings accomplishments, and, if possible, show them through your work samples.

Tactic #5: Close the “Sale”
If the stars align and by some miracle you and the company can agree on a salary – great! But don’t forget all the other things that make up your employment package:

• vacation time (usually negotiable)
• medical and dental insurance (less negotiable – companies often have fixed plans)
• training allowance (some companies will offer to pay for training course)
• flextime work schedule
• telecommuting options
• stock options (believe it or not, these still actually mean something in some places)

You want to get as much of this in writing as possible, in a letter of agreement or employment contract. As Sam Goldwyn said: “A verbal contract isn’t worth the paper it’s written on.” The road to hell is paved with unwritten promises.

Tactic #6: Evaluate the Offer
Once you’ve received an offer with all the details listed above, it’s time to do some hard thinking. Don’t be afraid to say you’d like a couple of days to think about it in order to discuss it with your family or colleagues.
You need to ask yourself:

• Do you like the work this job involves?
• Do you like the company and corporate atmosphere or culture?
• What do you think of your potential boss? Are they someone you can work with?
• Is the job challenging enough to meet your needs, but not so overwhelming that you would burn out?
• Is the total compensation they are offering enough?

And most importantly: Are you sure you want this job? If not, don’t be afraid to turn it down. As long as you persevere in your hunt, it won’t be the last job offer you’ll ever get.

Tactic #7: Follow the Job Hunter’s Philosophy
Evaluate the offer, make your decision, accept it and never look back. Nothing is more tragic than the words “I should have…” Don’t put yourself in a position where you later say: “I should have taken that job” or “I should have turned down that job” or “I should have asked for more money.” Regret and second-guessing will crash your mind as badly as an old hard drive.

Your career path will reflect the sum total of the choices you make. This is a view that must permeate the management of your career. Job hunting is one of the hardest, most stressful, most draining and most depressing things we have to endure. But it doesn’t always have to be. More important than what happens to us in our job hunt, and indeed, in our lives, is how we respond to it. As Holocaust survivor Viktor Frankl wrote in “Man’s Search for Meaning”:

We who lived in concentration camps can remember the men who walked through the huts comforting others, giving away their last piece of bread. They may have been few in number, but they offer sufficient proof that everything can be taken from a man but one thing: the last of the human freedoms — to choose one’s attitude in any given set of circumstances; to choose one’s own way.

***Have a great summer. When this column returns, it will take on a new form. What will it be? You’ll have to wait until the fall to see…

This month, we complete our series on interview questions. Although we’ve covered many potential questions, note that we’ve only scratched the surface. There literally hundreds of questions that you could be asked. Although it is impossible to anticipate every question, the more that you can plan responses to, the greater prepared you will be.

Here’s an extensive list of other questions and statements to think about, from the sublime to the ridiculous, in no particular order. If you can think of a response to each one, you will be far more prepared than most people.

• What exactly does a technical writer do? Why do I need one?
• What are the most critical aspects of your job?
• What’s your energy level like?
• Describe a typical day.
• What’s your job experience?
• How do you feel about your progress so far in your field?
• What do you know about our company?
• How long would you stay with us?
• What are your qualifications?
• What would you do here on your first day of work?
• Do you take risks? Tell me about a risk you took that went badly.
• How do you organize and plan your projects?
• Can you work under pressure?
• What kinds of people do you like to work with? What kinds don’t you like?
• Define “technical communication”.
• What interests do you have outside of work?
• Why are you leaving your current job?
• Have you ever done product testing?
• What kinds of decisions are hardest for you?
• Why were you fired/laid off?
• How do you get information out of people? What do you do if they don’t cooperate?
• What are you looking for in your next job?
• I don’t know if you’d fit in here.
• How do you cope with change?
• Define “usability”.
• What have you learned from your mistakes?
• What can you do for us that someone else can’t?
• Describe a difficult problem you’ve had to deal with.
• If you could change one thing in your past, what would it be?
• What makes this job different from your last one?
• What are some of the things you’ve worked on in the past?
• How do you take direction?
• I’m not sure if you’re qualified for this job.
• What other areas could you help out with?
• What have your other jobs taught you?
• What do you do when you disagree with others?
• Are you a leader or a follower?
• Tell me a story.
• Do you work well with others?
• Can you manage other people?
• What do you think of your current/last boss?
• Wouldn’t this job would be a big step down for you?
• What have you done that shows initiative?
• What personal characteristics are important for this job?
• Explain your role as a team member.
• Describe a situation where your work was criticized.
• What kinds of things do you worry about?
• What is the most difficult situation you have faced?

Note that some of these questions came from a recent episode of “The Apprentice” reality TV show. The remaining four candidates (all vying for a plum job with real estate mogul Donald Trump) were subject to series of gruelling interviews. It was no surprise to see Amy fired: one the interviewers commented that she was insincere, irritating, bored and acted “like a Stepford wife”!

A Travesty of a Mockery of a Sham!
We’ve been looking at interview questions like these for the last few months, but now, a confession: it has all been a sham! Here are two incredible facts: a 1989 British survey revealed if an interview was done by someone who would be working directly with the candidate (which is usually the case), the success rate dropped to 2% below that of picking the name (of qualified candidates) randomly! And if the interview was done by a “personnel expert”, the rate dropped to 10% below picking the name randomly! It makes you wonder what on earth personnel experts are paid to do.

Why then do companies waste huge sums of money and time conducting interviews, when they would probably be better off just picking names randomly? I believe it is simply because they know of no other way to hire people, and most of them would certainly have no idea that the interviewing process is largely useless.

However, the fact that the process is useless is not your problem – it is the company’s problem. Your challenge is to learn the tricks and techniques that can help you win interviews. The fact that the process itself is flawed is irrelevant. There is simply no other way to play the game if you want to work for a company. Even freelance writers often have to go through the interview process, at least with new clients.

Winning the Interviewing “War”
The Chinese general Sun Tzu wrote in his famous military treatise “The Art of War”: every battle is won before it is ever fought. When you are heading into an interview, you are going into battle. You are up against every other person who is applying for that job. Fortunately, it is a peaceful battle, and you will probably never see (much less have to kill) your opponents. Tzu’s statement simply means “planning is everything”. What is astonishing is that Tzu wrote these words 2,500 years ago, yet they are still incredibly relevant today.

All major endeavors, from warfare to job interviews, involve three major areas: an objective, strategies and tactics. Do not make the mistake of getting these mixed up. The objective is the ultimate, single purpose of something. The strategies describe at a high level the ways you will achieve the objective.
The tactics are the specific actions you must take to achieve the strategies, which in turn lead to the completion of the objective.

Comparing these areas for warfare and job interviewing, we get:

Whether it’s war, job interviews, dating, getting in shape, or any other task, planning is critical. The more you plan, the more you strategize and think about how you will behave and respond to these many questions, the greater your chances of success.

Remember – the person who wins the interview isn’t necessarily the best person for the job, but is the person who is best at getting that job.

This month, we continue our series on interview questions. But before we begin, here’s some excuses people have given for taking time off work, according to a recent study by Accountemps, a Canadian recruiting firm:

• I need time to find myself.
• The pool is broken.
• My cat has hairballs.
• My partner and I need to practice for the square-dancing contest.
• I’m taking a few days off to start my own business.
• I’m going to jail.

It’s a wonder these people got through the interviewing process. Now, on to the questions…

Why do you want to work here?
To effectively answer this question, you must have thoroughly researched the company and the kind of work they will expect you do do. This will allow you to state specifically why you would be a good fit. For example, you may say:

“The type of documentation projects I’d be working on are similar to those I’ve done previously, and involve the type of work I enjoy doing best. I find that when I’m doing what I like, it’s a great motivator to do a good job, and therefore I think I’d be able to make a solid contribution here.”

What have you learned at your previous jobs?
This question represents a good chance to restate your strengths and tie them in to the current position. You may say, for example, that you’ve learned the importance of being approachable and always encouraging open communication with your peers. This has resulted in a higher quality of drafts during review time, because people are not shy about approaching you with practical suggestions for enhancing the documentation.

How long would it take you to make a contribution?
You need to get more information before answering this question. Ask a question such as “What are your greatest areas of need right now?” or “What would be my responsibilities for the first six months or so?” From this, you can base your response, which may be something like:

“It might take me a week or two to get settled in and learn what I need to about your documentation process. But during that time, I can be making a real contribution. Are there any special projects that you want me to be involved in right away?”

The strength of this response is that it gets the interviewer already thinking of you as an employee.

How do you handle stress?
A good strategy for this question is to state the ways you minimize or eliminate stress. You can list things like:

• carefully planning all projects to minimize “surprises”
• continually monitoring the status of your projects, and following up with others when necessary
• recognizing that new and unexpected events can happen, and reprioritizing when necessary
• taking regular breaks to clear you mind and get refocused

If possible, give a specific example of a particularly busy time that you had, and how you handled it.
Keep in mind that some stress is actually productive, because it can give you the energy needed to get the job done. It’s only when you have too much stress that your work can begin to suffer. Also, although most people associate stress with having too much to do, note that not having enough work to do can also be stressful. You may want to say that you handle any down time by reviewing other projects such as older documentation that has not been reviewed in a long time.

Why should we hire you?
This may seem like a tough question, but it is, in fact, a “dream” question, the one question that you should hope you will be asked. In fact, as I stated at the beginning of this serious on interview questions, all the questions you will be asked are simply variations of this question. The interviewer wants to know exactly what makes you so special that they will pick you over the many other equally qualified candidates.

You need to highlight the areas from your background that relate to the needs of the job. Recap the job description and match it point by point to your skills. Drive home the fact that you are enthusiastic, a team player and that you are ideally suited for this position, but be specific. This question represents one of your single best opportunities to sell your strengths. A sample response would be:

“This position needs someone who’s able to handle multiple projects at the same time, has strong technical skills and is able to give effective feedback on product design. My experience has shown I’ve got these skills, and that I have a genuine enthusiasm for what I do. This has meant I’ve been able to make a meaningful contribution at all of my positions. And I’m proud of the fact that I’ve always been able to improve both the documentation and the processes for developing it wherever I’ve worked.”

Next month, we’ll wrap up our discussion on interview questions.