Is Age a Barrier for Technical Writers?

Is age a barrier when hiring technical writers? Well, the answer is—it is and it is not!

When hiring experienced writers, age is definitely not considered. When hiring someone without previous technical writing experience, age sometimes becomes a selection criteria. One of the reason is because after other experience, the expectations of the candidate is much more than a fresher who is relatively younger and inexperienced.

Most of the times, organizations are ready to take in people with no related experience in junior positions and might offer a salary relative to their relevant experience and skills. Those seeking a job may not be able to accept the fact that after being experienced, they are considered to be on the same level as the trainees.

In such a situation, ask yourself if you possess the skills required for this job? Do you have the relevant experience? Why should the organization pay you for the skills and the experience you don’t possess? This will give you an answer why you are recruited at an entry level. You need to be exible and mature in terms of understanding and accepting your limitations. If you are comfortable working with youngsters, in a junior position, for a lesser salary (probably), and if you are con dent of using the skills of your prior working experience to your advantage, age doesn’t really matter.

On a personal perspective, age limit is more of a mental state than physical. If you are eager to learn and grow in the team starting from the basics, age is not a constraint. For that matter, age is not a barrier in any eld if you have the right attitude and if you are mentally and physically fit for the job/work.

Advertisements

Problems in Materials Written by Non-writers

Many organizations involve the development engineers to prepare documentation for various reasons—because of limited resources, time constraints, or probably because they don’t understand the importance of documentation. Some of them feel that the engineers know the product/application better than anyone else, so it is better if they create the documents.

Example: The following are some of the prize-winning entries for the Worst Technical Writing Contest held by Metamor Documentation Solutions.

  • Warning label on the side of a cash register:  Before disconnecting, disconnect the connecting connector.
  • The text found in a reference manual of a manufacturing software: To add a part, use Add a Part. Note that you cannot delete a part using Add a Part. To delete a part, use Delete a part.

The trouble with writing is that there are no hard and fast rules or any magic formulae that make it an easy step-by-step task. The truth is, inspite of referring to style guides and procedures to create manuals, you have to re-conceive the rules every time you write because every occasion has its own specific set of requirements and problems. In such situations, the SMEs cannot make a right decision.

Some of the problems in materials written by non-writers are as follows:

Not Communicating What is Required: Click here for details

Lack of Audience Analysis: Click here for details.

Poor Presentation: The most common errors the information presented by untrained technical writers are:

  • Long and complicated sentences, even if they are grammatically correct.
  • Use of lengthy, crammed, and dense paragraphs:
    • When the information should be in a bulleted or numbered list.
    • Where a labeled figure or illustration would have explained the information.
    • Where a table would have done more justice to the job.
    • Lack of white space.
    • Lack of consistency. It is an important factor as it helps to avoid confusion

Poor Organization

The document may be complete and accurate, but it is useless if the users cannot find what they need, when they need it. This happens because the information is not organized properly. The most common errors in organization of information are:

    • Steps are not organized in logical order.
    • Inability to identify between essential and optional information/content.
    • Information not organized in logical and sequential flow.
    • Inappropriate navigational aids, which do not help the users in nding the required topic easily.
    • Section headings not used to logically separate information.
    • Unclear and vague heading (not appropriate to the text it deals about).
    • Sections not describing an idea or concept.

It is extremely easy to recognize a poorly written and badly organized documentation. But, it is equally difficult to prevent it, unless it is done properly.

Working in a Documentation Team

In contrast to the single writer scenario, the numbers of writers in a documentation group usually range from 2 to 20 and even more. In India, the documentation team usually consists of technical writers, some of them doubling up as editors and illustrators as and when required. Every working scenario has its own advantages and disadvantages.

Advantages

