All right, it's 230 pm uh European time. That's the scheduled uh slot. So let me just get started. Hello, everyone again and a warm welcome from my side. My name is Swathi. And in this session, I will take you through the topic of navigating global diverse teams.I've noticed that people usually talk a lot about the terms global uh diverse and teams. But here, I actually emphasized the word navigating. As I think it's about how we can navigate these complex uh setups and emerge as winners both individually and collectively. There's also another reason which you'll get to see by the end of my presentation. So let's get going first things first. Uh Who am I? I come from? India where I did most of my education, including my bachelor's. I started my tech career there and worked in two different companies as a software engineer. After a while I moved to Germany did my master's and I've been working here ever since. Currently, I'm employed at Siemens as a research engineer c technical project manager. In terms of technologies.

My focus is around artificial intelligence, semantics, linked data and knowledge graphs other than work I'm quite passionate about diversity inclusion and diy projects. That's the reason I actively engage with these three initiatives as a mentor organizer and volunteer. Now, the African Tech Vision Ready School, Learn it girl, all these are activities uh aimed at enabling and empowering either women, immigrants or other groups towards stem fields and entrepreneurship. If any of this sounds interesting to you, then do get in touch after the talk.

I would be glad to tell you more about these and how you can also get involved. OK. So um what I'll be sharing today is a combination of learning from my full time job as well as these three part time activities. And in both cases, I engage on a day to day basis with uh diverse people located all over the globe. Now that I've told you a little bit about me, let me take you through a journey. The one from me to we, meaning where I went from being a solo software developer to a team contributor, a team driver and a team manager. Firstly, I want to ask what comes to your mind when I say team, while I'm actually curious to hear your answers due to time constraints, we are unable to have an interactive session right now. Do share your thoughts in the chat and I'll go through them at the end. Now, what we see in this image is a sports team. So you have similar people dressed uniformly. Uh physically together in one place, they look perfectly in sync. You might also say they are organized. Uh They even seem to have the same goals right now. Let's make a slight shift to tech teams. These can be quite different, they can be globally distributed. The company I work for Siemens, this is located in different countries.

So in my project, apart from Germany, I work with colleagues located in uh India, Sweden, Romania, the USA on a daily basis, then we have multicultural and Multilingual aspects throughout teams. Um From my personal experience during my initial days of coming to Germany, I found some behavioral differences between Indians and Germans, for example, concerning feedback, culture or direct versus indirect communication hierarchy and how one sees their higher ups and management also with language, I've observed that even if everyone is speaking the exact same language, in in my case, English, the interpretation could be quite different then comes diversity.

We have gender age across generations. There's so much of it. Lastly, not everyone necessarily has the same set of goals. For example, for someone, this might be their very first project. So they are keen on proving themselves for some others. The project might decide our next promotion for some a specific project may only be a side task rather than their main activity and so on. At this point, even if you haven't had the opportunity to work in such teams, I'm quite sure this will change with remote working, picking up so much space in the current times, it won't be long until each of us will certainly experience this. So uh the more equipped we get with this topic, the better prepared we'll be having said that um distributed teams have been around for a few decades. Now, it's not new. That means we have formal guidelines, frameworks, experts and extensive studies telling us precisely what to do and how to do these things. One such methodology is the agile approach to software development. Now, I'm quite confident that you might be familiar with this. You might have even come across the term Scrum or Kanban or you might have these uh in your work regularly. Therefore, let's look at what agile methodology tells us about teams on this slide. Um I've directly copied the 12 principles from the HL manifesto.

The intention, however, is not to go through them in detail, but rather focus on these numbers are 456 and 12. I've even highlighted some keywords where we see the mention of teams or team spirit. So we have um working together daily or having motivated individuals to get the expected results or the importance of face to face communication and also reflecting and adapting regularly further. One of the core values of agile is to prioritize individuals and interactions over processes and tools.

Therefore, we know that experts stress on how important team alignment and chemistry are and how every company every project should abide by these guidelines. Now, the question is, um isn't everybody just following that? Is there even a problem we need to discuss? And it turns out that things are not that simple. I've quoted two surveys only two here. One that says 97% of employees believe a lack of team alignment impacts project outcomes. And the second study where companies reported an enormous amount of loss, $37 billion due to miscommunication and misunderstandings. What this tells us is that there is certainly some gap. Let's try and understand what it might be. We could be missing. If you do a quick online search, you will get the most typical problems in distributed diverse teams and projects there. You'll find uh time zone differences, cultural differences, language barriers, and they are all indeed true. In addition, I've listed a few reasons based on what I've encountered myself.

