I'd Rather Be Writing » roles

Strategy Versus Tactics and the Ongoing Debate about Roles

Tom Johnson — Tue, 26 Oct 2010 14:15:46 +0000

In the ongoing discussions about content strategy, one recurring idea keeps emerging: strategy versus tactics. The key differentiator between content strategy and technical writing is strategy. The content strategist develops a strategy; the technical writer carries out tactics to fulfill the strategy. The general develops the battle strategy, the troops carry out the necessary maneuvers to realize that strategy.

Which is more valuable: strategy or tactics?

Although strategy is generally held as a higher-level task (MindTouch says content strategists are the next corporate rock stars), others scoff at the value of “strategy.” For example, Dick Carlson, responding to Olivier Blanchard’s snarky post on the proliferation of self-appointed strategists, says,

This kind of talk is what used to get me in trouble at Microsoft. I used to tell people that “strategy” could be done in a few minutes, and that “tactics” took skill and experience and would go on for years and years.

Strategy: Sell low-cost goods in huge stores

Tactics: Build the world’s most efficient distribution chain in Bentonville, AK and beat the hell out of your suppliers for 20 years.

Strategy: Sell ok coffee in really nice stores with comfy chairs from people wearing green aprons.

Tactics: Spend years convincing emerging nations to sell you beans cheap, and spend years convincing yuppies to give you $5 a cup for flavored water.

I have always been proud to be a “tactician”, a “practitioner”, and a guy who knows how to actually take a messy battle plan and make things happen. And the Generals really like me, because they end up winning.

In other words, strategists aren’t the geniuses that get results. Instead, the genius is the innovative tactician who finds a way to overcome all difficulties and achieve the near-impossible “vision” of the strategist. Carlson suggests strategists simply state the end goal (for example, “to win the war against on terror”), whereas tacticians develop the ingenious plans to bring about that goal.

One could argue the matter differently. The strategist could easily develop the strategy with a lot more detail before handing it off to the tactician. For example, following the same theme, the strategy might be to “win the war on terror by launching a massive education campaign that targets the youth in Afghanistan to understand the benevolent motives of the West.” The tactician would then figure out the details of the education campaign, such as creating literature, providing scholarships to Western universities, or implementing humanitarian aid camps.

Exactly how basic or detailed the strategy is might vary, but we should be careful of assigning the tactician to a lower-order thought process.

In the context of help authoring, the strategies might also be basic or simple. A simple help strategy might be to help users learn a software application. Such a strategy is no more ingenious than a leader’s strategy to win the war on terror. We all probably support the strategy of helping users learn an application, but how on earth are we going to achieve it?

At this point, the tactician arrives and begins to analyze the audience’s most troublesome pain points, designs a series of short guides targeted at each pain point, and provides this information as attractive job aids that the users can pin up around their cubes. In this case, the tactician is the genius; the strategist is the simple thinker.

One could equally argue that the strategist develops a more detailed plan. For example, our strategy might be to help users learn this application by targeting their pain points and developing short one-page guides that users can easily pin up in their cubes when they run into problem situations. The tactician, then, would begin to determine what these user pain points are, create attractive layouts for the guides, and maybe even laminate the guides and include a box of pushpins when distributing the guides. In this case, the strategist is the genius; the tactician is merely the worker bee.

Does thinking strategically make you a content strategist?

Olivier Blanchard on the Brand Building Blog keeps maintaining a constant idea. He says,

Content is tactical, not strategic.

In his view, you can have a communications strategy, but the content you produce supports that communications strategy, so content is tactical, and not strategic. He rejects the semantics of the term “content strategist” and instead prefers someone to be a “communications strategist” who develops content to support a communications strategy.

As a technical communicator, I don’t object to either way the argument is positioned. Whether you’re a communications strategist who develops content to support your strategy for communicating to users, or a content strategist who develops content in support of a strategy to communicate to users, does it really matter?

