2009 Tools Survey

From http://www.writersua.com/surveys/tools09/index.html:

“Which tools do most of us find useful? Which tools provide us with the most satisfaction? This portion of the survey supplies you with a peer review to assist you in planning your tool acquisitions…”

“Note: Past surveys had consistently shown that well over 90% of respondents use Microsoft Word. We left Word off the survey to make room for other UA-specific tools.”

Which Course or Certification is the Best for a Fresher Looking to be Technical Writer?

Someone asked me a question that I felt is the most FAQ:

Courses in Tech Writing – Your opinions solicited!

Hi, Nowadays I see more than one company/school offering certification courses on Technical Writing. Would it be wise to advocate any of these courses to a fresher?

Any tips, opinions, thoughts, on which courses might be better? Any tips, opinions, thoughts, on which courses are best avoided?

Any other suggestions I can give to an interested fresher?

Any related experiences to share?

I don’t think any of these courses are necessary to be a technical writer. I feel the courses are “nice to do,” but not essential. Because, an employer often hires a candidate based on a lot of other things than just the experience and the knowledge of tools.

A fresher or otherwise, the candidate must have great written and oral skills in English (no matter which degree or certification) apart from positive attitude and quick learn-ability. I’d rather practice writing well and learn the language.

Then, the person shot another tricky scenario:

I myself never took any related course. But I was fortunate to find someone willing to hire a fresher!

I am looking at openings posted online for a the last couple of months. There is no dearth of openings, but there’s exactly one opening that says “freshers welcome”. Everyone else wants at least 2-3 years of experience. In this scenario – I was wondering if having a “certificate” helps.

Fresher vs. experienced – that is the dilemma everyone faces! Best way is to write as much as possible (blog and different types of documents – your samples are often sought during the interview process). Apply for the jobs even if you don’t have the experience, and wait for a call patiently. There are still a few employers who don’t care for the experience, if you prove you can write well. By all means, go for the certification if you can afford the money and the time.

Remember, the first sample of your work is your resume!

All the Write Moves

According to the Newton’s theory of inertia, an object remains in its current state unless acted upon by an external force. This tendency to remain in the current state is called inertia, which also translates to inaction and lethargy. No, this is not a physics paper. I was thinking why the technical writers would choose to move to a new role: this article reviews common reasons (why move), and discusses practices (when and how to move) to sustain consistent growth in one’s career and insulate it from potential layoffs. Be warned, the topic is emotional and so is this article.

Why Move?

Now, let’s identify the forces that act upon your career and force you to break free of inertia, by choice or otherwise. There are no prizes for guessing the biggest factor – growth in terms of role, payment, and recognition. Whether you’re in your first job or trying to befriend the board of directors of an organization for the CEO post, seeking growth is as universal as looking for a good spouse. The difference, everyone knows the latter is just too much to ask for!

Change is the only constant thing. It’s no different at work. No matter how well you stick to a routine, there are always surprises. The comfort zone is shrinking – the product you’re documenting is scraped without notice, cost-cutting measures are announced, co-workers leave, and so on. At some point where you cannot cope up with the pace, you may begin thinking about moving. That’s when you’re caught in a ripple effect – you lose interest in your current role, it affects your performance, you’re looking for a new role (often outside of your organization), and finally, things don’t work out any longer. Then, you’ve to move – there is no looking back.

When to Make a Move?

There are no rules to decide a good time to move to a different role. However, if your answer to any of the following questions (symptoms) is yes, it’s probably time you start thinking about it. Of course, if you really enjoy your work and none of these questions bother you, then you may stay put – you truly belong to a rare species!

• Are you too good at work (you’ve received multiple awards)?
• Have you learnt and done it all (you get bored of your work or you’re able to finish it quickly)?
• Have you been in the current position for far too long (everyone knows you and your work)?
• Do you have a burning desire to learn something new or work on a particular thing (experiment with too many software or tools, you browse through forums and RSS feeds all day long)?
• Is there an interesting role you wish to pursue (you like someone’s work)?

