I was recently asked for some advice for people new to technical communications and I found myself reminded of the Curse of Knowledge: “when we know something, it becomes hard for us to imagine not knowing it. As a result, we become lousy communicators”.

I struggle to remember not only what I didn’t know when I first started out in this profession, but how I learned things on the way. Memory suggests it was a mix of trial and error, good advice and lots of reading of other documentation to see how other people did it.

I won’t give away the advice I passed on, it’ll be published next week, but it did cause me to ponder my own career progression and how I pass on the knowledge I have to the rest of the team.

Passing on a mish-mash of learned knowledge is always tricky and can be dangerous. A recent discussion about improving the quality of our indexing reminds me that the way I learned to do it was based on thinking that is ten years old and may, or may not, have been superseded by better researched methods.

So the best thing you can teach anyone is surely the ability to learn for themselves, give them space to make mistakes (everyone does, it’s an essential part of learning), and help them understand what questions to ask and when best to ask them.

The next ISTC technical communicators’ meeting in Glasgow will take place on Monday 8th November 2010, from 7.30 pm onwards. Come along to talk about latest news and trends in communication, or just to meet other communication professionals.

The event is free and open to anyone interested in technical communication, such as technical authors, information architects, internal communication professionals, report writers, marketing writers, web content writers and graphic designers.

Venue: Waxy O’Connors pub, 44 West George Street, Glasgow, G2 1DH. Please make your way to McTurk’s Room on the middle level.

For more information, contact westscotland_areagroup [at] istc.org.uk.

As the end of the year starts to draw close, inevitably thoughts turn to 2011 and the challenges that may lie ahead. From a product point of view we are starting to get a feel of how the year will shape up, and so we can start to look at how our team negotiates the (still forming) landscape.

It already looks likely that our aim (alongside keeping pace with product development) will be to get to a point where we can correctly focus our efforts around structure, and ad-hoc document requessts. Given that we have access to outcome codes from the Support team, several of which are specifically around product documentation being either wrong, missing, or not read at all, and we will soon have a full set of analytics from our online product documentation, which should put us in a much better position to correctly prioritise those additional work streams rather than fall into the “whoever shouts loudest” model we are currently prey to.

The analytics are powered by Google Analytics and track visits to each topic of the documentation set. The numbers should help point is to areas of the documentation that, for one reason or another, need some attention. This works both ways of course, a high number of views indicates a lot of people using the information, but where are they going afterwards? If they head to the Support area of the website then can we presume the information isn’t correct? And those topics with little to no views, are they not used because they can’t be found?

I’m a little wary of spending too much time analysing the statistics and initially they will be used purely to direct us to the outliers, those topics that for one reason or another are causing anomalies in the reported numbers. Once we smooth those out then it will require a lot more deep-dive style root cause analysis which, as with everything else, will bring a fresh set of challenges and hopefully some new routes of communication with our customers.