Technical writing can be found in every sector of public and private industries. The reason is that everything has to be documented. Now don’t get me wrong, has to is different than actually doing. Many professionals feel they have it in their head and that is good enough, which works until they leave for a new opportunity. Then leadership runs to the technical writer to locate documentation that was never created. So now we circle back to everything needs to be documented within an organization.
Having worked on both the private and government side of technical writing, I can say the worlds are vastly different. The private sector is where most technical writers, in my opinion, would rather work. Often companies are more willing to experiment or take their documentation to the next level. They will have legacy documents in Word and Acrobat formats but want to get more from documentation. This will often fall into the realm of structured documentation. Wikipedia states a structured document is an electronic document where some method of markup is used to identify the whole and parts of the document as having various meanings beyond their formatting. In a nutshell structured documents are marked up (usually XML) and pieces of the document can be repurposed due to this markup.
Software to create structured documentation is often quite expensive for a license, and customization of applications like Arbortext can run into the millions for large companies. Even with these large costs associated with taking documentation to the next level, private companies will often take this chance to offer a better document product for the end user. Private companies will also find the cost savings associated with being able to repurpose documents for multiple uses. The fact that companies will take the time to incorporate higher tier software into their document process benefits the writer as well. The technical writer will now learn markup languages, software often used for high paying positions, and be in step with the current technologies.
In addition to structured document software, a lot of private companies are moving/already using collaborative component content management systems (CCMS) like Paligo. I know a lot of people will think of SharePoint as a collaborative environment for documentation, but SharePoint is very limited when compared to a CCMS. Trust me, I know with my attempts to inject code into SharePoint to push its boundaries. The CCMS allows for beginning to end document creation while keeping the theme of repurpose.
Now let’s take a dive into the government side of the Technical Writing field. I have a special place in my heart for the government side as some of things you get to see and document will help our troops in the field, create better policies, and the numerous other great things that come from what we do at the public service level. With that said, government technical writing could restrict your movement in the field. The reason being is that the government is about a decade behind the private sector when it comes to technical writing. Now this is coming from someone who worked at the DoD/COCOM levels of government. Maybe state and local government agencies or NSA/DIA may use more up-to-date technologies for their documentation. Government tends to use the old reliables, PDF and Word. This does not bother me as I am an expert in both and have often pushed both beyond their initial capabilities to make leadership happy.
Some of the documentation within government is so primitive that custom styles are not even incorporated into the Word documents for policies and memorandums. When it comes to documentation, the government takes the approach of not broken don’t fix it. I can understand this approach as their documentation needs are basic and there really isn’t an infrastructure in place to create an advanced document process without a lot of work. SharePoint is used as a collaborative tool for creating, editing, and signing documentation; however, due to security restrictions, you cannot as a technical writer inject code in the SharePoint environment to make it more robust. You would think this is the government and they should have unlimited resources for technology when it would benefit them. Well I have fought this battle at multiple locations, having my proposals for the incorporation of structured documentation declined every time. So how come?
There are two reasons: budget and security. The government likes budgets—believe it or not—and documentation is not a high priority to modernize within an organization. The great thing is the government likes to document everything, but Word and Acrobat is just fine for the job. Even trying to obtain one license for new document software is often declined due to cost. The next reason is security. Much of the latest and greatest documentation environments run on the cloud. Think of Adobe’s suites all being CC. The government can’t just connect to a public cloud due to the sensitivity of the documentation created. Likewise, companies using cloud for their software would not be able to push updates to users on a government network because of security protocols. This creates a huge headache to even attempt on multiple levels just to have some higher functioning documentation, and most GSs won’t take it on because of this.
Remember how I mentioned the possible restriction of your career working for the government as a technical writer? Think of it as being an actor that is typecast for that role. I am a fan of mobster movies, so who comes to mind: Robert De Niro and Joe Pesci. I know they have done a lot of other movies, but that is how I see them. The same can be said for technical writers who spend a long time in the government. While great at our jobs, we are mostly using Word, Acrobat, and SharerPoint. These software restrictions will also be seen by potential employers who want writers that can markup and/or code documentation or be familiar with the latest collaborative software. I personally have been passed up on positions due to not having hands on, production experience with the latest tools even though I could easily learn them. Us technical writers are great at learning on the fly. This is one of the biggest downsides to working as a technical writer on the government side, especially if you are in an organization that does not value the latest software for content creation. As a technical writer, you can always help yourself by downloading the software and trying it out after hours, but I have found this does not replace experience while on a team.
Working for a private industry or on the government side in the technical writing field can give you completely different experiences. By no means is one greater than the other; it should be based on what you prefer as a writer. I am hoping one day that government organizations will put more effort into stepping up their documentation game to compete with the private sector. While it would take some time and budget rearrangement, it would be very beneficial and save the government money in the long run. I also hope that private companies can look past us government writers to see that we can easily adapt to their “more advanced” documentation process. If you have had different experiences or see the same thing as mentioned above, let us know in the comments.
-Chris