Category: Work

The modern day technical writer, in fact I think we’ll go with technical communicator for this on, has a myriad of tools at their disposal. Be they authoring tools, publishing formats, or ways to collaborate, we are spoiled for choice. I can write content and make it available to the world in mere minutes if I so choose (and I do, frequently, you are reading it).

Of course, there is more to our job than the tools of our trade, so much more that at times I think we can forget that our value lies elsewhere and if we are forgetting that, can we really blame others for losing sight of it too? We are more than our knowledge of Microsoft Word, but I fear that’s not always apparent.

Working in a software company, I hear talk of the ‘quality of the code’ frequently, thankfully I hear similar comments about the product documentation, so where does the disconnect occur, how do our fellow professionals move from “those are the people who produce good quality product information” to “anyone can write product information” and, more importantly, how do we change that notion?

Part of the problem is that anyone can easily create and share information, better than that, they can collaborate with the author on that content. The people using the information can ask questions of the author directly, add their comments and even edit the content if it’s not correct. This is not new, Wikis have offered similar functionality for many years, yet somewhere along the line the value placed on information shifted from the quality of the content, to the functionality surrounding it.

• Can I access it easily?
• Can I leave a comment?
• Can I send it to someone else?
• Can I port it to another platform?

Some argue that information as a commodity raises the bar for us all, that by placing a value on information it allows us to be part of discussions we’ve struggled to gain access to in the past. Whilst that may be partly true, somewhere along the line we missed a grand opportunity.

Treating information as a commodity hides the real value and, worse, it places the high quality information we create into the same jumbled marketplace of content that we are all all too familiar with. As a commodity we have become just another coffee maker. Some people will seek out the best of such things, but the majority will not, they will seek the lowest cost and presume that, as it comes in a box that says ‘coffee maker’, it will meet their needs.

How do we change this?

The short answer is, we can’t. The horse has flown the cowshed (?!), the battle is lost.

However, that’s not to say the war is lost.

Good quality information will bubble to the top of the pile eventually. If your information is in a small pool, this will happen sooner rather than later. If you are concerned only with an internal audience you can help this happen by reaching out to other parts of your organisation to make them aware of what you are doing. If your information is in a larger pool, and you have to contend with other ‘google-able’ sources then you will need to do some leg work, some P.R.

This is not a new scenario and the very things that give us flexibility and power are also the things waiting to plot our downfall.

Information is a commodity. There is no escaping that fact.

But we are craftswomen, craftsmen of the highest order, and our knowledge and approach to information gives us an advantage that we shouldn’t be afraid to push home. Yes, all that other information is good, yes I’m sure it comes in handy now and then, but our information is something you can rely on, something that you can trust. It is honed, refined and delivered by experts.

Our information is not a commodity. It is a differentiator.

The sooner we all understand, and believe that, the better for us all.

Here in the UK, there is no escaping the fact that Christmas is approaching. On TV the adverts have started, the store shelves are being stocked, and in the office talk is turning to who might make a fool of themselves at the Christmas party.

It’s also about this time of year I start dropping hints in the hope that I don’t end up with yet another reindeer sweater…

So, in keeping with the Christmas spirit of giving, and to save you all some time and effort, here’s a few suggestions that you could, perhaps, print out and leave sitting around for a loved one to happen upon, or email to a sibling with a subject line of “Buy me something from this list and nothing else!!”

• Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services – I’ve just started re-reading this and the more I read, the more value I gain. Don’t be fooled by the titled, this is about content first and foremost.
• Conversation and Community: The Social Web for Documentation, 2nd Edition – a new edition of a book I recommend at every opportunity. The social web has changed the landscape for many of us, this book will help you cope.
• A new mug for the office perhaps?
• A nice pen? I like this one, but I’m sure this one would do me.
• A nice notebook, or two or, if you are like some of the stationary fans I know, several!: Moleskine Ruled Notebook
• How about a Dropbox account – always have your stuff handy when you need it and an easy way to share files with others.
• Reindeer Sweater – awwww come on, it’s Christmas!

Hopefully some of the above suggestions will save you from yet another pair of slippers…

Note: Most of the above links go through an affiliate account, so I get a few pence if you actually purchase the item.