In a comment on the ongoing thread on Sarah O’keefe’s Scriptorium post on Content strategy for technical communication, Larry Kunz, who played a part in earlier distinctions between the term technical writer and technical communicator (see You May Already Be a Technical Communicator!), points out that despite the shift to content strategy, the semantics may not have any impact on tech comm professionals in the workplace. Larry writes:

… On Monday morning [despite my new title as a content strategist] when I walk into the client meeting to talk about the new project, they’re going to say “We need you to create some PDFs.” It’s very hard to move managers away from that mindset.

It’s hard, but we have to try. Do you think it will make any difference if we start referring to ourselves as content strategists rather than as technical writers or technical communicators? Put another way, if I refer to myself as a content strategist, will that Monday meeting go any differently? Instead of saying “We need some PDFs,” might they say “Tell us how we can make our content work more effectively”?

In other words, does changing our job title change how others in the workplace perceive and interact with us? About two years ago, as we were redefining my group’s name in my organization, I complained about the way the term technical writer pigeonholed me into a stereotype about providing writing tasks and nothing more. As a result, we changed our group’s name from User Education to Information Strategies and Design. At the time, Information Strategies and Design sounded sexy and high profile. It sounded a bit mysterious too, so no one could simply dismiss us as writers only.

But as I introduced myself on project teams, noting that I’m on the Information Strategies and Design team, no one had a clue what that meant. Over time, to deal with the confused looks, I gradually moved back to saying User Education. It’s a term people understood. My role, for the most part, was to provide education.

I’m not dismissing the power of names. My official title is “Senior Technical Writer.” And project managers almost always consider me just for writing tasks, giving audiovisual deliverables, design work, or usability research to other people and departments. I’ve written about this frustration before in “Tech Writer: ‘Someone who writes as opposed to someone who rides something’, The Name of Your Department Does Matter,” and my series From Overlooked to Center Stage.

But I have learned another truth: actions are more powerful than nomenclature. When you start acting strategically, when you listen to a project manager’s request for a certain type of help and you say, Yeah, well, let’s think about that a bit more, doors open up. People start treating you differently; you start exchanging ideas about strategies rather than tactics. The job titles fall by the wayside and you start functioning as a key team player without regard to a specific role.

Future Discussions of Content Strategy

I have been somewhat obsessed about the topic of content strategy lately, but I predict that this buzzword will soon blow over as the heated topic among tech comm professionals. Here’s why. Besides the fact that almost no one’s job title is “content strategist” in the field of tech comm, the discussions about content strategy spin around endlessly on semantics and definitions, with no real substance behind the conversations. The discussions about content strategy mostly revolve around what a content strategist does, and then devolves into abstract debates about roles and nomenclature and who should do what.

For example, in my previous post, I delved into strategies for achieving relevance, findability, and clarity in tech comm projects, but those topics weren’t that exciting or controversial. My final note about content strategy nomenclature, however, incited comment wars.

Yesterday Gary Franceschini summed it up well, explaining that the last section overshadowed the former content. Gary writes,

An excellent post, Tom.

However, my main takeaway from this article isn’t in your content — it’s in the posts that followed it.

Why? Because the discussion quickly dropped into a battle of semantics, theories, and philosophy. This concern with how-we-work over end-product has an immediate deleterious impact on what gets put in front of users.

Therefore it’s really no wonder so many users detest “help” and other forms of technical communication.

Amen to that. We get far too caught up in what to call ourselves. Many tech comm professionals have spent years battling between the terms “technical writer” and “technical communicator.” These semantics have achieved little in the workplace, and only serve to reinforce our futile goal of landing on the right term that will earn us sudden respect and recognition on project teams. It’s a kind of navel-gazing form of self-pity and attempted aggrandizement.

Everyone seems overly occupied with titles and roles rather than the problems and solutions users face.

As I said, I think the discussions will lose velocity and return to the core that Gary suggested: the end product rather than the how-we-work. Here’s an olive-branch like sign that gives me hope. Yesterday I saw an description from the STC for an online 101 certificate course from Leah Guren. The description begins,

Technical communication is an exciting and challenging career that offers unlimited opportunity for professional development. But to succeed, it’s not enough to learn a desktop publishing or Help authoring tool—you need to master the analysis process. This is a thinking person’s dream career!

