Why is it difficult to work in a multinational team?

Hello!

I have been working in a multinational team for almost two years. Dutch project, front office in the Netherlands plus a couple of back-offices: Russian and Czech. Holland is a country where people from different parts of the world are moving to work, and the company itself is no exception. Everything does not end in Czechs, Russians and the Dutch; Romanians, Poles, Mexicans, Indonesians, Macedonians, Indians work in projects, and these are only those with whom I have already managed to work. As you can see, we have a complete set here. Of course, it is necessary to take into account the specific character traits of each person separately, but some features are clearly manifested precisely depending on the nationality. In this article I want to share my experience about such teams and some arguments on the topics: software skills and technical skills, misunderstanding in the team due to differences in mentalities.

I am not perfect either, so I’ll add a picture of my life’s case:
')

Soft Skills - not our all

In most cases, software skills are valued above technical. This is striking almost immediately at the beginning of work. The culture of politeness in communication in many countries of the West is part of the mentality. After the greeting, you need to ask “How are you”, and in my case with the Dutch, it would be nice to have a couple of proposals to discuss the weather. For us Russians, this is at odds with the usual “Hello” and the following further question on the topic. In addition, we ask about business, as a rule, comrades with whom we have a good relationship and tell in detail about the weekend, vacation or something else, and not just “Fine, thanks”. Sometimes a bit annoying when this typical dialogue even follows during release. The team has unclosed tasks that need to be urgently addressed, and then you spend time discussing the weather :) But still, someone adapts and in such cases goes right to the point.

This is certainly not the end of the software. But the less the consideration of these skills, as one of the main, in my opinion, is erroneous. The fact is that having technical skills helps to find common topics in a team, participate in technical meetings, and even solve common tasks. It is thanks to them that even quiet team members can open up to you differently.

I want to give an example from my old work. In a team, one employee did not even consider it necessary to greet everyone. This is where his level of social skills does not end. When talking to some of your questions, he could not answer immediately, but just start talking and then leave. But he always came back, he just has such an approach to thinking about difficult questions, to which he has no answers right away. Sometimes he would go for a walk on the floor, and sometimes he would leave to work, and only then after some time (within half an hour) he would return to you with an answer. Of course, at first glance, the case of the absence of the usual mutual greeting seems rude and disrespectful, but he still communicated with someone from the team. The answer was simple - he is not interested in communicating with me.

It was necessary to find an approach, and decided to take part in several conversations on the subtleties of C ++ and still could tell what he did not know. The guy went to the workplace, we threw some quick examples, that's all. After that, you also find it interesting.


That is, on the one hand, these are completely different soft and hard skills, but on the other, they are closely related.

Therefore, technical problems and architects in our teams often have problems. It was here that I met such that a former programmer in another language with a 2-3 year programming experience can become an architect of the C ++ project, which is good if there is any programming experience. Of course, you seem to realize that the architect is the same role not obliging to write code, but on the other, you have to explain that this is impossible to implement in C ++, and if micromanagement is still beginning and you don’t want to go into your code in the case, the eye begins to twitch a little. Still, a person with C ++ programming experience has at least two languages ​​for communication with programmers: English and C ++.

So, working in multinational teams, everyone will have to adapt.

Misunderstanding even when using one language to communicate

Mentality plays a big role in understanding the same actions and even ordinary utterances. Take, for example, a couple of aspects.

Openness

Many topics that seem very personal to us, for others - a common thing.

Yes, we don’t want to discuss our visit to the doctor or tell us that the gamal last night is personal. We are used to discuss such things in a certain circle of people. Moreover, she is not sure that someone likes to talk about visiting a doctor at all. At the same time, openness disappears somewhere when it comes to some technical things. By the way, it doesn't even always depend on personal qualities. Keep in mind that in some nationalities it is not customary to ask directly if something was not understood during a conversation, even if this is actually the discussion that is being held. For some reason, it is considered completely normal after the discussion to google all the concepts and terms heard and try to figure it out on your own. In addition, sometimes the same words have different meanings depending on the context, which adds more misunderstanding. So be prepared, read on the face of the interlocutor, where you need to explain and tell more. But it is really difficult to do in a Skype call, if only judging by the uncertain voice uncomprehended.

Approaches to feedback or feedback

It is common for Russians to give feedback personally, be it positive or negative, comments on the behavior in a team. The Dutch do it in a group. I call this “public whipping” when it comes to a negative assessment made publicly in a team. My colleagues laugh that I see this action, but it is so. If we think about the “public beating” approach, this is also used here, but, as a rule, this is, if not reached, after two or three times the comments made. Someone in general can perceive feedback in the group as a personal insult, but from the side of foreign colleagues everything seems to be normal.

Conclusion

Complaints about the features and complexity of working with Russian programmers, I heard not only here, but also in other companies, you can read about it in articles on the Internet. Of course, by this I did not discover America. But not everyone understands that we also have to look for special approaches and make efforts to gain respect from the same Russian colleagues. Adopt that this is a big plus for you, if you can achieve this. And when working with foreign colleagues, try to overcome the stereotype of "these coarse Russian programmers."

I want to finish my tale with an advice to read a book on cultural differences, which I haven’t yet personally read, but many colleagues have begun to read the last half of the year as must have:

“The Culture Map: Breaking Through the Invisible Boundaries of Global Business” by Erin Meyer