Ben Connolly

Hi everyone, and welcome to the session.

Really looking forward to sharing a piece of our journey today, all about one of the things that's really helping us in transforming Vodafone into a global technology and a digital-first company.

Start with a couple of intros. I'm Ben Connolly. I'm head of digital engineering at Vodafone here in the UK. And that means I get to build and lead the teams that build our digital channels and the platforms that they sit on, as well as drive a bunch of the newer ways of working and techniques that help us drive software engineering at the heart of how we deliver to customers.

I'm a software engineer myself, passionate about technology, but it's fair to say I've been on a bit of a journey myself, personally and professionally here at Vodafone, with one of the most exciting parts of my job now being able to help find ways to allow teams to really fuel themselves, drive the company forward in ways I probably wouldn't have even dreamed of myself.

My role now is one where I'm constantly learning about new ways of working and how to improve. And for me, that really is the best place to be. And so I'll hand over to Sabina to say hi.

Sabina Kamber Salamanca

Hi. Thanks, Ben.

It's an honor to be here and to have this great opportunity to talk to you about driving cultural revolution via OKRs in Vodafone. But before we do that, I am one of the agile lead coaches in Vodafone within digital engineering area. And let me tell you a little bit why I actually joined Vodafone. This was about two years ago, in April 2019. One of the promises for Vodafone was "Future is exciting." And even though we all entered, sadly, a global pandemic with COVID having hit the world last year, more than ever at that time, I actually felt the mission of Vodafone, what it stands for, which is connecting the world for a better future. I felt that kind of connectivity and keeping everybody going.

And now where it's going on next in terms of what's dear to my heart, "Together we can," it's something that we really believe within digital engineering in Vodafone. And one of the other reasons why I joined was I wanted to work for an inspirational leader, especially somebody whose passion and drive is empowering his or her own people, and that's Ben Connolly here. So that's why it's an honor to be here together with Ben to tell you our story.

On that note, I'm going to hand over to Ben, who's going to talk about Vodafone's ambitions and what the future holds for us.

Ben Connolly

Yeah. Thanks, Sabina.

Right. So I'll give an idea of where we're going, so you can see why some of the steps that we're taking are so important to us, and we believe in them so much. Like I mentioned, our journey really can be summarized as one where we'll become a technology business first and foremost. One that happens to be in the communications industry rather than one that's defined by that. We call that being a tech comms company, but you get our meaning.

For us, that means putting our customer experience first, and a digital experience at that. Changing how we serve our customers and interacting with them on their terms, really, rather than on ours. It also means really genuinely becoming a product-led company, really focused on the value we're adding, moving to a real persistent focus on those products rather than more of a transient business-case-by-business-case model. And fundamental to that is becoming a software engineering business at our core, really.

Historically, like all telcos, we focused on our network first and foremost, but we're now full steam ahead, really, on transforming that perspective with our networks and the products and services that we offer to support that being driven from a software and technology-first angle.

It's a really exciting and super ambitious journey. One that's touching, probably influencing every single corner of the company currently. We've come a long way already. And we've learned a heck of a lot as well, including, I'd say, a lot about ourselves in the process. Not least about how to affect change in a company like ours, which can often seem easy, but in practice has a number of hurdles, any one of which can limit or even prevent sometimes success happening altogether.

And one of the key things personally has been, for me, I think, is to recognize that this isn't a single big transformation. It's more likely a series of probably thousands of micro-transformations. Small steps, minor victories that culminate together to affect real change organizationally and culturally. So the key really has been how to unlock those, and how to ensure that when we do, they're all targeted towards the same outcomes that we're chasing. And that is what we're going to talk about today.

So as we can see, just for a bit of added context really, you can see here that our focus on software engineering as a capability within Vodafone has really started the motor a few years ago. It's fair to say that proportionally across all of the 26 markets in Vodafone, we had very few software engineering roles delivering IT solutions. When it came to the IT side of the business, in fact, we'd been used to more of a delivery culture, I'd say, where our people are there to drive the technical direction and to protect Vodafone's interests, but not necessarily to be hands-on with our own proprietary systems, building them from the ground up.

That's changing quickly now, as you can see, with a really ambitious recruitment drive worldwide, and a really great opportunity for our own people to upskill into new areas as well, which is happening across the organization now. Some fantastic examples of people moving roles and changing their focus for their careers. Within digital engineering in the UK, for example, we've gone from around six to around nearly 200 roles in engineering in the last two and a half years, with lots more to come.