A thinking person’s dream career. Wow. I could not help but contextualize this remark within all the discussions about content strategy and tech comm and tech writing. All the lines people have been carefully drawing and delineating about who develops strategy and who doesn’t — it’s quite ridiculous. Regardless of any job title, you do what’s necessary to solve a problem. You think and analyze and strategize and dream and then work, work, work. When you forget your title and self this way, whether you’re a content strategist or technical writer or information developer, positive things start to happen. You achieve real solutions that influence the user experience.

Blog Sponsors

The Role of the Gatekeeper

Tom Johnson — Wed, 28 Jul 2010 06:04:27 +0000

Sarah O’Keefe’s guest post — The Role of the Gatekeeper is Changing — on Peg Mulligan’s blog is interesting. Sarah writes,

The Internet is removing the traditional gatekeepers for content.

This may seem obvious, but its implications in my life have been profound. I majored in English and then earned an MFA in creative writing. After graduating, I gathered up my best essays and sent them off to literary journals for publication. After months of waiting, I didn’t publish hardly anything. It was frustrating. They were good essays, but they didn’t have the right focus. That timeframe was about 1999 to 2002.

A few years later, I started blogging. First in an experimental, non-committal way. Then I started to gain more focus, and after a while, I realized that I could have as much satisfaction publishing online on my blog as I could in any print journal.

I realize Sarah’s comment was in the context of technical communication, but the principle is the same. Whatever you want to publish, you can. There are almost no restrictions on the Internet. Collaborative platforms empower even the most technically illiterate people.

Sarah writes,

There’s never enough time for in-house professionals to create all of the content that’s needed. Contributions from the user community can provide additional support and build on the official core content.

This statement is more relevant to me now more than ever. I was enthusiastic about a particular project at work, and two weeks into it, the budget dropped. I have to take my half-written help content to the community to help finish it off. And while I have volunteers, I realize that I need a solid collaborative platform with clear directions, easy tasks, and a lot of management and feedback to be successful with community efforts. All my previous efforts to involve community in writing documentation have mostly failed.

Sarah writes,

There is a temptation for business executives, especially in cash-poor start-ups, to dismiss their technical communication staff and simply rely on the community to provide documentation.

This trend always astounds me. Even in my organization, support for professional technical writers varies significantly from department to department. On some projects, the customer (in a specific business department) has a designated writer who handles the material. On other projects, we (the IT department) provide help. But it always frustrates me to see a project manager marginalize help and dismiss the technical writer’s role. In fact, I need to meet with a project manager tomorrow to try to talk sense into him.

Blog Sponsors

Introducing Project Swordfish [Organizing Content 2]

Tom Johnson — Mon, 17 May 2010 13:56:07 +0000

Welcome to the new project you’ll be documenting: Project Swordfish. Project Swordfish is an application used by the FBI to train agents in virtual simulations of undercover operations.

With Swordfish, users can be super agents and regular agents. The super agents can configure the permissions of the regular agents with 20 different permission settings. This means the relevant help topics for any agent can vary from about 10 topics to all 200 topics, depending on the permissions an agent has.

An agent with all 20 permissions will find that every topic in the help is relevant. An agent with no permissions will find that just a handful of topics in the help are relevant.

Some of the permission settings for the agents include the following:

Allow agent to view master operations list
Allow agent to create new operations
Allow agent to close operations
Allow agent to create operation maps
Allow agent to add or remove members from his team

You get the idea. (By the way, this isn’t real.)

In Swordfish, agents are grouped into teams. The same agent can be on multiple teams, with different permissions on each team. For example, an agent can be a super agent on the Black Operations team, but a regular agent on the Public Operations team. Agents can even be double agents, so that they appear to be regular agents on a team but are actually super agents, and vice versa.

Project Swordfish has a moderately complicated interface that warrants approximately 200 help topics. Help topics include several types of topics: conceptual topics, task topics, videos, context-sensitive help topics, and FAQ topics. You need to create both an online help file as well as several printed guides. Your main task is to organize the help topics in a way that makes sense to users.

Content organization is the focus of this series, so that’s what the upcoming posts will explore — different ways to organize content from this hypothetical documentation scenario.

Blog Sponsors

The Do-It-Yourself Philosophy: Saul Carliner at the STC Summit in Dallas, #stc10

Tom Johnson — Mon, 10 May 2010 04:07:55 +0000

In this video, I interview Saul Carliner about a post he wrote on his blog describing the “do-it-yourself” philosophy and whether this philosophy is something technical communicators should embrace or fear.

Blog Sponsors

From Overlooked to Center Stage [10]

Tom Johnson — Sun, 18 Apr 2010 06:54:09 +0000

Epiphany: Cross Pollination

Ultimately, what my colleagues had to say did have merit. There is a point that, in playing too many roles, you spread yourself too thin. You compromise your specialization and expertise as you step into unfamiliar territory. There is a limit to the number of roles you can play, and perhaps I had stepped over that limit.

But I believe I also experienced the idea of cross-pollination. In biology, cross pollination refers to the mixing of species by taking pollen from one flower species and spreading it to another.

In an intellectual sense, cross pollination refers to the advantages that come through diversity of perspective, background, experience, knowledge, ideas. When you bring professionals together from “different species,” so to speak, they cross pollinate and create new ideas, hybrids, innovations, and advancements. But if everyone always works within his or her same knowledge domain, the diversity doesn’t often cross-pollinate. If people do their jobs and just report to the project manager, they remain in silos.

On the other hand, when you have these professionals walking in each other’s shoes, playing each other’s roles, seeing problems in unfamiliar domains from new perspectives, insights to problems come more easily. New approaches and methods appear more readily.

It’s the same perspective you get when you have others critique your documentation. The more unique a reader is from you, the more advantageous his or her perspective will be. The reader can show you what you can’t see. The reader has a perspective you can’t access yourself.

As I as writing one day, I realized that my extension into these other areas had made me a much faster, more efficient writer. It made me more aware. From my interactions with customers, I could better imagine personas. Often after writing a topic, I would picture that frazzled user who had me on speed dial and wonder if he would actually get what I was writing. I could think about specific users, like the people in Europe who traveled constantly, or the executives in audiovisual, or the mission presidencies in Russia. I could step inside the heads of the users better because I had actually interacted with them. The questions they would ask would naturally be on my mind as I wrote documentation.

The bugs I was logging integrated me with JIRA. I knew how to look and see if bugs and quirks would be fixed or not. I learned how to speak and communicate with developers. I could also see bugs where QA engineers could not see them, because I brought the perspective of documentation as I explored the application. I could anticipate possible problems on different screens in ways QA couldn’t. And as I applied the tools of documentation to my bug logging, adding screenshots with callouts and videos, I introduced QA to new methods that they adopted.

As I created scripts for my videos, I began to see how the dry, technical language in my help topics contrasted with the lively, conversational voice I had to implement in the video scripts. As I wrote, I often imagined myself speaking to the user in a video script. It’s amazing how conversational that helped me to be.

Because I was more of a presence in meetings and outside my cube, people trusted me more. They more freely communicated with me more to relay problems and issues. I could be a better wiki manager because I was accustomed to interacting with others, giving guidance and feedback in tactful yet assertive ways.

All of these ancillary activities weren’t detracting from my ability to do my job. Instead, they were enhancing my ability to do my job. I was becoming a better technical writer not in spite of these other roles, but because of these other roles I filled.

Given this cross-pollination effect, I openly welcomed the new roles I would play. Each new role would give me a new perspective, a new pair of eyes. And the more I could see the project from different perspectives, the more of an asset I would be to the team and to the success of the project.

To come back to a few quotes at the beginning, I mentioned some experiences from disgruntled technical writers on a guest post called The Raw, Unvarnished Truth. Last week someone posted the following comment:

I have been a technical writer for over 22 years. During the 1990s, at the time of the dot.com bubble, the field was exciting and challenging. Now, with the bust, technical writers often do nothing more than edit dreary procedures. I have found that working for small or medium-sized companies is much more exciting than working at a large corporation. …

The writer continues on for a bit after that to relate the drudgery of working for large companies. But let’s look at the sentence about working for small or medium-sized companies.

Why is it that technical writers working for small or medium-sized companies might find the work more exciting? Although the user doesn’t say it, I know why. In small companies, you wear many hats. You play many roles. You’re not pigeonholed into one specialized role all day long. Sometimes you’re the marketer. Other times you’re the instructional designer. Or the tester. Or customer support. Or the interaction designer. You probably interact with the CEO on a regular basis.

I recently interviewed Mike Hamilton for a podcast, and he said he started his career as a physicist and ended up at a software company. I asked him how many different roles he played at Madcap. His response:

Pretty much any hat that’s not being worn by somebody else the day we need something to happen.

I’d bet that almost every one of us transitioned into technical writing from some other career. Maybe not physics, but perhaps like me, coming from teaching and copywriting, or something similar. At some point in time, we decided to put on the technical writing hat and fill the technical writing role. Role playing is something we naturally do. We’re not technical writers playing other roles. We’re people playing many roles, one of which is technical writer.

Blog Sponsors

From Overlooked to Center Stage [9]

Tom Johnson — Sun, 18 Apr 2010 06:38:48 +0000

Crisis Point: Problems with Multiple Roles

As my attempt to fill the wiki role failed, I started to realize how busy I had become wearing all of these hats. It seemed that I was always logging bugs, answering phone calls or responding to emails, or attending this and that meeting, championing for a redesign of a page, or coordinating with projects. The core help I was supposed to deliver wasn’t getting done.

I knew that I had been sloppy and careless in a lot of the help topics, and I just hadn’t had the time to go back and carefully review all the content for the upcoming releases like I wanted to. I was being stretched in so many directions, it was hard for me to do what I was initially hired to do: create help material. At times I would refuse to answer simple emails because I knew it would take me out of my rhythm and make it harder for me to get my work done.

I started to reach my limit when one frazzled user put me on speed dial. He called me what seemed like several times a day over the course of a couple of weeks, and each time he called he would ask questions and ramble and complain.

I realized that if just three or four more users were like this also decided to put me on speed dial, I wouldn’t be able to get anything done. Our user base was expanding with the new release, and the project manager was now asking me to creating marketing slicks and big picture workflow diagrams that they could pass out to users. I just didn’t have time to get to all of this.

When people made these requests, I would kind of nod and say okay, I’ll do it, but as the release date approached, I was so busy setting up my online help file and adjusting the style sheet and the targets and integrating the videos and putting everything else into place, the days ended before I could dive into the actual content.

It wasn’t just a matter of time, though. I also started to question the appropriateness of filling so many different roles. Although I have good common sense, I don’t know a lot about usability, quality assurance, project management, e-learning, or even live training. I do know documentation well, and I keep up with the latest trends and best practices in this field. Was I doing a disservice to my organization by filling roles about which I had little professional expertise?

I started to think back to a conversation I had had with another QA engineer when we used to drive in together to work. We must have had this conversation at least half a dozen times while driving at six in the morning. I would complain that there weren’t enough technical writers working in our organization. I said a ratio of about 4 technical writers for 600 IT people was ridiculous.

My QA friend kept wondering why, given our limited technical writing resources, I would spend time filling other roles — especially if we already had people designated to fill those roles. If I truly wanted to expand my influence and provide documentation for all of these applications and sites that lacked help material, I wouldn’t try so hard to do QA. I would let QA do QA. I wouldn’t try so hard to do design. I would let interaction designers do design. I wouldn’t try to provide support. I would let the service desk provide support. And so on.

He even said I shouldn’t try so hard to write comprehensive documentation. I could just create quick reference guides and jump from project to project to project, providing only as much help as 80 percent of the users would actually need. But regardless of my approach, overall he said that it wasn’t efficient for me to do the roles that other people had been assigned to do. Doing so created unnecessary overlap.

