In this exclusive interview, Scott Abel of TheContentWrangler.com talks with Melanie Kendell, founder of eMorphus, a fledgling information management consultancy that specialises in helping people achieve XML-based content management for producing technical publications.
TCW: Melanie, thanks for agreeing to share your thoughts on technical writers and content management. How did you get involved in technical writing in the first place?
MK: As with a lot of people, I kind of fell into it by accident.
I had been a trainer and a technical support person, but when I found out about technical authoring (as it was called in England) and tried to go in that direction I was told I would need to be able to read code and that was that.
After moving to Australia I got a job as a helpdesk manager but it wasn’t working out, so I rang about an ad for another helpdesk manager position and they said that one had gone but they had this technical writer role. They obviously didn’t know anyone that they could put forward for it!
Anyway, the rest is history; it is a job that allows me to use both my technical skills and my love of language: a good left/right brain balance.
© Hans Auer – FOTOLIA
TCW: Most everyone that has made the leap from technical writing to content management seems to have an “Ah-ha!” moment story. Did you have such a breakthrough?
MK: I very quickly realised that creating manuals was easy (or at least fun) whereas maintaining manuals was a pain in the arse. So I started hunting around for a better way.
At that time the only thing that was around was document management. So I had a little “ah-ha” closely followed by an “oh-bummer” moment. Yes, it solved some issues around versioning and access control but didn’t allow for reuse or retargeting of information.
My particular problem at the time was the ability to make edits to the current manual and reissue it while at the same time continuing to work on the next version. We did look at SGML, but it was all too hard.
When XML emerged I got very excited. Here was something with the power of SGML, but in a format that was getting much wider acceptance across the data world so I was anticipating some whiz bang tools. Unfortunately, because it was the data world that made it popular, the initial tools were not good for documentation, they’re getting better, but it’s taking time.
TCW: The content management industry, although still in its infancy, seems to be attracting forward-thinking technical writing experts away from solving traditional technical communication problems. Instead, former tech-comm superstars have parlayed themselves in to specialists who solve content problems of all types. Theyre headlining at major conferences, writing articles for top business publications, and are often called upon to solve some of the worlds most complex organizational content challenges.
MK: I actually think XML-based content management is just an extended solution to traditional technical communication problems: how best to structure information so it can be found (both by the reader and anyone maintaining the text), how to deliver content that is relevant to the reader, how to maintain consistency, etc.
What content management does is allow the computer to do some of the heavy lifting. So, for example:
- Writers have guidance in how that particular organisation presents their information; even experienced writers need to come up-to-speed with a company style.
- Properly tailoring content to an audience becomes achievable; it has always been a nice to have, but required too huge an effort to do manually to any great extent.
- You can reuse content better: but now it should be easier to find the stuff that is worth copying … and divergence once duplication has occurred is no longer an issue.
Good tech writers (generally the ones that are happier to call themselves technical communicators) have always concerned themselves with the whole information management process from getting involved in change management (so they know whats coming), to understanding whats needed in marketing. They have a finger in every pie of a products’ lifecycle and are therefore in the best position to see how everything hangs together.
This tends to engender an extraordinary ability to understand:
- How information flows through an organisation
- How to capture that information as content
- How to make it available to information consumers
It is being able to balance this macro level view with a practical understanding of the necessary tasks at the micro level and the knack of making things happen that sets the superstars apart.
TCW: And yet, despite these far-reaching successes, most technical writers have yet to self-identify themselves as part of the content management solution. Why do you think that is? Why arent technical writers quickly positioning themselves as business content experts instead of cubicle dwelling authoring tools masters?
MK: I’m not sure I can answer that. For years people in this profession have been bemoaning the lack of recognition for our skills. Content management is our chance to shake our booty and I don’t understand why some people are reluctant to grasp this opportunity.
Organisations place very little value on their content, if we can both value-add that content, and make it more manageable (and therefore less of an overhead), we become more valuable to the business—and that can only be a good thing.
I have heard concerns that we will end up being robots that just put a bunch of existing paragraphs into new combinations. Of course this is ridiculous thinking.
- How will those “existing paragraphs” come into being?
- It takes skill to run a bunch of paragraphs together so they actually make sense.
But seriously, the majority of the writing process will be exactly the same. You still need to think of the best way of wording a sentence to get the message across.
You may be a little more restricted in terms of the structure of the document, but an existing corporate style could be just as restrictive.
Even the tagging process is similar in many ways to applying styles at the character level, you apply a filename tag rather than a filename style. At the paragraph level you have a hierarchical structure rather than applying heading levels. There are some extra complexities and I’m not going to say that it’s just as easy, but it’s not that hard either.
What is hard is the content modeling process—developing a schema that will work with your content. This is something that only some people will be able to do, but again, tech writers (many, but not all tech writers) can be some of the best people to do it—they know content structure! But this is one area where getting someone who has done it before to at least review the model before applying it is vital.
Another area where good advice early will save a lot of heartache, is setting up the publishing of the content. There are lots of approaches and they all have limitations, so you need to make sure you pick an approach where the limitations won’t kill you.
TCW: I’m not so sure that the average technical writer fully understands the implications of content management on the technical communication industry. They seem afraid of making the changes needed and of stepping outside their comfort zone. How much do you think fear plays a role in preventing the majority of technical writers from taking the leap from the narrow field of technical communication to the broader discipline of content management?
MK: I think one of the main misconceptions is that eventually all content will be structured. This simply isn’t feasible, structuring content requires a lot of work up front and not all content is worth that effort.
The other thing is that content management comes in many different flavours. I tend to focus on XML-based content management as I see that as true content management, but many content management systems are simply rebranded document management systems or web publishing systems, and these will have far less impact on the writing process.
But, it is important to understand in principal what content management is all about and, if you shy away from that knowledge because of a fear of change, you could find yourself unable to contribute to discussions that may affect your future.
TCW: What are some of the benefits of moving from technical writer to content professional?
MK: I now call myself an Information Management Consultant—people still dont know what I do, but they’re a lot more impressed.
As a tech writer, I got to try out lots of different roles business analyst, usability expert, information architect, project manager, change manager, etc. Now I get to use all those skills in an area that is close to my heart.
Of course, one obvious benefit is that, as I have developed rare and valuable skills, I can negotiate an appropriate reward for my efforts.
TCW: Its not enough to re-brand oneself a content professional. What do technical writers need to do first in order to find their place in the content management arena? What advice can you give those who are reading this interview who want to make a change?
MK: First things first, you need to understand why content management exists, what are the issues around managing content that cause the pain that drives the solution. If you don’t think there are any problems in maintaining documentation you’re going to find the idea of content management difficult to grasp.
Second, realise that content management is a business solution not a software solution. Researching content management software is not the way to understand content management (some vendors have good resources on their sites but be careful of being brainwashed into a proprietary view of what content management is). If you can identify a problem in a business process and see a better way, see if you can get your idea off the ground.
Generally, seek out information about content management and join email lists and organisations relevant to the subject. But maintain a healthy skepticism – not all sources will give you the right information or, it may be right, but maybe only if you are publishing websites (be aware that CMS is often used inappropriately in place of WCMS), or only if you have good developer support, etc.
Once you have a good grasp of content management as a concept (backed up with some practical experience : create your own projects if nothing else) you will need to work on general business skills. The stumbling blocks to content management success are far more to do with managing change appropriately than any technical problem. Nearly everyone is involved in content either as a producer or a consumer, so managing everyone that needs to be involved is a big job.