Now, How to Make a Move?

You’ve made a decision to move and you wonder how to deal with the next things to do. How about going through the pointers below? The pointers help you shortlist interesting roles and provide you with a few means to decide on the exact role you wish to pursue. In the context of assuming a new role, you may notice some of these pointers also guide you to excel at the new role, and avoid being laid off to a large extent.

Choose a Field (Domain)

Choosing your field of work is crucial. No matter what position or role you assume, you may find it hard to survive for long if the chosen field is not to your liking.

New field: Assume that for most of your career, you’ve been documenting engineering products. Just because an online software company has a huge market share, would you want to be hired by that company? You may be out of place, fighting for survival, while documenting products based on Internet technologies.
Better approach: On the other hand, assume that you had been learning and volunteering some of your efforts to document software while you were with the engineering company. You may do well if you’re hired by the software company. Your manufacturing domain experience may actually be an asset.

Related field: Continuing with the same example, after a while, you would be a specialist in documenting software products. You now have an option to choose a role of documenting hardware products that run on software. You primary role may not change. You may find such opportunities in your current organization or externally, in which case, you would move laterally.

Follow Trends

Most of us are deterred by the exponential spread of information and are intimidated by its magnitude. Fortunately, there are simple tools to work your way around it, and with a little effort, spot clear and emerging trends. Yes, anyone can analyze the market and crunch data. You just have to look for it – it is begging to be used to make informed decisions. Why follow the trends? The idea is to be at the right place (role, domain, company) – at the right time, as often as you can.

Try this: Google search for keywords like technical communication, writing, help authoring tool, documentation, and so on. Grab top ten results that show up and dig deeper – most of them point to many related blogs or portals. In an aggregator (such as Google Reader), subscribe to as many RSS (or atom) feeds as you possibly can. Go to the top level and view the topics of all subscriptions. Notice the common keywords and the direction of topics.

Though you do bump into speed breakers, or junk, more often than not, you’re bound to see the big picture. Consider this: you’re consolidating news, ideas, views and all other types of content from all over the world in one place. For example, the content comes from vendors developing documentation software, companies and managers buying the software, industry groups making standards for the future, and above all – from several other professionals like you who are ultimately affected for the good or otherwise. Isn’t it amazing what you could do with little thoughts and ideas?

Sharpen Skills

With trend analysis over a period of time, you get a sense of in-demand skills (tools, domains). However, the fundamental knowledge always remains as essential as ever. It is, therefore, important to identify and aim to get a good grip of fundamentals, as well as be in sync with the next big thing. Always sharpen your skills regardless of whether you working, or otherwise.

When I’m reading a blog or a book review, I often read the profiles of the authors upfront. I do the same thing with published articles, especially, the Intercom and the Technical Communication Journal. In the STC publications, the brief bio of the authors mentions their current and past roles, education, honors and achievements, and a reference to their websites or blogs. In the case of the journals, there is also a list of referenced works. For me, that is a ton of information about successful professionals, how they shaped their careers, and their fields of interest. Many of them are my role models – I just have to choose and follow something that interests me!

Shortlist and Experiment

There is no sure method to choose from the various roles that interest you, and there is no such thing as a perfect role. The only best way to find is to experiment rapidly, and eliminate choices that don’t excite you. Some things you can do to get the feel of the role and the tasks involved:

• Get your hands dirty; download trials; work on it (write documentation, setup content management system, and version control).
• Discuss with professionals (forums, groups, and blogs).
  • Know the pros and cons.
  • Know the potential career growth paths.
• Find potential impact of recession (identify trends and news).

Making the Write Move

You’re the best person to make decisions for yourself. Read as much information and talk to as many people you wish to, but don’t let anything influence your decision. Nobody knows you better than yourself, isn’t it?

Well, it seems to be an era where the Jacks of all trades flourish and do well. Being a specialist certainly has its merits, but greater risks and isolation. It doesn’t seem like a good time to place all your eggs into one basket, neither is it wise to have eggs all over the place. Rather, be a specialist at one or two things (tools, language), and be familiar with four to six other things (online help, domains, open source) that are doing well in the market. It certainly looks like we’ve too many eggs on our plates! In my friend Panda’s words, we cannot change the world; we’ve to change ourselves.

