Tag: <span>Technical Communicator</span>

One of the reasons I started this blog was as a way of exploring my thoughts about our profession, from specific issues to wider themes. It’s only been going a few years, but I’ve learned a lot since then both writing here, and reading the thoughts of other bloggers in this industry.

I live and work in Scotland, far from the thriving centre of capitalism that is London and the surrounding areas, M4 corridor and the like. There aren’t all that many Technical Communicators in this neck of the woods so blogging helps me keep up to speed with the latest trends, and with fellow technical communicators.

I don’t really have much other motive than that, to be honest, so I was more than a little surprised to find out that I’ve been included in a list of the 25 Most Influential Technical Communicator Bloggers and, looking at some of the names on the list, I’m hugely flattered to be there.


Back after a couple of weeks of merriment, over-eating and general lazing about. Hopefully the festive season was as good to you as it was to me.

But enough looking back, this time of year is all about looking forward. So what is coming up in the next 12 months?

Well, I’m hoping to start migrating some content from Structured FrameMaker to AuthorIT, having decided that the overheads required to get DITA up and running just don’t stack up against the cost of ownership of AuthorIT. I’m a big fan of the principles behind DITA, and I will keep up-to-speed with progress, but it doesn’t suit our needs here.

I’m also hoping to post a bit more often here, and I’m also toying with writing up an article or two for the ISTC magazine, Communicator. As ever, those will be the first things to go when project deadlines need to be met, but I’ll give it a try. One thing I won’t be doing is undertaking an MA in Technical Communications. The course starts this month and there is just too much going on in my life at the moment… maybe I’ll join the September influx. We’ll see.

I will, of course, be expanding on the themes I’ve been posting about recently, specifically the role of the modern Technical Communicator in a forward-facing software company. I’m hoping to make some strides in this area and I’ll be sure to write up my thoughts on a variety of topics. I’m also hoping to hear more from YOU, dear reader. Whilst I did start this blog as a way of getting my own thoughts straight, it’s been great to read your comments over the past year. Blogging is all about the conversation, so please, don’t be shy.

Here’s to a wonderful year!

Right, I’m off to write up that article I had completely forgotten about.


My name is Gordon McLean, I am a Technical Communicator* and I am proud to be a jack of all trades.

Working in the software industry, and particularly for a company that has embraced the XP development methodology, I have exposure to, and contact with, most of the other roles in the company. I talk to Marketing to understand to who, and where, we sell our software. I talk to Deployment to understand the real issues they experience when using our software (they are our customers). I talk to Training to make sure we are promoting the same message. I talk to Testing to make sure the bug that I have found IS a bug and should be logged. I talk to the New Feature development teams to understand what they are working on. I talk to the Core team to make sure I’m aware of the myriad of feature requests and bugs that they are fixing, and whether they impact the documentation. I talk to our Support team to understand the common issues being found. I talk to the Architects and product managers to make sure what we are doing fits with the strategy.

Throughout all of this I must have an understanding of both who I am talking to, and what concerns them on a daily basis. I need to know enough about how Marketing and Sales work, what languages the Development team use, and know the business reasons behind why a particular piece of functionality is being implemented, and throughout all of those discussions I have to remember my role, and consider how the information I’m receiving in the discussion may impact the user and, therefore, the documentation.

Frequently I find myself to be the cog that transfers a snippet of information from one area to another. A minor bug fix that relates directly to a new feature. Most times those links are known, but on occasion they are only discovered when one of my team has started to consider the documentation requirements in that area.

Talking to all of those people, these different professions has helped me understand my role, and re-enforced my belief that, whilst writing documentation remains the core part of my job, a large chunk of our value comes from making, and maintaining, those connections.

Perhaps Technical Communicators are the social web of the workplace?

Prompted by The Top 5 Reasons to be a Jack of all Trades

* Communicator/Writer/Author, pick one. I favour ‘communicator’ because I don’t always communicate through writing, sometimes through UI design, sometimes through infographics and diagrams. You get the picture (pun intended!).


I’m published baby, yea!

Finally got around to writing an article for Speakeasy, and whaddya know, that nice bloke Carey published it (and only a couple of grammatical errors to correct too, which were only in there to see if he was paying attention…). Titled “R.T.F.M. – The plight of the Technical Communicator” it is an insider view of my profession, or at least one aspect of it. If you’ve ever used product documentation, it might be of interest.

So what are you waiting for? Go read it now.

Comments closed

If you work in I.T. you will no doubt have heard the abbreviation R.T.F.M. at some point. It stands for “Read The Frickin’ Manual”. As a Technical Communicator by trade it is always disappointing to hear it uttered. Hours and hours of research, learning and knowledge accumulation are pored into most software manuals, and all too frequently they are ignored.

“No-one reads the manual”?

So why do we bother? Like most professionals we take great pride in our work. We try and ensure that the information we present is technically accurate, written properly (frequently writing to ensure an easy translation is possible) and most importantly, of use to you the end user. So why don’t people use product documentation?

The advent of online help has moved the information you need into the product, so it’s only ever a button click away. Yet still it doesn’t get used. So what next? Microsoft tried to move things forward with the aforementioned Clippit. What was the customer reaction to Clippit? Well, new users loved it, but experienced users hated it. We now have applications that are led by the online help, stepping you through a task with additional information where needed.
So why doesn’t product documentation get used? Well, ask yourself this: if you experience a problem while using an application, what do you do? You ask someone else, or you search the web maybe, hoping to find a user forum, or possibly something on the company website that may help? Or do you just continue on within the application, hoping to solve your problem via trial and error? For the record I’ll plead guilty to all of the above.

Ultimately product documentation, of any form, presented in any manner, is never going to be well received. After all no-one likes to admit that they don’t know something and turning to the product documentation is an admission of failure. Factor in most people’s experience with poorly written product documentation from a few years back at the start of the PC boom and you have a recipe for, well, empathy I guess.

Most software companies have at least one technical author. That technical communicator spends many many hours thinking about you. Analyzing what you might need, creating user profiles, and trying to figure out how best they can help you. How best to structure the information they are producing and whether it is the correct kind, and in the right order and a multitude of other factors that are discussed at length every time two technical communicators get together.

So I have a plea: Next time you find yourself stuck, or if you experience a problem with your software, check the documentation first, and if you don’t find what you want, let the company know. Somewhere in that company is a technical communicator who is crying out to receive some valid feedback, something concrete they can use to improve their product documentation.

Those technical communicators are constantly striving to improve what they and their company offer, both in the documentation and as user advocates within the development cycle. Go on, throw them a bone.

Suggested Reading : What is a Technical Communicator? – http://stc.org/answers.asp


I’ve often considered either switching this site or launching a new one which dealt with my professional interests and opinions, a la zeldman.

Trouble is I’m not sure how many people would care, and how to narrow down what I do so as not to tread into too many areas. Writing, Grammar, Evolution of language, UI design, HCI, web design and usability, educating users, etc etc – the list is endless. That’s one of the joys of being a Technical Communicator – you get to do LOADS of different things, unfortunately it is assumed that you don’t do any of them as well as a ‘qualified’ professional (except the writing bit that is).

Sigh, now I just need to get up enough motivation. Ohh and to check that I can post some stuff without getting slapped by anyone at work … lol.

I also need to start going to bed at a reasonable time and stop reading work emails at 11:46pm! And with that thought in mind, night all!

Comments closed