 So, my name is Evgeny and I'm a Product Manager at Trade Gecko and TG is actually a Singapore based startup founded by a few Kiwi folks from New Zealand. Yeah, and we have over 20 nationalities, 20 cultures at the office. So, it's quite an interesting environment. So, as you remember from my pitch, we're going to be talking about product management based on cross-cultural teams. So, product management actually has a diversity problem and that problem is not just the fact that we don't have good representation from LGBTQIA, good representation from women in tech and other ethnicities. It's also the fact that once we do get to that cultural diversity and gender diversity, we frequently find ourselves incapable of managing it properly. We also celebrate diverse teams because well, true, diverse teams allow us to go beyond our traditional practices but how do we make sure that diverse teams are productive? So, let me show you this. Oh, what the fuck? It worked just, oh yeah, there you go, now it works. So, these are all people from one of my favorite product managers, product management podcast. It's called This Is Product Management. As you can see, there isn't terribly a lot of color there, so to say. And the truth is that these product managers come from cities that look like this and all of their teams come from cities that look like this. And it would have been fine, but right now, no matter how many walls we build or how much we try to curb immigration, the world is flat and people will be traveling all over the world. Professionals will be migrating and as the pitch showed, there are people in the audience who work with teams from cultures other than their own. So, is this supposed to work like 30 meters away from the... Oops, sorry. Yeah. Is this really product management? Is it really the truly universal discipline that works for everyone? And the truth is that... I really have to stay close to that. The truth is that right now in Singapore, we have 190k EP holders. So, what does it actually mean? This means that people from Singapore, Singaporean managers, will end up working with software engineers from the region. They will end up working with software engineers from Europe, from the US because there is a lot of interest in bringing that talent in. We will also see a bunch of teams, local teams, working with managers, product managers from overseas. And the truth is that once we try to bring those practices that we all learn, all of them from the United States and Canada and maybe Britain, once all of those managers try to bring those practices here, they actually fall remarkably short. If you've ever conducted an NGO retrospective with a team where at least one software developer is from mainland China, you will know what I mean. If you're trying to ask for feedback, you're not going to get it because it's just not how they give feedback. They give feedback in private. So, the truth is that we are all ambassadors of our cultures. And the funny thing is that once we try to work with teams from other cultures, from other countries, we kind of think that since I had an international experience and they had an international experience, we're kind of on the same level. But that couldn't be further away from truth because no matter how much we try, we always carry this culture where we were brought up. We have this cultural trace that we cannot read out. And in times of crisis, in times of conflict or argument, we expect other people to communicate to us in the same way our compatriots can communicate to us. And that's when things get oary, so to say. So, to give you an example, so there was a very funny situation at TREGACO when a couple of product managers were arguing about a UI copy. And it was just a work discussion. It was very animated, but it was nothing special. And there was a product designer coming along, just passing them from a very low-conflict Southeast Asian culture and she thought that they were having a massive work argument to the point that she raised that as a disciplinary question to their manager. And we were like, what? And the manager was from Canada, so he was like, what? That did not make sense, but that is a real thing. Or another situation when we had a Thai software engineer once working with a software engineer from the US. And the US guy just left a very direct, straightforward comment on the Thai software engineer's pull request that didn't sit well with him and he refused to work with him ever again. So, things happen. Things happen when we have the wrong expectations. And it doesn't just happen in Singapore. There are sometimes cultural clashes within the same organization, right? So, cultural norm at Google is to give feedback in a very positive way, kind of, right? But French, the French are very direct, you know? And this manager at Google France found himself in a very unique situation when he had to give feedback in a particularly un-French way, so to say. So, it was tough. Let me ask you this question. Is it important for a manager to have precise answers to most questions about when it's raised about the world? Like, literally. What do you think? You think no? Anyone else? Anyone? Come again? Okay, the reality is that in some cultures it isn't. Like, in Sweden, for example. Yeah, doesn't care. In fact, if a Swedish manager knows something, they will never tell it. An Australian manager tried to apply kind of the same principle to managing their team in China. And it didn't really work out. And the Japanese executive is another interesting example. So, we have a manager from the West who's not going to give an answer. And we have an employee from, say, Japan who's never going to ask a question. It's like, how do you deal with this? So, the truth is like implicit communication failed us. It fails us on so many different levels that there is no single way to kind of solve this problem. So, like, how do we deal with it? The first question, the first problem is you have to solve this. Do you have to collaborate the team? So, and by collaborating the team, I mean that you have to find a way that will work for the team. If you have a cultural majority in the team, let's say a team of Singaporean Chinese developers and a couple of foreigners, your default culture is probably Singaporean Chinese and you have to train and you have to coach your foreign developers and yourself, by the way, if you're a foreigner, to default to that mode of communication, the one that works for the majority of your team. If a trade gap, if like a trade gap, you don't have that. Let's say in my team I have a software engineer from mainland China, a software engineer from Ukraine who grew up in Japan, a software engineer from Syria, another engineer from Indonesia and UX designer from Indonesia, a bunch of people. There is no cultural majority. Another interesting way to approach this is to find kind of map the cultures. Map the cultures and see what works and how does each of them uniquely communicate on multiple dimensions. There are things like, you know, high-context and long-context communication. There is the way they give feedback, lead, decide things, and so on and so forth. You can check this kind of culture map developed by Erin Meyer. She's a professor at INSEAD. It's a very interesting resource. There is a book, the Culture Map, if you want to read on it, or just Google it. Try to understand what is the preferred way of communication for each of your team members. And then you're going to have to work it out, what works for the rest of the team. All of you have to agree what is the best way. So, however, oh yeah, this is an example of Israel and Russia. However, establishing this baseline culture is not always as straightforward. You may end up in a situation when, no matter how much you try, there is also a certain corporate culture that you have to enforce. And I'm consciously using the word enforce. So, basically, you all know L'Oréal, right? It's a French company. So, L'Oréal prides itself on very direct communication. So, many years back when we first opened the South Korean office, and the flu execs from France flew in and started to have a meeting, their South Korean employees were horrified, because all those French folks, they told them exactly what they thought about the work in a very colorful, vivid language. And the South Koreans, they avoid conflict, and they're like, we can't work here. So, that experience, L'Oréal, something very, very important, they decided they will not default to the low-conflict, low-context, high-context mode of communication that the South Koreans were taking. Instead, they developed a course called Managing Confrontation, and taught everyone that. But the name of the course is a little bit misleading. It's called Managing Confrontation, but in reality what it teaches the foreign employees to do is to engage in confrontations, embrace them, and abandon their home culture, and become more French. So, they found that those South Korean employees found themselves arguing in a very non-Korean way in a few years after. So, another interesting thing that you're going to have to do is you have to abandon leadership colonialism. Leadership colonialism is this peculiar thing and it's a managerial practice when people from other countries come to the new location, let's say people from the U.S. come to South East Asia and say, you know what? You're doing it all wrong. I'm going to tell you and then I'm going to show you how to lead a team, how to build products, and how to make business wrong. The fact that you succeeded in your home culture doesn't mean that you're going to succeed in with your new team and then you complete a new market. The problem with this approach is not just because it's ineffective. The problem with this approach is that sometimes these managers and these new leaders assume that because their teams don't perform as well as they expected, they're either stupid or lazy or just don't communicate well enough. That couldn't be further away from truth again because the manager is also a part of the problem. So another one is you can't really rely on people's skills and empathy. This one is interesting because we as product managers we always try to be empathetic. There is even a saying like among our people in our discipline, empathy, go get some. But the truth is empathy is very culturally specific. If you try to be empathetic to one of your team members how do you know that the way you express empathy in your home culture is the same as the way they express empathy in theirs? So empathy is actually a learned ability. We don't become empathetic. We become empathetic in our cultures to our compatriots. So I saw, that was a very funny in a way quote-unquote fun experience. I saw an American manager being genuinely empathetic to his engineers only to be labeled as manipulative by some of them. So the way he was expressing his concerns did not make sense to some of the people on the floor. So don't try to be empathetic because you don't have the training and you have to be trained to be empathetic. And if you don't, just abandon it whatsoever. This doesn't mean being a jerk by the way. This means not relying on your gut feel because your gut feel is probably wrong. So instead you should try to study your team. Try to understand who they are. So how to approach this? First off, what I usually do, I take a step back and just observe the team. How do they communicate with each other? How do they behave? How do they start their day? A software engineer from the US will come at 9, 9.30, make a cup of coffee and dig right into code. A software engineer from Indonesia might come by 11.30, make some breakfast, start browsing Facebook and then dive into code and spend all the day in the office and leave at 11 p.m. whereas that software engineer from America is gone by 6. They have very different work styles, very different communication styles. So get in. You're going to have to find a unique approach to each of your team members. Just get them out for lunch. Talk to them in the morning. Embrace a small talk because that's how you get to know people. That's how you get to know who they are because even the small talk has to be styled differently depending on the culture. Let's say it's very easy to speak about K-pop with someone from Indonesia because it's pretty popular there but it's probably not going to work out with the software engineer from the US. And rather like one of my favorite tools is instant retrospectives. So after each meeting or after each engagement I literally asked this question, did this work for you? You can ask this in the group. You can ask this in one-on-one. It doesn't really matter as long as you get that feedback as soon as you possibly can. And of course you're going to have to read and learn. As I mentioned before, each of us working in different cultures with people from different cultures have to be trained one way or another. And I'm pretty sure that the majority of people in this room don't have access to actual cross-cultural communication courses that are provided by their companies. So you're going to have to learn on your own. So crack a book open. And your fundamental goal is to become a cultural chameleon in a way. By that I mean that you need to develop a range of communication styles which you can freely choose from, depending on the situation you're in, depending on the team member you're engaging with. And I really want to highlight the word styles because we think of management as, you know, I just do management. I do product management. I have my communication style, but it doesn't work if you have people that expect all different things from you. You have to be able to have this range, you know? So we all know Marty Kagan, right? He's a cool dude. He also uses the same clicker as I do. And he has 35 years of product experience. A massive amount of knowledge. But the reality is that most of that knowledge came from the US. And as much as we want to apply all of it here, whether you're an Asian product manager or whether you're a white product manager like myself, you know, we can't rely on all that knowledge. It's just a guidance. It's just a framework. We have to adjust everything. We have to change everything. We have to experiment. So don't be like Marty Kagan. Be like someone, you know, who blends those things together, who takes his frameworks, takes his ideas and transforms them. Yeah. And here are a few references, just very basic. I really like this book, The Culture Map by Erin Meyer. There are a few courses on Coursera. You can also just Google and look for courses at X and Udemy. There's plenty of information about cross-cultural communication managing cross-cultural teams. And I hope that in the future we could all like get back together again and talk a little bit more about what it means to manage cross-cultural teams because it's not easy and I sure as hell don't do it as well as I'd love to. I still make mistakes and I still have communication problems with my team members. Thank you. Questions perhaps? Okay. This kind sir will help us. Thank you so much for the engaging talk. Thank you. And be very open to talk about this. I think this topic is super important. So I was wondering if you can share some of your mistakes you made in managing a multi-culture like team and what was the takeaway from it? Yeah. Thank you. So where do I begin? There are quite a few. So I'm originally from Russia. I used to live in Japan for quite some time. Then I moved to Singapore. But I still give feedback in a very direct way and I still talk openly and colorfully, so to say about a lot of issues that we as a team and as a company face. Some of my engineers are totally cool with it. Whatever. We know how Evgeny works and that's the expectation. Some of my engineers are a little less direct and it's taken them time to adjust to this style. And the mistake that I made personally is the fact that I wasn't able at first, before I started working with it, I wasn't able to communicate how I give feedback properly and I wasn't able to establish this cultural practice immediately. So it took me a few months to actually figure out where I set the expectations wrong. So the takeaway from here is don't waste a few months, basically. If you know that or if you feel that you might miscommunicate in something, that you might be maybe too direct, that you might be taking decisions in a way that doesn't sit well with some of your team members, you have to ask them what do they expect. You have to help them adjust and you have to adjust your way of communication as well. Where I'm going with this is that sometimes we think that either they should adjust or I should adjust as manager, but that's also not true. It's on everyone to recognize the fact that we have to find a way that works for both of us. Another thing, since you have your own cultural expectations, you will never be able to fully overcome them. They are going to stay with you for the rest of your life, same with my directness and with someone from China with their indirectness. It's going to stay with them. They can't change it. Maybe in 30-40 years working in the US, they will, but it's not going to happen anytime soon. So you really have to find a way to expose those differences immediately. So I don't do that mistake anymore. As much as possible, when a new member adjusts, the team will discuss these things. Did that answer your question? Thank you. Why not just set common goals? It's like having a common enemy. If everybody is going against Hitler, you don't really need to care about the cultures per se. You actually do. How do you know that those goals resonate with your team? How do you know that you communicated them well? How do you know that everybody understands that, let's say, finishing a project in 10 weeks means finishing a project in 10 weeks, not in 15? Because the time is flexible and time is cultural, that's just as well. How do you know that the goal is well understood? You don't unless you actually expose it. Does that answer your question? They have very specific tasks. When you're running the sprints, everybody knows what they're trying to achieve by the end of the week. So there's a team goal, and then the individual goes from each individual person, so there's not really a need to care that much about the culture. Let's do the small talks and the lunch and figure out ways to communicate better. But once the goals are set, you run an immediate feedback by your instant retrospectives to make sure everybody is on the same page they've interpreted and told the whole team what they think they're supposed to do. This is something very interesting right now. You use the words everybody knows. How do you know? So if the tasks are bite-sized enough, then it should be easy for them to pick up and do it. So over a course of like three to four weeks, I think the teams will run in and then they should be able to perform. How many nationalities are in the team? Oh, based on your experience. And is this a new team? My currently new team, the previous one, maybe six or seven nationalities. The previous one was an old team, right? The new team. Did they ever work together? Well, look out. I thought it's going to work out as well, but it doesn't. To give you an example, so we've all run the retrospective, sorry, not the retrospective, the sprint planning sessions with the planning poker. Have you ever noticed how sometimes when you estimate a task, some of the people from maybe Asian cultures see the estimate of a white person and comply with it? Have you ever noticed that? And they say like, maybe he's right. So the truth is that is one of the sources of the problems. I noticed that a trade gecko that happened before and it becomes a source of friction eventually over time. So you may feel that the team agrees and that the team kind of finds an estimate that works for them, but it's also not true because you have a team member who just complied with someone else's opinion because they didn't vocalize their own or were uncomfortable of doing so, or weren't providing an opportunity to do so. So it's true that on the surface you might feel like the team is working well together. They found an agreement, but is it really an agreement? Thank you very much. I noticed that as a part of an agent this is coming from a perspective of part of an agent where you have a high level of self-awareness where then you notice there's a culture difference but not everybody in the organization or in the culture have the same level of self-awareness. I think to make this work there's a very important component of self-awareness. How do we create it or start it to make sure everybody is aware of this difference? That's sorry. Yeah, that's where the cultural scales actually come very handy because once you start kind of asking people how do they make decisions? How do they approach deadlines? Try doing this in a group. Once you start exposing those differences the conversation starts automatically. The other day I actually asked this question about is it important for the manager to know the answer. I asked the question to some of our execs. They are from the West by the way and they nick unanimously said no, of course that's not important. Of course we trust the teams. And then I asked some product designers from the Philippines and they were like, yeah, of course this is important. I want the manager to tell you exactly what to do. They're smart people but they expect a very thorough, solid guidance. So, and if you don't ask this question you will never know the answer. You're going to have to serve the differences because, yes, right, some people are a little bit more in themselves. They are comfortable with working in their functional teams, with the design. They just spend time and sketch, spend time in terminals, spend time in the sublime, whatever. But they also work with other people and you need to start this conversation. Kind of force it in a way. It might be uncomfortable at times but it's for the good. Also the presentation I'm getting. I'll go back to your slide about setting up the baseline culture. So my question is, as a product manager who works with diverse teams, engineers, same as marketing and so on, how do you influence this process of setting up the baseline culture? Because as a product manager you may want to focus on customer product and revenue whereas different team members would have different focus. So how do you set this baseline culture so that organization goes in the same direction? So in a way it has to come from both you, from the team, from the teams around you and from the outlets. So it's tricky. You don't have the organizational fallback. What is the culture of our company? How do we, as an extended team, solve problems? You're going to have to start from the basic, do it in a grassroots style, figure out what works for your team. Because that's your primary concern. Because without your team being head-in productive, there's not going to be any good products, there's not going to be good outcome and output. It's all about customer centricity. Everything translates into good products, delightful products. How can employees that don't understand each other build good products? I'm not sure if I answered the question actually. It was a very nebulous answer. But the basic principle is that you have to talk a lot. Yeah, I think the practical difficulty is none of them report to you, but you still need to be an influencer. To the point, yeah, every time in use of the R&D team, I have to recolorate things. Because there is a new variable in the equation. Thank you for the presentation. It's really an interesting topic. So I just have a question, very specific one, so you have a recommendation basically on adopting different communication styles, right? But do you see potentially maybe that's maybe perceived as a problem, right? Because if you communicate first in this way with the person the other way, would that be kind of perceived as being, you know, not honest and not genuine? Because that, you know, it's just an interpretation with the subject of culture as well, right? Because like, so in my experience, I try to read as honest and as genuine as possible and basically treat everybody sort of like I'm honest with like all my team members. So I don't know whether like having different styles for different people would kind of build this perception, you know, that's like, that's not consistent, I guess. I think it's not a question of being honest. It's about, of course you have to be honest, but does this honesty feel like you're attacking someone? Or does this honesty feel like you're taking care of someone? If I'm honest with someone from Russia, I'm sorry, but you're going to be offended. If I try to be honest the same way with you, that's just how it's going to go. So I can't, I can be all honest, right? But I have to express it differently. We have time for one last question here. Andrews. You talked a lot about the manager and team member relationship, but a lot of the team depends on the team member relationship with each other. So does the whole thesis that means that the links behind the team, the cultural team, how we care about the whole? Oh yeah, very good question. Since Andrews didn't look matter for me, I actually looked at it for the links. So he was asking whether, so the talk focus quite a bit on the communication between the group manager and the project manager or the manager for the matter, and the team. But what about the communication within the team? And does being a cross-cultural team mean that certain links and certain communication patterns are broken between the team members as well? And yes, it absolutely does. So we had a few situations when software engineers from Syria didn't really communicate well with software engineers from China. They're both very high-context cultures. There is a lot of implicit communication going on. And we had to have multiple retrospectives and discussions about how to make sure that these two people work well together. They're actually very friendly. They've never had a conflict, but they had a plant of miscommunication. So yes, being cross-cultural will affect your team, not only on the manager, software engineer level. It will also affect your communication between software engineers, communication between software engineers and your design designers. To give you a very clear example, let's say you have a software engineer from the US who expects a very egalitarian approach, very flat. And they expect that most of the decisions about the product are done within the team. Now imagine that you have a product designer, and that's actually a real case, imagine that you have a product designer who is from Southeast Asia and from a culture where they expect a little bit more leadership from their manager who is the head of design. In that case, you have a software engineer who works with the designer and expects the designer to take the decisions, whereas the designer wants their manager to take the decisions. So there is a hand-off process going on that software engineer does not like because it impedes his velocity. So in that case, you actually have to bring everyone into the room and discuss how do we make sure that the product designer is empowered to make decisions and gets an implicit buy-in for whatever she does from the head of design and doesn't affect the velocity of the software engineer. So it's not just like a process problem, it's a culture problem. Does this answer your question? This comes to the end of the session. The next session is at 12.30.