Challenges of working with remote teams to develop software products

Software industry in India has evolved over a number of years to work with companies spread all over the world. Over the years, software engineers in India are trained to develop and support applications for IT departments across various sectors like automobile, financial institutions, healthcare, and many more.

Although, building products with teams in India has proved to be cost-effective for companies but it has its own set of challenges. I have worked with multiple product startup companies in the Bay area and when I moved back to India, it was interesting to see that the software engineers are more geared/ determined towards making the 'client' happy versus building a product that will change the world. It's a different mindset altogether. I will talk about some of these challenges in my series of blogs  ... one topic at a time.

The first one that comes to my mind is 'Communication'.

A common challenge faced by product companies working with Indian teams is, communication. When you are face to face, you can easily communicate with internal team members and get the job done. The Engineers have easy access to Product management, Sales and Marketing, and other teams so they can constantly keep themselves updated about the product/market changes. This information helps them to build scalable products. However, when you are not face-to-face, with differences in time zones and physical locations,  communication plays a key role in getting effective results. While talking to one of our clients the other day, he mentioned 'Communicate with us as much as you can. There is nothing like less communication'. So if US product companies encourage communication, why do Indian companies shy away? I see two main reasons:

  • Indian teams’ communication skills,

  • Client-vendor relationship

Although English communication skills in India are much better than most of the other Asian countries, some engineers lack the skills to structure their thoughts. Product companies (in the US and Europe) work with a flat team structure which makes it challenging to work with a prevalent, hierarchical model, in India. Also, lack of verbal communication skills makes it  difficult for them to discuss a technical approach. In order to solve this issue, Indian software companies came up with a concept of 'technical leads' who have good communication and basic leadership skills to help the individual contributors communicate with the outside world. This concept has worked and hence the hierarchical model of team works to deliver a project.



One more reason why communication becomes important is, the nature of client-vendor relationship. US product companies are looking for engineering partners and not vendors. Indian software companies also want the same; however, the devil lies in the details. No vendor wants to air their dirty laundry in front of clients. This applies to US product companies as well, when dealing with their clients. Building a software product is about people, whether they are located in India or US or anywhere else. No matter where we are located, enabling people to be transparent and understanding their challenges is always the key. Trust needs to be built between the teams and this can happen only when you are effectively communicating facts that do not lead to unwanted escalations.

To summarize, communication is just not related to English skills. It is much more than that. The key people managing this relationship succesfully very well understand the importance of good communication. When I was working for US product companies in the Bay area, I worked with two such people who were key to making teams in India successful. Their sole aim was to build quality products in a timely way. They knew that only trust will open up all the communication channels for them. Having said that, the need to establish trust also lies with Indian teams. This can be achieved only through transparency. Thus both sides need to shoulder the responsibility of effective communication and think through, to achieve common goals. At the end of the day, you don’t buy an outsourcing relationship; rather it is something you develop over a period of time.

Product Development
Remote Teams
Software Development
Develop Software Products

Get in Touch

Get Aggregated Monthly Industry News