My first experience of managing a remote team was not a success: the team broke up quickly, and the company soon after. At first, I thought the issue was the personalities involved but as I’ve looked at more companies trying to set up offshore development offices, I’ve seen there are some common mistakes.
I want to start by looking at what’s different between managing a co-located team and one in which some or all of the team members are distant – meaning they can’t meet regularly.
Them and us
Firstly it’s very difficult for remote teams to feel part of a team at all. Typically, the project manager, and maybe the lead designer or developer, sit in one office and the rest of team in another – which eats away at the open collaboration principles behind Agile. The remote team often feels like their feedback is not appreciated and their input is not quite as valuable as the input from those in the head office. It’s made worse when the offshore team are contractors and know that when push-comes-to-shove they’ll be the ones that get pushed.
Keeping on the same page
A particular issue for smaller organisations is that priorities and business goals change quickly, and those not physically in the same office can miss out on the drinks after work, the lunchtime chats, and the corridor meetings, which form an essential part of keeping on top of what the company’s doing. Regular Skype calls can’t really replace the unstructured and more nuanced communication that comes from rubbing shoulders with colleagues in the same office. If the remote team are the last to find out about important changes to business strategy, that reinforces their status as second-class citizens.
Slower comms
Even with Slack and Skype Chat, a delay in responding to a text message can seem deliberately obstructive to the remote team if they don’t understand that you’re busy in other meetings all day. Even worse if the remote team are at a big time difference, and there’s only a small window of the day when messages can be answered in real time.
Cultural differences
Although software development is an incredibly egalitarian industry – I’ve worked with over 40 nationalities in my teams – there are still big cultural differences when people are not living in the same city. For example, in Romania, constructive criticism is expected in the most direct way possible, whereas in India it’s considered the height of rudeness to tell you anything but good news. Likewise, commitment to a sprint deadline can be treated as if carved in stone; or as an aspiration, if everything else goes well.
Middle management
Having a separate office often means needing a local manager to handle HR, office admin, and general project management. Unfortunately, this conflicts with the flat management structure desired in most Agile teams. In one Polish team I worked with, the junior developer failed to raise any serious questions he had about the specifications because this would show signs of weakness in front of his local manager, whereas the manager felt that we were paying him just to get it delivered whatever the consequences. As a product owner, I’d prefer to have an open and honest view of the project process.
Recipe for success
I’ve built up my current team (based in Cluj-Napoca, Romania) over two years. I feel we’ve built a strong culture, and the increased momentum of the development and loyalty from the team members speaks for themselves. Originally, I thought that a co-located, agile team in London was the optimal solution. But now that we’ve raised some funding, I see that offshore can work just fine if managed in the right way; and as office costs and salaries keep escalating in the larger cities, the reasons for going offshore are even stronger now.
So here are my recommendations of how to repeat this in your team:
1. Mix up the roles
Trying to create specialist centres – for example, having all the back-end engineers in one location – creates more problems than it solves. While the communication between the engineers, in this case, might be speeded up by having them sit at the same block desks, it exacerbates the Them and Us problem. Whereas having engineers at multiple locations means that stakeholder group feels represented in whichever internal meeting is happening. Agile team culture also thrives off the diversity of different personality types in the same office; whereas an office monoculture reinforces the view that ‘the others’ always do things in a certain way.
2. Bring everybody together physically on a regular basis
At Littledata we aspire to meet up as a full team every two months. This is only possible because we picked an office location in Cluj which is a direct short-haul flight away and the team is small enough (five people) that the travel and accommodation costs are manageable. Physical meetings always enable more honest feedback and they’re especially important for confronting entrenched positions. Obviously, visa-free travel within the EU makes this much easier – for the time being at least. But meeting up in a halfway country or location may also turn out to be a good value option. In our company, four times a year didn’t seem enough, but I know that 37signals set quarterly meetings as the goal.
3. Get social
Attending team building exercises might be your idea of cringing hell, but getting to know your remote colleagues as real people requires some dedicated time – and it is really time well spent. In our team, we discovered a mutual interest in board games and word games and have spent many happy evenings with a few bottles of wine, playing together. If you can’t manage a few evenings together over the year then you should probably question whether they’re the right colleagues to have in the first place.
4. Hand pick your team
As a product manager, you should choose the individuals who work with you day-by-day, not just the agency or offshore partner who helps to deliver the team. Unfortunately, in many remote working set-ups, the remote team is not hand-picked for the project and their loyalties will be split between your team and their local manager. Only by having true hire-and-fire responsibilities as a team manager, can you get the team properly to unify behind your goals.
5. Get visual
Tiny differences in story specifications get amplified across time differences. To minimise the miscommunication, you need to use all the tools available. Video conferencing can be great, but only with a rock-solid internet connection at both ends. Text chat may still be better for those who are not so confident in English, or when bandwidth is a problem. Even the simplest tools like pen and paper can be used to great effect. Upload sketches, diagrams, and flowcharts to your Agile board to get your point across.
6. Get local product feedback
Real customer feedback, from hallway usability testing through to full test lab feedback, is essential in keeping your product on track. We tried using webcams and screen capture software to share the results with the team, but the reality is the messages don’t sink in unless the team is physically present. Far better is to task the local team with recruiting user testers in their own office location. If your product is targeted at sea fisherman and your team is based in a landlocked country, that could be difficult; but in fact feedback from any similar users is better than none at all. I recommend Steve Krug, Rocket Surgery Made Easy, as a simple guide for non-specialists to run usability testing.
Conclusion
There’s a feeling that remote teams are an imperfect solution forced on us by limited budgets or messy company mergers, but they can be super-productive and a joy to work with. It will take more management and logistics than a co-located team but in software, the ‘best are everywhere’ and operating out of multiple locations gives us the best chance of working with the greatest software talent.
I wish you all the success in getting your team to gel so that the product process flows smoothly. Please do share any further tips you have in the comments below!
