Epiphany: Cross Pollination (Overlooked)

by Tom Johnson on Apr 25, 2010
categories: beginners

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.

Next: 2.1 Story (Overlooked)