Sunday, April 13, 2014

How to adapt to working with outsourced teams

For the longest time, as I was learning what it was to be a developer the most predominant model of collaboration was via IRC.

Interestingly many others I went on to work with didn't seem to know about it - the support structures it provided were simply missing or passed on via direct learning.

Having worked increasingly with offshore resources over the past few years, it's clearly a pattern that Australian companies are following more and more - not just in IT, but in administration and other roles.
It's not just for large companies either - the number of fluent, competent workers around the globe who are available as an extra pair of hands for an overworked developer is large; and can act more as a force multiplier than anything else.

Here's some of my observations on how you can work with a remote team.

Hire fluent people you respect

There's a lot of people around on sites like Elance, but it's really hard to find good ones. Invariably, it becomes a race to the bottom when outsourcing your project; and unfortunately you get what you pay for.
Offshore development shops that have a focus on winning contracts sacrifice quality for volume - and the people who work for them are often vastly underpaid. The rates you pay are low, and what actually goes to the end developer is even less.

If you have a project in mind, be specific in what you want. Hold people to a high standard. If you wouldn't read their blog or follow them on github because they seem to be doing interesting things; there's a good chance your relationship will become overly simplified and toxic.

Be prepared to pay accordingly: someone might work for a quarter of your wage, but produce work that required significant rework. Finding someone who can convincingly charge a reasonable market rate works best for all: you respect their abilities and time; you aren't going to muck them around

Build ongoing relationships

One off projects that cause people to push themselves too hard mean lower quality and no one wanting to work long term.

Someone who knows the kind of work you do, the domains you specialise in and is happy to work with you a few times a year or month is going to take far less time to ramp up to a new project.

In addition, you can both grow in experience - you'll learn how better to communicate and schedules; they'll know when to ask the right questions.

Use the highest bandwidth communication tools for the job

Clear specifications/requirements are key, but can you go further? Videoconferencing is trivial - a google hangout or skype call can convey significantly more context than any email.
Schedule these regularly, to keep everyone focused and keep aware of progress; even if timezones are a a little out of sync.
If mistakes happen, again, use the highest bandwidth medium to talk about them - it'll clear up misunderstandings with far less angst.

Find an 'always on' medium

Campfire, IRC, Email, etc - being able to constantly put questions out and collaborate means faster turnarounds on problems.
Find something that provides you with a transcript, is searchable, etc - linking to past conversations helps context be shared to new team members.

Experience common moments & humour

If you can't post memes, amusing gifs; or poke fun at each other it's a sign there's a lot of context and subtle communication missing.
Endeavour to find things you can share and laugh about, as it builds alignment if nothing else.
The more relaxed your communication is, the easier it is to deal with misunderstandings.

No comments: