I'd Rather Be Writing » growth

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 [7]

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

Catalyst 6: QA Testing

As if I hadn’t already been wearing enough hats, participating in both design, support, training, and help, I soon started to wear another hat: quality assurance (QA). We use JIRA as our bug tracking tool. It’s mostly used by QA and developers to log bugs, enhancements, and user stories. I always knew it would be good practice to keep abreast of the items added to JIRA, so I could know if the application was in sync with the help, or if bugs were leaving gaps in the accuracy of my instructions. But that was the extent of how I perceived JIRA to be relevant to me.

As I was testing my instructions (one of the most important ways to review documentation), I kept running into bugs in the application. At first I forwarded them to the QA developers through email. I wasn’t sure if they were already logged in JIRA or not, and I felt it wasn’t my role to log bugs anyway.

But soon QA started asking me to simply log the bugs. They gave me the appropriate rights in the JIRA. Okay, I thought. I’ll do it as a convenience to them. So I started to figure out JIRA, and I kept more up to date with the information and comments there. I started to log a few bugs, and then a few more. In a somewhat sadistic way, logging bugs felt therapeutic. Pretty soon I felt no fear at all and logged 25 bugs in one day. This got the attention of the developers and the project team in an astounding way.

Everyone was surprised at the degree of bugs I was finding. The QA lead had developed an extensive number of automated scripts, but he wasn’t finding all the bugs I was finding. I was finding a surprising amount of bugs precisely because I was simply going through topic by topic in my help documentation and testing everything (really testing my instructions but also the application at the same time).

I realized that I had literally written a book on the application — something no one else on the project had done. I knew the application as intimately and thoroughly as anyone else on the team, if not more. With this knowledge, especially combined with the user knowledge, I could see bugs in places QA never thought to look. Over the course of a week of heavy review of my help, I logged about 65 bugs.

One thing I was also doing was using SnagIt and Jing to show the bugs. All the other QA members just described the bugs with text. It quickly became clear that pictures were the preferred mode for developers to see bugs. They soon joked that unless the JIRA item included a screenshot, they wouldn’t review it. After a few weeks, the QA team also started to include screenshots.

QA considered me an addition to their team and said I would make a great QA tester. I thought they might be upset at the QA spotlight I was taking, because I was logging three times as many bugs as they were, but instead they thanked me for logging the bugs and genuinely appreciated it. (It would save them face later to not have bugs found in the production release.)

Pretty soon in meetings I was no longer someone they passed over quickly at the end. I was a key voice in bug triage, scrum, and other meetings, where developers and project managers would need to evaluate the bugs they were going to fix. I wasn’t just sitting there listening to others talk. Instead I was explaining the bugs I found, and evaluating the seriousness of the problems.

I noticed another thing — if I logged a bug in JIRA, someone usually fixed it. Not always, but it was the secret passage way into influencing the application. Even small fixes involving textual changes were something I could sneak in and get done. Soon one of the new developers on the team starting coming to me to ask if his planned fix was all right with me. I already owned all the text in the interface, but now that domain was blending into functionality.

On one occasion, I found a screen to be particularly problematic. I had a tough time describing how it worked, and the video I created was even more problematic. I also logged about five bugs against that screen alone. I made such a big deal of it that I convinced the project manager that, despite the time crunch and our lack of resources to fix it, we couldn’t skimp on this. He told me to get with the developers to redesign the page.

It wasn’t easy. I sat there thinking for a while, somewhat stumped on how to fix and clarify the process. I brainstormed together with a QA person and developer, and within 15 minutes we came up with a solution. We, not I. Not a single person, but we.

This was another experience where I wasn’t just documenting what is, or what had been coded. I was actually driving the design. I was determining what developers would work on through the JIRA items I submitted. I had zeroed in on the most problematic screen in the application and redesigned it.

We often come across problematic screens, but it isn’t until you start logging bugs that it actually forces project managers and developers to formally evaluate the problems and make a decision. Logging bugs makes you extremely visible on the team, because it forces an intersection point between the developers, project manager, QA testers, and you.

At this point I realized that I was much more than a simple technical writer on the team. I was actually part of a team. I was an integral player, contributing everything from help materials to customer support and training to user interface design and quality assurance and the product roadmap.

My main role was still to deliver help materials. Of course that’s one of my main contributions on the team, but it certainly wasn’t the only thing I did anymore. I had moved from overlooked to one of the main actors on the project stage.

When I would travel with the product manager to introduce the application to new groups of people, he had a hard time describing my role. He didn’t just say, this is Tom, he’s a technical writer on the team. At times he would say, Tom is our director of user education. Other times he would say Tom is our usability specialist. Other times he would say that Tom is one of our team members. Other times he would just look at me and pause before trying to figure out how to describe my role. The role he pinned on me corresponded with the purpose of the meeting.

The need to expand our roles, to move beyond what our company pigeonholes us into doing, is one of the encouragements I received from Mark Hanigan, former STC president. In one podcast, Mark told me,

