One of the challenges the team will face this year is how to coordinate the creation of product documentation with geographically dispersed teams, across different product lines.

At present we have engineering teams in Glasgow, Belfast, Limerick, Jakarta, Sunnyvale CA, and Bedford NH, building four products and maintaining five other legacy applications. Currently we have six technical writers in Glasgow and one in Belfast. Initial assessments suggest there is a bit of a resourcing gap (a separate issue I’m dealing with) but beyond that the main challenge will be figuring out how to best work with these disparate teams.

I have asked this question in a couple of places and had some excellent responses. Some cover things we had already considered but there were some gems borne of real life experience that I was lucky enough to have shared with me. Many thanks to Tom Marshall, David Farbey, Cheri Mullins, Larry Kunz, Alan Bowman, and Kay Winter and others for their suggestions.

First things first though, and it will be important to discuss and agree on responsibilities, tasks, and roles. Naturally there will be a level of autonomy, so it makes sense to have sensible agreements on what issues require escalation and so on. Part of these early discussions will also need to include tooling agreement, writing styles and output formats. Ideally these can just be extend from what the team currently uses but that will have an impact on both sides.

The timezone is an obvious issue which could have a dramatic impact on communications between the teams. Case in point, the teams in Bedford and Jakarta have a 12 hour difference! So one of the first things we will need to do is consider, as we won’t have the luxury of immediacy, is a ‘rules of engagement’ or contract between teams as to how we will correspond, talk, meet and share information. Nothing too formal, but setting out expectations will do no harm. For example, when sending out an email should you expect an acknowledgement? Or should everyone have ‘read receipts’ enabled?

Some of the challenges we may face we already have solutions for; we use Google Docs for collaboration, we have conference lines ready, our engineers use a common JIRA install.

Thankfully there are numerous technologies that can help us with communications:

• Everyday – Instant Messaging – for a quick question or two, and as a way to see who is available (and how you are working with), IM is a useful tool. Add in file sharing and it becomes a little more powerful.
• Information Sharing – WIKI and Google Docs – for collaboration we’ve had good success with Google Docs, but there is no reason a WIKI couldn’t fulfil the same role.
• Meetings – Skype or Google Hangouts – Skype nicely doubles as an instant messaging app, which also allows you to send files and of course you can host conference calls there. Recently I’ve seen some friends have success with Google Hangouts (part of Google+) which, as most laptops come equipped with a webcam these days, might be a good option too.

Not to forget the trusted old telephone! Ideal for a 5 minute catchup every day or so.

And, of course there will also need to be face-to-face meetings on a regular basis to make sure the technical writers feel part of the team, that includes organising social activities as well.

Other suggestions I heard, and which are worth heeding:

• Regular conference calls – Make sure these have an agenda and that everyone has prepped beforehand to maximise usefulness.
• Access to latest builds of the software – in our office we can checkout the latest build of the code any time we want, no reason remote technical writers can’t do the same.
• Be sensitive to cultures, both professional practices and social niceties.
• Adjust for time zones.

There are many pitfalls ahead and whilst I have great confidence we will figure them all out, obviously the more we can spot up front and negate, the better (and cheaper) the end solution will be. As ever, I have the advantage of working with smart people so I’m confident it will work, once we figure out exactly how.

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!

I hope the holiday season finds you all well, thank you for visiting and reading, and all the best for 2013!

Gordon

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.

This blogging thing seems to be catching on, so much so that my company will soon have a blog looking at industry specific issues and thoughts.

And yes, I’m one of the bloggers. I’ll link to it once it’s up and running (we are testing it at the moment) and provide a bit more information as well.

Feels a bit like I’m coming out of the blogging closet!

Well hello there! Apologies for the lack of updates recently, suffice to say there is a lot of ‘stuff’ going on at the moment and, inevitably, things like this blog are the first to suffer (which is, of course, perfectly correct).

For the next couple of weeks you are probably better keeping an eye on my Twitter account as I’m still pinging useful links and comments there. Never fear though, I will return as I’ve got a list of blog posts to complete (see below).

See you on Twitter

Quite a lot going on at the moment, but don’t worry dear blog reader I’ve not forgotten about you, I’ve still got plenty of things to post here just not really finding the time (or requisite brain power) to focus on them and think them through properly.

Here are some of the things I’ve started to write about but not yet posted.

In other words, “here are the posts languishing in DRAFT”.

• Content from the ISTC and STC publications, why isn’t it all free?
• Social Media Models, where I try and outline what I think are the models that we, as technical communicators can get the most value from adopting
• The evils of presumption
• Embracing user-generated content
• Small social media. If your ‘community’ is very small, what will work for you?
• How to stop thinking about documents

I will hopefully revisit some (all?) of these in the future, but before all that I have an eSeminar to prepare for, more details on that soon.