I'd Rather Be Writing » Paul Pehrson

Trust and Transparency: Leadership Day at the STC Summit #stc10

Tom Johnson — Mon, 03 May 2010 13:33:31 +0000

Paul Pehrson and I sat down after Leadership Day at the STC Summit to talk about some of the strategies the board is taking to address the issue of trust. This is the first in a series of videocasts that I’ll be posting at the Summit.

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

Free Ticket to DITA Tech/Comm Conference in North Carolina Nov 3-6

Tom Johnson — Thu, 02 Oct 2008 22:23:54 +0000

Paul Pehrson, a Utah-based technical writer who blogs at Technically Speaking, writes,

I’ve been invited to speak at the DITA Tech/Comm Conference at the beginning of next month. I’ve got a free conference registration I’d like to give away, and I wondered if you’d like to give it away on your blog. (I don’t think I get enough traffic on my blog for that.) … It’s a full 4-day registration, with a retail value of $795 dollars.

Do you need a free ticket to the DITA Tech/Comm Conference in North Carolina this November 3-6? Check out the conference website for details.

Paul has only one free ticket. If you want it, leave a comment below this post with your most creative rendition of what DITA might alternatively stand for (other than Darwin Information Typing Architecture). On Monday morning, I’ll pick the winner — based completely on my subjective judgment about which DITA re-acronym I like best.

Paul also adds,

Anybody who wants to attend the conference, can get $50 off the price of registration by using my name “Paul Pehrson” as their discount code on the conference registration page.

By the way, if anyone else has free conference tickets, products, or other services they want to give away through my site, let me know.

Madcap Flare Spotlight — “Six Persistent Flare Problems” Post by Paul Pehrson

Tom Johnson — Thu, 14 Jun 2007 09:37:38 +0000

Update Feb 2008: If you read Paul’s post at the link below, almost everything is now crossed out, because Madcap has either fixed all the problems Paul raised or they explained workarounds. It’s a really interesting read. Also, be sure to check out this podcast with Paul as well as my post on 45 Things I Love About Flare, 31 Things I Hate About It.

Paul Pehrson has an excellent post detailing six persistent problems he’s encountered with Flare. Paul introduces his post saying,

I’m a Flare user, and I really, really, really like Flare as a help authoring tool (HAT). It’s a solid program that does a lot of great things. On my recommendation, my company is going to renew our maintenance contract with Flare this fall, and I expect to be using Flare for a while to come.

That said, I think that there are a few persistent problems in Flare that new users should be aware of when they start using the product. None of these are deal-breakers for me, even in the aggregate. Still, I think that these are things that if I had known were problems, I wouldn’t have spent hours banging my head against the wall trying to solve them.

I enjoyed Paul’s post. Every tool has its shortcomings, quirks, and flaws that you don’t experience until you start using the tool extensively. At least now if you go in the direction of Flare, you will be less likely to encounter surprises.