Friday, November 11, 2011

Are Tech Writers Better Than Doctors?

(11/11/11 @ 1:11 pm, Plano, TX)

I'm sitting here at the office and I'm not in the mood to work. I've checked my various Internet distractions, email, news, paid a few bills and now there is nothing left to do but get some work done. I'm depressed. I'm unmotivated. I don't feel like working today. It's Friday. Nobody is here. Nobody pays much attention to what I'm doing as currently I'm the only tech writer on a big IT team. I need to prime my motivation pump. So what do I do when I don't feel like writing? How about write my blog?

Last night I couldn't sleep. I kept thinking about the nature of my work. No matter what I do, I eventually fail. No matter how hard I work, the job ends. Sure, I've quit a few before they ended, but who am I kidding? These jobs too would have ended. There is very little life control afforded in technical writing.

So there I was in bed. It's 2 am. I have to be up at 6:30. And what am I doing? I'm thinking about technical writing. If all tech writing jobs end despite my best efforts, how do I stay motivated? Am I crazy? I have raised two families on the income from my work, so that's good right? Doesn't seem like enough somehow. Seems futile. Why does it have to be this way?

How does one measure success? Money? Satisfaction? Happiness?

I don't know.

Remember when businesses discovered quality in the 80s and 90s? Smart companies thought, "we'll get us some of that quality and then we'll be successful."

One of the most prestigious quality awards was the Baldrige. Big corporations simply hired consultants and bought their Baldrige awards as publicity gimmicks. But smaller companies drank the Kool-Aid. They embraced the religion of quality and then promptly failed at the next economic speed bump.

How could that be? Is quality not synonymous with sustained success? Maybe not.

Let's talk about failure in tech writing. A company develops a product. Lets use the example of Texas Instruments and their calculator. That product needs documentation. They hire a tech writer. The product is successful. The tech writer is successful. The company reinvests the profits and develops more calculators. They hire more tech writers. More success. Things are going great.

For more than thirty years, things went great. Then one day TI is looking to save money. Look at the size of this tech writing department!!!! Let's outsource it they say. But they do it in a special way. They give the on site writers the option of going to work as contractors. Many of these folks have been doing this work as direct employees for more than twenty years. TI rewards them for their efforts by paying them less, taking away their stock options and benefits. Most of the good writers leave immediately. The new management is clueless. The rest of the experienced folks flee. What the heck happened? Is this how success is rewarded?

Yes. If success costs money, then in America you succeed yourself out of a job. This is part of the reason I fail. I'm good. I'm expensive. I fail.

The other problem is the tractor pull analogy. The more technical writing you do, the bigger the library of words that must be maintained. The sled gets too heavy and finally can no longer be moved. You fail.

Then there's the information explosion created by the Internet and a world where everyone is an author. More and more words to deal with everyday. The saying, "who has time to write" has been replaced with "who has time to read." Net result, you, the tech writer fail again.

So basking in the black light of all this failure at 2 am staring at my dark ceiling, I start thinking "what's the point? Is there any reason to go on?"

What a pointless career this is! Is there another profession that has to endure such frustrating hopelessness?

And then it hit me. Doctors! We respect them. Maybe not Michael Jackson's doctor, and in general, maybe we don't respect them quite as much as we used to, but overall, we still consider them noble and important. But look at it this way. No matter how good they are, eventually the patient dies!

Now I've done a lot of things both good and bad as a tech writer, but as far as I know. Nobody who has ever used one of my documents has ever died! Sure, something I wrote once in a missile manual did result in the emergency evacuation of Eglin Air Force Base in Florida, but I'm pretty sure that nobody died!

Then why do we love doctors so much if they can't keep their patients alive? Because doctors can ease our suffering.

And that my friends is when I realized my purpose in this life. It is to ease the suffering of the reader. To make the pain of their lives a little less acute.

It's not about job security. There is no such thing. It's about easing the suffering of the reader. Make it understandable. Make it correct. Make it brief. Make it enlightening. Make the world a better place one page at a time. And for God's sake, don't kill anybody while you're at it. At that realization, I finally rolled over and fell into a sweet sleep.

Funny, I feel like getting back to work now.

Art Fischman

Friday, November 4, 2011

Wiki Washy or Flavor-Of-The Wiki, Take your....ah...Picky?

(November 4, 2011) The need to document business processes has gone viral. Sure, companies started the process craze years ago with the need to achieve quality certifications like ISO9000, but what's happening today is different. It's much bigger. Now it's about survival. How do you run a business after you've fired all the high-priced folks who actually knew how to run things?