On the one hand, we have project leads not reacting enough or not reacting soon enough. Then there's uh the problem of not investing much into such kinds of trainings or getting too caught up in deadlines, milestones and crossing things off the backlog. One more important point is that I see people using the bracket term communication for for a lot of different things, be it trust, empathy and respect among team members or not sharing knowledge within the team or so much more. Then there's also the problem of not striking the right amount of balance between two little and too much if I had to share a personal experience here. Um Let me tell you about a project two years ago. Now, this project was planned for 18 months, we had secured the necessary budget and the project also started on time. However, it so happened that uh due to most of the issues you see here and a few others, we suffered a delay of more than three months. And at several points through the project, we also had dissatisfaction among the team members. Of course, I've learned a lot from that experience. If I were to do it again today, there are specific things I would do differently and I would um encourage others to do differently.

That being said, uh There are definitely ways to ensure successful teams. It's not that hard working as part of complex large scale distributed projects and even driving and leading them is certainly doable. Like if we pay attention and practice some fundamental behaviors, this will all come.

This is where I find this guide useful. It's no magic formula that I invented. It's all just based on my own experience over the years. So you're welcome to use it as a reference and adapt it as per your needs as per your own preferences, projects and scenarios. And I call this guide navigate. Let's start with n never, never assume. So whenever you are in doubt about anything, please ask and clarify, you might think now that assumptions might speed things up. But in the long run, the wrong kinds of assumptions can cost you and the project a lot always communicate. Communication is key. It's written everywhere. Everybody will tell you about it. And not only pure work related talk, get involved in small talk also. And uh sometimes I also encounter people who think that the more knowledge they accumulate, the more valuable they become for the team. Let me tell you that this is not true, being a knowledge hoarder and not spreading information within the team will end up making you the bottleneck.

And in a few cases, unfortunately, this might even lead to breakdowns. So keep dissipating knowledge. Next value, flexibility don't be rigid. I don't have to tell you that this is what agility is mainly about, right? And uh we are especially now in very dynamic times where even the next moment the next day can be completely unexpected. So adapt and don't be obsessed with uh even perfection initiative, often IC team members and even managers or team leads say that they sense that issues are there, but they're waiting for someone else to take action quite sure the opposite parties are also thinking the same way.

So rather than be idle, take initiative and do something while you still can then um grow together. It's important to remind yourself that team projects are not a competition. A team's success is almost always directly proportional to your own progress. So trust your team members and take them with you while moving forward. Also celebrate, we sometimes forget this even in our personal lives, we don't value and celebrate the small things. So whenever good things happen, and I'm quite sure this happens in all projects, take a moment to celebrate and also acknowledge those people who made it happen, then we have take interest, take interest in what other team members are doing. This is so crucial, especially in cross functional teams. For example, um if you have a UX designer or if you are a UX designer, don't merely be involved in your own bubble of work, like talk to stakeholders and understand the requirements, better engage with developers to capture what implementation challenges they face with your designs.

Now, not only does this contribute towards um building team spirit and making them feel that you also value their contribution, their work, but it gives you a better and a wholesome understanding of the project and take your own work to the next level. So don't ignore. Now in the end, take a pause and reflect, really embrace feedback and act on it. Don't be in a rush to start the next project or the next sprint. I've seen so many times that um sprint retrospectives get canceled or rescheduled, but I never uh have heard or experienced that sprint planning meetings or uh sprint reviews get canceled or rescheduled. So please allocate time for retrospectives for taking feedback. And uh there you have it my go to guide for navigating towards success in global diverse teams. With that, I come to the end of my presentation and I thank you really for uh listening and being patient. I hope you found it useful. I'm also happy to listen and learn from your experiences. So um post in the chat, how you liked it. And if there are questions you've been wanting to ask what you've done in similar scenarios. Have you experienced anything like this? Um Let's make it really interactive and by the way, that's my linkedin handle. You see on the screen, do connect with me. I'm happy to talk to you about these topics. Yeah. Thanks, Jana.