Have you noticed anything different here? Maybe not, but those of you who have been reading for a while (thank you!) may have noticed that I’ve been managing to post here a couple of times a week recently.

Don’t worry if you didn’t notice, there is no test at the end.

I’ve been pushing myself to write to try and get my blogging mojo back, partly because I enjoy the process and the fact that it helps me keep in touch with what’s going on in our wider profession, and partly because there is a lot going on and I like to capture some of it.

But I can’t capture it all.

Looking back at this blog, there are some posts which hint at some things which ended up coming to pass. The signs are subtle and obviously I’m more tuned in to them than anyone else as I wrote it but they are there. It’s not that I want to be cryptic, more that I know that a sensible level of awareness and self-censorship are one of the most important skills to learn as a blogger. Whilst the opinions stated here are mine, and mine alone, I simply can’t post things which might compromise the company I work for in any way shape or form.

And so, as I started to pull together some notes with a view to publishing them on this blog I realised I wouldn’t be able to, not at the moment.

Suffice to say that the next few months could see some interesting challenges and changes, and as soon as I can I’ll be discussing them here (and my Twitter feed is likely to be reduced to a serious of exasperated noises). I am feeling excited, nervous and ready for what lies ahead and hopefully as we learn lessons here, I can share some of them with you.

That said, if there is anything you’d like me to tackle, any questions to ask, please get in touch. Always happy to help.

Job titles are one thing, but what do you actually do? Are you a ‘traditional’ Technical Author or a modern technical communications professional? Is there a difference?

I think there is, I think there is a distinction between the two although I’m not quite sure where that line is drawn and, as with most things in this multi-discipline profession of ours, the line is probably blurry and not all that straight.

For me the line separates what I consider the old and the new, the line between traditional technical writing and the modern day technical communicator, and I think the distinction is largely around the approaches each type of professional take when it comes to managing content.

I realise this may seem a little contentious, and possibly a little divisive (pun intended), so let me explain.

At the recent West of Scotland Area Group meeting, a few of us started discussing this. We all agreed that the traditional notion of what a technical writer (author) does has changed and that the change was driven mostly through technological advances.

For most modern companies, gone are the days of the author, editor, and illustrator producing printed documentation. The rise of the internet has changed the understanding of information and so our job roles (if not our titles) have morphed into what we do today, we write, we draw, we collate, filter, edit and publish information from a wide variety of sources, we care about the user experience of the product, and we push all of that information and knowledge out in many different formats, to different devices in radically shrunken timescales. We write topics, not pages, and publish to online portals, not printed and bound manuals.

From what I can tell, and I’ll admit that I’m not best placed to comment on any of this, I’ve only ever worked in software companies, but chatting to people at conferences and so on it does seem like the more traditional (old-fashioned?) approach of having a team – where the technical author writes the words, the illustrator draws the diagrams and artwork, before their work is combined and sent to an editor before being printed en masse – is slowly shrinking. For me it seems like that approach is typically based around some level of regulation (or litigation) meaning the scope of the content, choice of format, and even the list of final deliverables is impossible to negotiate.

Meanwhile, freed of such constraints, many of us find ourselves free to choose not to document a small change in an obscure and little used part of our product, and able change what we deliver and how we will deliver it.

Is it fair to be so black and white? Is there really a line, a divide, within our profession?

After all, my exposure to other technical communicators is largely through online sources (blogs, twitter, articles) and as those of us in the software industry have a vested interest in understanding these different mediums, it makes some sense that we are the ones making more noise than our counterparts who work in industries that demand paper-based outputs.

I think the disciplines required to work in a regulated industry are starting to differ more and more from those of us who can have input into the scope of what we do (and what we don’t do). There is a risk that future professionals won’t be able to cross that gap, they won’t understand (or want to understand) why they have to have numbered paragraphs, or why every single change must be traceable to the root requirement.

Over time, the more traditional roles, or rather the industries within which they operate, will start to come more towards a more modern view, in fact they already are. Airlines are allowing iPads onto flight decks, more connected systems of documentation and information capture forms are being seen in car production factories, and as further industries invest in modernising their infrastructures, so to must the technical writers.

Why are we still banging on about Content Strategy?

