By Jerry Grohovsky, Copyright 2017. JPG & Associates, Inc.

If you—the client—have never worked with a technical writer previously (either as a new client, project manager, or subject matter expert—SME), there are certain facts about technical writers, the profession itself, and how projects evolve that will help you to be more successful in a first-time tech. comm. working relationship. Also, you may have false impressions or perceptions about writers that were formed over the years which are totally false or exaggerated, and therefore call for a “reality check.”

The candid truth about the technical writing profession (and what to expect when working side-by-side with such a professional) are offered in the following paragraphs, and which should help to create a better working relationship and, in-turn, a more successful and timely delivery of your project(s). They are as follows:

  1. Technical writers are NOT just typists or scribes, nor are they just content developers. It is surprising how many new clients view a technical writing project as primarily a singular task—pounding out words on a keyboard. Creating content is only a very small part of a tech. writer’s job. It is important to recognize that the project development process is multi-dimensional, and includes effort (or tasks) which may not be as visible or apparent to the client as creating content. This is particularly important for the client to be aware of when they are being billed for time and material—which brings us then to item #2.
  2. Lost in the perception that tech. writers “only write” is a lack of awareness of all the tasks (effort) associated with a project: project management, initial assessment and evaluation, planning and scheduling, identification of subject matter experts (SMEs) internal advocates and project allies, product research and self-training, data gathering, outlining and organizing, software tool identification/ template creation/delivery identification, meeting planning and attendance with stake-holders and cross-functional teams (such as marketing, safety compliance, legal, quality, etc.), holding interviews with SMEs, product access planning, photo and/or video shoots, managing cross-functional cooperation and team building, content review-cycle management, working with graphical development specialists, preparations for translation, internal and/or external production support/interaction, and so on.
  3. Once you have several initial planning meetings, technical writers will not simply vanish, write, and then return with a finished product. You have to be willing to put IN the time to get good results OUT. Words to remember throughout the project: tech. writers are not “fictional writers” who create content from “thin air”–zero input.
  4. Be prepared to provide the writer with whatever he or she needs (i.e., input, product access, data files, engineering specs, server access, marketing presentations, etc.) in order to successfully complete the project. Writers (especially contractors or consultants) are commonly powerless when it comes to maneuvering within a corporate culture, encountering internal policies, and so on. Therefore, an internal point-person who can retrieve and serve as a link between the writer and the corporate structure on behalf of the writer is invaluable role to play. Being responsive quickly and consistently throughout the project often is most important—particularly with the fast-paced project turnaround times that are common today.
  5. Tech. writers are usually not as knowledgeable about the topic(s) at hand as are the subject matter experts (SMEs)—nor do they have to be. This is one of the most common misperceptions about the technical writing profession. The tech. comm. professional has a unique role in the project development process in that they positioned themselves as a hub that is equally centric to the client, audience, SMEs, and other participants. Technical writers do not need to be experts on the subject matter as many perceive to be true. However, they do need to know the product, audience, and client needs well enough to sketch out a plan or skeletal structure, ask the right questions, and gather data and input so that the writer can complete “connect the dots” with the details—content and graphics.
  6. Tech. writers will typically ask a lot of questions—especially at the start of a project. Therefore, be prepared to make time on your schedule for not only project status review meetings, but also to be flexible in providing answers, information, access to product or internal databases, or whatever else the writer—and not at your leisure. If you are not the appropriate source for answering a question, then identify those name(s) of those who may be a better source. Always expect to share some of your time with the writer along the complete project timeline—especially if you are the primary contact or point-person.
  7. If you are the primary contact, the technical writer will rely upon you to be his or her advocate and partner, particularly when it comes to resolving internal issues, removing obstacles, and accessing vital information, data, and/or product. This is especially needed and valued by contract writers (consultants) and those who work remotely (off-site) and only visit the client site as-required.
  8. Trust a tech. comm. professional’s knowledge, experience, and advice. This is particularly important to remember at the beginning of the project—when you think you know what you want, but it may not in fact be what you need. The reason you hired a professional is to tap into their knowledge and experience. At the assessment and evaluation stage, keep an open mind, ask questions. Provide as much information about your objectives as you can in order for the tech. writer to provide a complete and thorough evaluation and plan. It is surprising how many client companies make significant adjustments in expectations once they discuss their project with a technical writing professional. Often clients think they know what they want, until they hire a professional to help them to define direction.
  9. A professional writer brings with them to the project a wealth of knowledge about delivery methods, authoring tools, UX and UI, and a whole host of analytical and problem-solving skills that a client should take advantage of at the time of assessment and planning.

Conclusion

Once you—the new client or SME—truly understand the role, capabilities, and project needs of a professional technical communicator, the better you can position yourself and adjust your schedule accordingly so as to be responsive, pro-active, and communicative as a primary point-person, internal advocate, or SME. With this type of working relationship in place at the beginning stages of the project discussions, the entire project “machine” will run more smoothly and efficiently. In addition, working relationships of all project participants will be strengthened. As more participants understand the role of a technical communicator more realistically, a more team-friendly and cooperative setting will emerge, and this will help greatly to minimize any negative drag on content accuracy, completeness, and delivery.