Docaholics Anonymous

Hi. My name's Andrew, and I'm a docaholic. I've been a proud member of Docaholics Anonymous (DA) for seven years now, and am grateful for the tremendous support I've eceived from them.
As you may know, Docaholics Anonymous is a world-wide support group that gives strength and comfort to those afflicted with docaholism, now medically recognized as a disease. Docaholism is the persistent addiction to the creation and maintenance of all forms of documentation. There is no known cure, other than professional counseling and the work of support groups like Docaholics Anonymous.

A DA History
DA has an interesting history. It was founded almost 50 years ago by two technical writers in Nebraska: Fred Bookend and Jack Riter. Fred had been a document addict for about 12 years. He was working up to 100 hours a week, and practically died from exhaustion. He would often change a single draft up to 60 times, driving his employer to distraction, resulting in constant reprimands and firings.

In 1956, Fred met Jack through the newly formed STC. Jack was also a docaholic, although not as severe as Fred. (Jack would only go through twenty review cycles compared to Fred's sixty.) The two men recognized that simply by talking about their addiction, it greatly alleviated their pain. They founded Docaholics Anonymous in 1958, and chapters quickly spread throughout the United States, then Canada, and finally the world.

Most of you may never have had the pleasure of experiencing a DA meeting. In a "Writer's World" exclusive, I have obtained a transcript of a recent chapter gathering. Because note-taking is not allowed at meetings (since it is a form of documentation), this transcript was taken secretly. Therefore, please keep this information to yourselves, lest I end up on the DA black list.

DA Support Group - North Toronto Chapter - Meeting Transcript

Nov 10, 2004 - 8:06 PM - Undocumented location
Cornelius (chapter leader): Good evening everyone!
Group: Good evening Cornelius!
Cornelius: I'd like to welcome everyone to tonight's meeting. Let's begin by going around the table. Does anyone have anything they'd like to share? Remember to state your first name, the nature of your addiction, and, if you can, how you've been working to overcome it.
Chloe: I'd like to go first, if I may.
Cornelius: Sure Chloe, go ahead.
Chloe: Hi. My name's Chloe and I'm a docaholic.
Group: Hi Chloe!
Chloe: I've been a docaholic for about six years now. My addiction has manifested itself in such as actions in marking up the magazines in my doctor's office, always carrying at least seventeen types of pens in my purse, and sleeping with a dictionary under my pillow, just in case I need to look something up.
I've had a pretty good week. The other day at work, a co-worker had a written post-it note on his desk, with lots of typos, but I placed it out of my "fear zone" and was able to let it go.
Cornelius: That's awesome Chloe! Thanks for sharing. Anyone else?
Rupert: I'll go.
Cornelius: Sure - go ahead, Rupert.
Rupert: Hi. I'm Rupert, and I'm a docaholic.
Group: Hi Rupert!
Rupert: I'm coming up to my tenth year in group. (applause) My addiction has taken the form of mild to sever heart palpitations when I see a billboard that is poorly designed and barely legible - also, I like to label all the kitchen, bathroom and bedroom shelves with the items that they hold. At work, I'm down to having only 15 review cycles in my drafts.
Cornelius: Great progress, Rupert! Keep it up. Soon you'll be down to ten cycles, then five and, if you "will" it hard enough, three.
Rupert: Well, to be honest, I don't know if I go less than seven cycles. That would just be too painful.
Cornelius: I feel your pain because I've been there. I too, thought that three review cycles was impossible, but by sharing my pain, I've accepted this number, and you can too.
Marla: But maybe sometimes a document does need more than three reviews?
Cornelius: Thanks for your honest communication, Marla. Does anyone in the group want to non-judgmentally say what Marla is practicing?
Group: Denial.
Cornelius: That's right. We love you Marla and we support you, and that's why we have to be honest with you, even if the truth is painful. Does anybody else want to share some facts they had to struggle with to accept?
Tyler: People don't mean to write poorly, they're just born that way.
(group applause)
Jason: It's OK if an index is missing an entry or two.
(more group applause)
Marla: Developers are not evil people just because they write poorly. They come from another world and don't know the customs of our planet.
(still more group applause)
Cornelius: Good, that's good sharing. Now I myself will share. Last week, I was working on a document that had fifteen screenshots. The problem is, they were all outdated and there wasn't time to update them. So do you know what I did?
Marla: Don't tell me that you - I can't say it.
Cornelius: Then I'll say it - I deleted them.
[Group gasps at the sheer horror of it all.]
Tyler: I think I'm going to be sick - how you could just, you know, d-d-d-delete them?
Cornelius: It wasn't that hard - once you've faced your fear, you can defeat it. You have to own your documents, or they will end up owning you. You have to choose whether the delete key will be your enemy, or your friend. Besides, the screenshots were redundant to the text anyway.
Tyler: Oh, thank god..
Cornelius: OK - it's time to move on to the "aversion therapy" session in our meeting. For you newcomers, this is where we all recite, in unison, portions of various incomprehensible documentation. The goal is that by facing "the worst", we can be "the best" at fighting our addiction.
Tyler: Yech, I really hate this part of the program.
Cornelius: Me too, but we have to do it to reach our self-actualization levels. Remember people - that which does not kill us makes us stronger. Now if you turn to page 6 in your DA booklets, to the group recitation section, let's read together:
Group (in unison):

To open the file, select to perform the clicking operation on the Open button. The file is now open and you can read it if that is your desire.
Error: The program has performed an unknown error. Please refer to this error message for details. This is the end of the message.
Warning! Failure to follow these assembly instructions may result in a permanent death. You may also be injured, too. If you are dead, you may not be able to use this product.

Cornelius: OK. Let's move on to my favourite section, "corporate-speak" ...page 12, section 2...

Group (somewhat in unison):

We are a cutting edge and bleeding edge team that strives to hyper-satisfy our clients by actualizing winning results.
We have the concepts that form the ideas which make the up heuristic viewpoint that comprises a systematized strategy for our forward-looking vision.
Despite the layoffs, the company is not "going bankrupt". We are in a transitional phase as we re-engineer our operations to face these challenges, and rework our operational constructs in a deprecated, time-phased manner.

Cornelius: Good. And if you care what any of that meant, you're still part of the problem and not part of the solution. And Marla, please put the pen down - you know the rules - no documentation allowed at group meetings.
Marla: Sorry - I was just writing down one sentence.
Cornelius: All docaholism starts with one sentence, with one word, with one letter. Then it grows like a virus into a paragraph, a page, a chapter and a manual. Before you know it, your labeling all the food in your fridge and putting name tags on your children. You can't be a little bit pregnant, Marla. I know, because I've been very pregnant.
Alright, let's finish tonight with the recitation of the twelve steps:
Group (in unison):

1. We admitted we were powerless over documentation - that our documents had become unmanageable.
2. We came to believe that a power greater than ourselves could restore our documents to sanity.
3. We made a decision to turn our documents to the care of a higher power as we understood him.
4. We made a searching and fearless moral inventory of our documents, except for the appendices, which nobody reads anyway.
5. We admitted to our higher power, to ourselves and our reviewers the exact nature of our documents, including typos, poor grammar and fuzzy screenshots.
6. We were entirely ready to have our higher power remove all these defects from our documents - at least the fuzzy screenshots.
7. See step 6.
8. We made a list of all the reviewers we had annoyed and became willing to make amends to them all.
9. We made direct amends to such people except when to do so would lead to really awful manuals.
10. We continued to take personal inventory of our documents, and when we were wrong, promptly admitted it, without using a spell-checker.
11. We sorted through, prayed, meditated, and proofread, to improve our conscious contact with our higher power, as we understand him, praying only for knowledge of his will for use and the power to carry that out. And we learn to accept really long, rambling sentences like that last one.
12. Having had a spiritual awakening as the result of this step, we tried to carry this message to those that still suffer. And we pledged to practice these principles in all our documents. Then we had lunch.

Cornelius: Thanks, well done. We'll see you next week. Let's close with the serenity prayer:
Group:
God grant me the serenity to accept the documents I cannot change;
The courage to change the documents I can;
and wisdom to be able to effectively document the difference.

Read More

Lessons from Star Wars in Information Management

or:

"Everything I needed to know about technical communication I learned from George Lucas"

Star Wars is, of course, the famous movie about a document. Specifically, it's about the efforts to deliver a stolen user manual of a killer application called "The Death Star", developed by an evil corporation named "The Empire". "The Empire" consists of various employees running around in extreme hockey gear and doing nasty things like destroying planets and not reviewing the drafts submitted to them.

I remember when Star Wars came to theaters in 1977. I went to see it on my eleventh birthday and vividly recall the excitement it generated. Everyone in the theatre knew they'd seen a film unlike any other. Love it or hate it, most people agree that Star Wars didn't just break new ground - it invented an entirely new type of ground.

The original Star Wars trilogy was recently released on DVD. The set includes a documentary about the making of these films, entitled "Empire of Dreams". This two-and-a-half hour documentary is as entertaining to watch as the films themselves, perhaps more so because it describes the battles that actually took place: the battle between George Lucas and the studio, the battle to get the first film completed against all odds, and the battle within George Lucas himself to stay true to his vision.I therefore offer the following lessons from Star Wars for all information developers: lessons from the making of the film, from the film itself and from its creator.

Lesson #1: Write like a normal person talks.
In one of most hilarious segments of the documentary, Mark Hamill (who played Luke Skywalker) recalls how he still remembers a long, rambling line he had to recite during his audition. Here is the line - try reciting it without taking a single breath:

"But we can't turn back - fear is their greatest defense - I doubt if the actual security there is any greater than it was on Aqualier Selis and what there is is most likely directed towards a large-scale assault."

"Who talks like this?", Hamill recalls. How true. The films would have failed completely if the language in them had been stilted and unrealistic - fortunately, most the of the dialogue comes across as fairly natural. The same cannot be said of the later Star Wars films: The Phantom Menace and Attack of the Clones. These films, while technically superior in special effects to the earlier ones, are not considered critically as successful, because of their awkward dialogue. There is also little humour in these later films, unlike the earlier ones which did not take themselves as seriously.

One of the biggest challenges we face as information developers is to take incomprehensible gobbledy-gook and make it sound natural, almost conversational, without losing any of the meaning.

To make things sound simple is, ironically, a complex task, but critical in creating successful documentation.

Lesson #2: Even with endless problems, you can still create great documentation.
The fact that Star Wars was completed and released was a modern day miracle. Filming was plagued with various problems. Studio restrictions meant shooting had to complete each day precisely at 5:00 p.m., unless the actors were in the middle of a take. The weather played havoc, with record heat waves in the desert scenes. Major cost overruns almost forced the production to shut down completely. Lucas was allowed to finish the film, but had to work at a breakneck pace to meet the deadline imposed by the studio. The original cut of the film before major editing began was a disaster. The pacing was terrible. Lucas and the editor could not agree on how to edit the film, so Lucas fired him.

But after months of long, hard work, the editing was fixed, the special effects added, the unique sound effects inserted, and, to top it all off, the dramatic memorable music scored was laid in. Initially, most theatres didn't want to show the film, thinking it was just another kid's movie. In the end, though, the film was widely distributed, and was an incredible success. Before Star Wars, most science-fiction films grossed less than $10 million. Star Wars made an astounding $461 million in the U.S. alone, and to date has grossed almost $800 million worldwide. Add to this the success of the later films and all the merchandising, and it's easy to see why Lucas is one of the richest men on Earth.

One lesson here is that the first draft of anything is crap - the final draft is all that matters. Also, the more time you have to work on something, the better it can be. When Lucas re-released Star Wars 20 years later, he was able to clean up and supplement much of the existing footage. Don't you wish we had the luxury of time to rewrite our final drafts, to make them how we really wanted them?

Welcome to Hell - Enjoy Your Stay
More importantly, though, Lucas's experience teaches us that we can achieve greatness even on a project that seems hopeless. We've all had the projects from hell. No one wants to review the drafts. There's no existing documentation or specifications from which to develop our documentation. We have trouble even accessing the application we're writing about. And yet somehow, adversity gives us the strength we need and we pull through, with great results. We create manuals that are the most complete, the most accurate, the most meaningful and helpful that they have ever been. We get feedback from our end users thanking us for at last creating guides they can actually use.

Yes, it's nice to create documentation at a steady pace, with full support, and without pressure. But there is no greater pleasure than creating great work under tremendous challenges. It strengthens you, and ultimately makes you a better technical communicator. As the saying goes: when you hammer steel, it becomes harder.

Lesson #3: Be careful not to become what you condemn about information development.
Lucas was constantly battling the studio for creative control over his film. Therefore, he was obviously happy when the success of Star Wars allowed him to form his own studio, LucasFilms, ensuring he no longer had to fight these outside corporate entities.

However, as Lucas notes at the end of the documentary, he was once against corporations, but now is the head of a corporation. Becoming the very thing you condemn is one of the themes in his films - with Luke battling not to join the dark side as his father had done.

Become What You Condemn, You Will
As information developers, we have no shortage of things that we love to condemn. But if we are honest, we'll find that we too can become what we condemn.
We condemn missing, incomplete or inaccurate documentation, but how much do we document our documentation and our documentation processes?

• Do we document all our troubleshooting techniques and tips for the various tools we use?
• Do we document our documentation development processes, such as how files should be generated and handed over to development, how to properly use the templates (if we even have templates!), and the standard names for our generated files?
• Do we keep a centralized list of all our documentation projects, with dates, statuses, estimated completion times and owners, so that we and others can review and prioritize them as necessary?

We condemn reviewers who don't review our drafts, but how much time and effort do we take to when planning and creating the drafts?

• Do we create documentation plans that specify what we are to produce, what changes need to be done, our requirements and assumptions, the names of the reviewers and a review schedule? Having a documentation plan may not guarantee success, but not having a documentation plan will almost certainly guarantee failure. We more than anyone should know that if something is not written down, there is no way it will be followed.
• Do we set deadlines for our reviewers and follow up with them, and escalate if necessary?
• Do we indicate what specific text has changed since the last draft, and which pages a reviewer can find those changes?
• Do we include internal notes and clear questions on the drafts themselves that stay with the document until they are resolved?

We condemn inconsistent information and seethe when we see variances where there should be consistency. But do we take full advantage of our tools to eliminate or reduce this problem?

• In FrameMaker, do we use variables and cross-references to store common elements such as the product name, version, and release dates?
• Do we properly plan and structure our documents using conditional text to avoid storing and maintaining the same content twice?
• Do we use text insets to store common sections that repeat throughout the documentation, such as copyright and legal information, lists of related documents and contact information?

Finally, we condemn those who do not take us seriously, and complain they don't know what is we do. But how much of an effort do we make to communicate and document our accomplishments?

• Do we keep a continuous, written record of everything we accomplished, so that we can complete those pesky annual review forms accurately and completely?
• Do we write down every milestone we achieved? Everything we did that improved the documentation, and how exactly we improved it?
• Do we continually update that most important of all our documents, our résumé, with these accomplishments?

If we are not doing these things, we no different than the doctors who smoke, the lawyers who break the law, and the accountants who can't do their own taxes. We must stay clear of the dark side of condemnation, and look inwards first. That is the only way we can grow in our profession.

Lesson #4: To succeed in the world of information development, you must change it.
Back in the mid-1970s, when Lucas was originally pitching his idea of a space fantasy film, most studios thought it was ridiculous and would fail completely. At the time, Hollywood was producing mostly dark, gritty films that offered pessimistic views of the world. These films were simply a reflection of the somber times, with high inflation and gas prices, the Vietnam war raging and the Watergate scandal. The idea of upbeat science fiction film with good and evil clearly defined was thought to be childish and out of place.

Lucas, though, had his vision and never strayed from it. He instinctively knew the time was right for a break with the bleak films of the past. However, in order for his vision to succeed, he knew that he would have to change the way movies were made.

At the time, studios didn't really have special effects departments. There was little need, because of the realistic films being produced. Lucas had to hire the best and brightest to create new technologies and techniques - specialists in photography, model making and electronics. They even had to build their own computers since none were commercially available.

Pioneering Effects
Among the pioneering techniques developed for the special effects were:

• Advanced use of blue-screen and motion-capture processes to create sweeping, dynamic views. For example, not only did the spaceships move at various complex angles, the view of the ships (the movie-viewer's view) was also moving, giving the incredible sensation of flying.
• The concept of a used future. Previously, science fiction films had pristine sets in which everything looked clean and brand new. Lucas felt that the ships and surroundings should have a dirty, used appearance to add realism to the story. This look is still used today.
• Advances in sound mixing and engineering to create the spectacular sound effects in the film. For example, various animal sounds were recorded to make the grunts and groans of Chewbacca. A metal rod tapping on a steel suspension cable was used to make the sound of the laser guns.

Star Wars not only set new standards for special effects, but added a key element to the film industry: merchandising. At the time Lucas was negotiating his contract, he had the foresight to ask for the merchandising revenues. Since merchandising was virtually a non-existent concept for the studios, they had no hesitation about accepting his request, because they assumed merchandising would not generate much revenue, if any.

Visionaries Wanted
Such utter lack of vision and foresight can been seen throughout the history of computing, with Xerox allowing Apple to steal the graphical user interface and the mouse, and IBM allowing Microsoft to license operating systems. In hindsight, it's easy to say these were terrible business decisions, but at the time they seemed logical for the large corporations that made them. These companies simply did not have the vision that others had. That's why Lucas, Steve Jobs (the founder of Apple) and Bill Gates are often called visionaries.

As a former executive of 20th Century Fox stated, "George was enormously far-sighted. The studios weren't because they didn't know that the world was changing. But George did know - he changed it."

The unexpected success of Star Wars completely changed the movie industry. It was the first real blockbuster. It had international success. It set new standards in visuals, sound and story telling. It created a whole culture of movie fans. But none of this would have happened if there had been no vision, no one willing to challenge the studios and change how films are made.

Change Management

As information developers, we are at a crossroads in our profession. Just as the film industry changed, new ways of creating and delivering information are slowly but surely being developed. Enterprise content management systems, single-sourcing, structured writing, extreme documentation, XML, object-oriented documentation, and real-time on-demand documentation are all dramatically altering how we work, and will continue to. But we must be the ones who lead this change.

Most companies don't use these new systems because:

1. They don't know these systems exist.
2. They know these systems exist but don't know anything about them, or how they can potentially save huge sums of money using them.
3. They don't know how to implement these systems.
4. They don't want to spend the money to implement these systems.
5. They don't like change.
6. They are just plain evil, like Mr. Vader.

In the future, these new systems and processes will be as prevalent as the Internet. Remember when no companies had websites? Now they all do. How did this happen? Because companies recognized the new technology as an expensive but necessary cost of doing business. So it will be with these new informational systems. Once companies realize that they cannot compete without them, they will be dragged, kicking and screaming, into the 21st century.

Leading the Way
As information developers, it is our duty to lead these organizations forward. Because if we don't, the same problems that plagued web page design will plague these new systems. So many early websites were awful, and many still are, because programmers, artists and business people, and not information developers, were given the task to create them. If we allow database managers and programmers to design and implement these systems instead of us, we will again be heading for disaster. We must be the ones to take charge, to shape our profession and our destiny.
And after we have changed how content is created, we will remember the insane way we used to create it "a long, long time ago, far, far, away."

***

The Final Lesson
These are the lessons from Star Wars, and there are many others. But the main lesson remains: have a vision and stay true to it, even when the odds are against you. Use the Force of knowing you are helping others get the information they need so that they can do their jobs. Who knows? You may even change the world.
May the "single-source" be with you...

Read More

The Info-Terrorist War

Welcome to A Writer's World, my new monthly column, where I offer unique and entertaining views on our profession.

Note: Occasionally, I will link to other websites. Please note that neither I nor the STC officially endorse these sites. So if you visit them and your computer explodes, the milk in your fridge turns sour, your car won't start, your pets stop talking to you and your spouse leaves you, don't blame me.
Now, on to the first installment...

The Info-Terrorist War
Warning! This editorial is satirical - anyone taking it seriously will be shot.

My fellow communicators,

There is an informational war waging throughout the world. It is nothing less than a battle between good and evil. Between the forces of confusion and clarity. And only one side can be victorious.
The enemies of clarity have committed an act of war against us. We are a profession awakened to confusion and called to defend clarity and completeness. Our frustration has turned to anger, and anger to resolution.

Communicators have many questions. We are asking: Who is attacking our profession? The evidence we have gathered all points to a collection of loosely affiliated info-terrorist organizations known as Al-Quanfusja ("I'll confuse you".)

The Info-Terrorist Organizations Exposed
In addition to Al-Quanfusja, there are a number of aligned organizations, whose goal is also misinformation. These groups include: Al-Misleedja (I'll mislead you), Al-Knatelja (I'll not tell you) and Al-Natshewja (I'll not show you).

Organizations like these, and their subsidiaries, constitute an axis of evil, threatening the existence and accuracy of the world's information.

Al-Quanfusja is to info-terror what the mafia is to crime. But its goal is not making money; its goal is hiding all meaningful content -- and imposing its radical beliefs on companies everywhere.

The info-terrorists practice a fringe form of extremism that has been rejected by information developers and the vast majority of companies -- a movement that perverts the clear dissemination of information.

This group and its leader are linked to many other organizations in different professions. There are many info-terrorists in many companies. They ferment within their own companies where they are trained in the tactics of info-terror, plotting misinformation and confusion.

The Demands
So today, I make the following demands on Al-Quanfusja:

Release all your internal and external documentation for review. Protect technical writers, information developers and usability experts in your companies. Stop immediately and permanently every person who is blocking the information development process. Hand over every document you are hiding, and give us access to every person in your development department, and to all the applications to be documented.

These demands are not open to negotiation or discussion. Al Quanfusja must act, and act immediately. They will stop the info-terrorists, or they will share in their fate.

A Message to Others
I also want to speak directly to the various company presidents, financial and information officers and development managers. We respect your professions. Their teachings are good and useful, and those who commit evil in the name of upper management blaspheme the name of business. The info-terrorists are traitors to their own profession, trying, in effect, to hijack the information development profession itself. The enemy of information development is not our many management friends. Our enemy is a radical network of info-terrorists, and every business that supports them.

Our war on terror begins with Al-Quanfusja, but it does not end there. It will not end until every info-terrorist group has been found, stopped and defeated.

These info-terrorists confuse not merely to end clarity and meaning, but to disrupt and end a way of life. With every action, they hope that we grow fearful, retreating from the world and forsaking our end users. They stand against us, because we stand in their way.

Know This - The Info-Terrorists are History
We are not deceived by their pretenses to profit and "best practices". We have seen their kind before. They are the heirs of all the false business ideologies of the 20th century. By sacrificing clarity to serve their radical visions -- by abandoning every value except the desire to confuse -- they follow in the path of those who hired programmers and engineers to develop documentation, resulting in chaos and confusion. And they will follow that path all the way, to where it ends: in history's unmarked repository of discarded user guides.

Technical communicators are asking: How will we fight and win this war? We will direct every resource at our command -- every means of influence, every software tool, every instrument of documentation standards enforcement, and every necessary weapon of business -- to the disruption and to the defeat of the info-terror network.

Forget Y2K
This war will not be like the war against the Y2K problem a few years ago, with a decisive repair of code and a swift conclusion. Our response involves far more than rapid and mass hiring of programmers to fix broken code. Technical communicators should not expect one battle, but a lengthy campaign, unlike any other we have ever seen. It may include dramatic restructuring of content, producing large volumes of internal documentation and creating complex documentation procedures, which are secret even in success.

By aiding companies that work with us, we will starve info-terrorists of funding, turn them one against another, drive them from place to place, until there is no refuge or no rest. And we will pursue companies that provide aid or safe haven to info-terrorism. Every person and organization, in every region, now has a decision to make. Either you are with us, or you are with the info-terrorists. From this day forward, any company that continues to harbor or support info-terrorism will be regarded by technical communicators as a hostile entity.

Our Obligations
We must take care to ensure that we are on the right side. If we create documentation that is not clear, consistent and complete, if we fail to recognize the importance of content management, if we do not create documentation that is usable and accessible, then we have done the work of the info-terrorists, and they will have surely won.

Our war on confusion is well begun, but it is only begun. This campaign may not be finished on our watch -- yet it must be and it will be waged on our watch.

Our cause is just, and it continues. And our world has been put on notice: We are not immune from confusion. We will take defensive measures to protect our documents. Today, dozens of technical writing organizations and special interest groups have responsibilities affecting their documentation. These efforts must be coordinated at the highest level.

These measures are essential. But the only way to defeat info-terrorism as a threat to our documents is to stop it, eliminate it, and destroy it where it grows.
A Group Effort
Many will be involved in this effort, from technical writers to information developers. All deserve our thanks, and all have our prayers. And today, I have a message for all of you: Be ready. I've called on all information developers to be alert, and there is a reason. The hour is coming when we will act, and you will make us proud.

This is not, however, just the technical communicators' fight. And what is at stake is not just freedom of information. This is the world's fight. This is civilization's fight. This is the fight of all who believe in meaning and clarity, in the completeness and accuracy of the printed word.

Join Us in this Fight
We ask every end user and office worker to join us. We will ask, and we will need, the help of management, developers, salesmen, quality assurance workers and marketers. We are grateful that many companies and many organizations have already responded -- with sympathy and with support.

These others know a basic truth - an attack on an information developer is an attack on all workers.
The civilized business community is rallying to our side. They understand that if information confusion goes unchecked, that their own documents, their own companies may be next. Info-terror, unanswered, can not only bring down the documentation department, it can threaten the stability of legitimate companies. And you know what -- we're not going to allow it.

Know Your Expectations
Ordinary workers outside of the technical communication profession are asking: 'What is expected of us?' I ask you to work with the technical communicators, tell them what you know, show them your work, and let them create their documents. I know many of use have fears tonight, and I ask you to be calm and resolute, even in the face of a continuing threat.

The thousands of technical communicators who are now at work in this fight may need your cooperation, and I ask you to give it. I ask for your patience, with the delays and inconveniences that may accompany developing new documents and implementing new content management systems; and for your patience in what will be a long struggle.

Fighting for Our Values
I ask all technical communicators to uphold the values of clear communication, and remember why so many of us are in this profession. We are in a fight for our principles, and our first responsibility is to live by them. Non-writers should not be singled out for unfair treatment or unkind words because of their business background or poor spelling.

I ask your continued participation and confidence in the information development process. Info-terrorists attacked our documents. They did not touch their source. Technical communicators are successful because of our hard work, creativity, and enterprise. These were the true strengths of our profession in previous years, and they are our strengths today.

Thanks to All
Tonight I thank my fellow technical communicators for what you have already done and for what you will do. And ladies and gentlemen of the STC, I thank you, your representatives, for what you have already done and for what we will do together.

Tonight, we face new and sudden challenges. We will come together to improve documentation, to dramatically expand the number of information developers, and take new measures to protect the accuracy of our work. We will come together to promote usability and keep our documents accurate and timely.

Coming Together
We will come together to give technical communicators the additional tools they need to track down missing or incomplete information. We will come together to strengthen our capabilities to know the plans of info-terrorists before they act, and find them before they strike at our documentation. We will come together to take active steps that strengthen our profession, to create new opportunities, and to put our people back to work.

After all that has just passed -- all the missing, incomplete, inaccurate and poorly organized documentation -- it is natural to wonder if our future is one of fear. Some speak of an age of confusion and the deliberate hiding or destruction of information. I know there are struggles ahead, and dangers to face. But this profession will define our times, not be defined by them. As long as technical communicators are determined and strong, this will not be an age of confusion; this will be an age of information access, here and across the world.

We Will Not Fail
Great harm has been done to our content. We have suffered great loss and mismanagement of information. And in our anger, we have found our mission and our moment. Confusion and clarity are at war. The advance of human knowledge -- the great achievement of our time, and the great hope of every time -- now depends on us. Our profession -- this generation -- will lift a dark threat of uncertainty from our people and our future. We will rally the world to this cause by our efforts, by our courage. We will not tire, we will not falter, and we will not fail.

It is my hope that in the months and years ahead, our documents will evolve to higher level. We'll go back to our work and routines, and that is good. Even anger recedes with time and grace. But our resolve must not pass. Each of us will remember what has happened, and to which projects it happened.

Never Forget
I will not forget this wound to our profession or those who inflicted it. I will not yield; I will not rest; I will not relent in waging this struggle for freedom and security for clarity, consistency and completeness of the world's informational content.

The course of this conflict is not known, yet its outcome is certain. Clarity and confusion, structured and unstructured documentation, have always been at war, and we know that nothing is neutral between them.

Clarity Will Prevail
This conflict was begun on the timing and terms of others. It will end in a way, and at an hour, of our choosing. Whether we bring our enemies to clarity, or bring clarity to our enemies, clarity will be achieved.

My fellow communicators, we'll meet confusion with patience and hard work -- assured of the rightness of our cause, and confident of the victories to come. In all that lies before us, may God grant us wisdom, and may He watch over all of our documentation.

Read More

Salary Negotiation

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…

Read More

Interview Questions - Part V - Conclusion

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:

	Warfare	Job interview
Objective	To win the war.	To win the job interview.
Strategies	Weaken and confuse the enemy. Overwhelm them with force.	Show the interviewer your strengths. Position yourself as a problem-solver. Show how you are unique and a good match for the position.
Tactics	Eliminate the enemy's leaders to create chaos. Carefully position all your divisions. Bomb the enemy's factories, bridges and roads. Capture the major cities. Continually rotate your troops to wear the enemy down. Cut off the enemy's supply lines. Destroy the enemy's communication system.	Practice interview questions. Prepare a one-minute summary about yourself. Be able to list several examples of your accomplishments. Bring a portfolio of your work that graphically illustrates these accomplishments. Appear confident and interested in the position, but not desperate. Show how you lowered costs and improved efficiencies. Tie the job description to your skills, point by point.

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.

Read More

Interview Questions - Part IV

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.

Read More

Interview Questions - Part III

This month, we continue our series on interview questions.

Where do you see yourself 5 years from now? 10 years?
The dreaded "crystal ball" question. Many of us have trouble knowing what we'll be doing 5 months from now, let alone 5 years. (By the way, a wrong response to this question would be to say to the interviewer: "Doing your job!")

A good way to handle this question is to turn it around by asking what opportunities will be available in the time period specified. From that, you can base your response, and say something such as: "It appears you're heading towards a more XML-based environment. XML is definitely an area that I'd like to be involved with."

Your response also depends, of course, on where you are now. There is no absolute standard on what constitutes a junior, intermediate, or senior technical writer, but the following guidelines are a start:

• Junior writer: 0-4 years experience
• Intermediate writer: 4-9 years experience
• Senior writer: 10+ years

So, if you're a junior writer, for example, you might want to say that you are planning to handle the larger and more complex projects that an intermediate writer would be expected to manage.

Who makes a better technical writer: a technical person who has learned writing skills, or a writer who has learned technical skills?
This is an actual question I've been asked. At first glance, you might be tempted to answer this question depending on which type you are: a technophile who's learned writing or a writer who has learned technology. You'd assume that you would defend your particular background versus the other type. But if you did, you might fall into a trap. Some interviewers will have strong opinions on this question - they will honestly believe, rightly or wrongly, that one type is favourable to the other. You want to avoid expressing an opinion that might be the polar opposite of the interviewer's.

The truth is that people from either backgrounds can make good technical writers, and this is true for most "hybrid" professions. For example, a medical illustrator may have started out in the medical profession, and then learned illustration. Another medical illustrator may have started out in art and design, and then become interested in medicine. It would be impossible to determine solely from these facts who is the better illustrator: you'd have to look at their portfolios to see.

This is the point to make in responding to this question: that either type of writer has their strengths and weaknesses, and ultimately the only way to judge these writers is on the quality of their work.

You might briefly emphasize how your particular background has helped you, but don't paint yourself into a corner by dismissing a particular type of writer.

Do you prefer writing from specifications or writing based on actually using the application?
Generally, the correct response is "the application". Employees will hope that you become an expert user in the product itself, so that you can more accurately document what a typical user would need to know.

However, keep in mind you may not always have access to the application as early or as frequently as you'd like. Therefore you may want to add that you can use specifications, white papers, product descriptions, marketing documents, use cases and other internal documentation to get a good head start. Then, once you have access to the product, you can flesh out your documentation, verify it and fill in all the missing pieces. As many of us our painfully aware, the final, released product is often very different from its specifications!

What is the purpose of technical communication?
This is such an obvious and general question that it's hard to believe you would actually be asked it, but in fact, this is another question that I have been asked. Note that a wrong answer is: "to keep technical communicators employed"!

Initially, you might think the answer would be something like "to instruct the reader on how to use a product". That may be true, but then you have to ask yourself - what is the purpose of instructing users through documentation? The answer to that is: to reduce technical support costs. From a business perspective, this is the reply you should give. If possible, show how your documentation has done this. Maybe you created a troubleshooting section that helped users identify and fix common problems. Perhaps you added missing content or updated an index to make it more comprehensive.

Companies hire technical writers not out of the goodness of their heart, but because the alternative is unthinkable: users constantly calling technical support for every single possible question. By indicating that you're aware of how critical it is that documentation be as complete and accurate as possible, and thereby lowers support calls, you show that you recognize the important role documentation plays in minimizing costs and thereby maximizing profits for the company.

Read More

Interview Questions - Part II

This month, we continue our series on interview questions and strategies for dealing with them. And the first question is…

List three of your greatest strengths.
This is a difficult question because many people are quite modest and don't want to appear boastful. The key here is not simply to list your strengths but to show how they are valid by including specific examples of them.

For example, don't just say that you write from the end user's point of view; state how you do this.
You could say that you discuss in detail with business analysts and product managers who your typical users are, their technical abilities, how much training they will have, and ultimately what they will be using the documentation for, and develop your documentation accordingly.

To develop your list of strengths, you need to carefully examine yourself and the projects you have worked on, and derive a list of the positive qualities you have used when managing these projects - these may include qualities such as:

• the ability to lower costs creating documentation that reduces the number of technical support calls
• the ability to improve efficiencies by merging duplicate documentation and using conditional text to distinguish multiple versions
• demonstrating innovation and creativity by taking the initiative to improve the layout and design of documentation templates

What is your greatest weakness?
The antithesis of the previous question, and also a difficult one to answer. Most experts suggest stating a weakness but then giving it a positive spin by indicating how you compensate or learn from it. For example, you may say that you sometimes find it stressful to rush to complete a project when there is not enough time. As a result, you have developed a good system of creating a documentation plan with specific tasks and dates, and ensuring that you and others follow this plan to avoid a last-minute rush.

How would your boss (or co-workers) describe you?
Ouch - a nightmare question. Often we may have no clue what others think of us - we hope they like us, but it is impossible to know for certain, which makes this a very loaded question. Some of the qualities you list may be among your strengths discussed previously, but you should try to state those qualities that emphasize you are a "team player". For example, you could say that others would describe you as friendly and approachable, and then give an example where you worked with others to solve a problem or meet a deadline.

Tell me about a time you failed.
Another question from hell. Always have one or two stories ready about a project that did not go as well as you'd hoped. Then describe what you learned from the experience. For example, you may talk about having to release a document only to discover later that due to time constraints, certain procedures that should have been documented were missing. As a result, when you had time, you later reviewed the application and included all of the missing procedures in time for the next release.

By the way, this is a great example of a "stress question". The interviewer is looking not only at the content of your response, but the way in which you respond. It is critical to remain unfazed and to answer the question slowly and clearly. The interviewer is trying to trip you up to see how you respond under pressure - recognize this is part of the game and remain confident.

What do you like about your job? What don't you like?
Most technical communication jobs involve similar activities, so it should not be to difficult to find tasks and responsibilities that exist in both your current (or former) job, and the one to which you are applying. Therefore, try to list two or three things that you enjoy doing in your job which you know that the job in question also entails.

For example, if the job involves working on a wide variety of projects simultaneously, and that is what you are currently doing, then mention that, and say you enjoy this kind of variety. Other tasks you may list could include working with certain tools, using and testing the application you are documenting, creating indices, and so on.

Describing what you don't like is a bit tougher. It's probably not to advisable to say "I don't like the fact I have to be at work every day!" Recognize this is another form of the question "What is your greatness weakness?", your weakness being that you do not enjoy putting up with some aspect of your work.

Again, the strategy is to state how you deal with this weakness and learn from it. For example, you may say that it's frustrating if critical information that could affect the documentation is not being passed on to you. Because of this, you make an extra effort to stay within "the loop" and ensure that you are getting all of the information you need, by keeping in continual contact with your SMEs.

Read More

Interview Questions - Part I

Happy New Year! This year, we'll start looking at specific interview questions and some good strategies for responding to them. Many of these are actual questions that I have been asked. Although there is never only one right answer to a question, there are effective methods that can help guide you in your response.

Some general principles to keep in mind when answering questions are:

• Think carefully before you speak - if necessary, ask if you can respond later. But note that the more questions you have practiced your responses to, the less likely you will have to ask for more time.
• Give short, clear, direct answers; 30-45 seconds is usually enough. Less is often more.
• Speak slowly and clearly - it's very easy to talk quickly when you are nervous - remember it's the not quantity of what you say but the quality.
• Always be honest - never lie, embellish or distort the facts - eventually it will catch up with you.
• If you don't understand the question, say so. Rephrasing the question back to the interviewer is a good way to clarify its meaning.

Now - on to the questions:

Tell me about yourself.
This is probably the world's most dreaded interview question, because it is so open-ended and vague.

To properly answer it, you have to understand that this question really means: "Tell me about yourself in relation to this job, what is you have done, what you are doing now and what you hope to do in the future, to show me that you would be the best person for this job."

You need a solid response to this question that nearly sums up your history and abilities, for example:

"I'm a technical writer with six years experience working on a wide variety of projects from user manuals and online help to technical and installation guides. I've also been involved in product design and have submitted many valuable product enhancements. I enjoy the whole process of creating documents that are accurate and helpful to the end user. Eventually, I hope to become more involved in the area of content management, which can greatly reduce costs by eliminating the duplicate information within an organization."

You should also mention the specific tools that you have used, especially if they are the ones required in the job.

Name three things you like about technical writing.
I was once asked this question, and admit I had a tough time answering it! Everyone will have their favourite activities, so practice stating what these are so that you have an eloquent response, in which one activity flows neatly to the next, for example:

"I enjoy the process of gathering the information required to create a document, including meeting with the subject matter experts, reviewing the technical material and using the product itself. Next, I like the process of organizing and "translating" this highly technical information into a comprehensible format. It's very intellectually satisfying knowing that I have created something orderly and meaningful out of chaos. Finally, I like the process of continually improving the project, both before and after it is complete. I feel that there is always room for improvement and welcome feedback from others."

This response shows that:

• you genuinely enjoy what you do
• you have a sincere desire to make a quality product
• you are willing to accept suggestions from others and be a team player

Why are you interested in this position?
One of the most important questions you will be asked. You can only answer this question effectively if you have:

1. Analyzed yourself and thought about your skills and what you like to do.
2. Carefully studied the duties and responsibilities of the position itself, and studied the company and its "personality".
3. Demonstrated how there is match among all these things: you, the job and the company.

In otherwords, you must state how there is a harmony between:

• yourself, your personality, your skills, the things you enjoy doing
  and
• the job, the company and the people in it.

The more you can show how similar these things are, the greater your chances of success. You must show how you were "born" to do this job, at this place, at this time, and that it represents a great opportunity for both you and the company.

Here's a sample response to this question:

"I'm very interested in this position because it would allow me to continue using the skills that I enjoy the most, namely - using FrameMaker to create complex but well-organized documents for a software product, and scheduling and prioritizing a wide variety of projects. Also, this position involves testing the product and giving feedback, areas that I think are particularly important. I'm very much a "user advocate" and in my current position have submitted many suggested changes for screen, field and button names, dialog box messages including error messages, and screen design and layout, all of which made the product easier to understand and use."

The point you want to make in your response is that you are a professional communicator who brings a unique outside perspective, and who is genuinely enthusiastic about this position because it matches your skills and desires.

We'll look at more questions over the next few issues.

Read More