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