The advantages of working in a documentation team outweighs the disadvantages. On a parallel comparison, the disadvantages of working as a lone writer translate into advantages of working in a team and the vice-versa. The advantages of being a part of the documentation team are:

  • Opportunities
    • The writers get opportunity to work on different technologies products, tools, and domains.
    • Tasks, projects, and assorted responsibilities can be interchanged or can be worked on in rotation. Writers can choose and work on their areas of interest (editing, graphics, training, etc.). This reduces monotony.
    • Writers can get involved in peer editing, reviewing, and proofreading.
    • Team members are available for peer reviews, peer edits, process and/or tool innovation, knowledge sharing, etc.
  • Uniform standards and processes
    • You can follow a streamlined documentation process in the team.
    • Writers get involved in decision making activities regarding the processes and stylistic issues.
    • It is possible to enforce a formal technical review process.
  • Growth and progression
    • The hierarchy in a team clearly defines roles and responsibilities and allows career growth.
    • It creates an environment for helping and mentoring. Senior writers will be able to take up more responsible roles.
    • Writers have an identity which greatly improves their self-esteem and in turn, their efficiency and productivity.
    • Projects can be allocated based on the expertise and experience of the writers.
    • Team work provides a nurturing environment which is required for logical and professional progression.
  • Knowledge sharing
    • The writers can share knowledge which allows them to stay connected and are up-to-date and consistent in the job skills.
    • It allows interaction with other writers, giving an opportunity to share information, knowledge, and expertise with team members.
    • Writers get the opportunity to share opinions about writing, process, usability, content organization, and presentation.
    • This increases not only the product and domain knowledge, technical writing skills, and knowledge about various tools.
  • Support from the documentation manager
    • The documentation managers can judge the skills and performance of a technical writer better than a product and/or project manager. Product or project managers may overrate or underrate the writers.
    • Managers or team leaders will try to ensure that a writer gets due recognition.
    • They can create opportunities for promotions and recognition. This way, technical writers can also attain a well-deserved professional status and identity in the organization.
    • They can help facilitate training and performance recognition.
    • They help in participation in events that involve local and international peer groups, such as STC.
    • In case of an issue (slipped deadline, personal tiffs, ego clashes, etc.), the manager has the authority to take the necessary/corrective action.

Advantages

The disadvantages of being a part of a documentation team are:

  • Some managers may enforce projects on technical writers without taking their opinion about it. So, there is a risk that the writers might not like the projects assigned to them.
  • Sometimes there can be ego hassles and clashes between the team members.
  • Favouritism can also occur (this can happen in any work environment) thereby hampering the future prospects of eligible and talented writers.
  • Team work requires strong interpersonal skills and team spirit. So self-cantered individuals will find it difficult to work in such environment. They may also make the other lives miserable.

 A big documentation group is lead by a documentation manager and each project or product line is lead by a team leader or a project leader. If the documentation group is small or if it is a part of another group, then the team leader or the project leader may lead the group. On the whole, having a documentation team is beneficial. Minor disadvantages can easily be overcome.

Working as a Lone Technical Writer

A survey of the job scene in India states that there are many organizations that have only one technical writer. We can call this as the single writer scenario.

Advantage of Being a Lone Writer

Being a single write is extremely challenging and a very crucial position.

  • You get the opportunity to shoulder the responsibilities of planning, writing, editing, and other activities/tasks related to documentation.
  • There is no scope for ego clashes.
  • You may ample learning opportunities as there is a wider scope of work.
  • It is good for those who prefer working alone:
    • Some people find it easier to work alone than in a team.
    • Some others like to work independently with no one to compete with.
    • Yet others like to be on their toes all the time and do all the tasks themselves.

Disadvantages of Being a Lone Writer

Being a single writer is challenging as, but it also has some disadvantages which translate into advantages when working in a team.

  • Apart from writing, you also have to take up the responsibility of planning, quality testing, editing, etc. You will have no backup or a helping hand for these activities.
  • You are expected to do the tasks you are responsible for and take on more.
  • Your performance may not be gauged appropriately.
  • There may not be anyone to peer-edit and proof read the documents for accuracy, language, style, and format.
  • You may miss the opportunity to share best practices in technical writing.
  • It may become difficult to implement documentation processes, just for one person.
  • You may be a star performer, but there will be no benchmark to compare your performance with.
  • You have to handle different projects at various stages of completion on your own. It brings in a lot of pressure, stress, and tension.
  • You will have to undergo a lengthy learning curve. You will have a tough time if you are expected to create standards, processes, project plans, self-edit, figure out the training requirements, communicate with engineers in the product development/quality teams, etc. to name a few.

