|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2006 --> Evaluating technical communicators
Vous êtes ici : Essais --> 2006 --> Evaluating technical communicators
by Geoff Hart, Associate Fellow, Montreal chapter
Previously published as: Hart, G. 2006. Evaluating technical communicators: criteria and possible career paths. Directives, newsletter of the STC Management SIG, July:9–13.
Paul Glen's book, Leading Geeks, offers many useful insights about working with the creative knowledge workers (the eponymous "geeks") who are responsible for many of the products such as computer hardware and software that we document. However, much of Glen's advice also applies to technical communicators because we too are knowledge workers, and share a surprising range of characteristics with our geek colleagues.
In one of the core parts of his book, Glen defines twelve core competencies that managers can use to judge the quality of a geek's work. These competencies are essential parts of evaluating these workers because brains and the ability to use them are not sufficient to produce quality work; even the brightest geeks can fail when they're overwhelmed by the complexity of a task, unsure which of many possibilities they should choose, and can't learn how to let go when perfection is seemingly just another week or another revision away.
Sound familiar? It should. Technical communicators routinely face similar problems in our daily work.
In this article, I'll present Glen's twelve points and some of my own insights to help technical communication managers rethink how they evaluate their employees. This list also clearly provides a way for technical communicators to think of how to develop their own careers, since each skill presented early in the list provides a strong foundation for the skills presented later in the list, and the more advanced skills offer communicators an opportunity to take on progressively more responsible roles within their organization—and thus, to progress through the ranks.
The basic requirement to excel at a job is an effective combination of breadth and depth of technical skills. Breadth is required to be able to handle the wide range of communication challenges we may face on the job, and depth is what lets us solve even the most difficult problem within a given category of challenge. As professional communicators, we can be assumed to have mastered the basic tools of our profession, but many of us gradually become so specialized that we limit the range of skills at our disposal. Worse yet, we sometimes become complacent with the current level of our skills, and accept that level rather than trying to push our competence to ever-greater heights.
Competence is all very well, but if we cannot apply that competence to produce results, we are less useful to our employers than we might otherwise be. As noted above, many things can interfere with getting our work done. Another example familiar to most technical communicators is that the stress created by constantly changing products and tight deadlines can make it hard to work effectively. Part of a manager's goal must be to help stabilize our goals so we know what we're trying to accomplish and can set out to accomplish it, undistracted by other potential goals. The ability to apply our tools in this manner is what makes us productive.
The flip side of productivity is that it's not sufficient to simply count pages of text or the number of help topics produced. There must also be some measure of quality attached to our productivity. Since quality is difficult to define and assess, it may be necessary to involve other workers in peer review of the work we produce to determine whether the quantity produced per unit time and the quality of this work are both acceptable.
Being technically competent and applying that competence productively are all very well, but if they are the only skills we possess, we quickly plateau: most organizations have very clear ceilings on how high a technical communicator can rise, and moving beyond that point requires the addition of new skills valued by the organization. Glen's remaining points list, roughly in order of sequence, the additional skills that must be added to competence and productivity before we can advance into more challenging and lucrative positions.
Few of us have the luxury of working on only a single task or even a single type of task. Instead, most of us must juggle many different tasks and task types. In a former job, I used to joke that I wore so many hats I could open my own hat store, and had so many clients vying for my time that I needed a bigger hat to hide in. To succeed in such environments, technical communicators must be able to monitor the status of all their tasks and track progress towards completion, must constantly reprioritize each task based on how acceptable the current result is compared with new tasks that have not yet been started, and must be able to switch between tasks quickly and efficiently when required. To this competency, I would add the ability to apply the right skill at the right time and to switch approaches whenever one approach proves ineffective.
At the most basic skill level, technical communicators may have only limited knowledge of how the products we're responsible for documenting relate to our employer's current and future health (the business context). It may be sufficient and acceptable to simply document a product to the minimum level required for customer acceptance, and leave it at that. But this is clearly insufficient if we believe that our roles include that of user advocate. If our goal is to eventually become the leader of part of an organization, and have some influence on product design, we must expand our knowledge to include a comprehensive awareness of the human, social, marketing, competition, economic, and tactical and strategic aspects of our organization's short- and long-term operation. Even if we don't aspire so high, we must nonetheless develop increasing awareness of these factors so we can better serve our employer—and advance through the ranks.
Awareness of the business context leads to another key competency: the ability to adapt the amount and quality of our work to the constraints that govern that work. For example, meeting a Marketing-mandated deadline may seem artificial and unreasonable, but understanding that shipping a product by that date (e.g., before the Christmas buying season or a key trade show) is essential to our company's survival makes it much easier to prioritize what we can and must achieve by that deadline and respond accordingly. There's no point creating perfect documentation for a small part of the product if the rest of the product goes undocumented. Thus, we must learn triage: complete the essential components first, work on less-essential components next, and finish the least important components only once the other two classes of work are complete.
This also requires us to learn to accept "good enough" even when our professional instincts are screaming out that we must strive for perfection. Perfection isn't always possible, and is never acceptable if attaining it seriously compromises other aspects of our work. After all, there's usually down-time between product releases to fix things we had no time to fix during the first pass.
As technical communicators, we have many clients: our boss, product developers and managers, senior managers, and the product's users. One difficult competency for us to achieve lies in bridging the gap between the technicalities of the job so beloved of the product developers and the much less proficient people who use that product. We do this every day, but sometimes need to take a step back and recognize that our own technical nature can lead us astray. Being immersed in the latest and greatest tools may lead us to forget that not all of our audience possesses, can use, or want to use those tools. Understanding all the latest communication theory can make us forget that this theory may be too technical for our clients, and trying to explain that theory may get us nowhere. I once discussed this very issue with a former manager, who was impressed by the depth and breadth of my theoretical knowledge, but who wondered why I never seemed to apply it on the job. I quickly pointed out several areas in which I was applying that knowledge, and more areas in which corporate constraints prevented me from doing so.
It pays to learn just how technical we can be and when pushing a technology or theory isn't helpful. The goal of establishing relationships with our many clients is not to let us manipulate them better, as the cynic might propose, but rather to better understand their needs and how to meet them. Where better technology or theory can help us do so, we can attempt to explain this persuasively to our clients. Doing so require knowledge of the business context and the compromises imposed by that context (competencies 4 and 5, above), but also the ability to listen, provide feedback, and achieve consensus. These so-called "soft skills" are essential to our success.
Working in teams is clearly less personally productive than working alone because of all that messy building and maintaining of relationships. We technical communicators are most often writers and editors, and both professions are by their nature somewhat solitary. This can lead us to withdraw and forget to work on those relationships, behavior I called the "cubicle syndrome". But these relationships are critical to our success. The goal of attaining this competence must be to learn how we can use our skills to make other members of our team, and colleagues elsewhere in the organization, more productive. This may involve sharing of our skills and mentoring. Glen calls this leveraging, but I prefer the term synergy: by helping make our colleagues even slightly more productive, the cumulative effect can be far greater than if we applied our solitary skills purely to make ourselves more productive.
I've often said that as soon as you get more than two people together in a room, you spontaneously generate politics. And anyone who has worked in even a relatively small company and kept their eyes open has seen the groups that form and come into conflict or the jockeying for position that occurs among those most interested in climbing the corporate ladder at any cost. That's the negative aspect of politics.
The positive aspect of politics is that it's about the relationships that develop at work and govern how people interact to achieve both their personal goals and the larger goals of the organization. It's certainly important to remember that we'll occasionally encounter ruthless climbers whose only goal is to use and manipulate others, but most people don't function that way and there's no reason we should. While protecting ourselves and our goals, we should also learn to play the political game for the good of our co-workers and our employer. A famous description of politics is Dale Carnegie's "how to win friends and influence people", and I like that far better than the competing Machiavellian definition: "the exercise of raw power". The ability to make our point without alienating others is key to this competency, but it also requires a firm grasp of competencies 4 through 7.
Learning how our role of communicator affects our clients provides insights on how to expand that role and make our impact increasingly beneficial. One way to achieve this is to develop an increasingly deep understanding of each client's needs so we can better consider how our work affects them. Doing so lets us make our work increasingly beneficial. As communicators, this competency may involve learning more communication theory, so we can write and design more effectively, and getting increasingly involved in audience analysis so we can act as increasingly effective user advocates. Communicators who have drifted into usability testing and interface design are examples of people who are developing this kind of competency.
Understanding clients can be particularly difficult when, as is often the case, our clients can't clearly articulate their needs. The process is further complicated by the current business context, the constraints imposed by that context, and the need to work with our colleagues to incorporate this knowledge in our own efforts. This requires considerable political skill (competency 8), since there are often many competing needs and constraints within our organization, and reconciling them requires consensus-building (competencies 4 through 7). Sometimes it even involves asking hard questions about whether we're competent to meet certain needs, and if not, determining who can provide what we cannot.
Competency 7 focuses on working with others to make them more productive, but the more advanced application of this skill takes this competency to a higher level, particularly when we begin to work as a manager. Here, for example, it becomes important to leverage our skills by pitching in where the need is greatest rather than focusing exclusively on our own work, and helping others to accomplish their own tasks so that our input is no longer required. This can involve a range of complex issues such as helping to resolve personality conflicts among team members, and learning to coach colleagues to become more competent rather than stepping in to solve their problems.
In high-technology or knowledge-based environments, ambiguity is an inescapable fact of life. The work is often inherently complex, the problems we are trying to solve may be poorly defined and only gradually understood as the work progresses, we may be affected (often impeded) by the consequences of past choices that constrain our current options, and human biases and subjectivity may further cloud the picture. As a result, the process is often the opposite of the carpenter's approach: we measure once, and cut thrice, with each new cut bringing us closer to the final goal. It would be nicer to "measure thrice, cut once", but that often isn't possible.
It sometimes helps to think of what we do as jumping out of an airplane and trying to learn how to fly as the ground rushes ever closer. (This metaphor also makes it clear why so many projects fail. With a little more planning, it at least becomes possible to strap on some wings before we leave the plane.) A key aspect of this competency thus revolves around striving to understand a problem sufficiently well that our short-term decisions, though clearly suboptimal, at least let us function until we can make better-informed decisions. Ideally, those short-term decisions should provide enough flexibility that their consequences won't unduly constrain us in the future.
Personal time management is covered to a large extent by competencies 2 and 3. But once we begin to function at higher levels, we also learn to integrate those time management skills with the more difficult skills of clearly defining goals and how to reach those goals. Beginners often focus too narrowly on the task at hand and start running towards that goal without fully considering whether we've chosen the correct goal and whether running is the best way to reach it. Mature communicators dissect the process more thoroughly to account for how the current and predicted business, technological, and social environments will influence how those goals will be achieved. This form of time management recognizes that the future itself cannot be predicted, but that certain aspects of the future are predictable: time proceeds both linearly (as we move towards a deadline) and cyclically (as we repeat the same linear process for each new release of a product). Recognizing this lets us plan to complete the current documentation cycle while making note of things that can be completed or improved during subsequent cycles.
We humans are a wonderfully complex lot, and the social and organizational structures we develop are no less complex. Simplistic application of the advice I've given in this article clearly won't solve every problem or work in every situation. Like any other advice, this approach must be used with a skeptical but open mind. Glen's twelve points make a good deal of sense, but do not represent mechanistic laws of physics. In particular, they must be adapted to the nature of our organization and that of the people being supervised.
That being said, Glen's approach represents an excellent starting point for recognizing the human aspects of technical communication work and rewarding those who excel at these aspects. And for those who don't, the points provide a clear plan of action for helping our colleagues learn to excel. Technical communication managers and the people they supervise should work together to use the best and most relevant of these points to develop more humane and effective performance reviews and help colleagues plan for career progression.
Bekins, L.K.; Williams, S.D. 2006. Positioning technical communication for the creative economy. Technical Communication 53(3):287–295.
Carnegie, D. 1990. How to win friends and influence people. Pocket Books. 304 p.
Glen, P. 2003. Leading geeks. Jossey-Bass, San Francisco, CA. 253 p.
Hart, G.J. 2001. Conquering the cubicle syndrome. p. 69–73 in: G.J. Savage and D.L. Sullivan, Ed. Writing a professional life. Stories of technical communicators on and off the job. Allyn and Bacon, Boston.
Moore, P.; Kreth, M. 2005. From wordsmith to communication strategist: heresthetic and political maneuvering in technical communication. Technical Communication 52(3):302–322.
©2004–2024 Geoffrey Hart. All rights reserved.