|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2013 --> Geeks like us: managing technical communicators
Vous êtes ici : Essais --> 2013 --> Geeks like us: managing technical communicators
By Geoff Hart
Previously published as: Hart, G. 2013. Geeks like us: managing technical communicators based on insights gained from software developers. Intercom March:11–17.
We technical communicators complain endlessly about the difficulty of working with scientists, engineers, programmers, and miscellaneous types of product developer—the “geeks” who are so often parodied as socially inept outsiders. (Think “Dilbert” and you get the idea.) While reading Paul Glen’s book, Leading Geeks, it occurred to me how similar we are to these colleagues; many of us even proudly refer to ourselves as “word geeks.” For simplicity, let’s call ourselves “writers” in the rest of this article, whether we write, edit, translate, or design information architectures. Glen’s book should be mandatory reading for any manager, but it is particularly relevant for managers of writers, and doubly so if those writers document the products of geeks. For writers and our managers, it also provides a concrete example of how understanding an audience can improve communication.
Why do I feel qualified to write this article? During my first job, I co-chaired the safety committee at a federal government research institute and managed their publications group for more than a year. At my next job, I co-led a self-directed communication team at a private research institute and later had the opportunity to learn from the best manager I’ve worked for in 25 years in this profession. Last but not least, I led the Montreal Chapter of STC for a year. In each situation, I worked with or managed a diverse group of communications professionals, scientists, programmers, engineers, economists, and various other types of geek.
Before we proceed, an important note of caution: Like any other form of audience analysis, Glen’s book and this article risk creating stereotypes. Even when stereotypes are broadly accurate, the differences between them and the real people they’re intended to describe remain important.
You can’t successfully manage writers without understanding how we differ from other workplace professionals. Some of our work appears mechanical and requires little thought; after all, adding a list of menu choices to documentation or transcribing technical specifications isn’t rocket science. But the interesting parts are very different. As “knowledge workers”, we focus on acquiring and applying knowledge, often in ways that resemble random exploration or even daydreaming. The work’s complexity and often-vague definitions minimize the mechanistic, predictable aspects many managers are most comfortable with and make the work much harder to predict and control. Anyone who’s had to justify a documentation deadline to an engineering manager knows the problems this can cause.
The creativity we require resembles a voyage of exploration when what we know represents a small portion of what we need to learn. This requires creative solutions, which is why most of us stay in this profession. Writers love to analyze and solve communication problems, turning the inchoate into something that makes sense and sharing that understanding with others. This is why the mundane tasks such as project status meetings that clutter workplace life can seem annoyingly irrelevant and why corporate policies and procedures can be so frustrating; they’re often poorly written and designed to solve different problems than those we typically face. Once, my employer implemented a lock-down policy for our computers after a colleague installed problematic software, forcing our overworked computer tech to reinstall everything from scratch. This prevented me from installing the software I was being asked to document. The tech’s workload delayed the installation by weeks, and I eventually required my manager’s intervention to get the software installed.
A particularly vexing problem arises when such obstacles interfere with the tightly focused thought that lets us solve problems or with the passionate creativity that inspires us to seek “elegant” solutions. Here, elegance is judged by how skillfully we wrap an abstract and difficult thought process in a tidy wrapper rather than just solving the problem messily. Such work is inherently solitary, since it requires quiet, uninterrupted focus on the problem. Yet our work also involves sharing and idea exchanges with our peers. The balance between these antisocial and social extremes shifts constantly, depending on the needs of the moment rather than on a manager’s goals. Because our toughest problems and our most important results require thinking (problem-solving) rather than acting (typing), we sometimes seem to be doing the least when we’re working hardest. The writer who creates a 20-page list of menu commands may seem more productive than the writer who finds an elegant way to communicate an incomprehensible process in a few hundred words, but the latter has done more demanding and important work.
Like geeks, we operate within what Glen called a “tribal culture,” with strong empathy and bonds within our group and with our colleagues around the world. Some of this comes from the siege mentality many writers develop; when nobody understands or cares about us, we band together for protection (see Hart 2007). These bonds are often stronger than those with our fellow employees, particularly when we’re underappreciated by managers who don’t understand what we do or why it’s valuable. Our tribal culture judges someone’s worth based on their brains and effectiveness and innovation, but the workplace cultures that surround us often prefer less thought, more action, and no innovation that might lead to departures from established procedures. This contrast often leads us to group others in our workplace with Dilbert’s pointy-haired boss.
One colleague used to lock onto writing problems I’d raised and focus so intensely that I disappeared from his perception until he finished the thought process I’d provoked. It was like watching a multi-ton bank vault door swing shut: slow, ponderous, but immensely powerful. This kind of focus is described as being “in the zone”, and when we enter this state, any distraction can be infuriating; it can take hours to return to the zone. This focus resembles the famous “runner’s high”, and I’ve felt it myself during the rush that occurs while I’m describing something that excites me and the words just flow into place. You may also have heard this described as “flow,” a term coined by Mihály Csíkszentmihályi.
This intense focus generates an equally intense need to blow off steam, and geeks and writers are both famous for bringing toys to work. These range from small Japanese robots with many moving parts to Nerf weapons that inspire office-wide firefights. MIT science and engineering students are famed for their smarts but infamous for their pranks. My own moment of shame came when I rearranged the icons in a colleague’s toolbar, causing enormous consternation before she figured out what happened. It can also lead to obsessive computer gaming; my weaknesses were Solitaire and Minesweeper.
Like most intelligent people, writers occasionally forget the difference between our opinion and fact, leading to interesting debates. (I’m as guilty of this as the next person. [A look back: Possibly more so. But I'm working on it.—GH]) Most writers first encounter this phenomenon in reverse when we must document an unusable product or confusing user interface. The problem? The solution satisfied the developer, who may have invested considerable ego in finding that solution. I once visited a programmer to report an interface problem; initially, he was hurt by my criticism. But by knowing what he wanted to achieve, I could persuade him to change the interface by suggesting an elegant solution he hadn’t thought of but eagerly embraced. Sadly, we often fall into the same trap that snared the programmer. I once got into a heated debate with an author about the best way to lay out a book I was designing for him; armed with my knowledge of typography, I had a strong opinion that conflicted with his (in my opinion) uneducated preference, and neither of us would back down. The compromise I proposed, certain of victory, was to prepare two versions of the layout and circulate them among representative readers to learn their preference—and the author proved to be right. I changed the design and also learned to be less certain about my opinion. Younger writers may need gentle guidance in this direction.
Tracking and managing productivity can be difficult. Witness the fact that some managers still evaluate us based on the number of pages we crank out per day. Needless to say, we’re smart enough to game that kind of metric. Concision and elegance take time we can’t afford when the goal is quantity. As Pascal famously noted, “I would have written a shorter letter, but I did not have the time.” The more productive approach is for managers and writers to work together to develop appropriate criteria. For example, it may be more appropriate to count the number of problems solved, with the recognition that problems vary in their complexity; indeed, solving certain problems may reveal whole new worlds of problems to solve, just as climbing a mountain reveals new horizons. (See Hart 2002 for suggestions on how to get around this problem.) An important related lesson is that it’s premature to predict how long a project will take at the start of the project. The earlier you attempt to predict, the less useful the prediction, because scope creep (“featuritis”) is ubiquitous and because a project’s ambiguity decreases steadily as its true scope and the true magnitude of the challenges become clear.
If you’re leading writers, several strategies can make your team more productive:
Writers value opportunities that stimulate thought and challenge our creativity. Unfortunately, much of what we do can be mundane and—let’s face it—boring. One solution is to rotate the dull and challenging tasks within the team so that nobody is condemned to documenting the Print dialog box for the rest of their career and everyone has a chance to seek a challenge. You can’t make someone love a boring, unpleasant task, but you can motivate us to do it well by rewarding us with opportunities to do something more interesting later. Of course, you also have to understand your team well enough to know who truly enjoys a challenge and who will only be stressed by it. An effective challenge must encourage someone to stretch—but without breaking. For example, writers tend to be introverts, and not all can become extroverted marketing writers.
Rewards provide an obvious motivation. Attending conferences and other learning opportunities motivates most of us. But pay attention to the difference between this extrinsic form of motivation (i.e., motivation that comes from outside us) and the intrinsic (internal) motivation that really builds enthusiasm. The problem with extrinsic motivation is that over time, it loses its motivational power (“desensitization”). Worse yet, if rewards are provided too liberally, writers lose the sense that we’ve earned the reward and it loses impact. The only rewards that don’t lose their appeal work on intrinsic motivation, because that changes to reflect our current condition. You can encourage intrinsic motivation by finding ways to match the work to the worker, since people vary in what we most love doing. Because creativity is largely intrinsic, it can’t be directly motivated, but it can be nurtured. The remaining points in this section contribute to creating an environment that nurtures motivation.
As noted above, you must provide enough isolation that your writers are free from distractions and annoyances. But don’t turn your team into hermits. Instead, provide opportunities for socialization (determined based on individual needs rather than imposed arbitrarily). For writers, creating formal opportunities to meet and get to know our developer colleagues is a good option. Informal activities such as brainstorming sessions and formal ones such as exchanges of “best tips” or post-mortem sessions after the documentation ships are also good options.
Finding ways to keep an eye on your team without annoying us also provides motivation. The old cliché of “management by wandering around” has been justly parodied because many managers consider it a form of surveillance, not as a way to understand their team’s situation. But when done right, it frees up time to ensure that you understand how someone’s work is going, what recent victories we’re most proud of, and how you can help us past our occasional defeats. Whether you remove obstacles or provide assistance (e.g., buying new tools, asking another group member to help out) based on this understanding, you create a sense that your goal is to help, not just to spy.
One problem with monitoring is that it can create the sense of a Darwinian struggle for survival. That’s particularly true if some group members are significantly faster, more creative, or more productive than the others, who will naturally feel pressure to perform to the same level. You can mitigate this problem by asking the superior performers to mentor, teach, or assist those who are having trouble keeping up. This stimulates group loyalty (i.e., builds a sense of teamwork) and helps the less-productive writer become more productive, thereby lowering the pressure we feel. This also gives you a chance to learn which pairs of people work well together and which simply can’t get along, so you can avoid the latter pairings in the future. Offering opportunities to work with someone we like and eliminating work with someone we dislike strongly encourages teamwork.
Because a typical technical communication manager is low on the corporate totem pole, you may have little flexibility for promotion and other extrinsic rewards. That doesn’t mean that you can’t provide alternative career paths that motivate. For example, junior writers can become senior writers, and senior writers can become team leads or even product managers when the communication group is responsible for documenting multiple products. Writers with unusual skills may be willing to branch out into different areas such as marketing or instructional design. At my former employer, I was hired as an editor, but my manager recognized my other skills and gave me chances to work as a translator and technical writer. The increased job diversity provided strong motivation to perform. It should be obvious, but therefore needs saying: these “promotions” must be more than empty titles. They must be real opportunities and must be recognized in performance appraisals.
Failing to provide the right kind of motivation is, itself, demotivational, but demotivation can negate even the best motivational strategy. One rule to keep in mind: anything in Dilbert that makes you laugh is something you must ruthlessly eradicate from your group’s experience.
In most workplaces, employees feel little sense of control over their destinies. Most workplace policies and procedures are imposed with little or no consultation or flexibility. Failing to let writers participate in decisions that shape the work environment, schedules, tools, and other aspects of the job is a strong demotivator. The only thing worse is being asked our opinion when there’s no chance this will produce changes. In contrast, as I noted in my recent article Uprooting Entrenched Technical Communication Practices (Hart 2011), people are far more willing to accept solutions we helped create. There will undoubtedly be times when you can’t include your entire group in a decision. When that happens, justify why and ask for a reality check on how your decision affects your employees’ work. Workers may not be pleased at being unable to shape your decision, but they’ll at least be more willing to accept it if they understand why and know that you’ll try to mitigate any undesirable impacts.
Here are some examples of demotivational activities:
As I noted earlier, evaluation of writing work is tricky because it’s often subjective. To create a fair evaluation process, look for ways to separate the subjective from the objective and to reward people for both. For example, you can objectively confirm whether someone documented a process correctly if you follow the steps and they produce the desired result. But you can also subjectively evaluate whether our solution is “elegant” by asking the rest of the group: “Is anything so good about this example that we should all be doing it?” This accomplishes several objectives simultaneously:
In my experience, writers see your most important role as getting out of the way and taking any obstacles with you, thereby leaving us free to do our work. But there are many other ways to make life easier for us:
Human problems can’t always be “solved”; more often, they’re an ongoing juggling act. Managing a team is more like sailing than it is like driving a powerboat, since you’re at the mercy of winds and tides that are largely beyond your control. Identify any problems that need solving, but where possible, don’t solve them yourself; you’re more likely to succeed if you play the role of an arbitrator who helps us to resolve our conflicts. Since that doesn’t always work, be willing to impose solutions when necessary.
Create and maintain a productive work environment:
Much of what I’ve discussed involves coordination within your team. But you must also act as a liaison between us and the rest of the organization. To succeed, you first need to determine what other groups interact with us, directly or indirectly. To do this, trace each action (e.g., approval of a manual, submitting a purchase order) from the time it leaves your hands to the time it reaches its final destination. [A look back: tracing requirements that are imposed on you back to their source is also highly useful.—GH] Next, keep an eye on each group along these paths so you’ll have advance warning when changes that affect them will also affect us. Some of these groups are obvious; for example, if you’re documenting software, the development group is the primary group you’ll need to deal with, as are the training and customer support groups. Some groups are less obvious, such as the accounts payable department that actually buys the software and hardware we need to do our job and the corporate IT department. (Recall my example of the employer who prevented me from installing the software they were asking me to document.) The purchase order example is a good one; by tracking a purchase order through the system, I identified roadblocks that slowed the process, and asking how I could make life easier for certain key individuals encouraged them to show me how to remove many of the roadblocks.
The strategic planning group (usually senior managers) is a crucially important group that remains unknown to most writers. If we don’t know where our company is going and why, how can we contribute to reaching that destination?
Once you’ve identified these key groups, build, facilitate, and steadily improve your relationships with them. Obstacles inevitably arise, and you’ll find it easier to overcome them if you have allies. Whenever you need to negotiate more resources (time, money, equipment, people), you need to know who can provide those resources—but they will be far more ready to help if they understand why they should care about your group. Sometimes you can’t get what you want, for good reasons or bad, but can propose an acceptable compromise rather than simply accepting the fate that other groups force upon you. For example, product development schedules sometimes tighten unexpectedly, and if you can’t mitigate the change, you can at least work with your team on triage (i.e., deciding what things are most important and how you can achieve them in the time that remains). Conversely, schedules sometimes slip, and that means you may be able to relax a tight schedule and allocate more time to things you couldn’t accomplish under the former deadline.
The common theme here is that you must find ways to monitor the company’s pulse and detect changes that will affect your group. Your goal is to keep us in synch with the overall flows of information and tasks in the company. This requires both passive information reception (e.g., paying attention to memos and asking what they mean for us) and active intelligence gathering, such as contacting the managers of key groups every week or two. One often-neglected managerial role is to serve as a symbol of your group. If you’re recognized as credible, intelligent, and effective, your fellow managers will come to respect you and your group. I’ve had great success by finding ways to talk with managers several levels up the chain from me and convince them of my worth. Glen provided a quote that resonated because of the complaints I’ve heard so often from other writers: “Without support [in the upper reaches of the organization], the technology group is likely to become an organizational backwater, a permanent cost center viewed as a burden rather than as a strategic asset.” Sound familiar?
Much of what we do is unambiguous: there are 50 menu items and they produce 50 dialog boxes, and we need to document each of them. Other aspects of our work are ambiguous. For example, what role can we play in improving the usability of a product we’re documenting? Most writers have no formal training in usability assessment, but since we’re the first ones to see a product and the first ones to grapple with figuring out how it works, anything that we find difficult to document will be difficult for the product’s users. If we have a good relationship with the developers, we can often persuade them to fix usability problems. At a former employer, I knew enough about programming that I could talk to the developers in their own language, and that gained me their collective ear; that, in turn, let me propose interface improvements they would accept (see my articles in the bibliography on revising a user interface). But in many cases, that won’t be possible because tech comm managers haven’t established that kind of relationship with the developers, and our ability to critique the product is ambiguous.
Ambiguity creates uncertainty, and uncertainty breeds a lack of confidence that can prevent effective work on a problem. Eliminating ambiguity begins with clear statements of goals for each team member and for the team as a whole: each goal must be precise and measurable, any constraints or requirements must be clearly identified, and deadlines must be equally clear. Nobody can accomplish a goal they don’t understand. Moreover, we writers often feel the need to understand why we’re doing something, particularly when that something seems illogical. You can make our life easier if you explain the larger context in which we’re working.
It’s not easy being a manager, particularly since actions that are easy to describe may be enormously difficult to do in practice; anything related to managing people falls into that category. Creative people, such as writers and other knowledge workers, benefit from conditions that provide a sense of self-worth, a sense of self-direction, and a sense of confidence about what’s going on around us. We work better when we feel that our work is valuable, when we feel we have some say in the decisions that shape our work, and when we know precisely what tasks we must perform and how we’ll be evaluated based on the performance of those tasks.
As a manager, you must develop a standard approach that provides these things. But motherhood statements aren’t sufficient: you must “walk the talk” so we can be confident we’re working according to your guidelines and can understand why the goals you set should be important to us. If you can do this, you’ll gradually earn enough of our trust that we’ll accept those times you must make an arbitrary decision rather than leading us to consensus; this happens most often when sudden emergencies or new constraints make it impossible to wait for us to reach the right conclusion and act upon it. This becomes easier if you can schedule such interventions infrequently rather than implementing “the death of 1000 cuts”, which is what happens when decisions occur on an ad hoc, ongoing, endlessly recurring basis.
Glen emphasizes research by Howard Gardner (Leading Minds: An Anatomy of Leadership) that suggests leaders must create and project a narrative that explains how the world works and how both the leader and the followers fit into this story. If that seems abstract, think of it this way: All stories simplify a complex world into a form that provides a structure within which we can understand that complexity. That’s the goal of technical communication, so it shouldn’t seem strange to you. (This attitude, and the principle behind narratives, is encapsulated in a popular cliché among fiction writers: writing fiction is more difficult than describing the real world because fiction has to make sense.) If your actions and attitude clearly parallel the narrative, you gain credibility; if not, we’re intelligent enough to note the contradictions and question your credibility. The narratives you act out, as opposed to those you claim to espouse, reveal your true values. (“Actions speak louder than words.”)
It bears repeating that my advice is no substitute for getting to know the real people you’ll be dealing with. I’ve based this article on Glen’s well-respected book, with a reality check provided by my own management experience. Geeks, whether they be programmers, engineers, or writers, share some surprisingly strong commonalities, and certain stereotypes reflect those commonalities—yet we’re a far more complex bunch than those stereotypes suggest. Like chicken recipes from around the world, the meat may be the same, but the individual flavors make all the difference. (This metaphor is particularly apt now that globalization has expanded the range of ethnic cultures brought into the geek workplace, something I’ve experienced firsthand during my work with colleagues from India, China, Japan, France, Spain, Nordic countries, and many other cultures.) By all means, let the generalities I’ve discussed in this article help you understand writers as a group, but never forget that we must be understood as individuals.
Gardner, H. 1996. Leading minds: an anatomy of leadership. Basic Books, New York, NY.
Glen, P. 2003. Leading geeks. Jossey-Bass, San Francisco, CA.
Hart, G. 2001. Using VBA to prototype a software interface.
Hart, G. 2003. Streamlining an interface using information design principles. p. 378–381 in: Proceedings, STC 50th Annual Conference, 18–21 May 2003, Dallas, TX. STC, Arlington, VA.
Hart, G. 2002. Practical, effective metrics must solve problems. DocQment, the newsletter of STC’s Quality SIG. Sept.
Hart, G. 2007. Should we stick to the shadows, or take on a little more heat? Indus, the newsletter of STC’s India Chapter, 9.2, April–May.
Hart, G. 2008. Meetings 101: tips for more productive meetings. Intercom February: 26–29.
Hart, G. 2011. Uprooting entrenched technical communication processes: process improvement using the kaizen method.
Author bio: During a diverse career as a technical communicator and sometimes-manager, Geoff has worked with many difficult and challenging individuals. None of this prepared him for having to manage himself as a freelancer.
©2004–2024 Geoffrey Hart. All rights reserved.