Tag Archives: Remote teams

How do you manage intercultural issues in your teams?

I recently had the good fortune to fly in from Doha to Dubai in a Dreamliner, and later again from Bangalore to Delhi – before they got grounded following a safety advisory. No doubt, it is a marvel of engineering excellence, and I am sure they will figure out battery problems sooner than later.

However, while reading this article “From the Start, Dreamliner jet program was doomed”, I could not help express surprise over some of the issues discussed. While some of the issues reflect a very high-end of engineering being tried out for the first time, and hence some teething troubles could be expected that could be solved by engineering, some other relate to the human aspects, surely not happening for the first time, which perhaps trumped several other issues:

It seemed like the Italians only worked three days a week. They were always on vacation. And the Japanese, they worked six days a week,” said Jack Al-Kahwati, a former Boeing structural weight engineer.

Even simple conversations between Boeing employees and those from the suppliers working in-house in Everett weren’t so simple. Because of government regulations controlling the export of defense-related technology, any talks with international suppliers had to take place in designated conference rooms. Each country had its own, separate space for conversations.

There were also deep fears, especially among veteran Boeing workers, that “we were giving up all of our trade secrets to the Japanese and that they would be our competition in 10 years,” Al-Kahwati said.

None of these are new issues to any student of inter-cultural issues, especially in project management, but what is surprising is that for a program of that strategic importance and such magnitude, these issues were ignored and they eventually came back to bite.

Distributed and virtual teams are a reality of today’s world. It is not just limited to well-heeled MNCs – we see countless everyday examples of such teams with NGOs, startups, voluntary efforts, college project and so on. There is more to working with people from different time zones and cultural contexts than we realize. Problem is, most of us haven’t been exposed to, or adequately trained to handle such diverse teams – not just as a manager but even as a team member. As a result, when there is a need to work with distributed teams, we tend to curl up in our cocoons and shun working with them. It could be due to excessive paranoia due to job insecurity, or it could be due to prejudiced mindset about folks who are ‘out of sight’, especially at a low-cost destination. Sometimes, it might simply be due to sheer laziness. I have once been in a situation where a VP based out of company headquarters wanted to only work with people within his ‘line of sight’ – he hated getting on emails, hardly ever responded to them, and his preferred style was chatting in hallways or at cubicles. Sounds familiar? However effective this strategy might be for his immediate team within a shouting distance, this would lead to his remote teams feeling disenchanted. You might be a great leader, but remember – managing remote teams is also part of your success!

Panel discussion on "Intercultural Issues in Project Management" at Grace Hopper Conference, India, 2012In Dec, I had the opportunity to participate in an interesting discussion at the Grace Hopper Conference, India on “Cultural Intelligence in Project Management”. We discussed some of the personal experiences of a very diverse and highly experienced panel. Some of these experiences ranged from Bangladesh to China, Japan to Israel, and US to Europe and so on.

