I’ve been working closely with two remote teams for a couple of years.  It works well but it’s not without its challenges. No-one would decide to work with remote teams to make a developer’s life easier. It might make your developer’s lives more interesting, more varied or more frustrating but it won’t make it easier. Here are some general observations about working with remote teams and little tips that might make things easier for everyone involved – based round nothing more rigorous or scientific than my own experience.

1. What you measure, they will do

This is true for developers generally but it is doubly true for remote teams. What you measure, they will do. If you make a big thing about speed then your remote team will deliver quickly. It will be full or bugs but it will be quick. If you have daily calls with the remote team and tell them what an evil thing it is to have bugs reopened then they will make damn sure that they don’t cause bugs to be reopened. They will scour the bug list of easy bugs, take a lot time over medium ones and make every effort to get horribly, gnarly bugs back to the home team. Measure quality and you will get quality but your development might go at the speed of a particularly sluggish glacier.

So do measure but make sure you are measuring the things you really care about and understand the trade-offs that this might entail.

2. Mind your language

It is startlingly easy for the relationships between teams to become strained. You’re convinced the quality isn’t good, the communication is bad and the number of bugs is just ugly. Tensions rise and everyone in the home team is talking about how the ‘Romanian’s’ aren’t doing their job; how the ‘Indian’s’ haven’t got a clue; how the ‘Serbians’ clock watch and go home at the earliest opportunity. The home team is so much better than the rest of them.

Listen to what you are saying. Are you talking about ‘the Serbs’, ‘the Indians’ and ‘the Romanians’? Are you speaking about the remote teams as one homogeneous mass of development unpleasantness?  It’s so easy to slip into but it might be a symptom of deteriorating relationship. It might even be a cause of it. It’s far better to address people by their names rather than their nationality.

3. Time zones matter

It seems obvious but time zones do matter. Obviously if there is 8 hours difference then working practices will have to be adapted to cope with that. But in my experience even an hours’ time difference has an effect. I have found myself skyping the remote team at 16.45 with complex demands, forgetting that for them it is 17.45 and home time. Better to show sensitivity and let them go home unless it is important and needs to be done.

4. Everyone does more than their fair share of work

It’s a psychological fact* that everyone thinks they do more than their fair share of work. Take any group of people and ask them what percentage they contribute to the collective whole, add up the answers and marvel when the combine contribution is well over 200%. Everyone thinks they do more than everyone else.

This is magnified with remote teams. The home team becomes convinced the remoters are not doing enough. The remote team suffers from increasing and hysterical demands and becomes increasing disillusioned as their phenomenal efforts are just not appreciated. Everyone loses.

Just remember that you will be utterly convinced that you are doing more than your fair share. In reality you are probably just doing your fair share and everyone is also doing their fair share too.

*(I didn’t even make up this psychological fact – it’s detailed in the book ‘Thinking Fast and Slow’ ).

5. Communication, communication, communication

Make sure that you have excellent lines of communication and the means to reliably do it. In practice this could mean

• Everyone has a Skype account and is always logged in when they are in the office
• Everyone has a working headset and knows how to use it.
• There are spare headsets in the office. Many spare sets.
• There is an established way to share screens (Skype, TeamViewer etc…). Everyone has accounts and knows how to use them. The IT department supports it and installs the software for all new developers/testers etc…
• There is an established way for developers to control the machines of the home team – especially important for tester machines when trying to reproduce bugs
• Everyone who has any cause at all to contact remote workers has all of the above. The remote team has all this as well.

It’s so obvious and so obviously not done by everyone. We certainly could do better at this.

6. Have one point of contact but everyone can talk to everyone

It’s so important to have one person who is your point of contact for everything that your remote team does and it is so important to know when to ignore this and go direct to the source. Sometimes a bug can only be resolved by a remote developer talking directly to the home team tester and working through it. Sometimes a full understanding can only happen with a direct developer to analyst call. Sometimes developers just need to talk to developers.

This does vary for us though. One of the remote teams I work with has very strict lines of communication. The other team also has strict lines of communication but that one has benefited from some direct communication.

7. Have great development infrastructure

It makes things much easier to have great tooling and great development infrastructure. Initially we had 3 source control systems, 2 project tracking systems and a bug tracking system that didn’t integrate with anything else. Our deployment process was based around 3 witches, a giant cauldron and a book of spells. No good for anyone and triply difficult with remote teams. We changed this to 1 source control system, 1 project tracking system and 1 click deployment.

Clearly any development team is going to benefit from this kind of infrastructure goodness but working with remote teams adds complexity so you want everything else to be as frictionless as possible.

8. Write better code

Of course we all write perfect code all the time – it’s just other people that write bad code. However even the best of us sometimes write complex code that is hard to understand. It’s not too much of a problem if you are sat among your fellow developers and can explain to them why the byzantine morass of code you’ve just written is in fact a work of great elegance and is the best way to solve this particular problem. It’s more of a problem if the team is remote.

They can and will be baffled by what you have just written. Much time will be spent on conference calls explaining what you have done. The remote team will desperately try to get you to do the work so they don’t have to look at the code at all. It’s ultimately far easier to write easy code in the first place.

9. Pay attention to the fixed costs of outsourcing

I think that any remote team has a fixed cost of outsourcing so 3 remote teams of 4 developers is going to be more time consuming to manage than 2 teams of 6 developers. It is obvious but we ended up with isolated individual developers working remotely which worked less well. So size does matter and it’s worth paying attention to the size and structure of the remote teams. We found individual remote workers to be problematic.

10. Go visit

Really this is tip number one and makes the other tips obvious. It’s great to go visit the remote team if you at all have the opportunity. Of course not everyone is going to be able to do this but if the opportunity is there then it’s great to do it. The benefits I found were

• It’s suddenly really obvious what the communication problems are
• Email addresses and Skype ids become real people
• You realise that time zone do matter
• It becomes apparent how hard these people do work and how much they care about what they do
• You might spot other opportunities for outsourcing or what activities would be far better done by the home team
• The remote team will have better ways of doing things that you can adopt and take home

And of course you get to visit another country which is always great.

And if you disagree with all this

These are just from my own experiencing working with 2 remote teams. I’m sure every situation is different but I really do think there are common problems. If you are in a furious rage and disagree with all this then it’s all good. Just have a lovely cup of tea and calm down by reading outsourcing tips courtesy of Scott Adams and Dilbert.