I thought about this, and wondered if in fact wearing multiple hats wasn’t a good idea after all. Perhaps I should have just remained in my cube and quietly created help materials in the most efficient way possible. Unless I knew something about these other roles, these other hats I was wearing, I perhaps shouldn’t wear them. After all, ultimately it wouldn’t be that helpful to the team if i were exerting my influence in areas that I knew nothing about.

Finally, what did playing these other roles ultimately do for me? It seemed that at the end of the day, I was still evaluated on the help material I produced, not the number of bugs I logged, not on the number of design suggestions I championed, not on the number of users I helped. Those seemed to be invisible efforts that, although appreciated, ultimately remained somewhat invisible. But you could hold a manual in your hand. You could see an online help system. You could watch an instructional video. And you know who produced the material, and you can evaluate the employee based on those products.

I asked my colleague what he thought about playing multiple roles. Was it a good idea?

Paul Person (“doc guy” in the Flare forums), said it’s good to fill other roles as long as you’re able. But you can’t really keep up your own knowledge about how to be a good technical communicator if you’re spread so thin in other areas. If you’re constantly moving into other areas, you suddenly don’t have time to keep up on the latest trends and best practices in your own field, let alone in the other fields.

Blog Sponsors

From Overlooked to Center Stage [4]

Tom Johnson — Sun, 18 Apr 2010 05:39:47 +0000

The Yearning: Career Trajectory

Although my chief interest in life is writing, more literary writing than technical writing, not surprisingly I wanted something more from my career. I wanted my career to be fulfilling and worthwhile. At this time, I had been blogging for a couple of years and had recorded dozens of podcasts. I had talked to professionals in the field who had said things like, if all you do is write, you’ll soon be fired.

In the trends panels at the STC Summit, I remember listening to Andrea Ames, former STC president, talk about how her role at her company was not just a tech writer. She was like an indefinable, a strategic innovator who solved problems, not just someone who wrote documents. She was enthusiastic and engaged. I wanted to move in a direction like this rather than sit quietly writing manuals that no one was going to read, or drawing little Visio diagrams.

I later spoke with Bogo Vatovec for a podcast and asked him to expand on the issue of roles. He explained,

Doing what you’re told to do and what you’re expected to do is nowadays simply not enough anymore. You always have to do something more than what you’re basically supposed to be doing.

I also talked with Jack Molisani, who said all writers needed to become hybrids in order to make their professions take off. In a podcast interview I recorded, Jack explained the essential career path technical writers needed to follow:

To be successful over the next 10-15 years, tech comm people are going to have to become hyphenated. You can’t just be a technical writer. You have to be a technical writer-usability expert. Or a technical writer-accessibility expert. Or a technical writer-project manager.

It was clear to me that in order to be successful, to avoid sinking into oblivion and dissatisfaction, I would need to do something more than what I was doing. But it wasn’t just a strategic career move. Inside I wanted to do something more. I felt I could do a lot more.

Blog Sponsors

From Overlooked to Center Stage [2]

Tom Johnson — Sun, 18 Apr 2010 05:15:18 +0000

A Poignant Realization

The other week at work we had a first-ever community developers conference. People from all over the state and even the nation came to the conference to participate in the community software projects. As facilitators for the volunteers, my colleague and I were asked to lead a tech writing “deep dive” for the participants who would be working as technical writers. We thought curiously about our potential audience. Would there even be any technical writers attending the conference?

As we prepared the session, we thought more about exactly who the track participants would be. It didn’t take long before we decided what the technical writing deep dive was all about. For people who wanted to help out with the projects but lacked the technical skills to code, they would be assigned as technical writers. The tech writing deep dive would be a way for the non-developers to participate, because after all, if you can’t program, at least you can write.

Realizing this might be the intent, it put our whole team into a fanatical, frustrated state of hysteria and laughter. We broke out in the kind of laughter that is both madness and frustration at the same time. It’s madness and frustration because the idea that anyone can write belittles our professional capabilities. It minimizes our skillset and makes us nothing more than replaceable drones whose job anyone, with a little common sense, can easily do. At the same time, we knew the idea wasn’t really feasible.