One of the points I shared was about how to manage inter-cultural teams. This is a big topic and we can spend a day on it and still don’t get it right! In my experience, there is a process that I have developed and refined that works well. Here is how it goes:

  1. Be aware of the intercultural differences – don’t paint everyone with the same broad brush. This is especially important for ‘foreigners’ in your team lest they start considering them as ‘aliens’ in the team! To me, recognition of such differences means respect and that itself is such a motivation for everyone to feel welcomed in a diverse group. In a Chinese company I once worked for, it was common for everyone to be in office till 9pm everyday, 6 days a week, even if there was no work that demanded people to stay back. Meetings would be setup at 5pm and go on until 9pm and beyond. While this was ok for many of the Chinese folks as they were ‘foreigners’ to Bangalore and had nothing better to do in evenings than work at office, this was not so ok for many Indian engineers who had a family. While no one minds occasionally staying staying for work exigencies but everyday was a drain. In that high-performing culture, leaving early for home would be seen as a sign of lesser commitment and effort. While things did eventually get better (at least in my team because I summarily rejected such outrageous ways of ‘measuring’ performance of an individual), it took some time and great efforts to make people realise their intercultural differences that we have grown so subconsciously used to.
  2. Creating common norms – Instead of forcing one set of people to change to another set of people’s preferred way of working, it is much better to arrive at a common way of working, even if that is not the most efficient way of working. Ideally, let the team evolve such norms so that there is a higher buy-in for those common standards of mutual behavior. This will demonstrate tremendous respect for individuals and encourage them to participate in team proceedings that will go a long way in building their individual buy-in and a team camarederie that will set the team on a high-performance trajectory. More than once in my career, I have been involved with diverse teams where simple things like how fast an email should be responded to has been subject of intense debate. We all have different ways to answer them. Some would take the old analogy of a telephone call – just like someone who is physically present is more important than the one calling on phone at their leisure, why should someone sending an email become a priority for me? On the other hand, there are folks who would want to respond to emails within a hour if not minutes! So, what is the best way? Clearly not making everyone answer the mails in one hour, I hope! Let the team discuss this issue and let them come out with common norms such as 24hrs or 48hrs based on what is important for the business. As manager, step in only when you think teams are setting the bar too low, and then also, step in not to dictate your preferred ‘norm’ but to clarify the objectives and provide supporting data and steer the conversation towards why it is important to meet those objectives – teams are smart, they will figure out the rest. For example, if time tracking is a project requirement (either for tracking project effort or for billing the client, or for any other reason), and given people’s propensity to either avoid it completely or do very meticulous time tracking, then it might be a good idea to also identify a common tool, such as a time and attendance software, that makes sure everyone is on the same page. 
  3. Exploit intercultural strengths based on individual strengths – the idea is not to make a rabbit fly or to make a bird swim, but find out who is naturally adept at certain strengths and match their tasks to their strengths. As managers, we don’t want to be parents to the team members, and there is no point ‘forcing’ them to change them to do thing that they don’t relate to (unless of course, that is jeopardizing project objectives). Instead of doing a command and control style management of allocating tasks, managers should walk a few extra steps and undertand what motivates their team members, and if possible, assign them that work. In most cases, that might be a strength they already posses, and in some cases, it might a skill they aspire to possess and might not be the best candidate for it. However, if they can demonstrate that they have taken steps to match their desire to improve their capability in that subject, then as managers, we owe it to them to give them a fair chance. Assigning a mentor as they take up a new task might also be helpful. I once had a great team member who was majorly motivated by helping everyone on the team. Almost each evening as people were winding up their work, he would go to them and chat up with them on their problems and offer voluntary help to stay late and fix it. He would do it in such unintimidating and affable manner that other team members loved it (and I can’t recollect anyone misusing that gesture of benevolence, in case you are wondering). As his manager, the only thing I was supposed to do was just to stay out of the way and cheer him up! He was clearly driven by his own deep passion for the product that we were working on.
  4. Broadbase core strengths – finally, once the team has come to the point where people don’t feel intimated or vulnerable due to their shortcomings but rather feel appreciated for their strengths, it will be much easier to cross-pollinate those strengths among the team members. Since everyone is a mentor and everyone is a ‘mentee’ to someone else at this point, chances are that this won’t create adversarial relations among the team members, but actually stimulate a culture of mutual respect and learning. For example, someone might be an expert with a technology and another team member is great at planning. Once there is a feeling of mutual respect, it will be much easier to make them seek each other’s expertize in furthering their own knowledge.

This four-step process has served me well in multiple scenarios. There is nothing rocket science about it, rather it is based on simple laws of respect to everyone, and that’s why it works. And to me, intercultural is just that – a matter of respecting people for what they are rather than ignoring or ridiculing them for what they are not. After all, we are all perfectly imperfect and similarly different!

How do you manage intercultural issues in your teams?

Which of the ‘real worlds’ does your software team live in ?

There was a highly charged discussion on real colocation vs. remote colocation on one of the mailing lists. I think the number of posts far exceeded 100+ and eventually there were more emotional and personal arguments than any meaningful real responses. Finally, the original poster left the group, people who were left on the group were in introspection + justification mode for a day, and life seems to be slowly returning back to normal on that list.

