Are you suffering from bouts of technophilia? Do you bend over backwards to understand technology? If you write daily about new or complex products, it seems highly improbable that you will not value the underlying technology. Most writers admit that they continually face the challenge in learning different technologies at their workplace. If content is today's king, then why such an outcry about technology?
Well, here goes...
The technological change is a moving target. You cannot gain complete dominance over a moving target. Yet with the correct approach, you can aim for the right spot. Technological change has affected, and will continue to affect, our profession. Technical communication professionals worldwide are expected to increase their existing skill sets. While the core competencies remain the same, we need to pick up new knowledge and continually demonstrate it at our workplaces.
The Scenario
You have been asked to document a new compiler manual. One of your primary tasks is to use the compiler to test the various command line options, and later document those options in the manual. The compiler identifies C source files as input. You cannot test these options unless you have a proficiency in the C programming language. Additionally, you will not be able to explain how the compiler works unless you can decipher the underlying technology. You will continually rely on the development or quality assurance teams for their support. As a technical communication professional, this is not a very comfortable position.
Get Trained
Ask your management team to support you with formal training on the technology you are using. This training can take advantage of your company’s tuition reimbursement plan or the training budget for your team or department. You can learn any programming language on your own, yet the effort can often be inefficient and not worth it. Ditto for any new tools you need to learn.
Go for an instructor-led training course from a reputed institution. Consult with people who have attended such training and listen to their recommendations. If you receive training on new authoring tools, you are more likely to spend time exploring hidden and advanced features in that tool that may have otherwise been hard to find. Training can be an expensive proposition. However, once you know how the technology or the tools work, you can recover the entire cost within no time through your added proficiency and productivity.
Pass on the Learning
The consumers of your product may not always be the customers or the stakeholders who purchase your product. Consumers may include people like the inexperienced call center executives or sales and marketing teams who are learning how to use the product. Even novice developers, who have no experience with the product, can be your customers. Some advanced customers, such as system integrators, may even request training materials, which is highly technical in nature and provides a greater depth of knowledge. These people may use the training materials for developing complex applications later on.
As a technical communication professional, you should provide accurate technical details by blending theory and practice with examples and exercises that gives the customer the necessary skills to work with that product or tool. In our business, we must reach out to a varied audience and convey the same thing the same way that we would to a single audience member. A technical communication professional, who is adept at technology, is more equipped to address complex issues related to the product and its domain, than the one who isn't.
Provide Complete Learning Support
When you are writing technical documents, you refer to many resources, such as user groups, competitor product web sites, books, reference guides, mailing lists, wikis, and so on. It is also necessary that you provide complete learning support by including other technological deliverables, such as online help, web and computer based training, and so on.
For instance, let's say you are documenting a software development kit (SDK). You must provide robust samples so that the application developers can use the sample as is, or modify and incorporate them into larger applications. If you design online help, ensure that the content will provide the developers with answers to their specific questions. They want real solutions to their problems. If you provide code snippets that they can cut and paste into their applications, they are more than happy to work with you.
Technology provides us with better tools for easily accomplishing our daily tasks. Now, we just need to write our content once and distribute it in various formats. Not just that, we can define our content methodologies and choose the best tools that support these methodologies.
As technical communication professionals, we should embrace the technological change. We need to constantly evolve, shift gears, reposition ourselves, and move beyond our traditional roles. It takes time to build and launch a successful product, but it still takes more time to ensure that we are providing total customer satisfaction.
In the end, I surmise that technology is just an enabler as it helps with the content delivery. While we concentrate on the "technical" aspect of our field, we must not lose sight of the "communication" component.
Suggested Reading
Perlin, Neil. Managing the Technical in Technical Communication. PCS, IEEE Professional Communication Society Newsletter – ISSN 1539-3593, Volume 50, Number 11, November 2006, http://www.ieeepcs.org/newsletter/archive/nov2006/pcsnews_nov2006_tools.php
Davis, Toni, Catching the Technology Wave: A Historical Analysis of the Technological Context of Technical Communication, http://orange.eserver.org/issues/4-1/davis.html
Worth reading.
ReplyDeleteRahul, its very true that writer
should focus on providing total customer satisfaction but is it possible to verify [usability] everytime?
truly said!! it is reader after all who should get all the benfit from the write up we create
ReplyDeleteAs always, very insightful article. Coincidentally, my "TechCom Year in Review" article is now online and touches on some related subjects.
ReplyDeleteHere's the summary:
"This year was an active one for the field of technical communication. New tools and technologies made their mark on our profession, while new pressures and business goals began to impact the way we see ourselves, our role in the organization, and our place in the communication spectrum. In this end-of-the-year report, Scott Abel, president of TheContentWrangler.com, takes a look at some of the year's most important developments in the field of technical communication and makes a few predictions of importance to documentation managers for 2007."
http://www.enewsbuilder.net/techcommanager/e_article000721384.cfm?x=b8HjghW,b25dnRPs
I enjoyed your article. I strongly support your position that technical writers must become competent in their understanding of the technology they write about. Too often, I find that writers depend solely on what the developers tell them to write or wht is written in an often-poor specification. I think your approach is most appropriate.
ReplyDeleteYes, but... in many situations, it is not commercially practical for a technical communicator to gain a thorough understanding of the technology, and so the technical communicator will be reliant on the development or quality assurance teams for their support. I tell each potential new client that their team may need to provide significant support and that I expect management support to ensure that this happens. I need to learn enough to be able to see that the answers I receive from the development team are sensible and self-consistent. It’s not ideal, but it is the only practical commercial approach.
ReplyDeleteHey Rahul
ReplyDeleteYou write pretty well and ur post actually provides an insight to an issue which we tend to ignore :)
keep blogging and wish you a happy new year ahead
cheers
Lavina
Hello Mr. Prabhakar,
ReplyDeleteI personally feel that, irrespective of the complexity of a product, what we deliver as technical communicators depends more on the following two aspects:
1. The core functionality, the business logic, and the complete logical workflow within the product that needs documentation.
2. How best we understand the audience –how much do they already know, how much do they need to know and to what detail?
If you observe carefully, even if our understanding of something goes to the level of programming language involved in the making of a product, we simply have to abide by only “what needs to be presented.”
As advocates of users, we humbly remain!
Hi Rahul,
ReplyDeleteI liked the way you summed the entire topic "While we concentrate on the "technical" aspect of our field, we must not lose sight of the "communication" component."
Communication is the key!!
Keep writing,encouraging and smiling.
Cheers
Padma