The popular answer seems to be, hire a tech writer and let them create a wiki! What's a wiki? It's a magical place where everyone joins hands in a circle and does something forbidden and dirty. They collaborate. That's the ticket. A wiki is a magical, writhing cluster of consensual collaboration. It's like Pandora...and we're all going to join tails (or tales in the case of process documentation) and be one. 

Well, I certainly would love to teach the world to sing in wiki harmony, but I can't. Wiki isn't an answer, it's a tool and like all tools, it has its place. So don't get caught up in the hype. 

Rather than go into a long discussion on the pros and cons, the whens and wheres, the hows and whys, I decided to share my answers to some qualifying questions I received from a recruiter recently regarding a wiki creation job for a well known Dallas company that sells (as Steve Jobs once put it) "sugar water."

Qualifying Questions:

Can you provide examples of file-based content you have migrated and restructured into Wiki content (e.g. web page orientation, extensive linking, embedded images/video/audio/charts, web page table of contents with links within web page, tagging for search, clear authorship and version)?
No for several reasons. Wiki is inside stuff. It is proprietary so I can’t share what I have done. Also, depending on what Wiki they are going to use, most are extremely inefficient documentation tools that are the worst of all worlds because they do not support a full set of HTML commands. So in other words, a nicely formatted web page does not work as a Wiki. And all of the features of a well done document do not translate to a Wiki. Now my experience with this is VERY current. Wiki is the business buzz term of the month, but it is a tool that ONLY has distinct advantages in a VERY collaborative environment, where folks are going to be participating in providing their two cents across the company. If it is not intended to be used this way, then real web pages or real documentation is far superior.
Now, can I do what they ask? Yes, in several flavors of Wiki (SharePoint and Confluence). But would it be right? Need to see. Anyone who does not agree with what I have just said does not know what they are talking about.

* Can you provide examples of Wiki layouts and topic structures you have developed and/or utilized in the past?
See above.

* What types of corporate documentation legal policies have you dealt with in the past and how did this modify your documentation work?
This question was written by a chimpanzee. For instance I could say I dealt with EOC requirements that preclude me from calling women “bitches.”

* Have you created an internal-use corporate Wiki previously? If so, what watch-outs can you provide from the experience?
So now they want me to give them what took me many hours to determine. Fine. I’ll give them a dealer’s taste. First, I have not seen a single Wiki that supports a full set of HTML commands. Why? It’s an immature technology. Second, some of the Wiki tools such as SharePoint cannot support simple cutting and pasting of graphics. Graphics have to be stored in special folders and linked to the Wiki pages. Now if you have ever dealt with linked files, they are constantly getting broken and the maintenance is horrendous, read expensive.

* Can you provide an example of the most complex Wiki you have developed to-date (e.g. addressed content hierarchy & compliance needs, consistent tagging, content structure and layout, integration of internally public and internally private Wikis)?
Wiki pages are organic and work best when used as a collaboration tool. In this case, you set up a structure for folks to use, let them draw on the board, and then come in after the fact to clean up the mess. Wiki pages are proprietary so I cannot provide an example.

* What would you consider "Wiki best practices" and how have you threaded these best practices into your Wiki content development in the past?
Wiki best practices are where folks want to use the Wiki to communicate information that might be needed by many groups. Most Wiki sites start out okay, but content does not get reviewed, and content is typically not dated. So once folks find out that they can’t get current information, they stop using it. I have not seen it work well for very long. It becomes like a garage that needs to be cleaned out. A fish tank without a filter. Eventually, the fish dies.
However, even with all the negative stuff I have said, it is possible to do it correctly. It takes CONSTANT maintenance to make the information usable. And most importantly, it takes a commitment to collaboration between all of the employees who use it. Wiki is not free. Companies need to understand that. It’s not the tool, it’s the process and the commitment to using the process that makes it work.
By the unbelievable naivety of these questions, it is obvious that your client is simply buying a flavor-of-the week. As a consultant, I would first sit down with them to try to define the problem that they are trying to solve, and only then would I propose a solution which may or may not be Wiki.
Frankly a far superior solution that I have seen used effectively (without the need for consultants) is Dropbox. Having a collaborative space where folks can place and share files is AWESOME. That’s why Dropbox, the company, is growing by leaps and bounds.
Tell your client that solving communications problems is MY business, not theirs. I will be happy to fix their problem for them once we figure out what it really is…for the right price.
*****
Funny, they haven't called me back ;-)
Art