Search results

The Problem: "Just a Writer" (Overlooked)

Series: From Overlooked to Center Stage

by Tom Johnson on Apr 18, 2010
categories: beginners

I started out as a technical writer for a large financial company in Florida. I'd transitioned over from teaching and copywriting, so I was new to the technical writing field.

As I attended meetings for the projects I was documenting, I rarely said anything. I could barely wrap my mind through all the developer speak and jargon the other project members bandied about during the meetings. I sat there patiently in the intellectual dark, trying to make sense of everything. What were they even saying? Near the end of the meeting, the project manager took two minutes to discuss documentation and training, I said a few words, sometimes nothing at all, and then returned to my cube.

I thought these meetings were useless to me, but our manager said we should attend all project meetings. So each day it was usually the same story: attend a meeting, listen to the developers and QA and project manager talk to each other, and then return to my cube. At this time I didn't have a Blackberry; otherwise I would have used to escape these dreadful meetings.

As if my silence during meetings wasn't enough, one day while I was receiving some training from a senior technical writer, I asked her who I should contact for questions about the application. She said I could ask the business analyst, but that I shouldn't bother the business analysts very often, because they were “very busy.”

Although the remark seemed innocent, it further reinforced the idea that my role was minimal. I shouldn't bother the other project members with my questions. The meetings weren't for me, except for maybe two minutes of the hour.

With one of the projects I was assigned, I didn't even meet the project manager at all. I was called in to simply document a new interface that had been added. A business analyst was assigned to give me a brief demo and then asked me to write and update the documentation. I was completely removed from the project and other team members. I met once with the business analyst, and then delivered the documentation a few weeks later.

I assumed this was simply the technical writer's role. You attend meetings, you listen, you watch demos, you take notes on how the application functions. You then return to your cube and document everything you learned. And that is it. After that, you move on to the next project.

We also had careful guidelines within our team. For the most part, you could only use the approved software. You could only produce the approved deliverables. The deliverables had to conform to the same look and feel as all other team deliverables.

While this environment was a good foundation for learning the basics, it also seemed limiting. I had a tremendous creative energy inside me (this was before I started blogging), and it was trying to break free.

At the time we were living in a really shoddy neighborhood in Florida. We bought a house in a beautification area in St. Petersburg with hopes that it would turn around. But we found out it was a drug neighborhood, and no matter how many times we called the police to report drug deals taking place, we couldn't turn the corner on the drug neighborhood. A drug lord moved in next door. They had a shootout one day and stray bullets ricocheted in my daughter's room. Then we were robbed. That was it.

We left Florida for a safer, more wholesome place. I landed a contract job in Utah at a biochemical military facility in Dugway, about an hour into the desert. At this biochemical facility, which had no windows, I worked 10 hour days trying to document a storage array system that I couldn't touch or see (except during special supervised visits).

For the most part, I made guesses from previous documentation, read books on network storage arrays that I bought myself, and tried to have conversations with the lead engineer. I actually started carpooling in with the lead engineer, which you think would be a tremendous opportunity for instruction. But it turns out the engineer was bitter about the government personnel, and how incompetent they all were, and how backstabbing and territorial.

At times the engineer would sometimes answer a technical question related to documentation I was writing, but he had little patience for me, and would often say, after seeing my confused look at his cryptic explanation, "I thought you said you were technical." And then sigh.

My brief interactions with the government workers were almost a casual hello in the hallways on the first day, and then nothing more than an occasional nod for the rest of the time. No meetings, no conversations, nothing really. I was just the guy assigned to write the run books for the time when the contracted engineer would leave.

It was clear that in this scenario, I was nothing more than a fly in a room. A quiet, unnoticed presence in a windowless building in the middle of the desert. Had I continued in this direction, I would have had an ugly fate as a technical writer. I would have suffered a similar demise that others have experienced in this career.

To give you an idea about where I was headed, here a couple of quotes from comments people have added to my site. My most controversial post is a guest post called The Raw, Unvarnished Truth, which relates the ugly side of technical writing. The comments express the fruitless end you can meet as a technical writer.

One person wrote,

After 12 awful years of working at [a company], I can concur with everything said in this article. This is a horrible, horrible “profession” (if you call it that)... Employers expect you to know just as much as the engineers, but you get no time to finish your product (yours needs to be done tomorrow whereas the engineers get years to plan and develop it), you're expected to know every graphics and new online tool out there, you're paid half as much as the engineers, and you have no hope of promotion. Oh yeah ... and you're expendable when things get tight ... because you're “just a writer.”... Advice to young people reading this: They say that, in business, if you don't make, sell, or finance a product, you're nothing. This is true. DO NOT go into tech writing. You'll be “nothing but a writer.” – Been there, done that ... never again.

Here's another comment:

Sad but true.... I recently quit my job as a permanent technical writer at a software company because I was being worn down by a thankless and impossible job. Generally as a writer I was regarded as unimportant, a pain, or totally forgotten about, until someone screamed at me they needed a manual – tomorrow. We were seldom told what was being designed or developed until the very last minute, when it was assumed we could magically summon up the knowledge of the entire design/development/install team overnight, and produce a polished manual.

At the same time, you are considered the lowest of the low – too dumb to be a developer or even a tester. I even sometimes experienced developers ‘baby talk' to me when explaining how their code works!!!!! ... On the whole I think technical is not worth it unless you are being paid A LOT. You will waste all your good energy on a thankless, frustrating, difficult job. I am a much much happier person now.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.