|
The Commerce of Content
|
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home |
This article originally appeared in the January 2002 issue of Intercom, the magazine of the Society for Technical Communication.
by Saul Carliner
|
In this Article |
More than keeping jobs in these tough economic times, technical communication managers face a number of strategic choices that will determine how they emerge from the current downturn.
What type of work will we be doing? We say we're in the usability business but is that really so? If not how do we get there? What role should tools play in our future? And how could that affect job opportunity? How do we assess the value of our products and services? And what do we do with the data?
Specifically, I see the following strategic issues that managers must address as we move through the next year or two. How we address them will determine in large part the long-term health of technical communication groups in organizations.
Through our magazines, journals, and conferences, we technical communicators talk about our role in interface design and usability. Indeed, our STC Annual Conference has an entire track devoted to this topic. Unfortunately, the proportion of talk does not match the proportion of practice. According to my recent survey of management portfolios in technical communication, such assignments make up a small percentage of our total workload. (The work is being done, just not inside technical communication departments.)
Our assignments lack a similar level of variety. According to the same study, the overwhelming majority of our assignments involve writing help, user's guides, and reference manuals. Training and marketing communications-Special Interest Groups within our Society-make up a small proportion of our total workload.
The limited variety of assignments makes recruiting and retaining strong workers difficult. A reasonably curious technical communicator can only write in the same genre and about the same topic for so long without becoming bored. Similarly, a reasonably curious technical communicator can hear about designing interfaces and playing a central role in usability for so long, before they will seek the opportunity-even if that opportunity causes them to change employers and to change professional identification.
The limited variety of assignments also becomes a self-fulfilling prophecy. When other groups in an organization only see help, user's guides, and reference manuals from their technical communicators, asking them to develop other types of user assistance and participating in interface design is not on their radar screen. These groups cannot request what they do not see.
The strategy needed to break this cycle is called upselling. Fast food restaurants provide the most common example of upselling, when a server asks whether "would you would like fries with your order?" after someone orders a sandwich. The idea behind upselling is to leverage existing customer loyalty by offering them complementary products and services.
Patience is essential in successful upsellling. Changing perceptions about the services that technical communicators provide does not happen overnight. While a sales clerk can upsell a burger customer to a full-value meal in a matter of seconds, technical communicators usually require 6 to 12 months to sell high-end services.
Since desktop publishing first emerged on the scene in the mid-1980s, technical communicators have had an obsession with them. Like usability, the newsletters, magazines and conferences on technical communication give extensive coverage to tools. And like usability, tools have their own stem at the STC Annual Conference.
But unlike usability, the pervasiveness of tools in practice matches its coverage in our professional literature. For example, when evaluating their own skills, many technical communicators first consider their tools knowledge, then consider their communication skills. Similarly, some managers require knowledge of particular tools when hiring, to the point of testing candidates. This practice started in earnest during the last economic downturn, when managers would receive as many as 200 applications for a single position and needed some criterion on which to sift through the resumes.
On the surface, this sounds like a great system. Because most technical communicators also serve as their own graphic designers and layout artists, desktop publishing and online authoring tools are an essential part of our job. They're also complex, not just because they are rich with function, but because their many of their interfaces are not intuitive. Finally, they're expensive. Expenses for some of the more complex content management tools can easily run into hundreds of thousands of US dollars.
But let's be clear about this software: they're tools plain and simple. They change frequently, so knowledge of any tool becomes perishable and, when chasing after the latest tools knowledge, technical communicators can fail to develop their communication skills and their understanding of the technology about which they are writing.
On the one hand, familiarity with tools and the ability to quickly learn new ones is essential from a practical viewpoint, just as typing speed and the ability to learn new composing typewriters was essential to those of us who started in this field in the 1970s and early 1980s. In those days, however, employers did not make a hiring decision based on typing speed (if they did, I would have received more job offers) or the ability to master composing typewriters. They hired on the ability to communicate technical information to a designated audience.
The danger of this over-emphasis on tools is more than well-produced manuals with indecipherable content. One real danger is that the requirement for tools is scaring away good candidates-people who can clearly communicate and who actually can learn tools easily, but don't happen to know the ones in vogue at the time they're hiring. Furthermore, because tools like Robohelp and Framemaker are priced for commercial use, few prospective job candidates can afford to purchase these and practice on their own. What's worse, most of these tools can be learned in a short period of time.
Another real danger is the message this sends to upper management. For all sakes and purposes, once the tools are mastered, the skills needed the basic text management skill needed is a clerical skill. It is not a professional skill. And the skills needed to set up and customize these systems are usually programming and systems skills. They're not technical communication skills. But upper management thinks they are, and assign work responsibilities according to these expectations.
As I reported in my trends column 3 years ago, some organizations have quietly started to re-visit the job descriptions for technical communicators. The ones whose primary task is text management are being reclassified as non-professional jobs. Professional jobs require extensive unstructured intellectual content. To be blunt, text processing jobs don't require them.
Furthermore, when technical communicators emphasize their text management skills to other groups within the organization, the others groups have difficulty seeing technical communicators doing more complex and creative work, such as interface design. This only confounds any upselling efforts that have been started.
Managers in our field have the ability to change this perception. We can change knowledge of specific tools in job ads from "requirements" to "preferences." When we evaluate the work of technical communicators, we can give more weight to effectively communicating technical content to a designated audience than to formatting tables in FrameMaker. Until managers re-emphasize the primacy of communication in job ads and evaluations, the tools jockey problem will dog us-perhaps so much so, that the excellent communicators will be driven from the field.
One of the ongoing challenges of technical communication managers (and, by extension, technical communicators) is an understanding of how to place value on the products and services that we use. The challenge is going to be especially acute this year, as financially-pressed organizations will go through the traditional hard-times exercise of asking all managers to justify their existence.
Hit at a vulnerable time, and usually with little time to respond, most managers look for a simple formula. A + B = the-company-must-keep-the-department.
The sad news is that no such formula exists. As Jay Mead noted in his 1998 article in Technical Communication, the literature on technical communication is littered with untested ideas and concepts that were tried once, but never validated in other organizations.
The sadder news is that convincing data can be shown, but the time to collect it is when things are going well. Because everything is going well, most of us do not think to do so at that time.
However, if we were to collect data about the value of technical communication products and services, what would that be? Marketing communicators have direct response measures. Although imperfect, these systems measure the actual responses to advertisements and direct mailings. People can use this information to assess the direct financial impact of a sales promotions (an ad that specifically sells a product) or the indirect financial impact of other types of promotions. Usability professionals have measures, too, which relate the expense of usability work to the reduced cost of supporting and maintaining software.
Trainers have a number of measures of their success, too. Trainers' measures include learner satisfaction, content learned, application of content to the job, and the financial impact of the overall training investment. Many of these measures resulted from a close collaboration of training managers in corporations (including competitors), and extensive research and testing in practice. This system of measures, still in development, has taken several years to perfect.
Furthermore, we must move past the belief that such data "proves" value(arithmetic) and recognize that, at best, we have several measures that provide persuasive evidence (argument).
We must also move past the na‹ve belief that collecting data on value means we're going to like what the data says. In some cases, we might learn that a communication product or service is not effective. By collecting multiple measures on it, however, we might be able to pinpoint what is not effective and use the data to suggest how to improve it. For example, a training course might result in a high degree of learning, but receive a low satisfaction rating. Clearly, the message is fine but the delivery needs to be improved.
In addition to identifying the types of data to collect, technical communication managers also need to devote resources to actually collecting, interpreting, and reporting the data. How much? The United Way, which requires all of the programs it funds to set objectives for funded programs and collect data on the effectiveness of the outcomes, estimates that organizations should set aside between 5 and 10 percent of the resources for a project for evaluation.
When a manager is faced with a full workload and little time for strategic planning, one can understand why upselling does not occur. The group has enough work for today, even if some of the communicators grumble about the lack of involvement in interface design issues.
When a manager is faced with an imminent deadline, one can easily understand how hiring someone who is fully-trained in Robohelp seems essential. The manager can only see tomorrow's production schedule, not six months' down the road.
When a manager works with a base of satisfied internal customers and has funds for occasional usability tests, one can easily understand why investing time in other activities to evaluate the effectiveness of technical communication products and services seems frivolous. Things work, why stir up a hornet's nest? But usability and high-end work does not walk in the door and, in many organizations, that work is already lost to other departments. Sophisticated tools do not design and develop good user support materials. And without an ongoing effort to assess the strengths and weaknesses of the technical communication effort, nothing exists to link the effort to the bottom line. Or the technical communication group to the organization.
How each manager handles every day management practice does make a difference. How the collective of technical communication managers handle everyday management practice can have a profound impact on the long-term direction of the field. Your small choices do make a big difference.
Check out my predictions for the year 2000 and 1998.
Carliner, Saul. (2000.) Trends for 2000: thriving in the boom years. Intercom 47(1).
Carliner, Saul. (1999.) Trends in our industry. Intercom. 46(1).
Mead, Jay. (1998.) Measuring the value added by technical documentation: a review of research and practice. Technical communication: 45(3) p.353-379.
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home
