Barbara Arnst

Good morning, everybody. I'm delighted to be here with you, together with my colleague Johan Morel, to share with you some insights on the transformation journey at Telenet, and how over the last few years we've learned to bark up the right tree.

But before we dive into the story, a little bit about us and a little bit about Telenet. I don't know how many of you have heard of Telenet, but Telenet is a telco company in the faraway country of Belgium. So we've come in from Europe for the summit, and we are one of the biggest telco players in the country, covering mobile, fixed telco, as well as media, serving more than two million customers and generating three billion of revenue. So quite a big company in our country, and part of the bigger Liberty Global Group.

I'm responsible for agility and transformation, and I'm extremely passionate about the topic, and you'll see that later today as well. In fact, I'm conducting a part-time PhD research as well on the topic of self-managing organizations. My colleague Johan here is our VP for one of our customer tribes, the Billing Experience Tribe, and he will share with us how he's experienced the transformation as well.

But let's dive into it. And to dive into it, let's start from the very beginning.

Telenet is a company that was founded 25 years ago, so not massively long time ago, but a quarter of a century. And in that time, we've disrupted the market on numerous occasions and have grown out to be a market leader in a lot of the segments in Belgium. But back in 2018 already, we realized that if we were going to set ourselves up for growth beyond 2020, we needed to rethink our operating model and move away from the siloed, hierarchical, waterfall delivery structure that we had in place back then.

So already in 2018, we looked at our house and realized that we needed to redo a lot of the rooms in the house, and in fact overhaul how we were working on most dimensions. And back in those days, Agile, and more particularly the Spotify model, provided a ready-to-use recipe on how to approach that.

So we as a company, we jumped in it, and we started with a series of pilots back in 2018. We expanded it to a blueprint exercise, did a whole lot of prep on how to scale that up. And in the early days of 2020, we took the leap. Most of our company, all of what we called back then the change organization, adopted a Spotify structure with a lot of the Spotify lingo that you may be familiar with. We had squads and chapters. They were working in tribes, and we had 150 of such teams. So essentially multifunctional teams using the Spotify way of working.

That was a rewind back to 2020. And two years into that scaling journey, we actually did an exercise to see, yeah, where are we now? Where are we at now? And what are some of the learnings that we've come across?

The most important learnings for us were, first and foremost, that the business objectives that we set out to achieve with this transformation, better products delivered in a faster way and with a stronger and more engaged workforce, mattered more than ever. Since the pandemic and since the recent evolutions, those things have gone ever more at the forefront of what we need to do and need to be able to deliver as a business.

We also firmly agreed that we would never go back, and that many of what Agile stands for has become part of the DNA of our company, and we're very, very proud of that. But also, we had to recognize that there were some structural frictions in our model, and that these prevented us from achieving true business agility and were also impacting the engagement of our workforce. And in fact, for many people, it felt that we were still standing at the bottom of the mountain and had a big journey ahead of us that looked unclear and still a long way off.

So that's a bit where we ended in the summer of 2021. So what happened next, and how did we move forward from that realization on?

There, I'm going to use this analogy of the left and right brain, and how you can think about approaching a transformation as a leader. We had a series of fantastic reflection sessions with our CEO and the senior leadership to have a debate about this and to see what we had done over the last years, using this analogy as a guiding framework.

There are some choices that you need to make as a leadership. Do you believe that you should invest in a culture-first transformation, which means working on the beliefs and the mindsets of the leadership and trying to instill new values in the company and new mindsets that embody Agile, and so really being agile? Or do you say, let's start with the practices first. Let's start doing all of the things that Agile prescribes in how we work.

I think particularly in Agile, there's a lot of specificities that feel very different from the old way of working: using Scrum and the weekly sprints and the big room planning, using Jira to do your work. You can spend a lot of time doing a lot of that. And particularly for Agile, it feels very different than the way of working that we were used to in the company.

Last but not least, there is the system-first theory. Do you say you wait with working on the culture and wait with adopting the practices, but you take a look at the organization's structure, the governance mechanisms, the incentives in your organization, and think, are those all aligned to realizing our Agile objectives, and do we tackle those first?

Inevitably, if you're doing a transformation, whether it's Agile or anything else, you will of course touch on all three of these elements. But there will be a set of choices and priorities that you make, and bets that you make on where you start first and where you put most of the energy.

