Overcoming Cultural Differences with off-shore people

  • starting position

    At the moment I have different test teams at my disposal who work on different continents or who accompany my project like now in India.

    I have noticed a wide variety of cultural characteristics:

    • There is no contradiction (no matter how meaningless an instruction would be)
    • Even if you ask for feedback or criticism, there are hardly any realistic answers.
    • So the customer (me) is always right, but exactly, that is a wrong view as I think. I expect comprehensive criticism and feedback from testers. Especially in my project I need negative feedback at an early stage to solve problems directly.
    • I have a team leader in India who does not allow direct questions to the testers. So I discuss 3 corners in an awkward way. Very cumbersome. Is this also a cultural habit? I do not know in such a way!


    I currently see the problem that assessments of my projects, just from the QA field, are too positive. Am I wrong?


    How can I prevent cultural differences in the test, across continents, across time zones, and local cultural differences?

    Or is it really because I'm too bureaucratic as a German 😉 Maybe I shouldn't see some things so doggedly?

    Maybe someone from India who might be able to explain the cultural differences to me and how I can best build the team.

  • I expect that your remote testers see their job the way it is defined for nearly all the organizations that use them: does the software work? and can they sign off on that and get paid?

    If you create an arrangement where their pay and employment is dependent on giving much greater feedback it will happen, though you'll need to invest time and training because they are not used to this

    Ultimately 'off-shore' testers may add limited value because of such issues. you may ultimately find it more value to employ two local workers at $100,000 each rather than 20 off-shores at $10,000 each. Also when you have a lot of people, human notions of shared responsibility leads to 'it's not my job' sorta issues. Whereas when there are just 2 people and they are in-house you can focus better on the real value they add. There can be a greater sense of responsibility and pride in work this way.

    To start operating this way you will also need to educate 'not in the moment of any given issue or test. You need to set up separate meeting(s) where you go over the requirements for constructive criticism in details. As with most messages about changes that are not usual to an arrangement, you'll probably need to repeat it several times.

    Also this does happen to on-shore core developers too. I have worked in shops where code reviews are largely a 'thumbs-up' exercise and not the vigorous debates they are supposed to be.
    So the culture problem here is not about place, ethnicity, etc, it's more about the culture of development, agile, seeking feedback, etc.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2