Obligatory “Blows dust off” title

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 🙂

Technical Authoring – in or out of fashion?

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[1]. 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?

[1] 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.”

Is this Content Strategy?

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?

“Had one of those Technical Authors in the back of my cab…”

Of all the places I ever thought I’d discuss the value of Technical Authors, I never thought the back of a taxi would be one of them.

Yesterday afternoon I was on my way to the local train station by taxi when the driver asked me what I did. “I’m a Technical Author,” I replied, watching the rear-view mirror for the puzzled look I usually get when I announce my profession [1].

Following the expected look, I explained: “I write manuals, specifications, any sort of technical documents.”

This immediately got his attention, and he began what I can best describe as a polite rant.

Turns out he used to be a senior engineer for a firm that sold shower units and cubicles. They began importing products from China, which unsurprisingly were supplied with Chinese manuals: no good for their customer base. Rather than employ a specialist, they set him the task of writing an English manual from scratch.

He tested the first draft himself, and found it wasn’t suitable. So after a rewrite he gave it and a shower unit to a couple of people in the Admin department for testing. Turns out more rewriting was necessary. Overall he spent several days trying to get the manual right, and that was just one manual for one product.

I commented on the waste of resource this represented, and he agreed wholeheartedly. He immediately saw how employing a Technical Author with the necessary skills could not only have saved his time – which would be better spent actually being a senior engineer – but would also have cut down on calls to the support line by customers confused with manuals not written by a professional author.

He dropped me off in town and I went on my way pondering the following question: if a skilled plumber turned taxi driver can see the value in a Technical Author, why is it sometimes so difficult to persuade our colleagues of the same?

[1] You know the one: mystification tinged with disbelief. As if you’ve said “I’m a Marmalade Consultant”, or “I yodel professionally”.

Content Strategy for me?

The title is shamelessly paraphrased from David Farbey’s presentation at TCUK10, and is a point of view endorsed by other delegates in their presentations, such as Roger Hart in the excellently titled The Spork/Platypus Average – Content strategy at Red Gate Software.

I hate to oversimplify these two excellent presentations, but between them they made three key points that helped formulate my understanding of Content Strategy:

• Content Management is about rules. Content Strategy is about thinking – David Farbey.
• A Technical Communicator’s toolbox of cool things is a Content Strategist’s toolbox of cool things – Roger Hart.
• Content Strategy is not just about the Web – A point of view endorsed by both Roger and David.

So how does this apply to what I do?

I’ve been a Technical Communicator of one stripe or another for twelve years. I’ve worked on manuals, help systems, reports, presentations, flyers, specifications, user interface design… I’ve never had trouble finding a new area to apply my skills.

However, in my current role my remit is quite different. I was taken on to think about and to begin to implement more efficient and effective ways to manage the documentation created by the IT Department. And what a challenge that was – in over fourteen years of existence, the company had given no real thought to how to actually do this. At all.

I confess I launched right into a firefighting exercise. I juggled competing demands from managers wanting me to document BAU procedures and processes, while trying to learn as much as I could about what tools or techniques might be best applied. In short, how could I help non-writers write, because there was no way I could do it all myself.

Before TCUK 10 I only had the vaguest idea what Content Strategy might be. Afterwards, my neurons were on fire with ideas. I couldn’t believe I hadn’t realised before that recasting my ideas in the form of a coherent strategic approach was the best way to sell this to the department – and the business as a whole.

With the resources at my disposal  – my toolbox of cool things (i.e. my communication and analytical skills); the knowledge and enthusiasm of my colleagues; and the limited tools and budget already available – I was sure that what had seemed like a Herculean (or perhaps Sisyphean?) task became something I could tackle.

Just how this all works out is currently in the balance. Whatever the case, I am now firmly on the path to becoming a Content Strategy advocate.

Welcome

So, my first professional blog post. I’ve agonised a little about what to put here, so I’ve decided that instead of trying to come up with a nicely crafted bit of text I’ll just summarise why I’m doing this.

I’ve been a Technical Author now for over ten years. As a career path it has had its ups and downs, and for the last year or so I’ve been thinking about where to go next.

By happy coincidence I now have a job as a Technical Author that is actually requiring me to apply my knowledge and skills to broader problems of content creation, control and distribution. Thanks to the experience of the ISTC’s Technical Communications UK conference last week, I now know that this is Content Strategy and that being a Content Strategist is what I want to do when I grow up.

This blog forms part of this career shift I’m seeking. I want to have an ongoing conversation with the kind of people I met at TCUK10 (and TCUK09 for that matter). I want to air my thoughts on Technical Authoring, Content Strategy, and related topics. I want to find out when I’m making sense and, perhaps more importantly, when I’m barking up the wrong tree.

I hope to be posting fairly regularly. Comments, constructive criticism, advice, helpful links and amusing cartoons are very much welcome.