Hi everyone,

I am currently working on my master's thesis as part of a research group which is looking at competences in IT/IS/software development teams. Our focus is aimed at multicultural teams and examining the competences involved.

Right now, we are looking at identifying which internationalization competences (soft skills for an international context) are important within the different phases of global software development and for the management of these projects. By matching the internationalisation competences to the technical competences it will allow us to provide recommendations on how educational institutions could adjust their teaching methods and for companies to readjust their personnel requirements when hiring new staff.

You can find the questionnaire under: http://edu.surveygizmo.com/s3/122371...of-Competences

The listed competences provided in the questionnaire are from previous research which identified common challenges individuals faced during the course of project development. The common challenges (in no particular order) were miscommunication amongst team members/management, management styles (or lack of) and working style/behaviours. Some of the identified potential solutions to these problems were mentoring, team building and clarification of goals to all stakeholder groups.

In order to promote discussion, if there are any specific instances or examples where working with someone from another culture comes to mind and presented a challenge please feel free to share the experience (both on the questionnaire and in this thread)

Sorry, I thought I replied to this but I must not have hit submit. I'm on vacation now so I can't write up a lot but my biggest problem was really communication. I worked with overseas teams and most of the time it was really hard to get them to build the right thing.

A typical conversation would go something like:

US: [explain feature] Does that make sense?
THEM: Yes, it's very clear.

Two days later...

US: We looked at what you built and its not at all what we wanted. [explain feature], Does that make sense?
THEM: Oh, now we get it!

Repeat a few more failures. Finally the features would be right so we'd move to the next phase which was:

ME: I looked at your code and I need you to clean up a bunch of stuff.

And then we'd go through the same dance where they wouldn't understand what I was asking.

So in terms of non-technical skills the biggest one for me is figuring out what you're suppose to build or being asked to do. And the problem isn't really even one of speaking English. It's more of realizing that its better to have one semi-frustrating conversation at the start then lots of miscommunications wasting days/weeks worth of time because you don't want to appear like you don't understand something.

The situation you describe was one of the common scenarios where the problem is one side not understanding the other side and the reluctance to just say 'I dont understand'

This is a cultural issue where in some cultures its bad to ever show weakness or a lack of understanding and better to essentially click buttons and hope whatever comes out is what was intended.

Its interesting to note that in our research, many other people brought up how the speaking English part wasnt the concern, but your exact example was one of the common obstacles encountered.

What do you think is the best way to solve this problem? Should the overseas team be better trained and open to asking for clarification or should the domestic team find a way to ensure that the task is understood before sending them off to click buttons?

Also, if this situation did not have an overseas team, would a domestic team working with another domestic encounter such a problem?

One thing I've noticed is that the "big picture" explanations/documentation are sorely lacking. It's more follow these steps in documenting/explaining something. It's hard to describe but I often get a very narrow view of the problem at hand.

Sounds like you didn't write tests for what they were supposed to be delivering? If they have test cases, they're not going to say they're done when they don't have what you wanted?

:eyeroll:

Edit: I don't know how to do that from my phone but hopefully the point got across.

If the point was that you haven't exactly resolved your virtual communication issues, it did.

There's a relationship between the amount of work you put in to explaining what you want built to someone and their likelihood of understanding what you want built.

It's a spectrum. On one end you have something like saying "Build what I want" which takes no effort on your part and has almost no chance of the person building your feature understanding what you want built.

On the other end you have completely building what you want yourself and saying "build this exactly" which takes a ton of effort on your part but gives the person building your feature virtual certainty on what you want since they're just copying an existing feature.

Obviously both extremes are kind of stupid.

Your response is basically saying we should have shifted down the spectrum and done more work up front and had a better chance of them understanding us. But that completely misses the point since there are still lots of opportunities for misunderstanding and the problem of them saying they understand something they really don't still completely exists.

Your response is basically an example of what I consider the absolute worst trait in engineers. It's where you really want to make some point so you shoe horn it into a discussion in an arrogant way just so you can feel good about making it - but you miss the point that it doesn't actually apply.

Further the point you're making isn't even very intelligent because it misses all of the non-engineering considerations involved. One of the goals of outsourcing is to save internal dev teams time. The main trade off is almost always quality (both in terms of immediate quality and long term maintenance). Depending on the business needs you're going to want to move up and down the spectrum I described above. If internal dev time is in high demand and the product being outsourced isn't very important it's probably a bad business decision to have devs spending time writing acceptance tests.

Better?

I have found one article http://www.howzzit.com/2012/10/18/ho...o-a-new-level/ which really helpful for software development team.

IMO a huge part of this issue is pride of "not understanding" and some cultures having a real problem of asking questions when they don't understand.

This is the difference between a quality engineer and a coder. The coder can only do simple tasks to match input and output. The quality engineer will understand the problem being solved and be able to make decisions.

One technique I've seen that can help solve this problem is having the other person repeat back what they think they need to solve. This can help identify gaps in thinking. But in general, until the developers establish themselves, it makes sense only to send the most well-defined and easily explained tasks for them to work on.

dayum i miss development. Good stable mood = competency 1, Ability to build a good working relationship with team members = competency 2

This is very well stated... and doesn't only apply with outsourcing efforts, but within internal teams as well.
My preference is always to work with people who can meet me as far as possible down on my end of that spectrum.