Now, these projects really did need technical writers. It wasn’t a cute little thought someone dreamed up at the last minute. But it turns out we were mostly right. About two thirds of the people who showed up to our tech writing deep dive had never done technical writing before. As I gave a tech writing 101 crash course with my colleague, I saw their faces light up when I explained simple concepts about what technical writers do.

The conference went well, but the technical writing deep dive gave me something to ponder: the assertion that “anyone can write,” or that writing is a basic skill almost everyone has, is an assertion that threatens technical writers more than anything else. Whenever you bring up this topic, technical writers get defensive and edgy. They blow off the assertions with laughter, but while they’re laughing their foreheads are turning red and veins and popping out with anger.

Whether the assertion that anyone can write is somewhat true or false is beside the point. It’s a widespread perception many IT departments have. And perception is the reality people act on.

Fortunately, technical writers can do more than write. In fact, technical writers can move in the completely opposite direction, moving from an overlooked peon that everyone assumes is “just a writer,” whose skills everyone else also has, to a key influencer who moves about on the center of the stage in the development of the project. I’m going to describe that journey.

Blog Sponsors

If you’re in Atlanta next week, be sure to check out Currents

Tom Johnson — Sun, 11 Apr 2010 20:43:14 +0000

I’ll be in Atlanta next weekend giving a talk (the keynote, actually) at the STC Atlanta Currents conference. You can read more details about the conference here.

My presentation is titled “From Overlooked to Center Stage.” Here’s the description:

The rate of online information continues to increase dramatically. Both professionals and amateurs in every field are publishing content on blogs, forums, websites, intranets, podcasts, and more. An attitude of do-it-yourself is increasingly common, as is the feeling that anyone can write. In a world where writing skills are becoming less valued, how can technical writers avoid being overlooked and instead move closer to center stage? Diversifying your skills, wearing multiple hats, and becoming experts in a complementary field (such as multimedia, web development, testing, usability) can help. Writers can also rise above ordinary content by developing the most compelling aspect of communication: story.

Exactly what does this mean? I’m trying to stretch my mind around two main concepts: moving beyond the writing role, and moving deeper into the writing role. It’s a topic that has occupied my mind for a while. First, we limit ourselves by restricting our role to just writing documentation. If all we do is write, we’ll eventually be replaced, outsourced, or overlooked. We can do more than write. We shouldn’t confine ourselves to this limitation.

Ultimately, though, our role usually involves writing. That’s often the technical writer’s flagship deliverable. But when it comes to writing, we do a poor job. We write dry material that makes readers yawn. We may write clearly and grammatically, but we overlook the larger structure of story. Story informs technical communication genre just like any other communication genre.

I only have an hour, and in preparing this presentation, I see that I may not get past the topic of multiple roles. However, I’m trying to structure the entire presentation as one big story, so hopefully what I don’t explicitly say about story will come through in an even stronger way through the presentation format.

Blog Sponsors

Tech Comm Lobotomies

Tom Johnson — Tue, 04 Aug 2009 13:59:14 +0000

Yesterday while driving I listened to a “Stuff You Should Know” podcast on transorbital lobotomies. Popular in the 1950s, the transorbital lobotomy was a procedure Walter Freeman performed by inserting an ice pick on the inside of your eyelid up into your frontal cortex to destroy the white matter tissue that was believed to cause extreme mood swings, schizophrenia, anxiety, maniacal behavior, or some other socio-emotional problem, such as “rebelliousness.” The popularity of lobotomies lasted more than 20 years and included about 40,000 patients in the U.S.

In case you can’t quite picture it, click here. (But avoid if you have a weak stomach.)

Today, the practice of lobotomies is considered revolting and barbaric. It cuts against our very sense of acceptable medical, human, and ethical practices. We’re all glad ice-pick lobotomies are now illegal. But from a broader historical perspective, the lobotomy provides a kind of symbol for those activities that, in retrospect, we are embarrassed to admit we once practiced.

