|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2009 --> Statecraft: applying the science of politics to office politics
Vous êtes ici : Essais --> 2009 --> Statecraft: applying the science of politics to office politics
by Geoff Hart
Previously published as: Hart, G. 2009. Statecraft: applying the science of politics to office politics. Intercom September/October 2009:8–10.
I once cynically opined that politics is what happens as soon as you gather three or more people together in one place and one of them leaves the room. Friends tell me I may have been unduly optimistic in assuming that more than two people are required. Politics affects more than just nations: it rears its ugly head in families, schools, and pretty much anywhere else people gather—including the workplace. Without going all Machiavellian on you, or delving too deeply into the murky waters of heresthetics, I do want to emphasize that understanding how office politics works can be crucial to our survival as working professionals. People seem to inevitably play various power games when they assemble in groups, and understanding the rules of the game is the only way we can play it well.
Dennis Ross knows a thing or two about the art of politics, having served as head of the U.S. State Department's policy planning staff during President George H.W. Bush's administration and as President Clinton's chief Middle East negotiator from 1993 to 2000. While reading a recent article by Ross, I was reminded of my statement. Whether or not you agree with Ross' critique of the current administration, he has interesting things to say about how desirable conclusions can be negotiated, and his approach can be extended to the office politics technical communicators often face. To be effective, Ross claims, negotiations must have the following characteristics:
Let's see how these principles apply, both theoretically and concretely, to technical communicators in the workplace.
Many of the articles you'll see in Intercom and STC's community or SIG newsletters call for us to become user advocates by emphasizing the importance of documentation and product usability. In most workplaces, it's simply not realistic to hope that we can instantly become the user experience experts, even if we've done far more reading and practical work in this area than our managers and product developers. Quite on the contrary: demonstrating superior expertise can sometimes backfire if it makes someone higher up the organizational hierarchy look bad in comparison. (Been there, done that. Still smarting—and somewhat smarter—from the wounds.) Even if our long-term objective might well be to become the organization's expert in user experiences, that's a patently unrealistic initial goal.
Instead, the goal must be to work our way into such a position gradually. At a former employer, I set myself a series of less ambitious objectives that would eventually lead me in the direction of a larger role. Initially, my goal was to get to know the programmers. I had no intention of becoming their friend, though if that happened, so much the better; all I wanted to do was to become more than a name on the organization chart, and get to know them well enough to be friendly at work. I achieved that goal by introducing myself—an obvious initial gesture many people never make—and spending enough time listening to them without asking for anything that they could see me as more than a supplicant.
My second goal was to see if I could find ways to make myself useful to them. That happened when I had an opportunity to edit the text used in the user interface; by working directly in a text file using revision tracking, I was able to clearly communicate my requested changes in a way that minimized their work in reviewing and accepting those changes. Given that I was already editing the text, one of them asked me for help shortening some text so that it would fit better within the interface. Having done so, and having mocked up some alternative dialog box layouts to show what I was proposing, I showed that my opinion was worth considering, and they subsequently began giving me opportunities to provide input on the interface. Shortly before I left to become a freelancer, I was even invited to a product design meeting so I could provide input—my ultimate goal.
In each case, I succeeded by means of a low-pressure approach, and by having the patience to accomplish a larger objective by means of a series of smaller steps.
As technical communicators, most of us have little power or influence in the workplace. This means that we must achieve our goals by means of persuasion. As STC Fellow Dan Voss memorably noted in a 1991 presentation, we are mice in a jungle full of elephants, and we won't have much luck if we try to confront those elephants head-on. But as the fable of Androcles and the Lion reveals, sometimes a small and powerless critter like us can find ways to earn the gratitude of more powerful beings who can then help us achieve greater things.
At a former employer, I volunteered to serve on a federally mandated workplace safety committee. Formally, I did nothing more than record the minutes, but informally, I also spent time getting to know the committee members and watching how decisions were made and how influence was exerted. When the employee representative serving alongside the management representative as co-chair of the committee stepped down, I offered to take their place and was accepted in that role—in part because nobody else wanted it, but also because I'd gained a certain amount of credibility through my participation in the committee. Because of the reality of the government workplace, my role of co-chair gave me a large amount of nominal power, but very little actual power. But because I had an opportunity to hone my skills at running effective meetings and achieving consensus, I was able to play a large role in shaping the committee's recommendations—much larger than my actual power suggested—and in bringing those recommendations to the attention of people with the power to implement them.
If you're the guy at the top of the organization chart, you have the power to tell everyone else what to do and how to do it, and the power to ensure that they do so. (Exercising this kind of power isn't always wise, and I mention this possibility because it exists, not because I endorse it.) Most technical communicators are so far from that position that we can only see it if we use the zoom tool provided by Adobe Reader—and even then, only if we have a large-screen monitor. This means that we can rarely force others to do what we say, even if we're right. Instead, we must use our powers of persuasion and clear communication to help others see what must be done, why it must be done, and how to do it.
In my case, despite having worn a surprisingly large number of hats during my career, I've worked primarily as an editor and writer. Both groups of professionals develop considerable experience and skill in translation or interpretation. Whether you're an editor working with authors or a writer working with product developers, you spend a surprising amount of time trying to understand what your colleagues are trying to accomplish and the words (for authors) or interfaces (for developers) they're trying to use to communicate. Less obviously, but equally important, you spend considerable time trying to understand what the audience must hear for the author or developer to accomplish their goal. Your role then becomes one of translating the author's or developer's thoughts into the audience's context so that communication happens. Over time, you develop a skill you may never have noticed: an ability to understand the thoughts and needs of both the communicator and their audience. This places you in a powerful position: Because you understand both parties, you possess an understanding that neither party possesses. That understanding allows you to translate between them in much the same way that an interpreter at an international conference translates between two nations. By paying attention to more than just the words—by understanding each side's needs, fears, and hopes—the best interpreters help to ensure that the two parties reach consensus.
By exercising this skill in the workplace, I've often been able to explain audience needs in a way that made sense to the authors I worked with, and in so doing, have been able to shape the nature of the communication. I'll provide a more concrete example of this under Acting at the right time.
After a few experiences of having our suggestions ignored, whether for good reasons or bad, most of us learn to shut up, focus on our job, and let others worry about larger issues. (Deadlines can also produce this effect when we simply have no time to do anything but concentrate on the task at hand.) This leads to a certain numb passivity in which we accept whatever is done to us and surrender the will to become actors; in so doing, we are acted upon, instead of acting. This kind of passivity is self-fulfilling because we blind ourselves to opportunities for action, and by missing these opportunities, rob ourselves of a chance to accomplish something that would renew our desire to change things for the better.
A common example arises in software documentation. Having learned the importance of audience analysis and user-centered design, we begin the project full of enthusiasm and the desire to change the world. Inevitably, we encounter problems and request that they be solved. But the intractable realities of tight deadlines and overworked developers mean that there's no time to act on those suggestions. So after the third time a suggestion gets shot down ("great idea, wish we had the time"), we give up and focus on completing our part of the job—getting the user manual and online help ready in time for the product release. Eventually, the product ships, and we spend the next few weeks recovering from our exhaustion—possibly even taking some long overdue vacation, or "comp time" earned through hours of overtime during the rush to meet the deadline. When we come back, the cycle resumes again.
But what we're missing is that even when product releases are tightly clustered, we usually have weeks or even months before the next major project starts gathering momentum. That's when we have an opportunity to remind people of the problems we raised during the previous chaos, and when we have time to actually take steps to correct those problems. And speaking of time...
One of the things you learn in the Japanese martial art of aikido is that you should never meet strength with strength, but rather use the opponent's strength against them. So, for example, rather than physically lifting your opponent off the ground and throwing them around by sheer force of strength, you learn to feel the person's shifting weight and apply your strength at the moment they begin to move; that lets you use their own strength to complete the throw. In the workplace, things are usually less violent, but the same principle applies: there are times when no amount of strength will be sufficient to move an obstacle, and other times when only a slight push is necessary; the obstacle's own momentum will do the work for you.
At a former employer, I'd been opining for some time that we needed to revise our reports to focus on user goals (implementation of our research), not just reporting of the research results. Though many people agreed that my suggestion had merit, nobody was willing to attack the status quo to make the necessary changes, which were perceived as risky. When the opportunity arose to survey our clients about how we conducted our research and disseminated the results, I volunteered to serve on the committee that created the survey. This gave me the opportunity to insert a few questions of my own and shape the form of several other key questions related to how clients used our research reports. When the survey results clearly indicated the importance of research implementation, I was given an opportunity to propose an implementation-focused redesign of our reports. By explaining how we could bridge the needs of our authors to communicate research results with the needs of our audience to implement those results, I was able to achieve consensus on how both goals could be achieved. The results were well appreciated.
It's always easier to persuade someone if they trust you—that is, if you have credibility. Each of the points I've raised in this article illustrates a way to gain credibility. Setting realistic goals shows that you understand the constraints that impede change, and that you're willing to move gradually towards those goals. Understanding the means to achieve those goals lets you adopt an appropriate strategy. Aiming for consensus helps you mobilize the resources necessary to implement that strategy. Acting rather than waiting for someone else to act lets you have some influence in how that implementation will occur, and acting at the right time ensures that your efforts won't be wasted. The sum of these results is credibility: the perception that you are striving for achievable goals in a way that is consensual, not manipulative, and that leverages existing momentum to cause a change instead of attempting to force change to happen.
As technical communicators, our skills focus on communication, and as I hope you've seen, each of the criteria for effective statecraft can be applied in the workplace with a little help from communication skills. Unfortunately, doing so may require us to take a step outside our comfort zone. In my own career, I've proven to my satisfaction that it's safe and effective to do so, and can have highly salutary consequences. But I've succeeded because I did more than write or edit quietly in my cubicle: I made a point of reaching out and making contact with my workplace colleagues, at all levels, and demonstrating that I was prepared to work both with and for them to help them succeed. Until I'd written this essay, it had never occurred to me that this made me a politician. I hope you'll trust my words despite that.
The difficulty in using the advice presented in this article comes down to a problem that's simple to state but exceedingly difficult to solve: the human factor. Every workplace comprises a slightly different and highly dynamic mix of people, each with a range of overt and covert goals and a sometimes bewildering array of personalities. The suggestions I've presented in this article are all logical and sensible, but understanding how to apply them in the real workplace requires us to devote considerable effort to understand the people we work with and how they interact. Without that understanding, even the most logical and effective suggestions can fail to have the desired consequences—as any student of international politics can tell you. The point of this article is not to present you with a list of approaches that sound great in theory; it's to teach you how the approaches work in reality. But making them work in your reality depends on your willingness to make the effort to understand your colleagues and on your skill at modifying these principles based on that understanding.
Start small, and learn the basics. Then begin applying them to larger and more complex goals. As my examples illustrate, you can accomplish far more than you might at first believe.
Hart, G. 2007. Should we stick to the shadows, or take on a little more heat? Indus, the newsletter of STC's India Chapter, Vol. IX No. 2, April–May 2007.
Moore, P.; Kreth, M. 2005. From wordsmith to communication strategist: heresthetic and political maneuvering in technical communication. Technical Communication 52(3):302–322.
Ross, D. 2007. Remember statecraft? The American Scholar, Summer 2007:47–57.
"Additional notes on Statecraft and When Statecraft Fails" presents series of responses to questions submitted by readers of this article and its sequel.
©2004–2024 Geoffrey Hart. All rights reserved.