Now, with that in mind, what did we learn on how we had approached Agile over the last years leading up to 2021? In a nutshell, I think it's fair to say we've put a lot of energy on the culture side and on the practice side, and really invested a lot in trainings and enabling our people in getting this right. I think we've done great things on that front, don't get me wrong. But I think we'd underestimated what needed to be done on the system side.

So essentially, we instilled the Spotify model with the tribes, the squads, the chapters, but did that in the old structure. So we still had a senior leadership IT domain, a senior leadership digital domain, product management, business, design, marketing, and they were all reporting to different members of our C-suite. And so we copied the whole Spotify model, but essentially put it on our old structure.

This resulted in an explosion of interdependencies between teams. And I think Gene gave the example this morning as well of the checkbook project, which, to get anything done, even simple things, we needed to mobilize 30 different teams scattered across the organization, who all by nature have different priorities.

Even more problematic is, with the belief culture that we had put in place, we also assumed that the teams could self-manage and solve these problems by themselves. Which of course, we learned, was proving too difficult and didn't happen.

So we realized we were there. And also that if we were to move forward, and we desperately wanted to move forward with our Agile journey, we needed to tackle the system side. This meant addressing the tougher questions of how are we structured? What does our organization look like? Who makes decisions on what? And does that fit with Agile?

This also meant that our leaders in our company had to take up a new role in the entire transformation. They had to really move to being architects of the system and seeing it as their responsibility to take away and remove the constraints that were making working in Agile difficult for our employees. And so it's a little bit of a mindset shift versus what we had predicated in the Spotify and in the Agile culture, which put a lot of the onus on the teams.

So with that in mind, and with that aha moment in our senior leadership, we embarked on what we called the Agile 2.0, or the next iteration of our model.

We approached this in three different steps, and that journey took a year, so we spent quite a lot of time on this. The first step was thinking: for Telenet and for our particular business context, what are the building blocks that we would like to have in place to enable us to execute on our strategy? And so this is really thinking generically and modularly. What are the Lego blocks, so to speak, that should form the backbone of our operating model?

Important to note here, we moved away from Spotify model or anything else that was created outside. We did this exercise with a very small team. Our senior leadership, our CEO led it, but myself, the chief architect, enterprise architect of the company, our VP HR, one or two business leaders, we facilitated that. So it was really a homegrown thinking based on what our context was and the frictions that we needed to solve for.

Only after we were happy with those theoretical building blocks did we even start talking about creating a blueprint, thinking about organization and structures. And last but not least, and this is also a super important step, we realized this journey would not be done on day one, as it hasn't been over the last year. So we needed to instill a mechanism for the teams to continue to inspect and adapt.

So let's look at these three steps and what's come out of there.

The first one is the building blocks. For Telenet, in our case, based on our strategy and on our context, we needed to reorient our entire organization towards the customer. This is different. It could have been different for other telco players, where it's more cost-focused or product leadership-focused or M&A-focused. But for us, in the market situation and our leadership position, our firm view was we needed everything to reorient towards the customer.

A second thing you'll notice on here is that the building blocks, we have three types of them, and I'll walk through them in a second, but they are all tribes. So in the previous organization model, we had a bunch of tribes, the people who worked in Spotify model, and the rest of the organization and more the run organization was still in business units and in functions. So we moved away from that.

We only had one Telenet operating model, and all of our leaders are tribe leaders, which means that they manage a team of teams with a clear mission. And every single person in our company reports into a tribe. That's their home base.

Three building blocks. The first one are the customer tribes. And these are the bread and butter of the model. These customer tribes are big teams, 150, 250 people, focused very firmly on customer outputs. So they have clear outputs to deliver to, but they also have all the means to be successful, which means they have the business resources, the development resources, some of the ops resources, the strategy resources, and they're all part of the customer tribe and all working to fulfill that one mission. And so the "build it, you run it," it's in there. It's really end to end and full stack. That's building block number one, and of course, super important.

Building block number two are the service tribes. Now, we realized that we couldn't, even though we like to, in the theoretical exercise, put everything in the yellow tribes so that they're 100% autonomous. But of course, in a large company like ours, that's not possible. And there are still some common service or platform tribes that provide a service that is consumed by all of the other building blocks.

And last but not least, we realize, and again for a company the size of ours, we need somebody with a mandate to connect all the dots together. So three different types of building blocks that we started to then imagine what these could look like for our company.