Is it really that hard?

A strategy shouldn’t be that tricky to formulate, especially as it’s concerning an area of expertise for many us, after all it’s only content, right? It’s not like it’s something new that none of us know anything about? So why is it so hard and why do we spend so much time talking about the whys and wherefores and, seemingly, so little time actually doing it?

Content Strategy is an area of our profession I’ve taken an increasing interest in. As the value of information rises, making sure you have a sensible strategy that is concerned about getting the best content required, for the right person in the right situation at the right time, has become increasingly important.

Even before Content Strategy became an entry on conference buzzword bingo sheets, making sure the content you were creating was offering the best ‘bang for the buck’ was something on the minds of all good technical writers. Sure, we could write documentation that would cover every aspect of the product but not only was that very difficult to achieve, leaving aside regulatory requirements, would all of that content be needed and used? Probably not.

Looking further afield, beyond documentation, many companies today are starting to realise that information and knowledge have more value than they realised, and so they are starting to treat content as a commodity. That means, for those of us who spend the majority of their time thinking about, planning, creating, and delivering content, our stock has risen and we have opportunities to do more, gain a stronger position in our organisations and flex our information management muscles!

And so we get to the tricky bit. For many people who don’t spend a lot of time worrying about content, it seems a bit grandiose to have to have a strategy around something that has been taken for granted or, in the worst cases, ignored altogether. Once you mention that having good control over the content being produced, with a view to improving how it is created and delivered, will cost money, suddenly the picture changes.

As companies start to better understand the link between content and the experience their customers have during their interactions with the company and the product they are using, so the need for better content, supporting and driving better user experiences, will rise.

None of this is new, these ideas have been talked about and debated for several years under the guise of Content Strategy, and for far longer than that in terms of ROI of content (and the teams who deliver it).

If you’ve been on the edge of any of these conversations, and wondered how on earth you could get such an initiative in place at your company then good news! Two leading experts in this area, Rahel Baillie and Noz Urbina, have combined their talents to write Content Strategy for Decision Makers.

Interestingly, you can’t buy the book in printed format yet, but you can read it and comment on it on the book website: http://contentstrategyfordecisionmakers.com/

It’s only online for the month of October, so I’d urge you to hurry along! It will be in print soon regardless, and I know it’s already on my wishlist.

In the past I’ve held the following positions:

• Technical Administrator
• Technical Writer
• Documentation Specialist
• Technical Communications Manager
• Publications Team Leader

The first three have similarities as they were all grounded in the production of technical documentation. The latter two are essentially the same thing, leading a team of technical writers producing technical information. None of the job titles I had limited me, by my thinking, in what I could and couldn’t do.

My current job title, as confirmed on my new business cards which handily arrived just AFTER I’d been to TCUK12, is Product Information Manager. I didn’t choose this but, whilst talking through my role and responsibilities recently, I realised it’s pretty accurate.

The team I’m part of does a lot more than write technical documentation. We create many different types of information, mostly recently writing more chatty article style content, and we get involved in all manner of product related discussions. We’ve also driven the creation of a developer community website, and we continue to look for new ways to improve our offering to the product and the company.

As the onus and value of information shifts, largely influenced by the web, it’s been something that we’ve actively pushed. Whilst our work is still mostly based around the production of information (albeit in increasingly different styles and formats) we are also pushing into the area of user experience.

Having to step back to explain my roles and responsibilities was something I don’t do often enough. It’s sometimes easy to forget how far things have changed and improved, and it made me realise that my new job title is more accurate than I’d realised. My team is a product focussed team.

The realisation matters not, however, and we will continue to push to improve, try new things and if those things aren’t of benefit to us we will try others. Above all we try and keep in mind that we are working on a product, and that makes it all the easier for us to have conversations with other parts of the company.

Am I a “Product Information Manager”, not quite yet I don’t think. Whilst my team do offer various types of information about the product, we don’t yet have a hooked up strategy for the entire product, and that’s where content strategy comes to play.

Regardless, it is the first time I’ve really felt like my job description represents what I actually do and, more importantly, that is suggests that there is more to come.

What’s your job title? Is it a good representation of what you do? If you could, what would you change it to?