In the field of technical communication, I’ve had my share of figurative lobotomies. The first ice pick in my frontal cortex happened during the initial week I became a technical writer. A senior writer/mentor introduced me to my first project and explained, “The business analysts are very busy. Try not to bother them.”

With this seemingly innocent remark, from the start she indoctrinated me with the idea that technical writers shouldn’t bother other project members, that we needed to passively acquire our needed information on our own. If we should venture to speak to the Business Analyst, or an even more daring figure, the Project Manager, we would be encroaching on their time and space with our smelly peon presence.

This passive mentality was, as I later found out, about the worst characteristic a technical writer could adopt to survive. A better mindset for the work of technical writing would have been that of an investigative journalist or a Guantanamo interrogator.

For more insane patients, Freeman performed transorbital lobotomies not just in one eye, but in both. Keep in mind that to actually reach the frontal cortex, he had to poke through some bone. So these procedures were not painless. To render the patients unconscious for the procedure, he used electric shock, thus compounding the barbarity of the procedure.

For my second eye, the figurative lobotomy happened in a less direct way. Through unwritten department policies about video tutorials, I was led to believe that my own voice was not good enough to use in a video tutorial, should the tutorial even use voice. A proper video tutorial needed professional voice talent. Therefore, if I made video tutorials, they must use captions and be silent.

Again, the damaging message this ice-picking taught me took years to heal. It introduced me to the idea that my voice was poor, perhaps corrupt. It stifled me — similar to the advice of not talking to subject matter experts. Only this time, the rule was not to talk at all, because I did not sound like a commercial narrator and could not learn to improve my situation either.

In retrospect, I later learned that I could record my own voice-based tutorials, and they were highly preferred over the silent ones, even if I didn’t sound like a professional voice talent. Further, because I controlled every aspect of the tutorial, I could pull from my help material for the scripts, record and re-record and edit to my heart’s content, and do it all in a quick, efficient amount of time. In the many video tutorials I’ve created since then, not once has a user complained about the quality of my voice.

Back to Freeman. Walter Freeman became so practiced with his lobotomy techniques that one time he performed a double transorbital lobotomy at the same time — that is, holding an ice pick in each of his hands and inserting them simultaneously inside both of the patient’s eyelids. During one demonstration of a double transorbital lobotomy, the patient, a woman, had two ice picks stuck inside her eyelids when Freeman paused to get a camera and take a picture. As he reached for the camera, one of the ice picks fell and immediately killed the patient. Freeman simply packed up his gear and drove to the next town.

The performance technique behind Freeman’s practice of lobotomies also has some figurative application as well. Some of the barbaric, primitive practices in tech comm are also fueled by managers, leaders, and professionals who enjoy the show they’re putting when they enforce standards. For some, it’s not enough to deliver a figurative lobotomy to another individual. One does it with a sense of arrogance, a touch of showmanship, pride at years of experience, and an attitude of hierarchical mentoring.

In this attitude, without good reasoning, many project managers and others often lobotomize technical writers with the common assertion that “you can’t talk to the user.” Ultimately the managers have no sound argument but manage foist the idea on technical writers anyway. This is perhaps the most invasive lobotomy of all, because it cripples you from the very start. Without interacting with the user, you can’t learn the user’s vocabulary and the tasks they need to perform. Without a knowledge of user vocabulary and tasks, your help material is destined to be unhelpful. Without helpful user assistance, your role on the project team and your own sense of importance on the project diminishes. Eventually, your job as a technical communicator is pulled out from under you during budget cuts.

Although we look at the past with embarrassment about some of our practices, we often lack the foresight to see the present with the same degree of scrutiny. Years from now, we’ll look back at what we’re currently doing and not only blush, but feel remorse and wish we could get back what we lost.

———-

Additional Resources

The Stuff You Should Know podcast I referred to was recorded May 19. You can listen directly here or search for “Stuff You Should Know” in iTunes and listen to the May 19 episode. Another great podcast is Howard Dully’s “My Lobotomy” journey on NPR.