Working with Developers

Many technical writers work in organizations where in their contributions are not understood. Their work is seen more as a luxury than a value-added to business. This develops a lack of respect which is shown in many ways:

  • Disinterest in sharing information for creating the documentation.
  • Disinterest in reviewing the documentation. But, do not to equate lack of time to lack of interest. They are two different issues altogether. Not getting to know, or see, or use the changes to the product until late in the development cycle. There should be a reasonably sufficient time between the code freeze and the final draft of documentation.
  • Writers are pressurized to produce quality document without enough staff.

This scenario can be changed by educating the engineers/developers, improving the quality of documentation, reducing the support calls, and by improving the overall documentation process and practices.

Understand Them

It is very important to think from the point of view of the developers. You should understand that the engineers/developer/programmer also work under tight release schedules and unrealistic demands. The SMEs expect you to:

    •  Be curious about the product you are working on.
    • Educate yourself about the technology/functionality you are going to work on before approaching them for information.
    • Understand and appreciate their tight schedules and give them time and space. You on your part should understand what is expected of you and try to create a working atmosphere that is mutually beneficial. This will improve the present thought process, relation, and situation.

Try out the products and understand the concepts before approaching the SMEs.

    • Schedule meetings (with the agenda) with them and make full use of such meetings.
    • Do not send an SOS email or make an urgent call for a minor problem. First try to solve it yourself, check if there are alternate methods and write about your concerns to them.
    • Give them a gentle reminder that you are going to send the document to them for review, so that they can expect it and plan their schedules accordingly.

Develop a Process

Include the technical review as the part of documentation process and formalize procedures for conducting technical reviews. Try to include documentation as an integral part of the product development life cycle. Having done all these, you should not forget to schedule adequate and enough time for reviews. Include reviews in the documentation plan and mutually agree to the dates by which you expect to receive the technical review feedback/comments. Try to work in close co-ordination with the development team.

    • Attend the development meetings. Not all the information discussed in the meeting will be of direct help to you, but they will be helpful in identifying the progress of work. It will help in setting and scheduling the task dates.
    • Write functional specifications for the development team. Though it may not fall under your scope of work, you will gain valuable information by doing this task.
    • Review the user interface (UI) for usability and consistency.
    • Maintain a database of tips and error messages which can be used to be a part of the trouble shooting document.
    • Edit the comments in the source code.

Improving the writer-developer relationship not only helps in improving the quality of documentation, but also creates a pleasant and friendly working atmosphere.

How did I Became a Technical Writer?

If you want to know how I chose to make this my career, it is a long story—actually, I just tripped and fell into it. After that fall, when I got back to my feet, I chose to remain with it because I loved the work. I have always loved the world of books—reading and writing were and still are my passion. Before technical writing happened to me, I used to write poems, short stories, and articles on various subjects for the local newspaper to satisfy my appetite for writing.

To cut the long story short, before I could realize what I was doing with my life I found myself with an engineering degree in hand. The engineering degree got me my first job as a production engineer in an electronics firm. One fine day (it really was a fine day, because it changed my life), I was brooding over what my future had in store for me when I saw an advertisement for the position of a technical writer. The requirement was engineers with air for writing. That was the best combination I could ask for.  A combination of both, my educational background and writing (something that I loved). I applied for the job and was called for an interview. Then, I did not know what technical writing was about, but it was the catchy line in the advertisement that motivated me to apply for the job.

Fortunately, I had ample writing samples to show off my writing worth. I was offered the job, I accepted it, and here I am!

Am I happy being a technical writer?

Yes! Do you think I would have spent one third of my life as a technical writer if I weren’t? Early in the career, there were times when I wondered if it was really fruitful being a technical writer, about how I would grow in this field, and my future in this profession. Simultaneously, I also used to think why I took up this profession when there were other options I could choose from.

The answer was simple, I became a technical writer because I loved the job profile and remained so because I loved being one. If you feel that you have made the right choice, you will be happy with what you are doing and your mind will be at rest. This applied to me as well. I personally find technical writing stimulating, fun, exciting, and a constant learning process (tools, subject, technology, etc.). In the 16 years of my career, I have worked for three organizations (this is my third).