I think the discussion lost its fizz because of several reasons, but I feel most of us are still living in a denial mode as far as remote work is concerned. Just because we have Agile Principles that ‘favor’ colocation, there is no good reason to justify that as the means to colocate the teams, come what may. My argument is don’t suboptimize the whole in order to superoptimize the parts. So, if I were a carpenter on contract to build a house and only knew how to use a hammer, it would amount to me demanding that every door and window be made using only the hammer whether the house needs that or not, and whether that suboptimizes the house construction or not. I look at life this way: if you are lucky to have an ‘ideal real world’: small, colocated teams, than by all means, go Agile in its full spirit. However, if higher business imperatives make your business remotely located in multiple locations, then you can’t be pushing your tool just because that’s your comfort zone ! A customer doesn’t care what process we use internally as long as he get what he wants and when he wants at the right price point he has in mind. To a large extent, the same goes for your management also. They might recognize that you can improve your development productivity 2X (or whatever is the going rate) but let’s be honest. How much time and effort does the software phase consume in the overall product development ? Obviously that number varies depending on the type of system being built, but even in 100% software-only products, there is a reasonable (and quite often, significant) amount of time and effort that must be consumed by non-software teams. If we assume software teams are consuming 40% effort on a systems project, and by distributing work, the organization is getting a 2X improvement (without being judgemental about the type of ‘improvement’, let me just say this is a result of availability of talent at the right price point that is able to deliver the work within desired quality). Now, even if Agile practices are able to bring a comparable 2X improvement, that is probably only affecting that 40% of the development effort to become 20% but at the cost of colocating everyone which means the cost of overall project might double in the worst case, going up from 100% to 200% ! So, if that is the way an argument for supporting Agile adoption is made, I won’t be surprised if there are no takers. This ostrich mindset reminds me of the Swiss Army manual – if there is a discrepancy between map and terrain, trust the terrain.

A far better approach would be to first understand what is an organization’s constraints and expections in distributing the work to remote teams. What benefits are being expected, and are actually being accrued in reality by doing that. Once done, that is a great starting point to have the debate on how best we can make distributed teams more productive – so, it is nomore a question of pure faith vs. pagan. It is a question of what is the best way we could help teams in the given context. The idea is not to challenge why real world is so ugly and try to facelift it because the mirror won’t like it, but to accept the real world for its face value (surely, healthy debate on why it is so is always welcome in any organization) and find or make the mirror that will do best possible justice to the real world.

I once worked on a product in Digital Set-Top boxes that had teams in Belgium, Netherlands, India, Ireland and US and even though some might argue, thre was no way we could have done that project in a single location, and the major reason was not cost arbitrage alone. We all knew how difficult it would be to coordinate among so many locations, how difficult it would be to ensure that architectural integrity is maintained, interfaces stay consistent, and so on. Yes, that is real world. We were some 60+ engineers combined in all those locations. Could we go back to our company and tell, you know what, our software development process doesn’t support multisite work and we get cold sweat just thinking of what a nightmarish experience this would be – how about putting us all in a single location because that’s what we know ? Theoretically, one might do this, but I think the company has hired me not so that I could replay obvious excuses to them, but show my knowledge, skills and ability to manage complex problems like these. Precisely the reason I am in this job – if those real world problems were not there, would there be a justification for my role ? So, I would perhaps be better off doing as best a job as I can. The first thing that I might want to do is to acknowledge the real world.

That brings me to a very fundamental idea – what is real world ? is there a universal definition of real world, or is your real world different from mine ? is there a universal process that can heal all type of problems in the real world (whether there is only one real world, or multiple real worlds) ? why should we always think that a process must be macho enough to be able to solve all type of real world problems ? when no one man or woman can claim to know it all even in one domain, why is it that we want to project our process as Mr. Perfect Process that acts like a silver bullet for all types of targets ?

Which of the ‘real worlds’ does your software team live in – an ‘ideal real world’ or a ‘real real world’ ?