The first nut we had to crack, and this was the most difficult one, is how do you split up the yellow tribes, so the customer tribes, into meaningful blocks? And for many companies who have clear business lines or who sell a bunch of different products, that may be relatively straightforward. But for a telco company who has a lifetime of value and relationships and sells a service, this is a lot more difficult.

So the way we cut it up is through the customer journey. So splitting up the lifetime journey in a series of discrete tribes that own the output that's associated with that journey. So Johan, who will attest to the billing tribe, he owns a micro-enterprise around billing: everything from the strategy, the tactics, but also delivering the full stack of IT services and ops that go with it.

This building block number one, super important. And we believe that this is the best way to guarantee the flow of value to our customers. Platform and service tribes come on top of that, as does the enterprise tribe layer, who connects all the dots and sets the priorities, orchestrates the drumbeats on a company level.

So again, this is still in the theory. We're still in part one. So thinking and imagining what it could look like, and thinking how, if we adopted this model, what kind of frictions would we take away? And we firmly believe that by bringing IT and business together in these customer tribes, we would take away a lot of the friction and the finger-pointing and the interdependencies that we had in the old model.

So step two, after we've done this, is then we translate it into an org chart. And only then. I won't talk you through the Telenet org chart. That's not relevant for you today. But a few things that stand out already from just looking at the picture.

First is, you see a few more yellow blocks than the five that I presented on the previous slide. And that's because we duplicated it to account for some of the multiple brands and segments that we have. And so that refers back to the modularity. We had the building blocks, and now we translated it into the real needs of our business context.

Second, you can't see that clearly here, but there is no CIO or CTO anymore in this picture. All of the yellow blocks and many of the blue blocks own software and own development and need to make software a first priority for them. And so, yes, we still have somebody who sets the enterprise architecture and our standards and manages the DevOps transformation. But it's everybody on this picture, primary concern is software as well as the business priorities. And so we've structurally merged them into one.

Last but not least, all of these leaders own different colors, different types of tribes, which means that their responsibility also spans their other colleagues. All of them deliver a service that spans the rest of the company. So this prevents silo thinking from its design.

So that was the second phase. And last but not least, I mentioned step three is keeping this alive also after we've gone live. And this is where these five pink enterprise tribes come in. So these enterprise tribes have a collective mission to manage and to own the operating model, whether that's from a tech side, HR side, way of working side, strategy side. But the mission is to own and optimize that operating model system.

I think this is really strong. So the transformation is not delegated to a program team, but it's really owned by business leaders who have skin in the game. And it also means that we build in learning into the very fabric of the organization. And so we accounted for that with these five enterprise tribes.

So that was a little bit the journey on how we reimagined and took away some of the frictions that we were facing. This new model, we went live with it in April. So we set the first steps with the new accountabilities. Johan Morel will attest to how that's gone from the billing side.

Yeah, I'll hand the mic to you. Clicker.

Johan Morel

Thank you. You see, I need to click. Sorry.

You see the same picture here, but now it's not a grayscale picture anymore, but it's like a picture in color. And that's indeed the phase that we are now at. We still have a way to go, but at least there is clarity on the path forward and the journey that we need to face.

And that clarity on the journey is based upon four business principles that I mention here.

The first one is transformation is a journey to be managed deliberately and intentionally. It's really hard work day in, day out. Like Barbara said, we started off with a Spotify model. We hired one of the big strategic consultants. They came in, they implemented it, they went off, and that was good to create momentum. But it was also only the starting point. And then we needed to build the system from within. And I think that was the main strength of where we are now. It's really built from within Telenet. It's not a Spotify model, it's a Telenet model. And I think every company should at the end end up with their own model. You cannot just copy-paste an existing model, but it's hard work day in, day out.

The second principle is it's an enterprise-level topic. I think Barbara explained it also very well. We have different types of tribes, and the enterprise tribes, like we call them, they play a crucial role. Yes, you have squads. Yes, you use tribes. But the whole ecosystem needs to work as well. How do you cope with ABRs to QBRs? What's the governance that you need? What are the value streams that you design? How do you steer the business? That's all a thing that you need to watch out for and manage as a whole. That's also a very important learning.

And then the third one, that's a very, very, very big one. It's bringing business and IT together. And I liked, I even took a picture of it this morning, the quote that we saw from Gene: "The problem we are trying to solve: technology function is misunderstood by senior business leaders, and it's often over-delegated to technology leaders. Instead, everyone needs to know that amazing business outcomes are created when technology is fully integrated into all aspects of strategy and operations."

