May 13, 2023
When we started our first India office a little less than two years ago (Nov 2010), the idea of managing two offices was an unknown. Quick background - we only had an office in Sydney before we started our Bangalore office. Truth be told, it was actually harder than I thought to start an office in a different city but I will save those nuances for another post.I didn't actually know what it was like to work in India until then. My adult life had mainly been spent in Australia so I didn't realise what I was getting into. The point of starting an India office at the time was mainly to look at product development in a cost-effective and an isolated (from our main operations) way.Like all things in startups, the original plan has changed completely. We didn't really intend to have execution of our Australian projects happen in India but now that is a substantial part of Langoor.We currently have a few members of our team in Bangalore directly working with our team and for our clients in Australia. This started around March last year and in that time I have learnt a lot.Having teams work across borders is a tried and tested model. It has various benefits the biggest of which is addressing talent and skill gaps. However it is very easy for it to all go wrong. Since we have been in this space I have heard innumerable stories of other people's bad experiences.We have had a few instances ourselves where there have been problems internally in expectations versus delivery. More often than not though, the thing to do is blame a specific person's capacity to understand. However, as we have grown we learnt that that is the easy way out.Most often, the root of the problem is communication."OH, I thought you wanted this part of the report""But you asked me to focus on a basic wireframe, I didn't realise you also wanted these features incorporated"So we started creating processes to try and remove unknowns and gaps as we grew. Some of them are common sense, like putting together a simple deployment plan that forces the people executing to think about what is being executed; or involve creating test cases for each task - only that the person writing the test case has to get it approved by the project manager so that they're all on the same page. Using Skype and Redmine (our project management system) more effectively. The list can go on. This gist is we are documenting, writing, talking and sharing more so that we don't lose things in translation or chinese whispers.I stumbled across the phrase that underlies all of these fixes - "over communicate". I actually borrowed this phrase from one of our clients.I was talking to the lead IT person at a client who has been working remotely for their company for the last few months. He shared that the only way to work remotely was to over communicate. He summed up what we had been doing consciously for the past few months in two words.Almost all problems in most businesses come down to the way people can work together. These problems can be magnified when teams work in different locations. The best way in my view to resolve them is to over communicate.
