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.