How to manage a globally distributed product team

A start up typically differs slightly in the way globally distributed work is carried out, from how more established companies go about it. A start up will typically have:

More freelancers compared to full time resources. An established firm will typically have an offshore team with a local project manager either through an agency or if it is a larger company an independent legal entity. Start ups don’t typically have those resources, so they rely on freelancers. The primary challenge of a start up is to locate the right freelance resources. Luckily services like oDesk, Elance and Fiverr makes it easy to get in contact with skilled people in off shore destinations. They also have a system of ratings to spot the good from the bad freelancers. You can get very far in identifying good prospects, but it is still difficult. If you need someone to code, do research or write you may want to check how they work first. It is common practice to do a tender for a small test task if it is a bigger (say, more than 50 hours of work) task you need to get done. Just design a task that will be similar to what you need and invite three people to do it. It is important that you remember this is a test, so you need to guide and inform them in exactly the same way. Also, don’t expect to use this: keep recruitment and operation separate. Another thing you need to do in advance is to list the criteria important to you and rate each contestant in the tender and compare them. This way you can also hold it against the price. It is also important to decide in advance whether you are looking for commodity or premium services. Even out there in off shore countries there is a relation between price and quality. Invite people according to this. If you need a premium copywriter, you will usually not be happy with the $5 per hour vietnamese freelancer. Even if he has four stars. You may on the other hand be very happy with him if you need a researcher to do product reviews, that you will yourself edit.

More specific individual tasks compared to a continuous flow of tasks. larger companies have a continuous flow of tasks. They may still work on projects, but when one project finishes resources are transferred to another. In a start up you will usually be restricted in funds and have much more defined tasks to be completed by off shore resources, like: design a landing page, implement an algorithm in PhP, define a colour scheme, set up a server etc. This shifts the management focus to being very clear and precise about what you want. If it is a specialised task you will usually not have the luxury of working with a resource who has any knowledge of what you do, so they need to be told very precisely what you want from them. This means you have to do a lot of work in preparation. This is by the way where most people fail and get a bad experience with off shore resources, but although the skill level may differ between the US and India it does not differ as much as you would think. The reason why you tend to hear about bad quality from India or other off shore destinations has more to do with them not being instructed in enough detail what to do.

There are also some general management challenges when you work globally that are the same whether it is a team, a freelancer or an entire division they are:

Timezone differences. Timezones are usually a problem, but they can actually be an advantage. The best companies manage to build an organisation that works 24 hours a day. That means you can have 24 hours support and develop new functionality twice as fast if you do it right. You need to set up a rhythm for your company where you define the hand offs between timezones. For example a morning meeting in New York with the off shore development team team in Ukraine (where it is the afternoon) where progress and new tasks are discussed. And then again an afternoon session with the Singapore team who have just started working.

Cultural differences. yezz, let’s talk about the elephant in the room. Different countries have different patterns of behaviour, but they all expect everyone to behave like themselves and interpret behaviour in that light. There is ample research that specifies particular countries culture, which would be worthwhile to become acquainted with if you expect to do a lot of business with that country. From a management perspective the first step is to become aware that you may not make sense to your off shore team because of how you frame it. Working with many different cultures it may not be feasible to get to know one in detail, so a little sensitivity will take you a long way and do try to read something about that culture, maybe even on quota. On the other hand for core tasks I would strongly suggest to pick just one destination, that you are either familiar with, or is ready to become familiar with. For my own company I chose Moldova for the core development tasks. I know the country from travels, speak some Russian and it is a similar size to my Native country, Denmark. These things for me resulted in a close cultural match where we have a really good connection. For Western countries I usually recommend Eastern European countries although they are usually a bit more expensive, but you earn it back really fast by not having to do everything three times because of misunderstandings. They are generally very familiar with Western culture as well.

The human factor. Off shore resources are human too and you need to show that you care. If you can, go there every once in a while or invite them to you. No Skype/webex/hang out will ever replace face to face interaction. When we talk face to face there is so much more information and you build bonds. This is important in any type of collaborative endeavour and especially in software development. I went to stay with my off shore team for a week on several occasions. I think they thought it was weird that I was there in the office, but we do have a really good relationship today.

Development phases. it is important to think about what development tasks are carried out close to the home market and which can be carried out elsewhere. A rule of thumb supported by empirical studies is that the earlier design phases are best and most often placed in-house or close to the target market. The middle phases where solutions are developed according to specification are more commonly performed by off shore resources, but the later phases such as integration and deployment is again best performed in-house. In research you talk about tightly and loosely coupled taks. Design is tightly coupled because every change can effect everything else. Coding a module designed properly with an interface definition is loosely coupled since changes to the module does not affect the workings of the whole system. Integration is again tightly coupled because one small change can make everything fail. Tightly coupled tasks also need more and quicker iterations which is intractable at large distances. For my own company I do all web and front end design with local resources although it is much more expensive.

Tools. Having a particular tool is not important (difficult as it is to admit since my company supply such a collaborative tool), but having the same tool across everyone who work together is very important. One common source of problem is the two versions of the truth problem. If everybody is not on the same page the product will not work and you will spend endless time clearing up what is the correct version. So by all means have only one system of record for one type of information. Deciding which tool to use you should consider several things: the functionality of the tool, the familiarity with the tool by the team members and yourself. Even if you have the greatest tool in the world an inferior tool that does the job is better. If the people you work with are used to work with Trello and you are a die hard Basecamp fan: ditch base camp and learn Trello. For each type of information decide which system to use. It could be lucid chart for mock ups, google docs for spread sheets, Jira for issue tracking etc. For example I went with my off shore developers choice of Redmine although I preferred to work with Jira.

Processes. People are used to working differently and you need a pragmatic approach to how you are going to work that will work for everyone. How do you plan a release or sprint? how will you test? How will you do status reports etc. Again it pays off to go with how your off shore resources are used to working rather than forcing the latest scaled agile framework down on their heads.

This is not an exhaustive list, but I do believe that it covers some of the more important ones you should keep in mind. It is difficult to work with a global team, but not impossible. It can actually be very rewarding. Just don’t expect it to be like working with a local team.