Working as a lone writer has its pros and cons. It also has a lot of challenges. After a decade of technical writing and working in some of the top notch companies, I decided to deep dive and take up a challenge with a startup.
Leaving Red Hat was very tough. I had a pleasure to work with some of the most talented people I have ever met. Red Hatters are some of the craziest, most passionate people on the surface of Earth. Working with Red Hat gave me an opportunity to work in the world of open source. Red Hat taught me how to explore the sea of unlimited information, learn new tools and formats, and so many other things. This gave me the confidence of taking up the challenge with a startup. Life@RedHat was really awesome!!
I joined my new company six months back, in the month of September 2015. In the team of 50+ which includes Devs, QEs, and Delivery, here I was standing alone, representing my passion – Technical Writing. People had weird ideas about technical writer and writing. They didn’t give much importance to the documentation. According to them, documentation was a job for the losers. People who are unsuccessful as Devs, QEs, and in other fields, take up tech writing for survival. Now this was a challenge I had; to change their mindset. I had to educate people about technical writing, technical writers aren’t losers but biggest contributors to the success of a product. Without good documentation, product has no value in the market. I am glad that I have almost changed that perception now. Though there are still some who under rate writers but it won’t be long before I win over them and hoist the writers flag high.
Another challenge, the biggest of all, was the condition of product documentation. The product documentation was in MS Word! Yes you read it correctly. Microsoft Word! An outdated, stone age era tool which is hardly (just being nice to Word :)) used in the new world of tech writing. The previous writer had done a good job but there were still lot of areas for improvement. The writing style, information flow, the processes were all in dire straits. With all these issues still in the field, I managed to get out two major and one minor releases with the existing tool chain. Although the quality of the documentation was not up to the standards, it was still like winning a small battle in a big war!
After joining, my top most priority was to get acquainted with the product and start documenting the new features/enhancements for the upcoming release. Along with new features/enhancements, another task was to set documentation process. With no process set for documentation, I used to get tasks and requests through mails which was a big hassle to track.
I will explain the doc process in short over here. Since we are using Jira, I created a project in Jira for documentation. All the doc requests which are not related to the current release go in the documentation project. Any one from the product team can create an issue in this project. For tasks related to the current release, in every Jira epic, a story for documentation is created. Each doc story has three tasks; Information Gathering, Writing, and Review.
For those of you who are unfamiliar with the agile/Jira workflow, I will try to explain the process in brief. In agile workflow, an epic is created in Jira. Each epic can have multiple stories. Stories are usually product features which need to be developed. Each story can have multiple tasks and in turn multiple sub tasks. The workflow may be different in different organizations.
Let’s take an example. User Administration can be called an epic. In User Administration there can be various features like adding a user, deleting a user, modifying a user and so on. These are all stories under the epic User Administration. Similarly, User Administration documentation can also be added as a story in the epic to track the related documentation tasks.
The future – roadmap to glory
After being six months at the helm, I finally have a roadmap to take the docs to glory. Recently, I received the license for a new tool chain – Madcap Flare. I am finally moving away from Word!! feels good. I have never used Flare but from what I hear, it’s not that bad. So here is the roadmap for glory which I have proposed to the management.
To understand what needs to be changed/updated in the docs, a documentation audit is planned. A documentation audit is a review of the entire documentation. The aim of the audit is to improve the documentation by making the guides easier to use, more user-friendly, and more customer-centric. The docs will be reviewed by all the stakeholders and the findings of the doc audit will be added to the doc project in Jira.
Simultaneously, docs will be migrated to the new tool – Flare. Migrating to a new toolchain is never an easy job. Once you import the content in the new tool, the fonts, style, everything goes for a toss. Keeping this in mind, two versions for docs will be maintained. Version 1 will be the same old MS Word docs, which will continue to exist for a couple of releases. The MS Word branch will be maintained and updated for the new features for the upcoming release. The new features will also be copied in the Flare branch, to keep it updated. The same old style MS Word docs will be released for next version of the product.
Version 2 will be the migrated content in the new tool – Flare. The documents in Flare, will be restructured and updated as per the findings of the documentation audit. Once the docs in Flare are structured and are good to go, the MS Word docs will cease to exist. Just like Simon Phoenix, the criminal in Demolition Man, the Word docs will be cryogenically frozen in time. Hope the Word docs don’t resurrect in future like Simon Phoenix! 🙂