It’s up to the technical communicator to market him or herself to the other individuals, the project managers, the appropriate departments within the company, saying hey, wait a minute, why do we have this separate entity of business analyst and technical communicator. I can help you with both. And we can provide deliverables that are faster, better, cheaper. And here’s why. And then you go on to explain to them what you can bring to the table.

It is up to us. We can create the opportunities that transform our role, but it has to be a conscious action. No one will magically change our jobs for us.

Blog Sponsors

oDesk Reports “WordPress” Fastest Growing In-Demand Skill in 2008 « WordPress Publisher Blog

Tom Johnson — Tue, 13 Jan 2009 21:09:55 +0000

oDesk Reports “WordPress” Fastest Growing In-Demand Skill in 2008 « WordPress Publisher Blog

Writing is second, SEO is fourth, CSS is about tenth.

Blog Sponsors

My Tip for Productivity: Tear Up the To-Do List

Tom Johnson — Tue, 18 Nov 2008 13:10:54 +0000

Have you ever thought of tearing up your to-do list?

A couple of weeks ago I started listing all of my to-do’s in Outlook. Soon the list grew so long that I felt I would never be able to do it all. We all lead extremely busy lives. We have goals, commitments, and an almost endless amount of tasks to complete. Are there any productivity tips that work for you?

Here’s how my friends on Twitter responded:

DeeElling: Take the work and go elsewhere — a park, cafe, or any place where no one you know will interrupt you. Planes are good too!

krug95: Take down the Internet.

okeefe_scr : Stay away from Twitter.

michelleschoen: My biggest tip for being productive is creating Project Plans with milestones and deadlines. Do with both clients and partners.

DrChaos: Be an inspiration to those you work with. The synergies created will benefit all!

Kristil: Before bed, list the 6 most important tasks for the next day. Identify the most important one. Even if you only do that 1, in a year you have accomplished 365 important things. Got this from Michael Clouse, and it really helps me focus: http://twurl.nl/0juvjf

rjhoughton My biggest tip? Get a good night’s sleep.

heidilhansen: Productivity things I do: headphones with classical music to drown out voices, email closed, some meetings skipped, and big mug of water handy.

Whataboutmom I start a list, prioritize the list, and then start on the first items. If I think of additional things while I’m working on the first, I add the new items to my list rather than giving my attention to them at the moment.

I don’t have any earth-shattering advice for being productive. For me, good sleep is probably what makes me most productive. I listen to music when I want to write and skip meetings when I think my presence isn’t needed. I focus my energies on one task at a time rather than trying to do five at once. I usually tackle priority items first, going along with the big-rocks-little-rocks metaphor. I also alternate tasks so that I stay fresh.

But sometimes I think we clutter up our lives with things that, in the end, don’t matter. A few weeks ago while cleaning I came across a list of a dozen or so old tasks that I’d written months ago. Everything that was important had eventually been done, without my crossing them off one by one.

It amazes me that the truly important activities I need to accomplish often never make it on to my to-do list. For example, time spent with my kids, dates with my wife, the slow walk along the countryside on a sunny day. These are things that matter, yet they are often written out of my schedule with errands and other to-do’s.

This weekend I ignored my growing to-do list, and did what I wanted. On Saturday I attached a child carrier on the back of my bike, put my two youngest in there, and then rode alongside Avery, my oldest daughter, five miles out to Eagle Mountain’s City Center and back. We stopped at her school playground, the library, and walked our bikes up the steep hills. It was wonderful, and not on my to-do list.

However, as a result, I skipped working on a project that I needed to start on. Now Monday morning approaches, and I have nothing to show for it.

My feeling is that the best productivity tip is not a neat way of organizing yourself, or waking up early, or making sure the lights are fully dark while you sleep. The best productivity tip is desire. For example, when I woke up, I did what I naturally desired to do. I know this sounds odd, since I didn’t finish what I thought I needed to do. Instead, I finished what I really should have done.

If you truly want something, you find a way to do it. Nothing can substitute for this inner drive. If you feel yourself moving in a natural direction, based on your inner compass, I say follow that, and not your to-do list. The important to-do errands will get done without a detailed strategy for them. But if you let a list of to-do’s drive you, they can smother inner movement and exploration that may ultimately be more productive in the long run.

I found a similar expression of this strategy on The Lazy Man’s Guide to Getting Things Done. In a list of unconventional wisdom, the author writes,

Allow things to happen: Trying to force things to go your way is not only stressful, it’s not very intelligent. It’s better to guide things along, than trying to marshal them in like a dictator. Try to let things happen, instead of making them happen. Remember that a small rudder directs even the most giant ship.

I love his advice — let things happen, instead of forcing them to happen. I know this doesn’t fully address the subject. There are tomes of books written on productivity. But time and again I find myself shackled down with a list of to-do items that become burdensome and frustrating. Many of the tasks don’t reflect what I truly want to do. When I remove the list and move in a natural direction, I often end up using my time in a more personally productive way.