And that's exactly what we have done. We have tried to bring really business and IT together, and that's really a crucial step change. We are a telco. We are highly software-driven. But like Barbara said, we don't have a CIO. Also, from my perspective, I have now IT responsibility, which is a new world for me, very exciting. But then that's a crucial thing: how can you really bring that together? And then it's really end to end that we are talking about.

And then the fourth one is, yeah, culture. Of course, this thing can only work when there's a clear culture of openness, transparency, and trust.

So big transformation, big journey. And that also implies some real paradigm shifts for us as leaders. I'm going to quickly run through three of them.

The first one is that we are all accountable to design the system, and a system that needs to empower people and optimize flow. We are the Billing Experience Tribe, so we are really a combination of people designing the customer experience. We own the underlying IT applications, and we have the build cash operations teams responsible for the day-to-day running of the bill runs, the payment processing, and the collections handling. So that's really that end-to-end setup.

We really want to instill that culture of a small-medium enterprise within a bigger corporate organization. And we really can do it. We have our own responsibility, and now we need to act upon it accordingly. And that's really also a very motivating thing for the people within the tribe. We own our own products, and there's no finger-pointing anymore to other teams. No, we own the thing end to end, and we also need to handle it that way.

Also, the fact that we need to design for flow. It's also a crucial role for us as leaders now, flow both on the tribe level, because it's not because you put three teams together that there is automatic flow. It's really for us to think continuously on how can we recreate systems and a context in which that flow thinking can foster.

Also, the flow thinking across the tribes is also very crucial to really take a look at it. I like the example of John Deere as well. You have foundations, and you have done a thorough exercise about what is the right foundational layer that you need to have, and then you need to optimize it. In every design, you will end up with dependencies. In every design. So you don't need to question the basic foundations. Just think it through at the beginning, and then start from there. And then it's for every dependency looking, what do we need to do? Can we break it, or can we manage it in a better way?

So that's the whole paradigm shift that we went through as leaders, that whole system thinking. That's a crucial step change.

Another one, very important, I like these slides very much, is everyone likes to work, especially when you're from the business side, on that left-hand corner. We all like to work on new features. We all like to create new products. We all like to create new services. That's what we like to do.

But now we are in a world where you're end-to-end accountable for the system as a whole. So you also need to think about removing non-quality and defects on the visible part. But even more importantly, on the right-hand side, the underlying IT systems and applications, you also have a responsibility for that one as well. And that's, again, that crucial step by bringing business and IT together.

And then for us as a leader, I come from the business side. We all need to become an IT manager, all of us. And that's a big step change. So now I'm also learning still a lot about software lifecycle development, about bug fixing, testing, releases, IT environments. Very interesting. Still a long way to go for me, but that's a crucial thing. You need to think across those four quadrants, because you are end-to-end accountable for it.

And then there's the last part. It's about culture. So that's our CEO, John Porter. And one of his favorite quotes is, "Culture trumps strategy." And in this journey, it's even more important.

We come from a world where we're really a marketing-driven company. We had really the thinkers and the doers, the designers and the builders, and that's now completely away. We have defined value streams. We have different yellow tribes, or the business tribes, and we as tribe leads of those yellow tribes, we co-own the value stream. And we are all equal-weighted there. And I think it can only work when there is full transparency, full trust, and openness to the maximum extent possible.

And that's for me the real step change. We co-own the thing and we run it as a whole, and we're all in the same boat, in fact. And that's the third paradigm shift I wanted to share with you.

Barbara Arnst

Yeah, maybe to wrap up, four final takeaways to remember.

I think what we learned is any transformation has left and right brain elements. You need to tackle all, but don't shy away from what are sometimes the tougher left brain structural things. And if they prevent the rest from happening, you will need to make time to address those as well.

It's leadership's responsibility to create the right conditions. I'm firmly convinced of that. You also, as leaders, need to ground your transformation in the why, because that story will form the backbone for all of the transformation steps that you will put towards the organization.

Also be mindful: this is never done. It's not a project. There is no end date. So you need really people with skin in the game who are committed and who will enable the organization to continue to adapt, to inspect and adapt.

So that's a little bit our story all the way from Telenet in Belgium. But I hope it was useful to see our learnings and what we ran into. And we still have a big, big journey ahead as well. So we'll be excited to continue to follow up on that.