Search results

Crisis Point: Problems with Multiple Roles (Overlooked)

Series: From Overlooked to Center Stage

by Tom Johnson on Apr 24, 2010
categories: beginners

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.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.