What working as a contract technical writer taught me about the workplace

Photo by Thomas Martinsen on Unsplash

I spent a big chunk of my career as a contract technical writer. During that time, I had my share of ups and downs working on contract — learning a lot about technology, human nature, human motivation, demotivation, and a lot of other life lessons — while working with large, medium, and small clients.

However, the good and bad parts of the human element often transcend organizations. There is an old saying amongst IT contractors I was once told, “You work with the same people in every place. The names change. Their sexes change. The positions may change. However, it is the same people.”

Here are some things I learned along the way:

  • “Me” can become “We” and “We” can become “Me” real easy depending on the profile of the project. The higher profile project you are working on has a greater chance of becoming “We” than if you are doing scut work which it becomes “Me.”
  • There is far more talk about a process than there is a process in the world. A process isn’t all bad, but there are a lot more organizations that espouse process than follow a replicable process.
  • There are more knowledge silos than there is group knowledge. As project teams are often smaller than they were in better economic times, technical expertise is more likely to be in one person’s head often than spread across the group.
  • History has a way of revising itself. Reorganizations, contract ends, resignations and layoff have positive and negative effects on a project team. One negative is people taking credit for more than they did because the original team isn’t there to speak up for themselves.
  • The person doing nothing all day in their cube may not be lazy, but just underutilized. You can walk around many commercial and federal organizations to find workers in their cubicles reading the news, perusing e-commerce sites, and not doing much related to work. At first blush, it is easy to blame this on the worker, but it can also be the fault of management and the organization as well.
  • Rebranding doesn’t take away the pain. Just because an organization rebrands itself doesn’t mean the dysfunction and other problems are going to go away.

My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.

Avoiding Mission Impossible technical writing projects

Photo by Aaron Mello on Unsplash

I’ve had the great fortune in my career to work on some very tough projects — in what I like to call documentation unfriendly environments — and won some and lost others but learned so much about technology and how to work independently as a technical writer.

Before I accepted my current position, I had the opportunity to speak to an organization which has what I quickly came to ascertain what could be a “Mission Impossible” documentation project where there would be more chances for things to go wrong than there was to go right.

After speaking to the recruiter who set up the meeting for me, I began to think how had I won the mission impossible projects versus being “the previous technical writer.” Keys to success include:

Strong technical team

A strong technical team — not to write the documents mind you — but like it or not the IT industry is peppered by a lot of smart people and a lot more people who think they are smarter than they are. If you have genuinely knowledgeable and capable people in the critical technical roles, then half your battle for extracting technical information is won in my experience. If the wrong people are in critical roles, the holes and gaps that sometimes happen in technical documentation can expose the shortcomings.

Proper technical writer/developer relationships

Relationship with the technical team where you as the technical writer isn’t an unnecessary drag on personnel or other resources. Technical writers who need their hand held or can’t work independently are only going to be set up to fail when it comes to a mission impossible project.

Product management and developer collaboration

Strong product management and technical team cooperation and communications. If Product Requirements Documents (PRDs) or stories are just being thrown over the transit without much dialog between product management and the senior members of the technical team, then the hijinks can ensue.

Access to test environments

Access to test systems and the bug tracking system because reverse engineering of technical documentation does often occur especially if the document efforts begin well into the development lifecycle.
Reality vs. vaporware can also come into play on such document projects. If for some reason, you are continually denied access to the system, don’t take it personally, but be on guard that the product may in whole or part not exist except for visions in an executive’s mind.

What are your keys to success on “mission impossible” documentation projects?


My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.

A lesson I learned as a contract technical writer

daria-nepriakhina-21925-unsplash
As a favor to an old friend,  I spoke to one of their friend’s kids who got laid off and was forced to go into contract IT work so they could keep paying the bills.

Here is one question and answer that stuck out from our phone call:

Them: What do you find true about contracting?

Me: The very people who will criticize you for the tiniest mistake will be the same people who take credit for your successes and good ideas after your contract gig ends.

Unfortunately, depending on the organization, it happens to full-time employees too.

Weird things I saw when I was a contract technical writer

alex-kotliarskyi-361081-unsplashI’ve been out of full-time contracting for almost two years and recently thought back to some of the stranger things I saw during the contract technical writer chapter of my life:

  • A fellow contractor was posting nude pictures of his wife on Usenet from his client account. He was busted and walked offsite by armed security guards when a Usenet reader emailed the Webmaster of the client’s domain.
  • A client who demanded the word, Please be used to begin every procedure in a user guide.
  • Contract agency recruiters who just told so many obvious lies I wondered if their nose grew. There should be a special place in hell for unethical contract agency recruiters.
  • A contractor who got sick and went AWOL while on a business trip to NYC. The contracting agency had to evict her from her hotel room. After taking over her hotel room, I could understand how she would want to lay in bed all day in that hotel.
  • A contractor who inflated their resume so much it made me see the problems that swept along technical writers and swept along trainers cause for real professionals.
  • A contractor who quit via email the Sunday evening before leaving Monday on a trip to Los Angeles. He knew the whole time he was going to stop. While I understand At-Will Employment cuts both ways, there is professionalism and decency.

Once upon a time, contractors could always count on other contractors. I stayed too long at the party. The contracting market I entered was not the same one I left.

What weird things did you see as a contract technical writer?

Photo by Alex Kotliarskyi on Unsplash