Too Many Inputs Freak Out the Technical Writer

How to track and address inputs from multiple sources.

Sources of Inputs

No, this isn’t the case of ‘Too many cooks spoil the broth’ – because the technical communicators are not supposed to ‘spoil the broth.’ They’re expected to accept, make sense, and use information at all rates of traffic, and by all means. Figure 1 gives you an idea of the various sources of inputs.

Figure 1: Sources of Inputs

Accuracy, quality, and sometimes, speed are non-negotiable. In such a scenario, this article presents some of the practices that have helped me track and address inputs effectively – regardless of their volume and criticality.

Get Organized

Technical communicators have no control (well, almost) over how and when the inputs are received. However, they can exercise complete authority over how and where the inputs are organized. Most inputs manifest in the form of e-mails (messages, attachments), files hosted on community sites, discussions (meetings, presentations), or ad hoc notes.

For quick and easy access, identify, separate, and mark the inputs as and when they arrive. For example, in Microsoft Outlook, the e-mails could be moved to exclusive PST folders. The files and notes could be stored in a single folder (with sub-folders for each project or source), whose shortcut is placed on the Desktop or Quick Launch. The intent is to consolidate the inputs at minimal places (2 or 3) and to know how to access them – eyes closed (you know what I mean!).

Get Your Act Together!

Before working on the inputs, it is imperative to understand your deliverables and their scope. Question your manager, project lead, and/or the subject matter experts (SMEs). Ask a lot of questions; never assume. Find out if you are expected to include information from all the inputs. If there are seemingly ambiguous, conflicting, unimportant, or excess inputs, get them clarified. Ensure the right expectations are set and key stakeholders are on the same page. At this point, any unusable inputs are fairly filtered out.

The following lists briefly describe key actions to process the inputs systematically, so you neither have to remember nor forget to work on any of the inputs.

Think – be creative:

• Group similar tasks.
• Seek and negotiate (where possible) specific deadline/priority for each group of tasks. If needed, re-group the tasks to reflect the agreed deadlines/priorities.

Plan – mark tasks for actions:

• Don’t try to remember anything – the deadlines, priorities, or groups of tasks. Use tools such as Microsoft Outlook (or an Excel file).
• Categorize the groups of tasks. For example, in Outlook 2007, you can mark a high priority group with red category. Groups that can wait could be marked yellow. Inputs that are not sure to be useful could be marked purple.
• Set reminders for each group. For example, in Outlook, you can create a new Task and set a reminder. It could also act as a place holder for collecting any particular information to be used at the time of documentation.

Execute – focus and work with no distractions:

• At the start of each day, be clear what you’re going to work on. Work in sessions of not more than an hour each. As you finish or wait for clarifications/review of each task, mark it as completed (clear the category) or waiting (mark it to blue category), respectively. Move on to the next task in the queue.
• Take breaks between sessions. Research/learn for 30-60 minutes on topics of professional development. Participate in communities. You get the satisfaction of doing your work, and more.

What Works for You

The suggestions in this article may or may not work for you. However, you do get an idea of dealing with a ton of inputs and how not to miss any of them amidst tight schedules. Choose what works best for you and your deliverables.

Of course, in the real world, there are more unplanned activities cropping up than you may wish to deal with. Accept and endure them. You made a choice to be a technical communicator, so you better get organized!

Daily Encounters of All Kinds