And we've changed the way we work with our partners as well to instead now augment, I'd say, our own capacity for engineering, rather than hand out work packages and wait for them to be delivered back to us. So across the globe, we're scaling out our engineering practice, as you can see. We expect that in the coming years, we'll have around 40% of Vodafone's people in purely software engineering roles, which for us is an absolutely huge shift.

And actually, one of the biggest shifts of all is not the numbers, but of course, what that means for us culturally. Of course, our real culture is our people. And so with our culture almost organically changing around us with all of these new colleagues, as we grow with new skills, with new preferences, with new ambitions of our teams and our people, we really recognize that our ways of working or the ways of empowering teams really needed to change in order to connect to those people better as well.

And these things are obviously important in any team. But especially with our new expectations, our new ambitions, we couldn't anymore work in a way that packages up work and dishes it out to a team, hands it down to a team. If we want real value, we couldn't really anymore pretend to know exactly what the precise solution is going to be. We have to iterate, we have to experiment to get there. We couldn't anymore expect to motivate ourselves without being connected to the outcomes and without being connected to the value that we create. And so we really started to explore new opportunities and new ways of working that will enable that and unleash and unlock that potential that we know we had. And that's when we started with OKRs.

So why OKRs? So just to say, we'd made lots of improvements, even had a framework for continuous improvement. And we were driving a lot of great change and really accelerating at pace in a number of different areas. Although we'd seen in many ways we'd begun to plateau in terms of our maturity, and we started really understanding and exploring why that might be, and what we could do to enable it. At some points, we recognized that our ways of working were still very much married to our old delivery outsourced model. We needed to find a way to really motivate, to drive from the ground up, our ambitions and our cultures.

There was quite a few ways that manifested itself as well. For example, we had over 100 KPIs at some points. And of course, with KPIs comes a need to hit those KPIs, a fear of missing those KPIs. And of course, so we do then focus on hitting those KPIs. In fact, sometimes at the expense of delivering value to the customers or to the business, and at the expense of driving ourselves to improve.

And so with some of these challenges now ahead of us, things like, as it says, these KPIs being gamed or being focused on too aggressively, a lack of desire and necessary behavioral change. We were trying really to change our ways of working, our principles of values and behaviors. But again, top-down, we were finding that this wasn't working. We were reporting on initiatives all the time. We were doing lots of great work. And in fact, we were improving, but not at the pace that we needed to and not in ways that were sustainable. We certainly weren't adding as much value as we'd hoped. And most importantly, our teams were feeling less and less engaged. Although they were marching on and delivering, they were feeling disempowered and certainly not connected to the value that they were adding back to Vodafone as an organization.

And so there is where we were at the time, and Sabina now is going to walk us through how together we rose to meet this challenge.

Sabina Kamber Salamanca

Thanks, Ben. So before I share the story about OKRs, I just would like to say continuous improvement is part of the DNA of digital engineering. And it's on daily basis something that we discuss, so always improving.

But then, as Ben explained, for these reasons that you see here, we wanted to up our game and how do we turn ourselves around, turn that empowerment dial, and how do we actually even begin to see what outcomes are we after? What is the value gain? How do we start to turn around even the mindset towards that way? That's when the actual get-together said, "How about if we trial a goal type of framework that unifies us all to a common purpose and turns the empowerment?"

But it cannot just be anything. We wanted to improve our culture, really wanted the culture of psychological safety, of experimentation and learning. Not fearing failure, but actually embracing it as a learning journey onto, towards the success. And that's how we said to ourselves, "Why don't we trial OKRs?" Because psychological safety is one of the fortes of OKRs.

So then the question was, through these experiments, the big hypothesis that was always in the back of our minds, when do we actually see meaningful, valuable, and really importantly, long-lasting changes? And what changes? The changes we were after is more than anything, is in the behavior and culture. Process and tools matter, and we were after that, too. But it's that kind of mindset change, the cultural change that we wanted to help us then collectively go towards something bigger.

And this is where the story begins in one of the very first program increments, and it focused around how do we rise to the challenge of turning around these problems that we were seeing of releasing to production? We were faced with extremely large monolithic releases, I'd like to call them beasts, at the time. On average, more than 25 services packaged up in one go. Often they would be prone to error or would naturally cause delay. And historically, and we're talking here just on average, so you can imagine it would've been even bigger at any point in time for a release, 30-day post-dev completion to actually release to live in front of a customer.

And then the sweating in the room of more than 20, 30 people, and then others dialed in hoping, praying that the release goes well. Or if it doesn't, then hours of debugging, making sure that we roll back, then we can then roll forward, and it was very, very difficult. Therefore, naturally, to us it was a clear message. It's not scalable, not sustainable. And this is where the experiment with the OKR comes in.

