What did I learn building an offshore and nearshore team?
A few weeks back I wrote an article about What makes global teamwork, offshoring, nearshoring and remote cooperations so interesting. I have a critical father in law who told me that I described some pitfalls that I walked into and asked me ‘but what did you learn from the mistakes you made?’ So I devote this article to that question, because I believe it could prevent others from making the same mistakes. I will go through the points that I described one by one (the italics are from my previous article)
The thing I disliked was having to go through so many mistakes. The first years, I was in the dark as to what one needs to do in order to cooperate with someone in India or Eastern Europe. I made all the mistakes you can imagine: hire the wrong people, work without any process, not using any online project management tools, communicating through chat only, work with suppliers that were not trustworthy, get stuck in the middle between client and supplier, not being able to deliver a project to a customer. And then another bucket of mistakes opening an office in India without any prior experience or Indian contacts.
> Hiring the wrong people
Although it seems easy to hire good programmers, because you can objectively judge the quality of ones code and you can reasonably judge the analytical skills, it’s less easy in reality. For having good remote collaboration, technological or analytical skills are only part of the equation. Communication is the most crucial aspect and it’s important to recruit for that skill. I also learned that hiring for values is crucial. Two of our core values that have the biggest impact on the success of our intimate work with customers are ‘openness’ and ‘responsibility’. I have dedicated another article to these too earlier.
> Work without any process
The human spirit is to ‘just get going’. We find a good remote programmer or team and send requirements and expect it to work out just like that. I have learned that it’s crucial when you work across distance, cultures and language to have a common understanding of ‘how you are going to work’. If you don’t think about this upfront and people just do what they are used to, unless they by accident build the right routines, you’ll build the wrong ones and your offshore project will fail.
> Not using any online project management tools
Technological advancements have helped a lot here, most people use tools like Jira, pivotaltracker, github and bitbucket, but 7-8 years back most remote work was just started by email and skype. If you don’t create an overview from the beginning using some online tool that tracks communication, status, bugs, questions, etc; your project will over time derail.
> Communicating through chat only
The striking thing is that this can absolutely work, we have several clients that work only through chat and are satisfied. But what you miss is the personal relationship and the verbal communication. It also takes more time than talking. It’s safe to be behind the pc, certainly for remote programmers. But it’s also important to build that relationship and to work efficiently. Scrum is one of the instruments that helps remote work most and scrum goes with talking and video, not chat.
> Work with suppliers that were not trustworthy
When I started Bridge I had only suppliers to work with. The ones I worked with soon appeared to be having too little programmers to process the work. So you branch out to other partners. It is hard to find the right partner and it takes time. But I have learned that you should take the time. I have also learned that for us it works better to have our own people, because we can decide whom we hire (on skills and knowledge, but also on values), how they work, how we build a team spirit, how we create some comfort and happiness among our team. I wrote an article last year about this topic.
> Get stuck in the middle between client and supplier
Here I also learned an important lesson: for offshore cooperations to be successful, there should be as few managers in between the person asking to create a software application and the person building it. We used to have projects in which an end client wanted a webshop, hired a publishing agency for this, who hired a web agency, who hired us and we hired a nearshore team. In each company there was a project manager involved, which means at least 5 project managers. If one is sleeping, the project fails. So the best version is the end customer talking to the programmer and if he doesn’t possess the skills for that, he can hire a web agency who talks to the remote programmer. A side effect is that you save some extra costs along the way!