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

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

The Consultant's Guide To Surviving Day One At A New Company

Or, it took you idiots ten years to screw it up, so don't expect me to fix it overnight.

There was a movie in the 60s called The President's Analyst. In it James Coburn takes on the job of being the psychiatrist of the US president during the height of the cold war. At first Coburn is stimulated by the depth and intellect of the man. Then as the sessions tick by, he begins to buckle under the weight of the problems that the President faces until he simply runs away.

As a consultant, this should be avoided at all costs.

Day one is like jumping out of an airplane. One minute you're serenely cruising through the sky, and then an instant later your senses are overwhelmed by the rush of everything coming at you at once.

Everyone is going to tell you their problems, and how happy they are to have you here to fix them.

Listen to the point where it stops making sense, then think about baseball. Rest. You're going to need that brain later. Smile. Nod. Empathize. Here are some strategies for success.

Step 1.  Promise Nothing

You've already written a lot of checks to get the gig in the first place. You've obviously said enough for now. Resist the urge to be a brave first responder. We all know what happens to them. Remember as a consultant, the life you save must be your own. Say nothing that can be used against you later.

Step 2.  Take Lots Of Notes

Taking notes shows that you are listening (hmmmm, I wonder if the Rangers will have home field advantage through the playoffs......ponder it). Clients like listeners. After all they are paying you to listen. It's the least you can do. It may not be active listening, but you can at least feel their pain.

"I got your back bro!"

Step 3. Lower Expectations While Appearing Eager To Help 

Here are some important phrases to remember:

"That might be difficult, but I can devote some significant time into it."

See what I've done? I have guaranteed a nice chuck of billing while diminishing any expectations of success. This is what we consultants call solid gold or gravy train. Strive for this. It is your happy place.

Here's another. I call it The Jamestown Strategy.

"I worked for a company that did that once. Yeah, they pulled it off but it cost a trillion dollars, took a hundred years and everyone died." (If you can cry a little with a faraway look in your eyes, that really helps.)

You are a fancy consultant. To the indentured schmucks of your client who haven't seen the sun in ten years you are like Marco Polo, Henry Kissinger and Warren Buffet all rolled into a neat khaki clad package. Until they get to know the real you, your words have weight. You matter. It makes no difference that you were once a schmuck like them...maybe as recently as yesterday. No matter. You have reached escape velocity. You are like Steve McQueen to them, soaring over the fence on your stolen motorcycle. Enjoy the power. It won't last.

Here's another good one. I call it The Positive Negative Switcheroo. It's like Jamestown except with an uplifting spin.

"That's a great idea!!!!!! (Always be stroking your client's ego. Never forget they are paying you like a geisha girl to make them feel like they are the center of the universe.) I can do that for you by next week (smile a lot, it sells your enthusiasm). Let me write up a plan to describe what I'm going to need to get that done and I will have it on your desk in the morning."

Always, turn it around. You are saying yes with an eager smile while at the same time ensuring that your client's stupid idea will never happen. They'll never let you write up that plan because then their silly idea will be documented complete with costs and schedules illustrating just how naive their suggestion was.

Step 4. Put Them In Their Place

This can be tricky, but it is critical to your success. You are Robert De Niro in the film Casino. You see, hear and know things. Of course you do because you are a consultant! It's why they pay you the big consulting bucks. Just by hiring you they have illustrated that they want to believe.

Don't disappoint your client.

Let them believe. Be the Easter Bunny. Don't destroy their faith. If they want to know why or what you see, hear or know, indicate in a tactful way that their tiny little brains could not comprehend the scope of what you see (at this point look wistfully into the distance as if you are hearing the report of distant cannons. Clients will generally nod and empathise with you. It preserves their egos.)

Remember that the goal of this exercise is for you, the consultant, to survive the first day. You have jumped out of the airplane. Your parachute did not open. You are lucky enough to have crashed into a deep pond and have somehow survived. Now you can't see a thing. Mud and muck are stirred up and visibility is zero. The only thing that can help you now is time. Buy yourself some time. The silt will settle. Things will become clear. Only then will you succeed.

Art Fischman
art@business-writing.us

Technical Writing - Who Should Own It?

September 6, 2011

At your company, which organization owns the red-headed stepchild named Tech Writing?

This question has always been an interesting topic of discussion in my little world. Do the design engineers and developers own it? Marketing? System engineering? Customer service? IT? Or is an independent jellyfish that floats through the company with marauding stingers of nuisance?

Most companies don't give it much thought, but they should. The reason? Perspective.

