Ever since I chose to pursue a career in technical communication (at the time simply called Technical Writing), I’ve been very interested in how we as communicators add value to an organization. It was the topic of my final project to get my degree and a concept I’ve pursued at each organization I’ve worked for or consulted with.
Recently, I’ve been engaged with a training and documentation department at a large healthcare provider out of Nashville, TN. Like many large organizations, the learning department within this organization is struggling to identify how to engage in more a meaningful way with the various project teams. I am specifically helping them to understand how to better utilize their documentation staff. Since many of the issues I’m helping this organization work through relate to increasing the value their writers add to the organization, I thought I would share some of our challenges and successes!
The Background
When I first started working with this organization, I was told there was a lot of work – more work than the staff could handle but they were having a hard time justifying additional full-time resources. They knew the work existed, but couldn’t predict the frequency, projected hours, time frames, etc. Since there was so much work, the two writers engaged with clinical systems were mostly relegated to editing and fixing formatting for end user documentation the product development team wrote. The main complaint was that they weren’t writing – they were simply glorified editors and formatters.
What was even more interesting was when I asked why the writers weren’t more engaged in the development process, I was told it’s because the Business Analysts (BAs) didn’t want to give up the task of writing. That single statement made me stop and wonder what was really going on within this environment because that is the first time I’ve heard of a whole department of BAs WANTING to write the documentation. This just didn’t fit with my prior experience where everyone was more than happy to give up writing the documentation because that was their LEAST favorite task. (I generally get good-naturedly teased about actually enjoying writing the content!)
There are always two sides to every story, so I asked to engage as the writer on a short but high-pressure project with one of the core development teams. I believe there’s no better way to truly understand what’s going on in an environment than to become immersed within it. A few weeks later I had my first meeting with the BA team. During that planning meeting, I listened as they outlined the process they generally followed to create documentation – each BA wrote their piece. They would send it to me and I would do a quick edit and compile into one document then publish. I quickly spoke up and asked if they would be willing to try a variation of that process – I work with them to develop the content and assemble the document. Essentially, it becomes a team effort instead of each individual doing siloed work in a more linear format. They agreed to try it out.
The Results
The results were spectacular! The BAs more than happy to give up the process of managing and creating the content on their own (which is what I suspected all along). I also found out that many years ago, the content development process worked this same way for all projects. Over the years, the system slowly degraded to the current system. All agreed that working closely on documents freed up the BAs to focus on the tasks they were ultimately responsible for (writing requirements and specs, supporting business owners, etc.) and allowed the writer to do what they specialize in – author content and manage the document development. It was a win-win for everyone.
As I related these large and small successes back to management within the learning organization, I noticed that I still hadn’t written a lot of the content. The BAs, who know vastly more about the application than I ever will, provided me with the base content. I edited and supplemented what they gave me, but the real value I added was providing a single point of contact for everyone on the team regarding the documentation. I facilitated (and, I’d argue, improved) collaboration both within the BA team as well as between that team and the outside business entities involved with other aspects of the overall project.
The Lesson
This increased facilitation yet lack of writing got me thinking about the overall value and role of technical communicators within large organizations. This is not the first time I’ve seen this in a large company. Last year I worked with an auto manufacturer in their corporate IT department. While I was hired to write documentation, most of what I did was facilitate collaboration between the enterprise architects and the business. Since they determined and distributed standards, they needed to sound like experts – so I helped craft the documents to be effective and informative communication tools. I did some writing, but it was more helping the architects convey the information they needed to convey, the exact same thing I’m doing for the healthcare organization.
My takeaway from both these experiences is that as technical writers we must stop thinking about simply authoring content and start thinking about how we help to convey technical information throughout the organization. This is where our real value lies. Many people can write these days. We as technical communicators set ourselves apart by understanding how to bring the various pieces, parts and people together to craft documentation that facilitates learning at every level.
The next time you or your writing team complains that they are not doing enough writing, take a look at your overall process and determine whether writing is the best way to add value to your organization. Like me, you may find that the real value of your writers is not actually writing, but facilitating the collaboration process within your organization.