Experiences & best practices on nearshoring, offshoring & global IT staffing

How to make an offshore programmer wildly motivated?

A few weeks ago, I wrote an article about oral versus written communication in offshoring. One of my clients pointed me to another interesting question: how to make an offshore programmer enthusiastic about your project, how to motivate him and get the best out of him? As he put it:


 

 

‘I have noticed that if we invest time in not only writing down our requirements, but also in the background of the project, the reason for its existence and the context of the requirements, I regularly get surprising advice or extra options from my programmer. What we sometimes forget because of the easy communication media is that our offshore programmers live in another world with different rules. What is logical for us can be strange to someone from India. The reason of functionality is therefore not always clear or logical. Extra background information of the functionality helps the programmer to empathize and become enthusiastic.’ So there are two ‘levels’ in shaping the offshore communication well: Firstly, you need to have the right communication process in place to ensure communication gets streamlined. This process can be developed using the three golden rules I described in my previous article: 

1. Invest time to write down your requirements (and use your mind to really think through each detail); ideally, agree on a standard way of documenting requirements.

2. Use voice (Skype/phone) to clarify requirements + ensure that the programmer writes down what was discussed (so you can later on always check whether it is understood and what was agreed exactly)

3. Save all written communication in an online project management system.

The second level is all about ‘empathizing‘: with the project AND with the onshore people. Let’s dive into both fields of empathizing. 

When a team is in one location and works on a certain project, it is rather natural that the project is ‘alive’ in the minds of the people. There are graphs in the office, colleagues exchange ideas about the project during meetings, coffee and lunch breaks, examples on screens are shown and clicked through, people ‘play’ with the application and it’s functionalities and discuss functionalities from the perspective of the user. This automatically leads to a deep understanding of the project. Now with an offshore team this doesn’t happen naturally. The people offshore miss all of the communication and idea exchange. And in many cases, they might even miss the ‘click or match’ with the business and the business logic the project is intended for. In the case of a software product, it is very important that the programmers understand the ‘why’ of the product: why do people use is, why is a certain functionality needed, why would users pay money for the product? 

What happens frequently is that the offshore team gets to work on specific tasks. The tasks are described in isolation and the offshore team has to ‘produce’. The problem that arises here has a big impact on the success of the offshoring cooperation: because programmers don’t understand the underlying logic or ‘why’ of a certain task or functionality, they cannot use their brain optimally to find the best solution. On top of that, because they don’t know the whole product deeply, they won’t realize the impact of that functionality on the rest of the product (which leads to bugs and a lack of understanding of what/where to test). 

The solution here is to invest substantial time in demonstrating the product, giving the programmer sufficient background information on the business and the business logic and make sure they understand the ‘why’ of everything they do. The most effective way to do this is by meeting eachother face to face. Let the team or the team leader stay onshore for a few weeks (best solution) or send a product owner to the offshore location for a while (second best solution). 

The second part of empathizing deals with human relationships. When a new colleague starts working in your office, he usually needs some time to ‘acclimatize’, to get to know the people and the culture. This goes rather natural, because he spends 8 hours a day in the heart of the company. But the offshore team doesn’t have that possibility. They have no frequent contact to crack jokes, to understand the subtleties of each individual’s communication, to drink a beer together, to really get to know their colleagues. 

The solution here is again to visit eachother. All the communication methods of the world can facilitate offshore work, can make it possible to cooperate across distances and culture, but they lack the possibility to do one thing: look eachother in the eyes and develop that human bond we are all hungry for. 

So if you want to get wildly enthusiastic offshore colleagues, invest time in product training and explaining the ‘why’ of the product and its development tasks and functionalities. And visit each other regularly, take the time to create a strong human bond. Business is all about empathy and relationships between people. 

Other articles you may also like:

This entry was posted in Bridge Outsourcing, Global Staffing, Offshoring, Outsourcing by Hugo Messer. Bookmark the permalink.

About Hugo Messer

Hugo Messer is the CEO of Bridge Global IT Staffing and is a Global IT Staffing Expert.Hugo Messer has been building and managing teams around the world for over 7 years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make a global cooperation work.Read his articles here.To know more about Hugo and his global team building programs visit www.hugomesser.com

3 thoughts on “How to make an offshore programmer wildly motivated?

  1. Offshore programming is a new way for the innovation or we can say that it is a source of new innovation to the business.So the the offshore programmer should be highly motivated.

  2. Many times it’s not really possible to give the full background of the project, becaue projects are specifically split up in small tasks for the programmers not to understand the full program. One of the big problems of IT businesses that start outsourcing is making sure that their intellectual property stays safe. Not providing all background gives them the (false) security that their property is safe.

    How would you handle motivating people in that case?

  3. Explaining the background of a project, the reason for doing it (aka WHY) can indeed help al lot! It helps the team to develop an understanding of what the customers aims to reach, and makes them think about how the product can be used to do this.

    This is also very true with ofshoring when using Agile. As described in Agile Software Development with Distributed Teams (Jutta Eckstein), initially people should be prepared to travel to get to konow each other and use richer forms of communication to build an understanding.

    When working with people in India I have seen their drive and eagerness to develop the right systeem, providing them with the background will certainly motivate them and enable them to develop a better software system for you.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>