bookmark_borderHappy New Year

Looking forward is always a good thing, but I’m going to start this year by looking back at the lessons to be learned.

Things I will need to improve upon include better planning of work, there is one big project that I will head up that needs to be delivered by September, so I’ll be looking at how to get a better handle on that. One thing I learned last year was to rely more on my colleagues, to look to their strengths to compensate for my weaknesses; attention to detail is something I can struggle with so I’ll be getting some help with that by getting my plans reviewed by a couple of people before I present them to others.

Delegating the right things is something else I didn’t quite get right last year, there are some things I do need to keep tabs on but the rest of the work I can, and should, delegate to the rest of the team. They have proven they can deliver so I need to trust them to do so again (and they will, because as I may have mentioned, I am very lucky to work with some excellent people!).

However, it is a new year so let us look forward.

I’m going to keep on writing here, suggestions for topics or questions you’d like me to tackle are welcomed, and I’ll hopefully get back to the Technical Communications Conference again next year. I’ve got plenty of things to do for the ISTC website and at some point will be assessing a new authoring environment for the team which, possibly, will expand to include resource overseas.

Plenty of challenges then, which is just how I like it!

bookmark_borderSay Thank You

As some of you will now be aware, I am no longer writing my monthly Blog News column for the ISTC newsletter, InfoPlus+.

It actually started life here on this blog, every week (or so) I used to post a list of interesting posts and blogs and for a while there was an overlap but, eventually, I dropped the feature from the blog as the monthly approach gave me a little more scope to collect the best links and yes, I will admit I enjoyed the writing process that went with the column (believe me, it took me longer than you’d think).

Alas life continues to challenge my time so after not managing to submit my column for a couple of months (the shame!) I decided to make the hard decision and stop altogether. It doesn’t mean I’m not reading blogs any more, just that I’m not writing about them as much.

When it came to writing my final column, I checked back at when the column started and I was more than a little surprised to find out that it had been going for over 4 years! I’m quietly amazed it lasted that long, given my normal propensity to prefer tackling new things than sticking with current projects (I am a magpie).

There was one thing that I always struggled with though, and that was the lack of interaction, the lack of feedback. I had no idea if anyone was reading the column! The newsletter is published as a PDF and sent out via email so there are no stats to be viewed, in fact it was only at the Technical Communications Conference when a couple of people mentioned that they read it and, even better, they enjoyed it that I knew for a fact that it was worth writing. What a lovely little boost that gave my ego!

I most certainly wasn’t writing the column for that reason, in fact I’ll be honest and admit that I was writing it to try and boost my profile (I was also speaking at conferences and presenting webinars at the time) but that brief moment of adulation was very welcome. At least I think it was adulation… maybe they didn’t actually want me to autograph their conference programmes… hmmmmmmm.

I’ve been blogging for a long time so I guess I get a little blasé about feedback. Comments are great to see, I love the discussion aspect and the fact there is a passionate community of technical communicators who pop in here now and then, and if nothing else I can always check my stats to see that people are visiting the website (and presumably reading for they stay for a few minutes at a time), but being told face-to-face that someone has enjoyed something I’ve done, not much tops that.

It’s only now, reflecting on the fact that for the first month in 4 years I’m not starting to collate links and thoughts for the Blog News column, that I realise that saying thank you is something I’ve not done enough of, so let me start.

Thank you, dear reader.

Thank you for visiting and reading.

Thank you to those who visit, read and leave a comment, who join the discussion.

Thank to those who link to this blog, or retweet the link for others to see.

Thank you for taking the time.

I sincerely appreciate it.

Now, it’s your turn. No, I’m not looking for anyone to thank me, but take a moment and consider who you should be thanking, have you said thank you to them recently?

If not, now is the time. Go on, you will make someone’s day!

bookmark_borderWhy seems to be hardest word

I was chatting to a new colleague, an experienced technical architect, the other day to give him an overview of my team and what we produce. He asked what type of information we provided, was it the “clicky clicky” type or something more useful that explains how our product works.

I assured him that we covered more of the latter type of information, but also provided “clicky clicky” (procedural) information when appropriate. For his type of role, that audience persona (experienced and highly technical), that form of information is exactly what he wants. For other parts of our product, used by inexperienced staff often with a high turnover, we try and help keep the costs of training down by providing more of the “clicky clicky”.

It’s all about the audience after all, right?

Thing is, as I walked away from that conversation, there was something in the back of my mind that wasn’t sitting right, something was irking me and it wasn’t until a couple of days later I realised what it was.

Within the team, there is one question we try and answer, one question that we find useful when trying to understand the latest greatest features of our product. Why?

We ask it of technical architects, product managers, software engineers and business analysts. We ask customers and our professional services staff. Hell if we can we’ll ask our Chief Technical Officer.

  • Why are we building this?
  • Why did we build it this way?
  • Why didn’t we build it that way?
  • Why should our customers use it?
  • Why should I use it this way and not that?

The list goes on…

And yet, walking away from that conversation I started to realise the one place we don’t ask it often enough. Within the team, of ourselves, we need to be asking one question more often; Why are we writing this piece of content? It’s a simple question but should allow us to follow on with further reasoning.

  • Who asked for this?
  • Who will use it?
  • Why am I WRITING this, would it be better as a video?
  • Does this piece of functionality even need any supporting information?

As the team continues to grow, and we start to take on more work from other parts of the organisation, we will need to keep these internal challenges in our minds.

This notion also fits, loosely, to a general theme that has been in my head since TCUK12 the idea of lifting your head, getting out of the default position of “write content” that many of us fall into. Whilst that’s a good default to have, as the world of Technical Communications continues to change it will benefit us all to spend a little bit more time asking why.

