Welcome to Redescoring the Power of Agility, our first virtual event in this new series, where we zoom in on how can we actually look into the power of agility. But let me just start by sharing a little bit of background with you. Because back in February in 2001, a group of software developers met in a ski resort in Utah. They were curious and they tried to find an alternative to the existing software development processes that they perceived as being complicated, unresponsive and too focused on documentation. So they sought to find the perfect balance between the existing ways of development and these new alternatives. They also acknowledged that planning is important, but it is necessary to accept that we are in a changing environment and flexibility is key if you want to be able to navigate in these uncertainties. The days resulted in the development of the Agile Manifesto, a set of four values and 12 principles for Agile development. This was the beginning of Agile software development methods that today covers a lot of different frameworks, ranging from Extreme Programming, Kanban, Scrum, Spotify, Safe and a lot more. A lot of organizations have embarked on the journey already with implementing Agile ways of working. Some organizations are still on the journey, others might consider how to get started and we also have some organizations who actually tried but decided to roll it back. We here in Implement are very, very curious to find out if Agile is still a thing or if it had its shine. Therefore, we have embarked on a journey where we have interviewed plus 20 market leading companies within several industries ranging from financial services, public service, communication and media and a lot more. Today, we are going to have some interesting discussions and learn from one of Denmark's market leading telecom companies, UC. UC has been on this journey. They have had this large scale transformation involving the entire organization, of course, somewhat more likely in some areas of the business. We are going to learn more about UC's experiences. So, without further ado, let me introduce our guest today, Christian Morgan, the CEO of UC and my good colleague, Thomas Leonhard. Welcome, Christian. Thank you. Really nice to meet you. Likewise. And personally, I'm really looking forward to this one. Really excited. I haven't been part of your journey, but I've been looking at it from the sideline. So, really curious to hear about that. Good to hear. So, my first question is, why did you decide to pursue an agile transformation? So, what was it actually that you wanted to achieve? Yes. So, I think it was many of the textbook things. So, time to market. We felt we were slow, unresponsive to customer needs. We wanted to create a more efficient structure. We wanted to create customer centricity and also more autonomy with the teams. And so, in many ways, trying to sort of bridge the triangle of happy employees, happy customers and less cost. We're actually trying to do all three at once. And I think that's been, for a lot of different companies, that's the textbook answer. And that was also the reason why we wanted to pursue that journey. Thank you. And so, now then you did a quite bold move. Yep. So, actually, you decided to roll back the transformation. What were some of the main drivers for doing that? Yes. So, maybe just a little bit of background. So, we decided to go across the entire company, go to something that was dubbed Enterprise Agile, which was a version of Scrum Kanban mixed with a bit of McKinsey lingo. And we went across the entire organization, which meant that certain parts of the organization, like shops or call centers, of course, used some of the same terminology but weren't really cross-functional or such. But we used it as sort of almost, I would say, as a framework for how we did things within UC and the other companies in the group. And what we saw when we then launched it was that we were missing some of the key fundamentals to actually realize the benefits. So, and the main one was IT. So, to really work in this way, you also need to be able to produce new things iteratively in short sprints or whatever you use. And what we saw was too many of the things we wanted to do were dependent on very complex legacy IT. Our main BSS system is from 1987, which made it extremely tricky for us to actually work in an agile way, to be honest. Yeah. So, at the time when it was decided to go this way, we didn't have a plan or a mandate to replace our IT. We were replacing it slowly, adding microservices on top of the monolith. That was the old system. And at the time, the leadership of UC and of the group believed that we could, by applying agile to this transition while we moved to more microservices, that that could be a good combination. Yeah. But the reality was, we were simply too dependent on legacy IT, very complex processes, long roadmaps, long delivery times to really become agile. So, we decided after just one year, also new management, I took over UC and so on, we decided to roll it back. Okay. Completely back. Completely back. Yeah. So, how many people was it that was involved in that transformation? Just to figure out the timing. Yeah. So, in total, of course, it was sort of four or five thousand, but you could say the real agile teams were talking more about maybe a thousand people or something like that, because a lot of them were agents sitting on the phone and so on. And they weren't, you know, you could always argue how agile were they really. Yeah. But I think the, but, you know, thousands of people, thousands of people. Yeah. It was a tough, tough call. And for how long did you actually do the transformation? Because I remember that also in the news and so on, it was quite big. Yeah, yeah. No, it was very big and very positively received as well. Yeah. So, we practiced for four years, something like that, with different subsets of the organization. Mm-hmm. We, at the time, the belief was that every time these agile parts of the organization met the non-agile parts, that's when the ball was dropped or the process was ruined. Yeah. And then we met some companies that had succeeded in going from the little test cases to big scale. Mm-hmm. And you could say based on that, we then sort of decided to move in that direction. And the process itself, which was your, and also how long we did it, we sort of then for about a, I think it was about a year. Yeah. We had a very inclusive process with the organization on how to move to agile. Yeah. And lots of big hackathons and other things to really drive this forward. Yeah. We had all sorts of reference groups. It was quite, quite inclusive. It wasn't just, you know, management away for a week and then we come back with a new structure. And then we tried it out for about a year. Yeah. Um, uh, COVID didn't help. So we launched around COVID, which of course made it even more tricky. Mm-hmm. But I, I still would say that wasn't the main reason for it, for its failure. Okay. But, and then we tried it for, I think about a year, maybe it was a year and a half, but something like that. Yeah. And then we decided to roll it back. Did you do any piloting along the way or was it, you know, like, you know, big bang? So we piloted for about four years, uh, with different, with different teams. Yes. Uh, like everybody else, we started in IT. It was more delivery method, you could say, in IT. Then we moved it to creating product slash IT teams that had specific responsibilities for delivering, could be, uh, specific journeys, online journeys or something else where they could A, B test, they could do all sorts of things. Uh, and not having, uh, journey people speccing to IT, but having them together and then having commercial people. So we did all the pilots. We did, we did everything you could say that, that you would normally do. Uh, we did that for, I think three years, um, something like that. And then big bang. Big bang. Yeah. Yes. So, uh, a big question for me here is, uh, so if you could start all over again, uh, what would you have done differently? Yeah. It's always so easy to be smart in hindsight. Um, I think the answer is relatively simple. Um, we, we wouldn't have gone agile. We wouldn't have, well, we wouldn't have gone our brand of agile, this enterprise agile. I think that's very important to say the way we did it, the big bang. Uh, what I think, I think what we're doing now, or I, I'm very, very committed to what we're doing now, which is transforming the root of our problem. The root of our problem is not how we work together or how we, how we, um, manage our complex matrix. It's actually the IT. It's the fact that our IT is from 87, which means it's tricky for us to sell products online. It's tricky for us to create great customer journeys. It's tricky for us to not make mistakes. It's tricky for us to communicate proactively with our customers. All these things is at the root of the problem. That's what we're focusing on now, rather than what you may call veneering, which agile was a little bit, uh, when you don't have the foundation. It was more sort of, how do we work together? And, uh, so now we're really focusing in my opinion on the, on the root of the problem. And I think that's, that's the right thing to do. Hmm. Not to, to add a, uh, work system or whatever you want to call it. Um, I, I don't think this is a, I think most people will probably agree with me that that is the right way to do. So maybe we should also realize that before, but, but, um, so I would not have rolled out enterprise agile and I would have focused on the, the root cause of the problems, which in my opinion, uh, were. Um, mainly, you know, the IT. But then on top of that, there are a lot of different things that we needed to change in terms of culture, accountabilities, all sorts of other things. But it was not necessarily whether we meet in standups or in normal meetings or whether we work Scrum or Kanban or Waterfall, to be honest. Yep. So, uh, it's not a one size fit all. It's not a one size, uh, fit all at all. And I think there are lots of the agile principles that we will be using and we already use today. Yeah. I think the mistake was even though every single time we talked about it, we talked about it not being dogmatic, it very quickly became dogmatic. Mm. Um, and, uh, that was part of the problem. What about inspiration? Did you get any inspiration from, from outside? Yeah. To say, you know, we want to be like those guys. Yeah, yeah, yeah, absolutely. So we, um, so we of course visited the, the usual suspects. Um, I didn't myself visit Spotify, but we visited ING in the Netherlands. We visited, um, Spark, which is a New Zealand telco. Yes. Um, and probably a few others that I forget. Um, and then we had McKinsey of course to provide a lot of, uh, insights and, and help, uh, in terms of, in terms of how this could be done in the best possible way. It was very much the, um, belief of the CEO at the time that, that, that, that this was the future, which, which it may also be in many ways, but you just need to have the right foundation. And I still, I think my own philosophy is rather than adopting a framework and trying to apply it on everything for the person with the hammer, everything is a nail. Yes. Uh, you, we need to have something that's more contextual. Um, and the most important thing for me, at least in what we're doing now is that everybody is accountable and it's clear what they're accountable for. And whether they then do agile or they work in a different way, I'm not too fast to be honest, as long as the accountability is clear and they know what I expect from them. And that goes all the way through the organization. I know it's a little bit old school, but that's actually the most important thing for me. And it works. It works. It works. It works. Thank you, Christian. Thank you. So, uh, Christian, we, we touched a little bit on this in the beginning, but, uh, we've been talking about agile for, for many years. Yep. Um, so if we should rediscover the power of agility, what are some of the prerequisites in your mind, uh, for being agile, uh, should be there? Um, a small caveat first. I am in no way an agile expert, as you can probably already tell from what I've been saying. Um, so a practitioner who's, uh, tried it out, I think is, is the best we can, we can say. Um, I think what, I think the foundation for delivering anything, uh, is of course that you have the right tools. So you need IT, you need whatever it is, you need the right tools to actually be able to deliver what you're trying to deliver. So that was also what we saw. You'd also need to be clear on the goal. Um, and I think that goes whether you're agile, non-agile, super clear on the goal, super clear on timeline, resources, planning, everything. You need to be very, very clear. I think for it to work in an agile fashion, um, it needs to lend itself to that way of working. So whether it's highly iterative, whether it's a lot of A and B testing, uh, low certainty, um, and so on and so forth. But where you can design quite a clear mandate, but also have room for maneuvering and creativity in that mandate. I think that's where it lends itself well. Um, and that's also if we do apply some of the agile principles as we move into new IT, which will be in a, in a year or so. I, um, I think that's also the areas where we will be applying it, where, where it ticks those boxes, uh, where you have the cross functionality, you need people to come together. But it's also within an area where they can actually control their environment and, and, uh, and test and, and publish, uh, new things in, in an iterative way. And that is only certain parts of the organization that are, that tick those boxes. There are other parts that don't. So what's the challenge there? If you say, you know, they want to be in, in control or, is that the value chain or? Yeah, it's, it's, uh, it's actually, I think it's defining, it's defining the tasks, um, that, where you can do that. That's, that's the tricky part. It's actually not that easy, to be honest, to define those tasks. Luckily, typically the organization's actually better at it than we are, because they will know, I always work with heads and we're always doing the same things. And why are we, why do we have to go to a steer code? Why can't we do this and this and this? So I think one area that we, we, uh, we, uh, we, you could imagine doing this as you become more technically agile in terms of IT, I think is for instance, uh, testing and building campaigns. So we will have a framework for what type of campaigns we do on broadband, but you do need product people, you do need commercial people, you do the marketeers, you need people that, uh, CXers, you may need, um, agents or representatives of agents. And I think that's, that's an area where you could imagine A-B testing, lots of agility to make it, to make it work, right? So I think, I think those areas are very well, well suited for this, whereas there are others, not so much. So identifying those, making a clear mandate, having a clear, uh, processes for how do you follow up? Uh, because I think one of the things we realized in our interpretation of agile, and I do recognize that we could also have gone wrong on certain areas, um, was that it became quite loose. Um, it became, it became, uh, there was a North Star. Mm-hmm. We had quarterly planning. Yeah. But it, it, it very quickly became quite loose, um, and quite, um, tricky to monitor progress. You had a lot of inconsistencies. You had a lot of idiosyncrasies. Yeah. Um, so, yeah, it just became quite tricky. So it's, it's, uh, you need to identify those cases where that works perfectly. And then some companies are born agile and have managed to have everything structured in those types of processes. But that, that's not the case for us, at least. That was not your case? Nope. That was not our case. Right. So did you also consider sort of the, uh, you touched upon it a little bit, but the nature of work? So, uh, different parts of the organizations maybe being more, you know, adaptive to, to the agile ways of working? Yeah, absolutely. And we did have, you know, a full map of the entire organization where, uh, certain parts were, just trying to think what we called it, um, like, let's call it a center of excellence. So they, in principle, they were not allocated to the, to the, uh, different teams. They were not in the cross-functional. They were flow-through resources, you could say. Uh, typically it was a scarcity, uh, thing. It could be, um, data scientists or something you don't have a lot of, but that you need to use them once in a while. Yes. Um, so we did have everybody, um, we had every profession split in chapters. So everybody was linked to a chapter, product management, commercial management, data scientists, data analysts, whatever it was. Everybody was in a chapter. And we did have different types of teams. Some were enablers, that's what we called them. Yeah. Some were enabler teams. And then we had others that were, that were more in a proper release train or in a proper tribe, as we called it. Um, so I think we were relatively, it was relatively thorough. I think McKenzie did a really good job in that. We were very, very thorough about people have to work with it in different ways. So, so I think we did do that, uh, exercise in the nature of work. Um, I think, but I think we overestimated the, um, what can you call it? We underestimated the complexity in delivering in our organization. Mm. So I thought we could push more out into these agile teams, squads, we call them, than we actually could. Yeah. They were simply too interdependent to really deliver, which created frustration. Mm. And it also created what I think is the counter to what you're trying to do with agility, which is empowerment. Yeah. It created counter accountability because people said, you told me that I own this. I own these three journeys. That was, that was what this was about. Yeah. But every time I want to do something, I need to talk to these 80 people. So I just go, I can't deliver. So we saw almost, uh, a counter accountability, contra accountability. Yeah. And all the old processes we had in the matrix organization to solve all that have disappeared. Okay. And I think that's where we missed the point on the nature of work. I think you called it, right? Because we missed the, the interdependencies, the complexities, the need for the governance, as long as we're in this old school legacy IT world. And, uh, so that's, I think, where we missed the nature of work that you needed those interdependencies were still there. Yeah. You need a governance, you need processes to solve it. And you can't just solve it with a quarterly planning tool and some stand ups. It's too complex. Uh, that was at least where we ended up. Yeah. I do recognize that it's not necessarily because agile is bad. It, it could easily be our interpretation, the way we, we, um, executed it. I think the message that's important for me to say is, um, we were quite well prepared. Um, we made a lot of mistakes, a hundred percent. Yeah. But we were quite well prepared and the, and the results were quite clear. It was not for us. Um, so, um, at least for anybody else who's, who's out there, um, preparation will help. But I think, uh, also look into some of the cases where, where it didn't work and, and familiarize yourself with the similarities between our company and your company. If you have an old, a legacy company, a legacy incumbent, legacy IT, material compliance, material bureaucracy that you need to adhere to. Be, be careful, I think in terms of how widely you decide to spread it. Um, yeah. So I'm just curious about the engagement of the people. Yeah. So during the process, how did you do that? And, you know, what effect did it have also, you know, moving forward? Yeah. So I, I, I struggle a little bit to remember now, but I think, um, but we, we were very, we were very, very, very cognizant that the Agile, that becoming Agile also had to happen in an Agile way. Does that make sense? So we wanted to involve people, we wanted to empower, we wanted to be iterative, we wanted to sort of build our future together, which all sounds very good comms wise. It also was in reality what we did and people felt extremely engaged, extremely engaged. It was very, very positive cultural transformation at first. So you would do that again? The way we engaged people, yes, I quite liked that. I think it was actually quite good. I think the issue of course is, and this is maybe a little bit more after the fact than during the transformation part of the process, but the problem was we got very self-absorbed with way of working, rather than what the original goal was, which was delivering more value to the customers. So of course the issue when you facilitate big workshops and how we can work better together and everything is that you can become a little bit way of working centric, rather than customer centric. And that was what we saw as well. That's a good point. Yeah, that's what we saw as well. So you need to balance it. But overall I quite like, I very much like the transparent model, I like doing things iteratively when you're doing big things. So some of that I would definitely do again, yes. And also I would want to say that we also saw an extremely positive response from the external world, from press, from universities, hiring. So brand-wise. Brand-wise it was a very big part of our brand identity at that point in time, which again did not help the way of working centricity, to be honest. It became what we were, rather than a tool to get results for our customers. And I don't think that is the right approach. And also one point on that. When what you're trying to be has a Wikipedia page, right? You can look up what Agile is, you can look up what the Agile manifesto is. And if you're trying to become something that has a Wikipedia page, then you should expect your team and the organization to continuously check. Look into that. Look into that. Check, are we living up to being this thing that's on Wikipedia? Is that the truth? Wikipedia? And the reality is, yeah, sorry, maybe not Wikipedia, but the reality was, of course, we were our own brand of this in positive and negatives. And you need to be really careful when you roll things out like this, that you don't try to adhere to a checklist online, because every company is different. You need specific cultural markers, you need specific cultural adjustments. So I think that was a bit of a mistake as well. All right. Good learnings. Yep. All right. I think so. Experiences and learnings, the last five years. Yep. So imagine, Morgan, that you and I will meet again in three years from now. Yep. And we'll have the same conversations. So what story would you wish you could tell us at that point? Yeah. Good question. I think since this is called rediscovering the power of Agile, I'll start by saying, if I am to tell a story of my company, of UC, then I wouldn't be too fussed about whether it was Agile or not, to be honest. I would be focused on what we're trying to deliver for our customers, which is a transformed company that can deliver great customer experiences, that can be truly digital and can sort of compete hard and fast in the market. That's the story I would want to tell, that UC has become this, this fierce telco that we want to create. Customer-centric and fierce telco. Check. Um, I think in terms of rediscovering the power of agility, I, um, I would hope that we had been extremely clear on what everybody's responsibilities and accountabilities are. So there's no doubt in people's minds on how they're a success, how they, how they, what they're supposed to deliver and, and, and so on. And then of course, I would hope and I expect that in certain parts of the organization, we will have in embraced some of the great qualities of agile, um, it, but, but in, in no means in the entire organization in a dogmatic system. But as, um, as you would pick tools, uh, in any other, uh, area to solve problems, I would absolutely hope that we would come to a, a place in our journey that our IT and our processes are so lean that we can start working, uh, cross-functional in a very sort of, uh, you know, in a, in a, in a very profound way, but absolutely only in the X areas where that makes sense. Um, the most important thing for me is definitely not the tool. It's understanding where we're going as at, and it's for every single individual in the company to understand that, that goal and their accountability and responsibilities to get us there and how that works. And I think that's, that's the most important thing for me and not, not whether it's agile or, and any brand of agile. The tool or framework. Absolutely not. And, and, uh, that, that's something I would rather have the organization say, listen, I know my accountabilities. Mm-hmm. I know where I need to get to. I think if we do this and this and do it in this way, I can do this in a smarter and quicker way. Yeah. And then absolutely fine. Go ahead. It's not going to be a dogmatic, um, system of work that we will be rolling out in, uh, from UC management. Absolutely not. Yep. Do you have, and this is a, maybe an extra question, but, uh, do you have anyone in mind, any company in mind that you would admire? You know, you know what today, if you look at it, who could you be inspired from? I don't know if I could, I don't know if I could put my finger on one single company, but what we actually do is, uh, UC is a, is a relatively large company in Denmark, but in the global scale of telco, we are a, uh, very small company. Uh, so I think what we generally, um, do is we, we try to get inspiration from the, um, from all sorts of different companies all over the world, different telcos, and we do try to steal a little bit with pride from their, from their playbooks. And, uh, I think, so I think we're very sort of, we, we, we try to track the, the consumer space and the telco space quite closely and learn from the best and, and figure out rather than hand holding, building ourselves little solutions. Uh, how can we leverage whatever the big ones are doing in a Danish context? Uh, and that's very much what we're doing. And I think a good example of that is recently, we changed our TV, uh, infrastructure or box architecture to piggyback on Android, rather than on a very bespoke system we've made ourselves. So in that sense, we're leveraging and, and of course, looking up to, uh, at Google and their capabilities in developing UIs and softwares and so on and leveraging that in a Danish context. So, so I think, so I don't have one company, I wish I had one, but, but I think, uh, so we, we really do try to, um, to look at all the good, the good cases out there in the world and then, and then apply whatever is, uh, the best learning, uh, from each of them. I think, I think MTG, if you remember that company is now called, uh, Viaply. They used to have a value, which was, I think it was steel with pride. I'm not sure. Yeah. We do adhere to that a little bit as well, uh, of course, in a very respectful way. I guess that's okay. Yeah, yeah. I think that's okay. No, I think it's important when you are, when you're a service provider, you have relatively slim margins, you shouldn't be reinventing the wheel every time. You do need to find things that scale well. So, uh, so that's what we try to do. Okay. Yeah. Thanks, Christian. And thank you for introducing us to the, to your agile journey. Thank you. Uh, we have some time for, for questions and, um, what we would like you to do out there, uh, is actually to, uh, to write a question, uh, in the Q and A section. And, uh, then there will be coming some questions in here and we will, uh, of course, look at, uh, at them and, you know, answer them, answer them. So, uh, So just to get us started a bit, Christian. So just to get us started a bit, Christian. Yep. I actually prepared, uh, one question to start out with. So, uh, I know you think we, we could use a better word than agile. Um, so, um, yeah. What could that be actually? Yeah. Yeah. Yeah. I, I, um, I think I probably don't have a better word, but I think what I was, I was touching a little bit upon it earlier. I think what, and I think again, what you need to be careful with is if you roll out, um, a company-wide system or a way of delivering something that's going to be not necessarily one-to-one with your culture, but close to it, you need to be careful that, that, that people don't expect it to be exactly what's online. And we use the word agile. It has so many, um, checklists, so many, um, opinions about, you know, what it is that you, you will be, you will be adopting a value system that you need to adhere to. And I think that's the reason why I think, again, I would never have gone agile if I could have redone it, um, at the, at the time. And if I had said, and as the CEO of UC, we, we probably wouldn't have done it. But the, one of the mistakes when you do it is you, you call it, I think you call it agile if you're not extremely stringent on what it is, um, and, and do it in exactly that way, because we did not. We had different things that were different from, from the, uh, from the, uh, the original plans. And that said, the original plans have morphed so much over the years that you have so many different frameworks, of course. But I think, uh, I think that's the reason why I say that I would not have used agile probably because it, it becomes quite dogmatic, um, not on purpose, but it just sort of organically just slips into dogmatism. Yeah. All right. And another question I have, which is, uh, uh, we talked a little bit about it before, but, uh, did you consider actually to do a second founding of the company? You talked a little bit about legacy and stuff. Yeah. And just, just background for everybody. So we were, we were acquired by, uh, um, a private equity fund and three Danish pension funds. And we split the company in two. We had the service provider side on one, and then we had the, the infrastructure on the other. And then what we did was we, um, we then had to, you have some questions coming in on this side there. Oh, okay. Thank you. We then had the, uh, we then had, um, we then founded, you could say, New Day very much on this sort of, which is where you see as part of, very much on this agile transformation was actually a very big part of our founding. That's also why you asked the question, should we have done a second founding? Yes. I, I don't think so because I think what we did do, uh, when, uh, John, the CEO of New Day, John James, when he started was we made a very rapid cultural shift. And of course you can't do a very rapid cultural shift, but in terms of leadership and in terms of the values that we, um, projected into the world, we very quickly set, uh, set a direction. Didn't spend a year on it. We just said, you know, it's quite easy to see. We need to deliver a better customer experience. We need to be much more digital and we need to be much more competitive. Yeah. Very simple. And then we very clearly, uh, quite clearly John, even before he started identified that we need UIT. Just stop mocking about with, with the, with the legacy. We need to change it. Yeah. And we very quickly got a mandate. So rather than refounding it with a big strategy process, lots of colors and so on, we just got to work, um, and said, this is where we're going, uh, which was a little bit top down. I recognize that. Yeah. But it was quite clear to everybody what was wrong, to be honest. It wasn't like, it didn't need a, I think if you had come in and been there a week, you would have said the same three things. Diagnosis of four to six weeks. To be reality. That's, that's reality, right? So, and then, and then we just got to work. Yeah. And then the, the cultural shift and the mindset shift, which is absolutely nowhere done. We're, you know, we're two years in or a bit more than two years into this transformation, um, was very much by example. Just, you know, putting a clear direction, not changing it, being consistent, delivering on the milestones that we, uh, that we felt that were needed, uh, making sure that the organization had clear accountabilities, were performance driven, results oriented, and, uh, then we just got cracking. And, uh, and so, so I think in many ways we had a rebirth. Yeah. Uh, but, or relaunch or whatever you call it, refounding. Yeah. Refounding. Yeah. But, but, but, um, but it wasn't one of these sort of, you know, now we'll, uh, rent, uh, and we'll have three bands and so on. It was just starting all over again. Yeah. Let's just get shit done. Yeah. Uh, that was, that was the, uh, that was the reality. And I, in many ways that created, I think, uh, and, uh, the, I wouldn't say a new culture, but a, the, um, the seeds for a new culture, um, about being close to the customer, getting stuff done, doing the right things, you know, um, don't, you know, don't wait around, you know? Um, so I think that was the, it got quite concrete actually. It got very concrete. Um, it got very concrete, uh, which is also generally what I like in the sense that strategies are good, but I, I, I really like actionable plans, to be honest, uh, and to execute on them, right? Because, and, and especially when you're in a transformation, which you have to say that UC is, uh, with so many legacy complexities and so on. So I think it's just, yeah. Super. Yeah. We actually have a question here from, uh, from Anas. Uh, I think, uh, that's, let me see here. Oops. So, uh, he says, hi, Christian. Can you elaborate on your organization's capacity to transform? Yep. Didn't the rollback create uncertainty? Yes. I think that's an amazing question. Um, so for anybody who's been in the TDC group, which was the, uh, the name for it originally, um, it's been never ending amount of transformation. Let's just be fair. Um, so the, uh, the capacity was quite high, but, but the problem is it wasn't necessarily capacity. It was also a little bit of numbness, to be honest, transformation, numbness. So I think, I think, um, what, what it felt like originally with the agile was it was a employee and customer centric transformation, which people liked. We also let go of a lot of middle management and gave the power more to the people. Yeah. So in terms of comments, in terms of the empowerment, it was a very positive transformation, which I think gave people a lot of energy. Yeah. Um, so of course, when you then roll it back, uh, it's very complex. I think luckily we did it long enough that, excuse me, that everybody could see that it was not for us, uh, in that brand that we're doing it now. So, so I think at the time where we rolled it back, the fatigue of this new system had set in, uh, which meant that most people were happy. Yeah. Most people were happy that we went back. Okay. Um, I, of course it created some uncertainty. Yeah. But I think in many ways when we rolled back, because we focused on clear accountabilities, clear processes, all these different things, um, so it was like, it was not going back to blur. No, exactly. It's not going back to blur. In many ways, the agile had created more vacuums of accountability than before. Yeah. So I, in, in that sense, lots of questions. So in that sense, it was fine, but I think that's, that's a very partial answer because the reality is bouncing back and forward like this always creates uncertainty. Yeah. So of course there was a lot of uncertainty. So I think that's, that's, that's, that's clear. And, and obviously not something I would recommend anybody doing, going to a full new system and then bouncing it back a year after, but a hundred percent, the right decision to bounce back. I, you just have to look at it as a some cost there, to be honest. Yes. Um, for us at least. And you still had the engagement from the people. Yeah. So, so it, no, so yeah, uh, we did, uh, but it did take a while. I think, um, I think the, the, because of the transformation numbness, people would tend to say, yeah, right. You know, let's see, let's see, new management. I was new COUC, John was new for New Day, new management. Yeah, yeah. Customer centric, blah, blah, blah, right. Good luck. Good luck. Good luck guys. So I think where we, where we managed to move the engagement, which is now very high, we have really good employee satisfaction scores and high engagement in the transformation, which we of course measure specifically. We, um, clear direction, consistency and execution results have really moved the sentiment to, we're actually doing it, uh, from year, right, new management, same bullshit. So, um, okay. Yeah. We have another question from Anders. Yes, please. So you have mentioned that accountability really is a key focus after the rollback. Yep. But in agile accountability should also be very well defined. I completely agree. So how does it differ now compared to when you had the enterprise? Yeah. Agile organization. No, I think that's a, I think that's a, that's a really good, that's a really good question. So I think the, uh, we were very clear on the accountabilities in the agile as well. So the way we did it was we had a number of tribes. Yeah. And in those tribes, we had squads and these enablers and every squad had KPIs, had accountabilities and so on. Yeah. So that was actually all quite clear on accountability. In many ways, more clear than you would have a normal system because accountabilities need to be refreshed once in a while. And people don't get around to doing that and putting it in writing and so on. So in many ways, that was actually quite good. Um, I think the, the, the issue was, uh, they became micro accountabilities in small teams, which, which can be good. Um, but the problem was that the holistic accountabilities became blurrier. So we had split like the, the CEO of UC only owned certain parts of the value chain. A lot of it had been centralized in like product tribes or IT tribes. So you couldn't, there was nobody who like owned UC. So this end-to -end accountability had dropped away a little bit. And the other thing was these micro accountabilities, what we saw was they were pseudo accountabilities. Okay. It was very, they, which of course is, is not the fault of agile. That's our prerequisites that weren't there, but they became pseudo accountabilities in the sense that you actually didn't have the people there or the tools there or the agility in IT to really deliver on your area of accountability. And that's where people went, you know, how am I supposed to deliver on this when I'm reliant on our, you know, legacy stack developers, right? So it comes back a little bit to work in progress. Uh, yes. Okay. We actually have, uh, some time for a short question if anyone wants to, to drop it. Um, otherwise, uh, if, if I can take a takeaway from this, from what I hear at least is that, uh, there's also some good takeaways from you in that engagement that you had with the employees overall. Yeah. Uh, and also, you know, quite a steep learning curve, you can say, to get to a point where you are today. Yeah. Uh, whether it's agile or whether it's other methodologies or whatever, you know, I guess the, the point is that you still want to achieve agility in your, in the way you're working absolutely whatever that is with some kind of a customer centricity, right? Agreed. And, and, and, and being a digital service provider in the end, which is, I think a lot of telcos wants to do that. So, um, but, uh, with that and, uh, thank you for all your questions. Um, I will hand it over to, to Julie. So thank you all for joining us today. We will of course continue our series of business agility events during the year. So stay tuned and look out for new invitations in your email. Thank you, Christian. And thank you, Thomas, for taking us through the interview today. And thank you for listening in.