CultureDevelopmentGuest BloggerProduct Management

How to Manage a Product with a Global Team

By Anders Linsdorf

globalBuilding a product by oneself is difficult. Building it with a team can be harder. But building it with a distributed team is even harder.

Today it is rare for companies to build products with a 100% local, in-sourced  and on-site team. This is why one key requirement to build a successful product is to be able to manage a globally distributed team.

That is not easy and there are some crucial differences between being a small start up and an established enterprise.

Here is what I learned from teaching this at the University and doing it in practice.

Specific challenges – Startups vs Established Companies

A start up typically differs from a more  established company in the way globally distributed work is carried out.

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 possibly an independent legal entity. Startups don’t typically have those types of 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 make it easy to find skilled people in off shore destinations.

But a skilled person is not always a good fit. If you need someone to code to do research or to write, you may want to check how they work first. It is common practice to post a tender for a small test task you need to get done.

Just design a task that is similar to what you actually  need and invite three people to do it. It is important to remember that this is a test, so you need to guide and inform them all in exactly the same way.

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.

More specific individual tasks compared to a continuous flow of tasks.

Larger companies have a continuous flow of tasks. They 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 offshore resources, such as:

  • tasksdesigning a landing page
  • implementing an algorithm in PhP
  • defining a colour scheme
  • setting up a server etc.

This shifts the management focus to being very clear and precise about what you want. If it is a specialized task, you typically don’t have the luxury of working with a resource who has any knowledge of what you do,

This means you have to do a lot of prep work. 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.

General challenges

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 organisations that work 24 hours a day. This means they have 24 hour support and develop new functionality more quickly if done right.

You need to set up a rhythm for your company where you define the hand offs between timezones. For example one can have a morning meeting in New York with the off shore development team team in Ukraine (where it is the afternoon) anbd discuss progress and new tasks; and then have an afternoon session with the Singapore team who have just started working.

Cultural differences

culturesLet’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. 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.

It may not be possible to understand each culture in detail, so a little sensitivity will take you a long way and do try to read something about that culture. On the other hand, for core tasks I would strongly suggest to pick just one destination, that you are either familiar with, or are 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 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

Just because they are offshore, it doesn’t mean you can treat them differently than onshore staff. Try to visit them every or invite them to visit you. Neither Skype nor Webex nor Google Hangout will ever replace face-to-face interaction.

This is important in any type of collaborative endeavour, and especially in software development. I went to stay with my offshore team for a week on several occasions. I think they thought it was weird that I was there in the office, but we now have a really good relationship because of it.

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 performed inhouse 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 are again best performed inhouse.

In research, you talk about tightly and loosely coupled tasks. 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 do not affect the workings of the whole system.

Integration is again tightly coupled because one small change can make everything fail. Tightly coupled tasks 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

tools2Having a particular tool is not important, but having the same tool amongst people who work together is very important. One common source of problems 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 those problems. So by all means have only one system of record for one type of information.

Even if you have the greatest tool in the world, an inferior tool that does the job is better. If the people you work use Trello and you are a die hard Basecamp fan, ditch Basecamp and learn Trello.

For example I went with my offshore 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 offshore resources are used to working rather than forcing the latest scaled agile framework down on their heads.

There are likely other factors to consider,  but this article covers some of the more important items 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.

Anders

Tweet this: How to manage a product with a global team http://wp.me/pXBON-4g2 #prodmgmt 

A version of this article originally appeared on the Sensor Six Blog: http://sensorsix.com/blog/how-to-manage-a-globally-distributed-product-team/

About the Author

 anderslisdorf-bwAnders works to to turn new innovative ideas into the reality of tomorrow. His company, Sensor Six, makes software to help companies develop new products.

11 comments
  1. How to Manage a Product with a Global Team | Pr...

    […] Building a product by oneself is difficult. Building it with a team can be harder. But building it with a distributed team is even harder. Today it is rare for companies to build products with a 100% local, in-sourced and on-site team. This is why one key requirement to build a successful product is to be able to manage a globally distributed team. That is not easy and there are some crucial differences between being a small start up and an established enterprise. Here is what I learned from teaching this at the University and doing it in practice.  […]

We really want to hear your thoughts...

This site uses Akismet to reduce spam. Learn how your comment data is processed.