Bangalore Travel Blog Part 3

Introduction

This is part 3 of my travel blog on my current business trip to Bangalore, India. The two previous parts are here and here. In this article I want to talk about the various communications challenges we have in working with globally dispersed teams and in particular with the one here in Bangalore.

The main purpose of my visit to Bangalore has been to enhance communications. To meet all the people I regularly talk to on the phone or exchange e-mails with. I’ve met several team members you have spent time in Vancouver already, so this has been my turn. Meeting face to face certainly provides the best medium for communications. Face to face is the most reliable mechanism, especially when you can discuss things over a period of time (in this case I had two weeks). But the trip to India is quite grueling and it’s a long way from home. So practically speaking we need other ways to enhance communications for the rest of the time. A key part of face to face visits is to learn who knows what, so in the future people know who to talk to.

Communications Breakdown

One of the big reasons for this trip was to solve a number of lingering problems that just didn’t seem to be getting solved. We would think decisions were made and then a few status calls down the road they would resurface as open again. Generally it appeared communications between the various teams on this project were facing some serious challenges. Most of the discussion in this posting isn’t specific to these particular teams or to teams in India. They could equally apply to teams in different cities in North America, or even sometimes teams on different floors of the same building. But since I’m writing this in Hong Kong airport on my return from Bangalore, some of the items might have an Indian flavor to them. I talked about some of these issues in my blog posting on the umbrella ceiling which was to do with working remotely, but I think this topic deserves more discussion.

Roots of the Problem

I think the biggest root of this problem is that either people are trained that its best to be self-sufficient and try far too hard to solve things themselves rather than ask for help or people just don’t realize that there is someone else who knows the answer that they can ask.

Another cause might be politics between different companies when the teams work for different companies and there is some higher level interference because management wants things to look better than they really are. The paradox here is that if the team did ask for help, then things would be able to get better. By not asking for help, maybe you can create a short term perception of super-human ability, but this then just falls apart when the first milestone is missed.

Similar to the last paragraph, project time pressure also leads to a certain amount of bad decision making in this regard. Programmers under the gun will just work on their short term deliverables with all their effort and ignore e-mails, not read Wikis, etc. Doing this saves a bit of time in the day, but costs dearly if a key piece of information was communicated but not received.

Technology is Not the Answer

There are all sorts of great technologies to enhance communications. Video phones like Skype, all sorts of IM clients, very fancy telepresence setups, Wikis, blogs, etc. People are almost always connected these days to the Internet, so even with terrible time zone differences like between North America and India, communication can still be fairly immediate. But this all depends on people actually using the tools. A lot of times people see all these tools as a distraction and tend to avoid them.

The really hard problem here is how to disseminate important information that people will pay attention to. If there is too much information, then it’s just treated as spam and ignored. If there is too little then there are communication problems or people don’t bother checking for it. Add to this the problem that usually a new piece of information needs to be communicated three times in order to be absorbed.

Most Programmers are Introverts

Independent of where a programmer lives or works, whether it’s Canada, South America, India, Asia or where ever, there is a pretty good chance that programmer is an introvert. This usually means that the programmer almost has a physical repulsion to picking up a phone and calling someone. This usually means that the programmer is not going to arrange a telepresence session on their own initiative. This usually means the programmer won’t arrange a remote desktop session to work with someone to solve a problem.

Using e-Mail to Delay Communicating

E-Mail is often used as a way of delaying communications, especially when different time zones are involved. A good way to put off communications is to just send an e-mail. Often you won’t have to deal with the answer until tomorrow. It’s common to see a question e-mailed one day, then the next get a response asking for clarifications, then send the clarifications, then the next day get back an answer to the wrong question, then send further clarifications, etc, so that a simple question takes a week to get answered even though people are being fairly prompt with responding to e-mails.

E-mail is also a continuous interruption. Managing how you answer and manage your e-mails can be a big productivity booster. Certainly turn off audible alerts when you receive e-mails and don’t let them ruin your concentration on your real job. Perhaps set aside specific time slots for answering e-mails.

Special Problems to India

People often list language as a problem when speaking to India. One thing to keep in mind is that India actually has 1,652 languages. Even in Bangalore where the common local language is Kannada, many people working in the high tech industry have migrated from other regions of India. This means that often the only language in common between team members in India is, in fact, English.

Development groups in India tend to be quite large. Often communication problems aren’t limited to overseas. Often you get worse problems communicating things just to the whole team at the India location or just connecting the right people together who in reality sit quite close together.

Of course there is the 13½ hour time zone difference, and then the fact that it’s such a long flight to get to India. Visiting has gotten easier over the years, but it can still be challenging for westerners.

Summary

Communications is always a challenge on any large project. As a project increases in size, the number of communication channels increases exponentially. Enabling effective communications on a large project can be helped by technology, but is really a people problem and has to be continuously managed.

And so concludes my blogs while on my Bangalore trip. Perhaps not a true travel blog, but I like to blog on the issues I’m dealing with and this trip provided some good topics. Anyway I’m back in Vancouver now and life returns to normal.