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
No comments:
Post a Comment