One of the leaders in Ben Connolly's team actually came in the program increment 15, mine starts in October 2019, stands up in front of everybody and says, "We're going to do an experiment. We're going to organize ourselves around these problem statements, how to resolve them together. I would like us to hold on onto the bigger mission that we're after." And that's the quote that you see here: every release is an opportunity to stop theorizing what we believe customers want, and actually put these hypotheses to test and get the product, get the service, get the stuff in their hands to validate.

So what we're going to trial now to see how we can get towards that overall mission, we're going to have a goal, and this goal is every OKR, I apologize, every team must release to production independently at least once. So that's the objective and a key result rolled into one.

And then before I tell you the story about the learnings that we experienced along the way, I'm going to tell you about the second OKR, where we upped the game and said each person on each team should lead an independent release at least once. These were the two experiments across two PIs.

So even though later on I will be talking about amalgamation of learnings that we've got from all these experiments, I'm going to actually surface two really pertinent to this particular drive, or we were after in terms of independent releases and what we observed.

The first one was in our teams, the mindset change starts to happen, and this is what we really cared about. And the shift in the mindset was along the lines of, "I've got this user story, I've got this bug fix or feature. Which release is it going into?" That means and tells us, before the OKR happened, I'm passing the bucket to somebody else. I'm giving the responsibility to another team to release my stuff into production in front of customer.

Mindset shift happens during these OKRs to this kind of thinking. "I've got this bug fix. I've got this user story or feature. When can I get it in front of a customer? I'm responsible. I want to get it out to live." That's huge. That mindset shift then starts to raise the awareness in our teams as well, to start to think outside of the team boxes, their own, let's say, team land and a bigger land of teams that work together. Because if I get this part of a user story working, but it doesn't join properly to make an end-to-end journey, let's say, work or breaks one part of a journey, then I will not have succeeded. So the awareness of dependencies of services and end-to-end journeys starts to happen.

And there are other lessons which I will share later on. But the results that we experienced, the key results, were after the two trials, we saw more than 75% of the teams achieving the key result following the trials. Now, this is actually a status quo for ourselves today. Every single team, in fact, 100% of them all release to production independently. So no more sweating buckets, sitting in a big room, hundreds of people and big releases in a production-like environment, and we flip from one to another and hope and pray works. This is now a new way, and it's been also given us some tremendous outcomes that even beyond our expectations.

The teams started to feel empowered, excited, but that was really important. That's what we were after. We mentioned that in the previous part. The throughput begins to skyrocket. It goes from these big monolithic releases before the OKR, which were on average less than a handful, or less than 10, to actually hundreds per quarter. And the last record showed us more than 500 in our last quarter. Cycle times really substantially reduced. And really importantly, the stakeholders start to get happier. The trust improves. We are shipping stuff in front of customers earlier. We can get even some features out to the door earlier because of these independent releases going out to the door rather than waiting for these big packaged things all to work together.

So on that note, we decide let's continue further. Let's see what more we can learn from these experiments. I mentioned that we've already done independent releases to production. Those were our first and second trials. We continued a little bit along that path, and then we said to ourself, this was organic by the way, thinking, "What's the next challenge that we need to rise to?" And in practical terms, it was about how do we further improve our relationship with the business? How does that trust and collaboration grow? And that's when we went after sprint predictability, as well as experimentation and quality.

In terms of sprint predictability, we wanted to try and raise the bar to deliver on our commitments, but on small timeframes, and reduce the dependency chain between the teams if one delays to another, so we can actually, as much as possible, ship things on time. But the beauty of this, as we went along the way and improved the sprint predictability from something like before the OKR, around 50% predictable sprints, to 75%, to more than 95%, we actually also allowed room for change, which means we didn't work on contract basis with the business stakeholders. It was a more collaborative negotiation, and if we needed to maneuver within the sprint and cope with change, we did. So that was really important for us, and that's where even further the empowerment dial starts to shift.

Quality was not the one we were particularly happy with in terms of results. But OKRs, as I mentioned before, psychological safety and not fearing failure, the failures were fundamental stepping stones for us for the learnings what we needed to do next.

And that's when we did the next experiment, and I'm going to talk about it because it becomes a big part of our drive where we're going on next in the financial year. We upped our game and we said, "Okay. Let's try, and with our teams, see if we can introduce the trial that drives us towards first strides, towards inner sourcing, collaborative engineering, really turning the dial on quality, and kind of unleashing the potential of driving scale, Vodafone global company."