[This article has been published in MITWA News, January 2009 edition. It is available for the members of MITWA Yahoo Group at http://groups.yahoo.com/group/MITWA.  Click here to view the article.]

How Technical Communicators can deal with frustrating moments at work.

One of the topics at STC India’s 10th Annual Conference in Pune dealt with the emotional train of thoughts that the Technical Communicators ride on during their daily activities. This article presents further commentary about the same subject.

Oh, God!

Did you go crazy at the last-minute inputs to be included in the documentation? Did you doubt your proficiency of English writing skills when you saw the numerous editorial scribbles on your document? Did you throw up your hands when your documentation set had the review comments ‘incomplete, inaccurate’ ? Did you give up trying to convince your seniors about organizing the content the way you think is better? Have you wondered why your team is using the mainframe-age tools when the World has moved on?

Understand Your Scope

All in a day’s work, isn’t it? Well, in the movie Seven Years In Tibet, the young monk says, ‘There is a saying in Tibet. There is no use worrying about things that have no solution. There is also no use worrying about things that already have a solution.” Seems contradictory? Think again. Like with everything else in life, you need to focus your attention on things you can do, and try to live with things you cannot control.

Once you identify the things beyond your control, you would probably worry less. The same goes for events that occur outside your scope. For example, if your work is reviewed as inaccurate and/or incomplete, it doesn’t mean you’ve failed alone. The inputs from the Subject Matter Experts (SME), the delay in receiving the inputs, technical reviews – all of them have failed to a degree. Perhaps, the next time, you could ask better questions to SMEs to gather better information. You could fix deadlines for sending inputs.

Accountability

The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.

Likewise, the Technical Communicators are the owners of documentation. You need to account for your deliverables. Across cross-functional teams, you may not like the way certain individuals or processes work. If you cannot get along with someone, try to maintain professional decorum. That is fair enough, as not everyone can be your buddies.

Customer Focus

What you need to understand is everyone is mandated to work with customer as the focus. All the teams function for a better deliverable to the customers. If you get this fact right, you’ll probably understand why the editor, being ever so unpopular, still goes about his/her job, diligently. You might also not squeal at the last-minute changes, knowing that they ultimately benefit the customers.

May I Help You?

[This article has been published in INDUS, December 2008 edition at http://indus.stc-india.org/. To view the article, browse to the bottom of the page for a list of articles or go to Viewpoint > May I Help You?

You can also view my permanent copy at Google doc.]

Leveraging Product Technical Support Teams to Improve Documentation

Write in Exile

Whether you are working in a traditional or new age environment, technical documentation needs to traverse through the usual grind of user and task analysis, multiple drafts, and review cycles. This grind leaves little or no scope for technical communicators to receive or address customer feedback. Let’s admit it, most of us work in exile, away from the customers who matter the most, for whose cause we toil away day in and day out.

Customer Speak

Customers often seek help and provide feedback about a product by various means. Organizations have product technical support teams in place that are the first point of contact and have the onus of resolving issues. It is clear who is more aware of the problems faced by customers and who learns about them first. The support personnel listen to or read about customers pointing errors, asking how to use certain features, enquiring whether something works or why not. In most cases, each customer interaction is assigned a reference number, and a repository of most such interac tions is maintained.

Leverage and Collaborate

The problem repository is indeed another vital source of content for the technical communicators. It only makes sense to leverage this existing setup. A collaborative environment should be built where technical communicators have a constant dialogue with the customer-facing personnel. A seamless process should be incorporated in to the documentation life cycle, wherein all relevant customer problems are identified and documented.

The support personnel should ideally review the documentation drafts as early in the game as pos sible. They should be part of the review cycles as a norm and provide inputs directly to the techni cal communicators. The content could then be reviewed for accuracy and validity by subject matter experts.

What is the Gain?

Table 1: Improved Documentation

Direct Impact	Overall Impact
Accuracy of content	Higher customer trust and satisfaction
Focus on key topics and FAQs	Meaningful organization
Lower undocumented topics	Higher coverage of content
Lesser number of reviews/revisions	Quicker delivery time Better utilization of resources
Lower problem requests	Cost reduction

Own and Drive

The world is not perfect and neither is the workplace. You could find resistance from several quarters and be tempted to give in to the pressure. Of course it’s impossible to document everything, right?

However, you could always try. As content owners, the onus is upon the technical communicators to drive quality and usability of documentation. In the process, you may as well capture tangible results for your work. Perhaps, a low customer problem count is in order.