I read that uh you mentioned all these are very good points and you agree with them. If there's anything that um you would also like to share from your personal experiences, I'd be very happy to hear. This was a 20 minute slot, but I didn't want to take up the whole time. I really wanted to leave some time out for a discussion for um questions, any form of interaction. And I'm sharing the link to the feedback survey again, if there's something you want to share with me, do so. OK. Now I see a question from Ines. I hope I got your name correct. How do you deal when a team is reluctant to do a task? Hmm um interesting question. Actually, I would um first break this, break the situation down into a few um different parts, right? Um First of all, you need to ask yourself, is this team equipped with the right set of skills to perform that task? So uh do you have the right skill set? Uh if it's a development related task, are these uh developers you're talking to familiar with the technologies with the platforms? Um The task requires. And secondly, do the people have enough information to get started with the task? Do they understand uh what the task entails? What the expectations are, what they need to be doing when they need to be doing it by when they need to finish and things like this. So make sure that requirements are clear.

Um If one and two are already answered and you feel that um there's no issue, the third thing would be trying to understand why the team is reluctant to go about this task, try and really uh understand from them, their perspective of this reluctance. Is it about um history from a previous task? So maybe they worked on something previously and um the experience was not so good. So maybe the team members um weren't cooper or friendly enough. Uh then try to understand if uh there was pressure, uh any kind of pressure, like time, pressure or peer pressure or pressure from stakeholders about something. So really um go deep into understanding why this reluctance could be in the first place. And then I think, uh once you understand all of this, you could, um, go about, uh addressing this reluctance like there's no one, um, one magic formula to, yeah, to get them started with the task, you need to understand why exactly. Are they being reluctant and then address them one by one? Right? Ok. Um, having worked in international organizations, by the way, ines, um, if you want to elaborate on something more regarding your question, feel free to do so. And I'll be happy to come back then. Jana writes, having worked in international organizations for more than 10 years, I feel that openness to listen and learn from other people. Also the ones with very different approaches, views, opinions is the key to succeeding as a team. Very true, very true. Um And I've experienced this myself.

Um Sometimes I, in the beginning, I worked only in um co located teams where all of us were from the same uh location from the same cultural background and so on. There was not so much diversity. So to say, of course, in terms of behavior and individual peoples, yes. But, but otherwise, um there was not so much diversity and also there like just listening to different perspectives and learning from them, sharing your perspective, it helps you learn and grow so much and this only like extrapolates and uh doubles and exponentially increases if you are in an international team in a global setting, so I couldn't agree more.

OK. Uh Ines is back. Thanks for answering. This was a task that is coming from a higher up and the team feels it is a bit out of scope and causes constraints with existing work. OK. Uh That gives a bit bit of clarity. Um First, I would like like to ask if you're following some sort of um sprint set up, like uh are you following Scrum or age um Kanban or any other form of agile methodology? If so, then I believe you will have meetings like sprint planning meetings and um you would have refinement meetings, you would have um retrospectives if you do it properly. So there's a lot of uh scope, lot of um place opportunity for you to really share for the development teams to really share with the product owners with the Scrum masters, how they are feeling. So make sure that you communicate to the stakeholders that you find some tasks out of scope and understand from them. Um Why it is so sometimes it can really happen that the requirements that you started out with in the beginning change quite a lot. So um a few years ago, a few decades ago even we were so obsessed with the waterfall model. So let's start with requirements, engineering, finish requirements, engineering, no matter whether it takes five months or 10 months, let's finish with requirements, then move on to development.

Let's work on development and only development, then let's move on to testing. And uh we've left all of that far behind now, we are in this agile phase. So uh things really move at a much faster pace, that means requirements that were valid a couple of weeks ago might have changed in the meantime. So it's also important that the team understands that stakeholders interests might differ. Of course, you cannot have changes every day, but um be a little open-minded and uh understand from the stakeholders, what uh it is that you could still fit into scope and uh how this can affect existing work, uh whether it has conflicts and how they would also see these um conflicts getting resolved.

And I think usually if you discuss this openly with the stakeholders and with the development teams in the same room, then it usually helps not having an intermediary talk separately to the development team and talk separately to the stakeholders or the customers, but having all of them in the same room.

Same. Um Yeah, in today's world, I think meeting room in the same conference call, this helps in my opinion. Any other questions or anything you would like to share? Ok. Otherwise, uh I think we've reached the end of the slot. I'd like to thank you again. Uh Also for the questions and comments. I was happy to read them and to present today. So like I said, uh feel free to connect with me on linkedin and happy to take this conversation forward. Thank you everyone and have a nice rest of the day. Bye.