 I think we will start even those people are still coming in. Today we have a very good topic again, I would say, and it's nice to see so many familiar faces and also some new faces. So I think I just will hand over the word to Linus Kronevik, who is from working together with Martin Berg at the wireless car, which is a very interesting organization as well. Thank you, Ingella. Yeah, right. My name is Linus Kronevik. And working at the wireless car, that is a super interesting company, just like you said. We are very, very short. We work with helping the automotive industry, or let's say car makers, primarily, into the digital society. We enable safe, smart and sustainable mobility. So this could typically mean like how we are connecting actually cars to the cloud, which enables super smart services for customers like how you can unlock your car, like from your your your phone, etc, etc. A lot can be said about that. But that should be another topic. But wireless car, yeah, we have been around for quite some time. And today we'll really dig into how we work with the team development. And maybe I should say something there. I mean, I think something that is super interesting with also wireless car is as a basis that we won't talk that much about today. But it is actually the culture. So if I should bring up one really, really good thing with wireless car, it is our culture, which we build everything upon. So just bring that with you into what we are also going to talk about when we come to to talk about team development. So what I'm doing, I'm working both with team development and part of the team development crew being also the lead driver for that. That was actually why I came to wireless car to actually work with and develop how we work with team development. But I'm a part of a crew, we'll touch upon that later, but also work in a way of working team. And that's another leg in my what I'm doing at wireless car. So Martin. Yep. Hello, everyone. Martin Bay is my name. I'm from adult people, of course, but I support here at wireless car within the team development crew. And I also support the wireless car in different organizational change that is needed in the organization. But we don't have to stay too much on me. So let's go. Ingela. Yeah, I just wanted to say that we will give this presentation and then afterwards we will give it will be an opportunity to ask questions so you can do that by raising your hand or using the chat and you can place questions in the chat during the presentation as well. Yeah. Okay. Thank you for saying that. So of course, yes, everyone is welcome to ask questions in the chat. And then if Ingela feels that there's something that needs clarification during our talk, she will raise that and make sure that we support you in this. But we will want to save the questions until after just to have seen the full presentation first. So let's take you on our journey. It started before Linus actually joined wireless car and it's been ongoing, of course, in the team in the organization for a long time. We want team to be developing. So and I think most of you have seen these teams, the team that once upon a time you've seen it, the team that are highly productive, they are very focused, and they are nice to be around. They produce value and they support each other and they support the surrounding organization also in order to do things. They finish both boring things and fun things. We want this team, the team that supports everyone. And our vision, of course, is to make sure that we have all of these teams are like this, that they support each other and they support the surrounding. But as most of you have seen, not all teams are like that. And that's because all teams are on a journey. Some teams have managed to get to a space where they have high effectiveness and efficiency and they support each other. Yet some others are on the road there. They support each other and they go there. They build the foundation of where they want to be and how they should work together in order to reach the target where they want to be. Yet other teams, they are on a place where they are more unsecured. They don't really know where they are supposed to go. Maybe they argue a lot. Maybe they feel confused. Maybe they're even fighting internally. We see those teams also. And we also see the teams that are very leader dependent, that can't make things going unless they get support from someone to dive and support them in their direction. And we have all of these teams in all organizations. So in reality, it looks something like this maybe. One problem that we see in the agile context is that agility more or less assumes that all teams are in this position in the organization. Most frameworks, I would be blunt to say maybe, but they sort of assumes that teams are here where they are highly productive and supporting each other and have a good structure and behaviors that is supporting the team to produce value. Or even leaders, let's build a new team so that we can do productive things because we need this. And then we implement the team and the team doesn't start there. They start in on the left side somewhere and they need to go on that journey, all of them. So in some way or another, we in the wireless car want to build a framework or a structure that supports the team to do this journey as quickly as possible and as safe as possible. Right, Linus? Exactly. So this is something that we have actually talked about this quite a lot actually. I mean, we have been at several companies and we have seen kind of the same patterns that sometimes it feels like we're kind of leaving teams alone in some sense, where they need to manage on their own. Sure, that can be supported around, but is it enough? And that's where we think that maybe not and wanted to try something else. So if we take next on that, to give this kind of surrounding support, not in the controlling way, of course, but in the supporting way, right, to give the right amount and we will touch upon it a little bit more. And this is so important, I think also especially when we have teams like in our context at wireless car, more or less none of our team can actually work on completely on their own. They're a part of a context. They need to collaborate with others, like we sometimes call it like in the scaled context, right? So that means we need to collaborate with other teams. Teams need to collaborate with others, but also we need to collaborate tightly with the customer in our case, right? So this is so important. And this is the place in the teams that is really where things are happening. I'm not sure how well you know about software industry and how to make that, but I mean, in these teams, that's really where we are coding. That is really where things are happening, where we are maintaining our services. I touched upon the example before, like how you can unlock your car from your phone. These are the heroes that make that that works every day. And you can think that if you have implemented it once, will it want it to stay like that? Yeah, but it needs to stay safe so that no one can hack it, etc, etc, etc. That is super important. So we need to take care of that over time also. So this is really where things are happening in an organization like ours. So if we take next slide, we think that putting the teams in center really to really enable to have these well-being teams, because like I just said, this is where things are happening. So we need to make this environment really, really good, right? So we have these well-being teams so that people also want to be a part of this. So we have these well-being individuals, because the team is of course built up by individuals. It's of course, it's obvious for sure, but it's so important to think about. And this is also what builds up a well-being company that actually can make our customers awesome in the end. So we can just take next step. If we, I'm thinking about a little bit like developing this support that we talked about. So if we think about where we started out, I touched upon just before we had these teams and in quite many of our teams, we had a squad master working together with the team, not all teams actually. Some years ago it started to become more and more common that we have that dedicated squad masters for our development teams. And you could think like, yeah, but like I touched upon before, isn't this enough? And actually what we have discovered, like I said before, in quite many cases, it's actually quite troublesome. And both Martin and I, we have been in this role. It's quite challenging. And I think that if you have been in that role, it is actually quite hard to make it work and to make it work in the bigger picture in the larger context. So what we did and tried out, and this was really trying things out. So if we take next slide, please, was to create this kind of cross-functional supporting team that we call at Wireless Car, we call it Team Development Crew. And the whole idea is here to not take over any of the responsibilities. We are very, very actually clear about that. We are not taking over anything from like a squad master or any other roles or developers in a team, but we want to give the support that they need. So we have actually set up the purpose of this crew is that we want to support our growing organization in building this environment where teams and people can thrive and feels motivated to deliver the highest value to our end customers. And that I think is so important there that we create environment where people and both teams and people can thrive. So this is a truly cross-functional team. So we brought together people from people and culture. We brought the people from line management. We line managers. We brought in squad masters, of course. We had people from like way of working area, the ones building like the framework of how we work and such. And what we do then is that we are working on like coaching and individuals, building up the different tools. And there, Martin, you will talk a little bit more about one of our tools. Yes. So one of the tools that we started on with, quite early, actually tried out before the team development crew was even initiated was the GDQ. I will talk about the GDQ, what it is and what it comes from. But it's a tool that support us and the support team in order to be able to understanding what they are doing. Maybe a few of you have heard about it. So what we did in order to test and verify that this is a valuable tool for us was that we first had a few tests and runs with different teams to see if it works. And then we decided to do a proof of concept to verify that we can actually follow it and use the process in a good way. And when we had that in place, we have as of now done, I think 100 GDQs with the teams. Some of them have done it four times and some of them have done it once and so forth. I will talk about what it is now. So GDQ stands for group development questionnaire. It's a tool to identify team stages and give support to the team. So the team can fill in this form for themselves to understand what stage a team is in or their team is in. And it also gives them a subscale analysis of things that could be interesting to focus on for a team to develop further. Okay, I'm talking about team stages and you probably have heard about forming, storming, norming, performing. We are sort of talking about that, but we are talking about the integrated model of group development, which is the tool or the model that we decided to use as our base model for team development at Wireless Car. It's been developed by Susan Whelan in the early 1990s. And as it says, integrated model of group development. So it integrates previous theories and models and verifies that they are true. So Bruce Hackman's model, forming, norming, storming, performing in different orders. She confirms that that is there and then she makes, made a bit of a modification to them, you can say so that they are more true to the point. I will talk a bit about these stages for you so that you have a better understanding of what we are supporting. So what if I take you through the different stages here, the first one is called dependence and inclusion. That's where the team are new or the perspective of the team is new in some way or another. And in that space, the team is quite unsecure what they need and what they should have and where they are supposed to go. So we are very lead dependent in that situation. We also call it the honeymoon sometimes because the team feels very happy in this space. They feel that they are producing value and they are doing things most of the time, but at some point the team starts to feel safe together because we are in this stage one, in Sweden we call it fika time. People are happy interacting, talking, but that's because we want to get to know each other in a better way. We want to learn what type of levels we should put ourselves on in order to be able to later on then, unknowingly most of the time, start to challenge behaviors and structures. And that's why we enter stage two because then we have enough trust on ourselves and the psychological safety is on a high enough level for the team to start to have a counter dependency to each other and start to fight in different sense. So that is when you start to feel like the way that we are doing things in this team is not the best, I think. I have my feeling and I want to share that with the group and that's where it could start to go bad if we don't have a good behavior there. But if the team and when the team manage to get out of that, they have formed the platform of how this team works together. We will have our roles, we have our structures, what we want to achieve and we have a good way of handling different type of conflicts, different opinions about how to solve things. And that's where we are, then we are in stage three, which is called trust and structure. And what we can see in research is that that's where the team starts to produce a lot of much more value. And we can see that from the graph on the bottom here that stage one team, yeah, they are often perceiving themselves at least to be quite productive. And I think it's because that they have a strong leadership most of the time, so that someone is helping them to move forward in a direction that's important. But then when they enter stage two, the team needs to go much more inwards, have conflicts, have discussions, how do we solve things? And of course, productivity goes down. They also perceive that they are less productive in that stage. And then, as you can see in the curve stage three, the team grows, they feel productive, they know what to do, they want to support each other in the best way. And in stage four, of course, that's even more so, which is why it's called work and productivity. But okay, now we've been talking about teams, but what is the team leaders? Yeah, you could think like, isn't that very obvious, right? But when we started to dig into this a little bit in more structured manner, we actually thought that this is actually quite important to actually be able to answer that question. So this is our answer in our context at Wireless Car. We came up with this, that the team is a group of people who combine their effort and knowledge to fulfill a common purpose. That is what it is. And if we look into what makes it a team, it is that they have this formal team purpose. They consist of three or more people. And we have a clear team membership. So it's not that like we are switching out people every week. Then I think we should maybe call it like a meeting or something like that, or a community of practice maybe, or something like that. That is not what we call a team, at least. So could it become a team? Yeah, it could. But yeah, so it's just to try to frame it a little bit. And that was one of our learnings, like, okay, we actually need to talk about, but because that question comes up quite often, actually, are these people really a team? And maybe we should say that also here, when we talk about teams at Wireless Car, we are not only talking about development teams. That's maybe the most obvious. I saw there were a question, how many, and maybe someone answered it for us. But I think we actually think about all also the ones that are working in supporting function functions also at Wireless Car. So it could really differs what it is. But maybe it's not the gross part of the team are, of course, development teams. They are, I think, 70 or 80% of all the teams in the organization. Yeah, something like that. So we're around like 50, 60 development team, and then we have like a 10, 15 more. So I think when you talked about GDQ, I think we have met up with at least 60 unique teams now, and then around 100, like you said, sessions with those. So like you said, we have met several of them, we have met several times in this structured way. Right. So looking into another area, how we do and create this support is that we have built up a toolbox that we call Team Development Toolbox. Easy as that. So what is that? It contains a lot of exercises, workshops and guides. And we have stolen a lot from maybe you have been part of creating some of it. I don't know. We have taken it from everywhere. But like from if you have looked into like liberating structure, it could be from sociocracy, management 3.0, etc, etc. All kind of tools or practices, exercises, etc, etc. And then we have tried to tailor it to fit into our context to make it super easy to bring in. It could be, if I take one example, liberating structure have a great, if you haven't tried it, they have a great exercise or workshop that is called Purpose to Practice, that really helps a team nailing quite a lot of the parts that we have been talking about and we'll touch upon. That is great. So we have taken into our context, tried to tailor it a little bit to make it super easy. But also how we can help out with, it could be that someone have tried out this and learned how to run it, then we can have people supporting each other in doing this in different ways. That's like the way that I talked about before, not taking away like responsibility from like a scrum of stuff. How can we connect people to help out each other and like with the tools or tips, ideas, tricks, and so on. But we have also tried to connect this to the different stages. So what kind of workshop could you to use in different stages and so on to give some more guidance there? And then we try to help out as much as we can. It could be a team that are, let's say that they are quite a lot into maybe having conflicts, etc. It can be so nice to have a third party stepping in to facilitate such sessions. And it could really help out sorting out those questions because you are actually, when you are a part of it, it's quite hard to actually facilitate really great sessions there. So yeah, that was shortly about that. One thing that I can add there is that it's a collaboratively built, so it's not just we in the team development crew that add tools here, but scrum masters and others are supporting us in developing things there. And we are of course supporting them in order to be able to map them to the integrated model of group development and we're doing it collaboratively. And it's growing daily or weekly with new things and people also add themselves to. I know how I tried this one. So then people can know that they can reach out to that person to get support about their perspective of how to use the tool. The growing and evolving, changing and being tailored all the time. Now we're going to look into what it can look like in reality. So if we take the next slide there. And Martin, this is actually a team that you have met up with, right? Yep, this is a team that I've been working with. And maybe some people here in the group also recognize this team. I think I've been working closely together with a scrum master in doing this and supporting this team. So what we see here is actually three different gdqs. So from the left, we had a gdq that was done in November 2021 and then in June 2022, the one in the middle and then in December 2022. What we can see here from the graphs could be hard to know if you're not familiar with gdq and how they present the data. But what you see here in the first graph is that the team is a stage one team. And then they go into in June here, the team. What we can see here also what we need to confirm together with the team of course in our workshops is that this team is starting to enter stage two. That is what we can see from the graphs there. And then in December 2022, the graphs clearly indicates that the team is now in a stage four. They view themselves to be there. So this is a good example of how we use the tool to support the scrum master and the team to move in the different stages of development. And for the background of it, of course, there are challenges both within the team, in the technical surrounding that was in the team of how to approach those things. And I remember when I met the team on the work or something like that in the company, they were so happy. I met them around there December 2022 or right after. And they talked about some key events that had happened that made it impossible for them to even do this turnover, which I identified as the steps when they moved from stage two into stage three. And so it's great to see a team that has managed to get to that space because everyone in teams that are in stage three and four are much more happier and well-being because they feel that they produce value and they have a purpose of why they are supposed to be there. So it's very nice to be close to teams when they manage to get there. On the productivity level, we can also see the change. So it's the bottom graphs. And actually the first column is the interesting one because that's the self-evaluated productivity measurement for the team. They rate themselves from one to four. How productive are we? And you can see it continues to rise. And of course the team could still feel even more productive. So I hope that we will do a GDQ for this team soon because we aim to do it once every half year. But we don't know if we said that, but this is voluntarily. All teams sign up for this voluntarily. We don't push this to teams. They ask for it. We ask them if they're interested. If they are not, they can do that, of course. They don't have to do the GDQ, which we feel is very important. Still, we have managed to get 100 teams to do it. Some parts ask the teams to do it more thoroughly, but we do never ask that. So you could feel like you got a lot of data here. But really the key takeaway here is that you see that the ID is here to really work with it in a structured manner, where we really try to nail the areas also. Because inside these pillars that you see and the data, behind that we can actually see what we need to work on more. So that could be like that we identify an area that we really need to work more on. Like how can we have like constructive conflicts, right? To be able to bring up topics, to discuss it, and to be like come to a decision to move forward, etc. etc. And that is what we need to work on. To be very precise in that and this structure manner where we're really following up, coming back to it, looking at the trends, really try to understand the whole situation for the team also. And that I would say is really the key here, and that we want you to just see how we work with it in a very structured manner. Hope that shines through. Yeah, now this team is the Stage 4 team and of course they don't need a Scrum Master anymore. No, just kidding. Yeah, it's important. I've been in Stage 4 teams and supporting them and they need a Scrum Master just as much as any other team do. Yeah, and they need someone that continues to support and challenge them. Yeah, and Martin, like that is also something that we have seen sometimes. Maybe you have heard it in some, I have heard it in a couple of organizations. Like if we can just move all the teams to be like high performing, then we don't need these supporting functions anymore. We can remove them. And that is just basically not true because we are also just from the fact that we are change is a fact. It's happening all the time. Things are changing, customers are changing, people are changing, right? People comes, people leave. And we need to work on this continuously. Nothing is static. It sounds obvious when you say it, but sometimes we tend to not remember that, that these kind of things are really something you need to work on continuously. Maybe we should move on into a couple of learnings. So that was actually one of the learnings that you saw there to work really in this kind of structured way with this to get these kind of results. It comes from quite hard work, actually, behind that slide that you just saw. Another one that we have identified, and this could, we are not saying that this could be in general like that for all companies, but I have seen it before at other companies. And at wireless car, we have seen this, that actually when we started to look at this and have met up with quite many teams, we saw actually a pattern where we saw that quite many teams actually had quite unclear purpose. And you could think like, how can that be that you are developing stuff like on daily basis, you're developing code and don't know the purpose? Yeah, but that was actually a problem that we quite often heard, like the purpose that people answered about their team were that they said like, yeah, the purpose is to develop stuff. But that is not enough. When we look into this, we want more, we want to know the direction. So it's not just about completing tasks. It's about where we are heading, what direction we have in the team. And that is so important to nail that area. And that's also why we also saw that into the definition of the team, right? That we have a common formal purpose. Everything starts there more or less. Because that is really what makes us a team or set up the need for a team, right? If we don't have that, we actually might not need the team, then we can hand out tasks to individuals. But we don't believe in that. So but if we have it, it creates really creates alignment, because we know what mountain to climb, right? That creates focus. That makes things much easier to when it comes to making decisions in a team or partition that is so hard to make, right? Me and my own team needed to do that just a couple of months. And it's so hard every time when you need to scoop out things that you think is super important. But if you have this clear common purpose, you know where you're heading. It's at least easier, not easy, but easier. And we have seen that this in our context, it really need to be connected to the scaled context of the team really need to be clearly connected. Because sometimes when you work with this in a team, it could be they say that yeah, but this is we cannot affect this. Because it's it's into the larger context. And then you need to work with that context. So that's something we actually also do actively step into coach and help and support in the surrounding that's also into that's supporting arrow. And then we see this connection between like, when you know where you're heading together, it also helps out when it comes to building up the psychological safety so that you feel comfortable in this team. And it really affects each other, right? So it becomes like a positive spiral. So much more could be said about that. But I think we can jump to to next one. Yeah, let us just touch very quickly up on this, this one. And that is about the leadership. And that it need to be a little bit different. Martin has already touched upon it a bit. But this is the old thing we have talked about for for very, very long time, we have talked about situational based leadership, right? And this is just a reminder of that, that we need to tailor our way of addressing teams and people, understanding where the team are, right? So sometimes, you know, we want to be on the right side, right? We want to have this like delegating leadership and so on. But what I have seen many times, if you step in with that approach from day one, when you're forming a team, that might be a little bit confusing to everyone involved, actually, and that people actually ask for a need a little bit more clear and present leadership, but that we also need to make that journey. Me myself, I could just be, take my own example, could sometimes feel a little bit uncomfortable being on the left side, right? In that sense, when it comes to to leading, I want everyone to be involved, I want to delegate, etc. I already want to be on the right side, but sometimes we really need to do this work. And this is not something new to you. You have heard it many, many times, but we really want to connect the dots here. And see that that is needed. But because there could also be a lot of like informal leadership also in a team that you need to work with, then you need to help maybe a technical expert to maybe start delegating, sharing knowledge, etc., etc. So there are so many flavors into this. Something you want to add there, Martin, or shall we jump to next? No, we can we can move to the next one. I think we are pressed in time and I think people might want to have the Q&A also. Yes. Another important part is conflict management. In teams, we need, we have to have conflicts, otherwise it won't work. That's the most important ingredients of any team is to have conflicts, but they need to be constructive. So we don't want any of these two. We don't want the conflict avoiding behavior and we don't want these personal conflicts that assaults to happen. So we try to make use of a model that is from Patrick Lancioni, which is called the conflict continuum. We decided to call it the conflict spectrum instead because, yeah, it could also be a spectrum maybe. So what we talk about and we work with it is that we see that and we try to map it to the team development stages that we've been talking about. So in the artificial harmony on the left side, it's typically a stage one type of team. They avoid conflicts because they don't feel safe. So they need to challenge themselves in order to start to initiate discussions and reflect on things. And, yeah, in stage two, they start to do that and could be that they end up on the right side instead of the destructive personal assaults level. And that is of course the reason why the team are cautious in actually initiating discussions and reflections because they are a bit afraid of what happens if I go too far. Because a team don't know what too far is yet. They need to practice that because it's different in all teams. At Wireless Car we have, I don't know, I don't know, 40 different cultures within the company. So everyone have different ways of handling discussions and conflicts. So conflict management is even more important in our context because we don't know how different cultures manage and work with different types of conflicts. How do we initiate things and talk about that? So the team needs to find their optimal zone. So it's a tuning work that needs to be done and we want to support that behavior and reflections about those things. So we have a different types of exercises also in the team development toolbox to work with this type of approaches also in a cultural perspective. Enough about that I think, Linus, or do you want to add something? Yeah, it's just so important. And we have found that many, many times. And it's really nice when you see a team moving from being on the either side, but really step into having those productive conflicts. And it's always so nice to see that that happens actually in the team, nailing that green area and actually just add on. I mean, it actually applies to any kind of relationships also like in marriage or whatever. This is where we want to be, right? Being able to talk about things in a productive way, right? That is where we, yeah, things really can happen and where we're meeting each other. So yeah, but let's move on. So let's look into a little bit into the horizon, right? So and how we plan to continue our journey. And if we just look into the near future, we are right now, to be very open here, we are looking into identifying and address negative structural behaviors in the organization. This is like, it's not that it's any kind of like catastrophic behaviors, et cetera, et cetera. Like I said in the beginning, we have a really good culture at Wireless Core. But do we have things to work on that we can improve to make the perfect like environment for our teams? Yes, we can. So we want to identify those and work with those in a structured manner also. So that's the bullet one. Next thing is that sometimes we see that maybe it's not, because what we haven't said here is actually, we work actually only on pull bases here. So it's like teams are signing up. We are not forcing any teams to join this and or to be a part of it actually. Every team at Wireless Core is supposed to work on continuous improvements, work on team development, for sure. But they don't need to use. We are not dictating like what tools to use. We have a couple we offer, but they are free to use whatever they like. But what we've seen sometimes is that those stage one and two teams that maybe also have got stuck there, maybe are not the first ones to actually reach out for help either. So there is a little bit of a question for us, like how can we give active support to them and reach out to help them? And the third one is to investigate and try out complementary tools. We have focused quite a lot on this tool that we have talked about today. It's not the only one, but the primary one. So we are a little bit, we are too curious, I would say, to not dig into others. There are a lot of things out there. And if we look into connected to that, look into long term, that would be to even more like build our own tailored model and tools and so on. And where that will take us, we have no idea. But that's something we talked about just a couple of weeks ago in the crew. So I just wanted to share that with you. And maybe you want to team up with us or something like that to create like who knows a bigger community in that and how we can build that. That could be super interesting. Yeah, that was just a couple of glimpses from what we see for the future. So let's hand over to you Ingela and the Q&A. Yeah, great. Really interesting to learn how structured you work with getting the teams to perform together. We have some questions regarding how involved support functions is in your value stream like sales, marketing and other functions. And is it about like in team development or if they are a part of it? Because they are also, we are offering this to, so I will actually meet up with the sales and marketing team in just a couple of weeks to work with that team. But I'm not sure if that was the question, but we offer this to all kind of people. It was your question. Paul, would you like to place your question? Yeah, sure. I'm starting to think about how to, when you're working team-based, so you have like marketing keg and stuff, folks like that would say that you should integrate different kind of functionalities to build like a product team, they were a product manager and stuff like that. This seems like more like a technique, like how you organize development right now. And my question was, how do you organize like the product of the value stream with the different kind of functional because I usually met like development teams are quite keen on organizing like this and then you work like, or like different kind of working structures like more like waterfall or in other functional areas and exposed usually are quite a big conflict and you end up like you, the sales dictate what you do anyways, in some ways, then you end up like semi-structured, trying, but you're not reaching that far, I would say. Martin, where should I go? I mean, I think there were several things here that could we could have another meet up about, I think. But I think if I got you right, I mean, I think like I touched upon here before is that like our teams are into context, so this could also, I mean, it could affect the team like how we have written the contracts with our customers, right? So that affects our teams highly, a lot actually. And also how we set up the whole value stream and we have been working with that at least, I would say with some parts of our organization. And maybe you want to touch upon that, Martin, because you have been involved in those at least. I'm part of talking and reflecting on different types of silos and other things within the organization that exists in all organizations and they should be there. We need the structure, but they have secondary effects like loss, site of value streams and other things, because they normally stream through different types of silos. But it's not connected to team development, crew assignment, even though they are of course connected in the sense that they could block team development. And I think that is what you're after here, Carl. Yeah, yeah, because you're trying really hard to be agile. And then the rest of the organization doesn't really follow along. Yeah, exactly. So it's a structural behavior that needs to be attended to when people need to be aware of that that structural behavior is there. And then we can start to approach it. And there are some problems and challenges that wireless car, as with any organization that we're working with, connected to this. But we are attending to it, that is all I can say. Yeah, exactly. And like I said before, I'm working also in the way of working team. So of course, we are addressing that or also working with that. But if we turn it really to be into the team development area, it's important here that we, like we said before, let the team also understand that they are a part of this context, and that we also need to work with that environment, that context, that is the first thing. But when you talk about that, it could be easy for a team then to say like, yeah, but it's on the outside. It's purely on the outside. So it's someone else that need to make a change. But something here that I found important is also that to let a team understand also that they can actually work on how they tackle this, because the environment will be challenging, and it will continue to be challenging. It is challenging to work in these kind of environments. So then we need to develop our skills as a team, how we address that. Does it make sense? Yeah, I can. I want to add one thing there, because the more empowered the team or the more team developed, the closest to stage three and four they are, the easier I see, it is for them to start to reflect on their context, their external context, and start to approach that. Maybe using the scrum master as their tool to get that change going. So if they feel that they are blocked by product management, because they are dictating things that is not really connected to the reality, but that the team are seeing, they can, when they start to feel that they have power to actually influence and work with that, that they feel that that's part of their purpose to actually do those things, they will start to create, which we see at Wireless Car, they start to create this reach out for connection and boundary spanning between different silos. So that is what we can see. I've seen that at Wireless Car. Thank you for the question. Yes, thank you. Yeah, we have a question from Kevin regarding the support on individual level. Kevin, would you like to raise the question yourself? Yeah, hi folks. You know, really, really, really, really good stuff. And I love the way we know we're sort of progressing just back into my office now. So I'll stop my video here so you can see me. So really, really, really progressive, love the integration of previous theories, et cetera, the tooling side of it and the measurement side. But you know, it's just something we know, and you mentioned yourself at the beginning, is that teams themselves are not an entity in themselves. They are made up of individuals. And we know that some of this conflict behavior, handling conflict, agile working stage four, if you like, all stage type behaviors, different individuals will have different comfort levels with that. So interested about the individual dimension to this and how maybe that has been recognized that not everybody is the same in terms of their comfort and their likes and dislikes about teams and team formation. So just wondering is that the toolkit and development process include and even the measurement process include the individual dimension, not just the team level dimension? Yeah, that's okay, Linus, please. Yeah, the quick answer is that you can look at subgroups in this particular tool that we are talking about here. We are not pointing out individuals, because that's something we don't want to do in this way, because then it becomes too pointy, right, to bring someone out. But if we have two or three more people, we can actually look at that, think a little bit of the same. When we're doing this kind of survey, we can look at that. And that is very, very common to see in different teams. And that's also something that I really like with this GDQ, is that you can see these subgroups. And you can do any analysis on that, because just like you said, people are different. Maybe someone joined in late. Of course, they will feel in a different way than the others that have maybe been in this team for like two or three years, of course. So we need to address it. So I'm not sure if that was a good enough answer to you. No, we can just complement on that, because these subgroups is the way we show these subgroups to the teams when we are after the GDQ in the workshop, where we do together with the team, so that they can be aware of that the team actually have different opinions about the team. So it's not rare to see half of the team or a major part of the team view the team as a stage four team, and another part view it as a stage one or two team. And just being able to visualize that helps the team to see what steps we need to take in order to understand each other better. And usually what we see is that as they progress in the different GDQs, is that they are more aligned on what they want to have. And maybe the one in stage feel that the team is in stage four move back to stage three, and the one other ones. So they are more equal in what they view the team is. And being able to do that helps them to progress further. But to be super clear here, we're never pointing out individuals, so there are never any names on it. We're just looking at that we see differences. Yeah, and I didn't mean that at all. It was more about the supportive side, as you say at the very beginning. It's a recognition of that individual. But that doesn't take away, if I may add there, that doesn't take away of course that we work with individuals and working close to line managers, etc. etc. There can be many, many, many reasons to do that, right. But this is looking at like team behaviors. And that's how we address it. Thank you. Great. Thank you. The clock is ticking. So I think we will do a cut here. There are some questions in the chat regarding conflict resolutions and so on. We can say, Martin, that we will have a podcast follow-up. And then we will build in some of the questions that you have in the chat, which can you say something more about that, Martin? Yeah, I don't know. Your sound is breaking up. I don't know if it's just for me or others, but I can repeat what I think you said, at least. And that is that during next week or so, me and Linus and David will record a podcast as a follow-up to this presentation. And we will bring the questions that we did not manage to answer during this time period here into that podcast. And we will propose that in the different forums so that you can reach out and see that when you want to follow up. And of course, if you want to, you can of course contact any one of us, Linus or me on LinkedIn, if you have specific questions or thoughts that you would like to soundboard or reflect on. Great. Then I think we say thank you for today. Thanks for joining. We have already planned a new stories from reality. In May, it will be about value on all levels, how you can use it in work, but also in your personal life to get harmony in your life and working life. So great. Thank you to Martin and Linus. It was really, really interesting to learn how you work with teams. And that you also have a continuous plan for the next coming stage. So again, thanks for today.