Challenging presumptions and changing attitudes towards our profession is not easy, but asking why can help.

Our profession is largely focussed on product, we understand that there are users of the product, we understand that those users vary in skill level and knowledge. Asking those why questions tells everyone else that we are thinking at a higher level, that we are trying to do better, that we want to contribute value to our organisation, this is particularly of value when you bear in mind that we tend to have a different view of our products from many of our counterparts.

As a technical writer, we touch all levels of a product, from the conceptual information all the way through to the technical detail of the implementation itself. We understand the business requirements, the use cases, and the end functionality. Not many other departments share that view so when we ask why, we can ask it from a position of knowledge and, increasingly, authority.

Too often I hear people say that they feel frustrated, that they don’t get the information they need, or struggle to get people to understand what value they bring to a company. Maybe the questions we are asking are partly to blame? Asking why is a soft way of challenging, of gently nudging people to a different view, if you are persistent and consistent the people you work with will start to anticipate your questions, raising their game to meet yours and that’s where the value lies. Not only does asking why get you more of the information you need, allowing you to make better decisions about your work, it’s also provide a link between parts of your organisation.

So be that person, be the central resource that asks why. It may take some time but stick at it and, along the way, you’ll have opportunities to promote what you do and others will start to place more value on the information you produce and the value you provide to the company.

And that, to me, is a perfect example of a win-win situation.

bookmark_borderWhat is your job title?

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?

bookmark_borderSo that was TCUK12

It’s been a few days since I got home after the Technical Communications Conference this year, and I’ve been digesting and mulling over some of the ideas and thoughts gathered from the speakers and conversations.

The conference was in a new location, Newcastle, and that brought a different feel to the event. Hard to put my finger on it but it felt a little more business like, or maybe just a little less social? Not sure, and as ever my experience will be different from others.

Something that hasn’t changed was the value. It remains an excellent opportunity to learn from your peers, industry experts, and if nothing else it’s great to hear that we are doing the right things or just have the same problems as everyone else.

A few standout presentations from me, Leah Guren (whose workshop I attended on the Tuesday) kicked off the conference in great style. Passionate, funny, upbeat, everything that we can occasionally seem to lack in our profession here in the UK. Ray Gallon and Scott Abel backed that up with some excellent presentations that expanded the scope of what we can, and should, be doing.

It took me a while to realise it but the one thing I didn’t get this year was an overall theme. Not an official one, but typically there is one stream of thought that seems to be prevalent. I think the closest to that would be ‘Structure’ (as a strategy) and I wonder if, perhaps, that that particular stream of thought hasn’t yet hit a tipping point?

Still pondering that, and many other, things, one of which is that I really need to be blogging here more! Time will tell if I can stick to that.

bookmark_borderTCUK 12

The time has come, so Gordon said, to talk of many things, of slides and chats, and learning facts, and something else that rhymes but I’m rubbish at poetry (with sincere apologies to Lewis Carroll).

Enough of that though, what I want to talk about is the Technical Communications Conference 2012 (TCUK12) and why you should go.

Disclaimer: I serve on the Council of the ISTC, who organise this event. 

Let me tell you a story.

Once upon a time a young (ok, middle-aged) man had started a new job and was trying to figure out the best way to improve things and solve some of his problems. The year was 2007.

At the time, the young man (oh shut up) had started a blog and was finding a lot of interesting people writing about Technical Communications. From that he heard about something called DITA. To learn more, as it sounded very much like it might solve his problems, he went to a conference (X-Pubs) in Reading. He learned a lot, and met a lot of inspiring and interesting people. Turned out DITA wasn’t for him though (yet).

Later that year, he had the opportunity (entirely thanks to his blog and a lovely woman named Anne Gentle) to attend and speak at TICAD, an opportunity that came about directly through this blog. It was a smaller conference in scale but just as rich in information.

Having set a precedent of attending conferences, he looked around for another the following year and, remembering how good he found the Digitext conferences (many years ago now) he decided to attend the User Assistance conference in Edinburgh (2008). Again, he found himself surrounded by his peers, and took away some valuable lessons.

The following year he heard of new conference, and as it had multiple streams of presentations he thought that would give him the best chance of learning. He also felt foolhardy enough to present at it (but let us not dwell on that). The conference was called Technical Communications UK (2009).

And that’s quite enough babbling about me.

It’s always interesting to see what presentations and theme the conference will have, each year has had a different third stream, and this year it’s focusing on Accessibility and Usability, something I know many technical writers working in a software environment inevitably get drawn into (if it’s easier to use, it’s easier to document). Add in the longer workshops on the first day and, for the money, it’s hard to beat.

Like many people I’ve had to convince my boss it is worthwhile letting members of our team attend, but I’m convinced that everyone will find a handful of topics that they could learn about and look to apply at their own workplace, the trick is to plan to do just that.

Any time I’ve ever returned from a conference I’ve been excited and looking to apply ideas and techniques to what we do. If we hadn’t managed to implement some of these things then it would be much harder to ask again the following year as the evidence of value is a hard thing to argue against!

Above all though, TCUK seems to have a good energy, a good ‘vibe’ and everyone who attends seems that little bit more driven and up for learning, discussion and basically getting stuck in. I does help that most people stay over so you start to make friends over a glass of wine (or three) and that carries through into the next day giving the entire conference a relaxed, friendly feel.

If you only plan on attending one conference this year, I would heartily suggest TCUK as a great starting point.

Hope to see you there!