I started my career as a technical writer in one organization and worked with them for a little over five years. Then, I moved on to another organization where I set up the documentation team, the systems, and processes and have been managing the documentation activities. I was there for a decade and then moved out of the comfort zone to the present organization.

What do I like about technical writing?

I like my job—the number of years that I have spent as a technical writer and the effort I have put into writing a book on the subject proves that I just don’t like it, I love it!! Along the way, I discovered this enchanting world of technical writing (for me it is) and I have spent the following years as a one.

  • Technical writing is a combination two things—my passion for writing and my educational background. There are many people who like one or the other. For those who like at both, technical writing is a natural choice.
  • Very few people (like me) have the privilege to love their job. I have the privilege of combining writing, engineering, creativity, and technology—all into one job.
  • I am always learning something new—products, subject, technology, tools, processes, etc.
  • At the end of the day, I feel satisfied because I know that I am responsible for making a difference in some one’s life, by making their life a little easy at work. This very feeling keeps me motivated. I visualize how I have struggled with understanding the concept of certain products.It is probably because the writer who was in charge of that part of the project did not do a good job in explaining the matter. This motivates me to avoid such a situation in the documentation I write and/or co-ordinate. I hope I have been successful!
  • Last but not the least, isn’t it a pleasure to be paid for doing something that you love doing? How many people are this fortunate?

Gaining Respect as a Technical Writer

Your value as a technical writer wholly depends on how you value yourself in the role. First and foremost, you have to respect the profession, the responsibilities you have, and the role you play. Only then you can demand respect from the others. The best part of being a technical writer is the mixture of creativity and technology. You can bring in a small amount of creativity in the way you present the information-that is where you can expand your thoughts.

But to expand your boundaries in this area, you definitely require staunch support of the management. Unlike the other professions, here you have to first prove your worth before you receive their support. The respect given to technical writers, or to documentation in general, depends on (at least) three interlinked factors: management support, processes, and technical writers themselves.

Management Support

In most organizations, the culture is usually influenced by the factors that are important to the management. If the management is really serious and committed to technical writing, that will be reflected in the way the documentation team is treated. Commitment and support from the management is very important. You need to make the management aware about the value addition you do. Let them see your contributions and recognize them as valuable addition to the product. If your organization is paying you well, remember that they are already respecting you by compensating well for your work.

Integrating and Formalizing Processes

Indifference of the SME towards documentation—giving information and performing the technical review on time is a common problem that most of the technical writers around the globe face. When assigning work to the engineers, the product managers fail to consider the time they spend in giving a demonstration of the product, providing information, and performing documentation reviews. So most of the time, these activities becomes an added burden to the engineers. There are some organizations which consider all these factors and account for the time in their product development plan, but most don’t.

  • If the documentation cycle is integrated with the product development cycle, then the engineers may become more cooperative because they are educated about the requirement to do the tasks and because the process says so.
  •  If the process states that the writers be informed of any decision about changes in software as soon as developers are, it will be done.
  •  Another way is to integrate these aspects (time for writers and reviewing the documentation on time) into the annual performance review of the engineers. This makes a lot of difference in the attitude of the SMEs who may think of documentation related work as waste of time.

When something becomes a process, it no longer remains personal and has to be followed by every concerned/involved.

Technical Writers Themselves

There may be an existing documented process or guidelines. But to start with, the writers can earn respect for themselves by being knowledgeable atleast about all the aspects of documentation—the product or technology they are writing about.

  • Be confident as a writer—Create error free documents and display outstanding and noticeable performance that will gain you respect. Others should want you to work on the documents of their product!
  • Do your home work—Always do the groundwork before meeting with the SMEs. Most of them will give time if you succeed in demonstrating that you have done your homework or made an honest effort to learn about what you are documenting.
  • Be proactive—In addition to creating documents, take active participation in suggesting usability changes to the user interface (UI), reporting software bugs before QA phase, and helping the developers create the functional specification.
  • Be friendly—At another level, be being friendly and courteous with the SMEs. Developing a rapport on a personal level with others helps.

 Always hold your head high, with the strength that comes from your conviction about your work, its importance, and your role as a technical writer!