So this is the last trial. We have seen something around lots of experimentation starts to happen, and teams are starting to get excited about this particular... They're starting to drive and sense of meaningfulness, that cultural aspect starts to turn on within the engineering.

And after five trials worth of these kind of experiments, we now have a kind of a land where we are going on next into in our digital engineering world, as well as I'm going to talk about it globally next, we're upping our games, and we have end-to-end OKRs as our navigational systems that tells us how we are doing towards the North Star we're going towards. We still have KPIs, they're important, but we don't have 100, we have just five, and they are key indicators that are telling us, is our navigational system working? Do we need to adjust? Is the OKR potentially wrong? Or do we need to change the initiatives underneath that? Or is there an impediment that we need to really tackle?

As we go along this kind of scaling, we are not forgetting our friends across the entire Vodafone and globe. We're sharing these lessons. Sharing the journey. Sharing also where the pain was experienced, the failure, what did we learn from it? As we go towards eventually using this way of working as actual navigational system for the entire Vodafone towards its very exciting ambitions that Ben mentioned earlier.

Now, in terms of the actual summary of the lessons that we've experienced, they were quite numerous. But I will just extract one of the big key overarching ones. OKRs definitely, we believe, drive cultural change. We have seen that kind of mindset shift, empowerment dial. But not only just empowerment, it's not like just, oh, cowboy style land. Let's just do everything and anything, see what works. We also went for alignment, so kind of a concept of aligned autonomy. So we keep our eyes together on what our North Star is, whilst we turn the empowerment. We tap into the ground, we drive the change, we go for across several layers, helping us to resolve the problems we wanted to resolve or create new opportunities.

The real important bit here is the creation of the psychological safety zone. The leadership style that drives it is kind of agile, lean, servant-type leadership of their people, and setting the tone around not to be fearing failure. Failure is actually a good thing, as long as we learn from it, and we implement on our journey together those lessons, we carry on. And this is what kind of really for us unleashes the willingness to even take the first stride, and not just do it in hackathon land, but actually all the way through, every quarter after quarter, challenge the status quo. Can we do it better, and feel safe in that experimentation land?

The next lesson is the OKR must be meaningful. Not every single one was, and this is what we learned. The first most meaningful one was the actual independent releases. Sprint predictability was also a very good one for us. We understood the trust comes from that kind of predictable interaction with the business on a smaller scale, growing trust. Some of the way we positioned the quality OKR was not maybe necessarily meaningful at the time to the teams, but we definitely went for it in terms of the inner sourcing stride. We're seeing already the beginnings of some greatness, and we are onto something here internally.

And celebration part is really important. There was almost like team comrades, a little bit of a, "We show off how much we've achieved," especially when it came to the independent releases and celebrating and keeping that competitive spirit going in a healthy manner.

The next thing that we also experienced, there were some failures along the way as we saw the OKRs as maybe not being so clear about the measure. The first one was a very easy one. Independent releases, either all 100% of the teams achieved the independent release or not. So it was pretty clear to say how much of the percent of the way we were towards that key result. Sprint predictability wasn't that clear. Neither was the quality one. But we learned from it. We adapted it, and now when we come and share and collaborate around these OKRs, at the forefront of our thinking is actually, do we even have the measures? Can we get these measures? Are we clear on them in terms of how are we going to prove that we're actually achieving the result we're after?

And the final one, but not the least important, really key to us, we take impediments seriously. We act on them. We surface them, and we address them. And not just within the team level, beyond the teams in a larger scale, so that we can together on this journey overcome these challenges and really feel like we're touching and we can achieve our North Star.

On that note, this is the summary of our OKR journey, and I'm going to hand over to Ben.

Ben Connolly

Ben, you're on mute.

This is the phrase of 2020.

Classic.

Classic. It had to happen. Classic.

Yeah. Thanks very much, Sabina, and thanks, everybody, for the time. Really appreciate the chance to walk you through our story, and really very much looking forward to some of the other sessions across the event over these days. And especially those that are showing how technology and commercial teams are working together end to end, really trying to change the ways of working, the relations, and the methods in order to drive value end to end as quickly as possible.

So I know that there are a number of sessions on that already that I'm keen to be dialing into. But of course, I'm also looking forward to the Q&A, and learning as much as I possibly can while we're here from all of you as well. So once again, thank you very much, and I'll see you soon.

Sabina Kamber Salamanca

Thanks very much from me, too. Looking forward to see everybody at the Q&A.