It’s been a long time since my last post, and I was never a prolific blogger.
So what’s changed?
In short, a lot.
Since my last post, detailing my redundancy from a company in the West Midlands, I’ve moved to Cambridge and have held various permanent and contract roles. Right now, I’m contracting again, in a role based just over the border into Hertfordshire.
The reasons for the job changes are various, but essentially the problem remains the same: finding a role where a Tech Author is regarded as more than just someone who writes help guides.
But a lot of good things have happened since then. I’ve learned DITA, created style guides and standards, presented at TCUK, and even won an ISTC Merit award. The last several years have, in short, afforded me many opportunities to learn and grow.
The reason I’ve decided to revive this blog is that my current contract offers even more such opportunities. I’ll not only be creating API documentation, but also working with developers to help them move to a new set of API tools. I’ll also be helping refine the project processes for capturing information in Jira tickets to inform release note creation and help documentation updates.
And as I type, I’m also chatting with a colleague in another office, a UX specialist, who wants to ply me with coffee and cake while I tell her all about Tech Comms. I’ve agreed, provided she reciprocates on UX.
So, over the next few months, expect some updates about my progress in all these areas. I’ll be sharing my thoughts on my learning experiences, and hopefully that will help both me and some of my readers… if you’re still out there!
You never know… maybe I’ll have time to learn how to use WordPress properly, so I can make this blog a bit prettier.
Watch this space 🙂
Much has changed for me since I last blogged. So this entry – and those to follow – will be based on my new experiences.
In October I found myself facing redundancy. It didn’t surprise me, I am afraid to say. A new CIO had been brought in late in the summer, and he didn’t seem as supportive as his predecessor. It was reported to me that he had been heard to say “Technical Authoring – that’s a bit old fashioned, isn’t it?”
I prepared the ground to persuade him otherwise by beginning to pull together a presentation on the Information Management issues facing the IT department. My slot in the Senior Management Meeting was cancelled with a week to go, and a few weeks later the news of the redundancy came out. So had I been given the opportunity, what would I have said?
I suspect – although I will never know for certain – that the CIO believes Technical Authors write manuals, and nothing else. In fact, while the company had many customised and bespoke systems it used to operate its business, these had never been documented and I wasn’t employed to do so. What I was in fact brought in to do was to help identify areas where information was not being well managed, and to improve the processes and tools used to do this. This was what I was going to base my presentation around, citing examples of my work with the Project Management Office and the Architecture team.
I think most Technical Authors know that the communication, analysis and presentation skills we develop in the course of our career give us a very useful toolset that can be used more broadly across the business environment. Communicating this to our colleagues can sometimes be a real challenge. I know in twelve years of permanent roles as a Technical Author I’ve run up against this challenge time and time again. Now, as a contractor, I’m finding things are very different… but that’s a subject for another blog post.
I’d be interested to hear your experiences. How easy have you found it to expand the perception of your role as a Technical Author? Or, like my friend Content Tactician , have you found yourself drifting into the role without realising it? Do you think we have a fashion image problem? How would you improve it?
 To quote (from memory) Roger Hart during his Spork/Platypus Average presentation at TCUK10: “A Technical Author’s toolbox of cool things is a Content Strategist’s toolbox of cool things.”
On return from TCUK10 my mind was seething with enthusiasm and ideas about Content Strategy. I have been quite the giant nerd at friends and colleagues, some of whom have displayed more than polite interest.
However, twice now I’ve been asked to explain what specifically I mean by Content Strategy. On both occasions the explanation has gone down reasonably well, but I am still slightly concerned I might be getting it wrong.
So what better way to invite a storm of correction and disagreement than to post my explanation on the internet?
Content Strategy, as I understand it, is the application of strategic thinking to the way content is created, distributed, stored, used and maintained in a given environment. This could be a website, an intranet, a department, or even an entire business.
In practical terms, what does this actually mean?
I want to describe a scenario that doesn’t actually have anything to do with the Web, but in which content is (or at least should) be generated in considerable volume: project-based software development. This scenario is essentially a composite of several examples I have come across during my career, and therefore shouldn’t be attributed to any one business.
Software development lifecycles often generate a great deal of content: proposals, authorisation documents, business cases, requirements, specifications, meeting minutes, release notes… maybe even the occasional user guide.
In our scenario, when a project is initiated a new shared folder containing the templates for all the types of documents that might form part of a project is created. All the members of the project team are supposed to use these templates to create documents, and should store all the resulting versions in this shared folder.
As I type, I can almost feel my fellow Technical Communicators wincing.
The reality, as I’m sure we all know, is that this simply won’t work. Documents will be stored elsewhere and passed around on email. There is no way to know whether the documents on the folder are the most recent versions. In some cases there will actually be no content in one or more of these templates, either because the actual version is sitting in someone’s hard drive or inbox, or because it was never needed in the first place but no record was taken of this.
Clearly, a huge amount of vital information could be falling through the gaps here. How therefore can anyone, present or future, trust the content that exists to be valid and complete?
So what to do?
Simply installing a Document Management System (DMS) will be insufficient. Without thought given to how such a system should be used, it runs the risk of being used as if it were a shared folder. I have seen this. It is not pretty.
In my opinion, the following needs to happen, with each stage logically informing the next:
Content audit – A full audit of the content on the DMS, and on a selection of key projects. The aim is discover content that is invalid, incomplete, out of date, or even completely missing.
Process discovery – There is bound to be a gap between the theory and practice of project processes. The content audit should already have given some idea of where these gaps fall, but interviewing the people who work on projects on a day-to-day basis will give an even clearer picture. To date, I have never found a project that has followed a mandated methodology to the letter.
Process and Template improvement – With a better understanding of the processes, the existing templates can be either improved or completely replaced with new templates aligned with how people actually do their day-to-day job.
Technology assessment – Notice how this has come so late on. I am a strong believer in not just throwing money at technology to solve problems. If a DMS is to be deployed, time must be spent to understand how its functionality can be used to help project teams discover, capture, collaborate and publish content.
The next steps are not necessarily in this strict order, and will in fact probably form part of a continuous improvement initiative:
- Revise existing content on the DMS in accordance with the audit.
- Document and publish processes.
- Run a pilot project or three using the DMS and new templates.
- Continually monitor and gather information on other possible improvements in process and technology.
So, within the bounds of this scenario, this sounds like Content Strategy to me. How about you?