Technical writing only exists to solve a problem. You can't solve a problem if your perspective doesn't let you see it.

Let that sink in because there is a lot of good stuff in that little paragraph. Let's take the part about technical writing only existing to solve a problem first.

In a perfect world, products would be....well perfect. And perfect products are completely intuitive. Remember when Apple invented the Trash Can? Pretty perfect. Everyone who was a possible customer for their Macintosh knew what a trash can was so it didn't take much explaining to use it.

Now let's think about who they were competing with, the evil Microsoft/IBM alliance. In order to delete files on a PC, you had to understand a bit about MS DOS and that included a lot of commands, command prompts, file structures and a bunch of other stuff that resulted in a boxed set of documents delivered with each PC that rivaled the largest set of encyclopedias known to man. The tech writers were trying to solve a business problem because PC customers did not intuitively know how to delete files.

In a world without problems to solve, no documentation, and therefore no technical writers are needed. So there's your first solid gold tip for the day. Want to get rid of all that annoying documentation and expensive technical writing? Strive toward intuitive perfection!

Of course, nothing is perfect in this world so despite your best efforts, you are still going to need some documentation to support your business. And that brings us to the part about perspective.

Consider this. If the technical writers who supported the PC were part of the design engineering team (I don't know if they were, so just go with me on this), they were probably some pretty smart folks. Computer savvy. They understood everything about how that PC worked from the inside out. Now imagine how the documentation might read. You guessed it. It looked like that box of encyclopedias they shipped with every PC. I remember looking through that stuff for hours trying to find basic information to no avail.

Why was it so bad? Perspective. What probably happened is that the technical writers were directed by the designers who did not have an end-user perspective. The writers were instructed to write epic works to glorify every glorious detail of the designer's work. No matter how hard the designer's tried, they could not understand how to explain things for a novice computer user. The PC wasn't so hard to use. It was the documentation that was useless!

The PC world never really solved this problem until they copied Apple's point and click window interface. Suddenly the gargantuan box of encyclopedias disappeared from the PC shipping container.

How could this have been improved short of stealing Apple's GUI? IBM had a customer service organization. Actual Americans used to answer questions from actual customers all day long. By placing the technical writing activity under customer service, IBM could have grown the PC market much quicker because this documentation would have been the direct result of addressing end-user needs.

Is placing tech writing under customer service always the right answer?

No. Some companies may not have a customer service group. In the case of business-to-business sales, the product marketing group may be the one most in tune with customer needs. Sometimes it's sales. Often it is system engineering. If it's internal documentation or legal stuff, then maybe human resources should be the owner.

The answer varies. The point is think! Which organization has the best perspective for solving each individual problem? Picking the right owner may be the only decision you need to make to improve the business value your company's documentation.

Here's a final warning. Many companies make the mistake of putting technical writing under the development or design groups. Why? Because during product development, the only folks who know anything about a product (we call them Subject Matter Experts or SMEs) are the designer/developers. This is a dangerous practice and if you want to know why, think about the previously described IBM PC example.

I contend that producing a lot of useless information is worse that doing nothing at all. It costs a fortune. It creates a mountain of junk that now has to be maintained. It wastes the end user's time and frankly just pisses them off.

Art Fischman
art@business-writing.us

Technical Writing - Drowning In An Ocean of Words

Sunday, September 4, 2011

Today I woke up and watched the news. If something bad is happening, I want to see it coming.

What do I see? Unemployment. I'm not surprised.

I have been working in my chosen career of technical writing since 1978. For most of these years, I did very little technical writing and a lot of managing. I guess executives saw me as "management material."

It struck me that the vast majority of what I was learning was not about tech writing at all. I learned about processes; unique, non-transferable processes. This always struck me as ironic. Here I was, young, eager and darn good at what I do, but being asked to do something else entirely.

As I would later learn, it's natural for people to assume that if you take your best engineer, or janitor, or construction worker and turn them into a manager, that they will then infuse that same goodness into the folks they manage.

Yeah, sometimes this works, but I couldn't help feeling guilty. Why? Because I was not doing what I had been trained to do. I also felt worried. I was not perfecting the individual skills necessary to make me a better technical writer. I couldn't quiet the little voice in the back of my head that was screaming to me, "you are not worth the money they are paying you! What new skills are you going to have when this project is finished?"

Despite my individual success, my fears intensified as my career progressed. Each new job became more difficult to land as potential employers saw me more as a niche manager than as a skilled professional. How could this be possible? Why would employers pay me more to manage, yet consider me less essential than the people I managed?

Skip ahead. Now it's 2001. I'm selling technical writing services for an international company. The air is starting to come out of the economy. 9/11 happens. The balloon pops.

ENOUGH!

I approach one of my clients and suggest that maybe I'd like to do the work for them directly.

"Sure," they say. "Go for it."

I've been on my own ever since. Business Writing, Inc. is my company. Sometimes it's just me. Sometimes I have a small team of folks. Sometimes I'm busy. Sometimes I'm not. I love the freedom, and I hate the uncertainty, but I'm never bored and I'm always learning. I've learned more in the last ten years than I learned in the previous twenty.

If you know me, you know that I'm passionate about what I do and believe to be true. At one company, my team affectionately gave me a soap box at my going away party. Yup, I was born to blog.

So why blog now? This is blog numero uno for me. Why have I stayed quiet until now? Who cares? Why should anyone care at all? Why do I care? What do I hope to gain from all this?

To understand the answers, let's talk about my current big client. It's a start-up chip company in Austin. I service them from my home in Dallas with lots of trips down I35. Eight months invested. Highly technical stuff, but I have the perfect experience to service them. I spent the last six months training a writer to take the account over and move to Austin. On my end, things are going pretty good. I'm staying on top of the requirements and okay about it.

On the client side, things are not so good. They are late. Months late. Maybe up to six months late to produce their first chip. They are well funded, but it doesn't take long to burn through millions of dollars when you're hiring people without any sales.

There are many strategies for working a remote client relationship. You can be in their face about every need you have, or you can work quietly in the background to do the job without wasting a lot of their time or money. Which is the best approach? Well that comes down to what "best" means. Best for your client and best for your business are often at odds.

Last week one of the founders called me up and told me that they were hiring a direct technical writer who amazingly has none of the technical skills they had deemed absolutely necessary when they contracted me. They admitted it. What the heck is that all about?

The answer is, I'll never really know. People are weird. They say one thing and they do another. You never know how an individual perceives and values you.

My young trainee was crushed by this apparent client rejection. One of the things we had run into with this client was a disconnect between what they thought they needed and what they really needed. I know from my Texas Instruments experience that the single most important piece of documentation a chip company needs is a datasheet. You simply can't sell, test, program or use a chip without a datasheet. I don't need the client to tell me this. I know it and I've got a good story about how a single chip and its datasheet shut the entire US military down for a few weeks in 1984. But that's for another blog.

Our client didn't think it was appropriate for us to work on a datasheet until they were closer to actually selling chips. There would be months of testing, and software development before they reached that point. However, we (the writers) were not busy and had already received internal requests for a datasheet to support the testing that would occur as soon as the first chip rolled out of the fab.

I made an "executive" decision to start quietly working on a datasheet as a background project despite what I had been instructed to do by the client.

What happened? A big potential customer asked to see the datasheet. Even as I write this, my writer is working through the holiday to complete a working draft to satisfy this important request.

What lesson do you take from this? We lost direct responsibility for the writing despite being right about what our priorities should be, and despite working effectively without solid professional direction. How can these brilliant people at this highly-publicized start up be so confused about their documentation requirements? How indeed?

In a cut and paste world, where every person with a computer is an author, where the volume of words produced in single year exceeds the total sum of everything written by man across all of history, do you justify paying specialists to produce more words?

We are drowning in data while dying of thirst for information. On one hand, thirty years of technical writing has made me jaded. Why bother? Open a hot dog stand and forgetaboutit. On the other hand, people still need good, timely information to do their jobs, to run a business and to sell and use products.

How do you develop it? Who writes it? Who reviews it? How do you maintain it? What tools are the best for a given job? How much do you spend on it? How does it fit into all the other facets of your business? What are the differences between product and sales documentation? Between company internal documents and external customer documents? What skills does a tech writer need? Interview skills? Tool skills? Product skills? Market skills?

Technical writing can be complicated and costly. Do you even need tech writers, or is it better to have your technical folks do the work? What kind of infrastructure and process need to be in place before a technical writer can be effective? Is it better to produce documents while a product is being designed or should you wait until the product is almost perfected to start your documentation effort?

Short answer? It depends.

With this blog I will explore the myriad of situations that I have encountered across my 30-year career. In each little case study, I'll present a single problem, describe how I approached it, and then honestly present the results, both good and bad.

Maybe folks will read it. Maybe not. But I refuse to be jaded, and if I can help one person navigate this mess of information we have all helped to create, then, for me, it will be worth the effort.

Art Fischman
art@business-writing.us