Taming the Complexity – Accelerating Value Delivery

Welcome, everyone, and thank you for joining me today. I'm Rob Howse, and I'm going to talk to you about how we've been trying to tame the complexity of our organization.

Before we get into that, let me give you just a little bit of my background. I'm the chief operating officer of Leeds Building Society and one of the executive directors on the board there. I've been at Leeds for over two and a half years now. Before that, I spent a decade in a variety of senior technology and transformation roles at Lloyds Banking Group and the Royal Bank of Scotland. Where my professional focus is, where I'm really excited, is that over the last 10 years has not just been on changing banks, but changing how we change banks, and in the process, hopefully changing the banking industry a little bit for the better, too.

So why should you care about this talk? Well, when I speak to leaders who are looking to change the way they deliver transformation in their organization, I find a lot of them are like this. They've read all the books. They've maybe got the latest version of The DevOps Handbook. They may have watched the Henrik Kniberg videos. They're enthusiastic to start. Then when they look at the case studies, they can't see their organizations in those case studies. They maybe don't have the scale or the technical depth of some of those large poster children of the agile world, the Capital Ones, and they certainly don't look like a software-heavy startup. They sit maybe somewhere in the middle. They're large enough to have a huge amount of complexity and variety in what they're trying to do, but they just don't have the team size to be able to apply maybe some of the classic techniques of DevOps. If this is you, if this describes maybe your organization, then I hope our recent journey at Leeds Building Society could help you.

Let me introduce you to Leeds Building Society. We're one of the largest of the UK's building societies, which for those of you who haven't heard of a building society, think of us a bit like a bank, but owned by our customers, our members, as we call them. In our case, 800,000 of them across the whole of the UK. Our purpose in serving them is to put home ownership within reach of more people, generation after generation. It's something that we've been doing for over 100, well, nearly 150 years now, which means that we're entirely focused on mortgages and savings, and we look after over £20 billion worth of money.

As a business, we're financially successful. We're highly profitable, with market-leading cost and capital ratios. Most importantly, we're proud of what we offer our members. We regularly win awards for our mortgages, and we're also proud of our internal culture. We were absolutely delighted that earlier this year, we were crowned the best financial services company to work for in the UK.

You may be wondering, if the business is so successful, where is the challenge? It is a great question, because back in 2019 many of those things were still true. But strategically, we faced a number of issues. Margins in our core mortgage market were compressing quickly, threatening our profitability. We were also faced with increasing unhappiness from our mortgage brokers with our systems. They just didn't like them. They were old. They were clunky. These independent businesses, these independent brokers, sell the vast majority of our mortgages for us. On the savings side, our digital offering was woeful. Finally, if you looked at our technology, our core systems, our infrastructure, it was nowhere near as resilient or fit for the future as we needed it to be.

A transformation of the business, it was clear, needed to happen if we were going to sustain our success, and it was going to need to be a technology-heavy transformation. Therein lay the problem.

While Leeds Building Society was good at many things, we hadn't been very good at delivering technology-based change. Back in 2019, a portfolio status report would look a lot like a rail departure board in the middle of a rail strike. Everything seemed to take a long time, or was canceled or delayed. Small changes, which could be as simple as a field change on a core system, took around six months. There was a lot of activity, but not much delivery, and finding a successful project was a little like trying to find a ticket to the World Cup final. You knew there was one out there, but you really struggled to get hold of it.

When you look at the root causes, I'm sure they're familiar to many of you who've been on your own DevOps journey. There was largely one delivery method, and that was a heavily gated waterfall one. The organization seemed to like turning everything into large projects. The delivery teams were functionally siloed: a team of business analysts, a team of software engineers, a team of testers, a vendor team. Work moved from one silo to the next, coordinated by project managers. We had more project managers than we had testers.

Then there was the fact that no one seemed to say no. Almost every business case got approved, and the business case listed in great detail all the minutiae of the resources that they needed: 0.2 of an FTE of this skill and 0.3 of an FTE of that skill. As every project got approved and rushed to start, they went off to find all their 0.2 of an FTE of this and that. As you could imagine, context switching was rife across the organization.

In short, this was an organization that was crying out for a large dose of the DevOps medicine. But before we could take that medicine, the messy reality of our business hit us.

This wasn't an organization with a lot of similar in-house software development where we'd be able to start rolling out a standard Scrum approach or thinking how we could maybe apply SAFe across the whole organization. We had a huge variety in the nature of the work. From a system perspective, we had almost every variety of model. Yes, we had some in-house developed bespoke systems. We also had everything else: bespoke developed outsource, software as a service, packaged software but hosted on-premise. Then we had all the normal infrastructure delivery, ranging from colleague desktops to networks and servers.

In terms of delivery, while we would have liked to just do lots of small initiatives, it was clear that we weren't going to be able to avoid doing some pretty big new stuff: big new platforms or large infrastructure work, at least not in the short term.

That sort of complexity is not untypical of a large organization. We had plenty of it in the two large banks that I'd previously worked at. But at Leeds, we simply didn't have the same team size or bench. If we were going to start putting in place a DevOps operating model, we were going to have to find a different way of doing it to the standard patterns. Something that could cope with the variety that we had in the nature of the work, but could do it in, you might say, a lean way.

We started by splitting the organization into what you might call value streams. We called them delivery streams. We had three aligned to the different parts of the business: the mortgage business, the savings business, and the third one picking up the internal functions like HR and finance, as well as colleague IT and infrastructure. Into these, we put all of our change colleagues and all of our IT colleagues and all of our systems, doing our best to minimize the dependencies between the delivery streams.

We explained to everyone that the old world was a bit like trying to drive through Leeds city center on a wet winter's day in rush hour. What we were trying to do with our delivery streams was put three brand-new motorways through the city center so that no one was going to get delayed by crosstown traffic.

Finally, we gave each of these delivery streams two leaders. One was a transformation lead, analogous maybe to a product owner, and one a technology lead. Both of them had end-to-end accountability for everything that happened in the delivery stream. Then we agreed with our executive committee a set of objectives and key results for each delivery stream. We tried to link the work that they were going to do to our company strategy, quite tightly link that. What we said to those two leaders in each delivery stream was, "Look, these are the objectives. This is the outcomes we want you to deliver. Go and develop and implement a range of initiatives that will achieve those outcomes. Oh, and by the way, here's your budget, and you've only got the resource in the stream."

This was pretty effective at stabilizing the organization, stabilizing delivery, and actually helped significantly improve it. But it didn't do a huge amount for actually the flow of work. So we turned to the problem of variety, the variety of the work that we had to do.

We started by asking what were the really fundamental dimensions of that variety that actually drove how we needed to approach it. We realized that it came down for us to two. Firstly, could the work be broken down into multiple releases? We knew we wanted to get to frequent value release, but given the constraints of our architecture and the nature of some of the work, for example putting in a new data center, there was going to be some work that it just wasn't possible anytime soon. Practically, we were going to have to allow for that spread of work.

Secondly, the second dimension we realized was how much coordination was required. In an ideal world, our teams would be entirely cross-functional and self-contained with no dependencies on anyone else. While we could see our way to that for some of the work, we knew that others were going to require coordination across multiple vendors, internal teams, high level of coordination. An example might be the integration of our new software-as-a-service mortgage origination platform.

With those two dimensions, we found that we needed roughly two types of team and three types of delivery approach to manage all the variety of work we had. The agile teams we set up as cross-functional delivery teams, while the program teams contained the coordination, control, and design to manage the work of other teams and suppliers. On the delivery methods, one of the aims of those three delivery methods was to optimize the amount of governance and oversight needed to the level of risk. If you were going to be in an agile team with a constrained budget and a fixed team that was delivering frequently, then we figured that you weren't going to need that much oversight. But if you were running a big program and you were going to be a year away from delivering any value, then you could quite easily see a way to wasting millions of pounds. So we figured we needed a lot greater oversight of those, and the delivery methods try to optimize for that.

With these two types of team and these three delivery approaches, they allowed us just enough standardization to be able to start implementing a new operating model, while giving us enough flexibility to cope with the variety of work that we had to deliver.

Then we turned to how we organized inside our delivery streams. Here, we put in place what we call product streams. If the delivery streams are the motorways of change, think of these product streams as the lanes on that motorway. Let me illustrate it with our mortgage delivery stream. Where the delivery streams are aligned to the different parts of the business, the product streams are aligned to the IT platforms and the main vendors within the delivery stream.

In mortgages, we have some internally developed bespoke applications, mostly in the mortgage servicing area, and the platform teams that support those. We have our third-party mortgage origination system, and a different set of skills are needed to work with that vendor and manage the integrations. Then we have a big managed service provider that manages our core banking platform for us. Again, that needs to be managed in a different way.

Within these are a number of delivery teams. These teams are made up of the agile teams and the program teams that we talked about on the previous slide. The teams are persistent, and the skills in the agile team vary by the nature of the work. The internal dev teams have a lot of developers. The one in third-party delivery has none, but has quality engineers and business analysts and a delivery manager or two. We seek to flow work into these teams, even the program teams. It's just that for those program teams, the work tends to come in bigger chunks with lots of time between those chunks. But the same team persistency principle applies. We're not going to break up a team and reform it for every project. Projects come to them.

Finally, to complete the picture, every delivery stream contains what we call a shaping team. This is to help the delivery stream transformation lead fulfill their product owner responsibilities. They are there to take the objectives and key results, translate them into deliverable initiatives, and then flow those initiatives into the appropriate product stream.

The final part of our journey so far was when we started to push hard to move to more incremental delivery, essentially trying to get some degree of flow happening with all the benefits of earlier value delivery, lower delivery risk, and faster feedback loops.

The first thing we did, and this may sound really obvious, is that we just decided to do it. In many cases, there wasn't an architectural constraint or a technical constraint or a capability constraint. It was simply that no one had thought to do it that way before. The best example here was our data center program. We were moving to two new data centers, and having built out the target environment, we could have spent ages then planning and rehearsing for two big moves into there, where we moved everything over a weekend. Or we could do what we did, which was choose to do it system by system, 178 in total, in an incremental way.

That's what we did. Each individual move was much lower risk. Every one we did made our IT a bit more resilient. We got value earlier, and the team got better and better with each move. The top picture on the screen shows the team flushed with success, and the bottom one shows me and our chief executive helping, and I use the term very loosely, do the final move.

The second thing we did was we pushed hard at automation. We started automating tests, and to some extent release. We started with our new mortgage origination platform and built out a fully automated regression test suite and set of tooling. Now we're doing the same in digital. If you went back to 2019, the typical approach then around testing had been you'd see lots of three-month-long manual regression test phases in the project. So it was clear there was huge opportunity here to improve the pace of delivery.

Thirdly, we've been working hard to decouple our architecture, helping to break up the dependencies between teams. Our core banking platform now has a ring of modern APIs that other systems can interface with, rather than the messy point-to-point integrations of the past, which has really helped remove the dependencies between a number of the delivery streams. Our digital savings platform are now building out on Azure, helping allow us to have multiple independent releases for all the teams working on it.

So what difference has this made? Well, we still have a long way to go. Our maturity levels are still pretty low, but nevertheless, the progress has been far from shabby. If we start with release frequency as one metric, this is where we were back in 2019, and this is where we've got to. We're more than an order of magnitude faster, and more importantly is the business impact that those faster releases have given us. Our ability to iterate and release and adapt has really helped us. This is what it's done.

I mentioned the data center program. That has delivered a huge improvement in infrastructure resilience for us. What has also happened, what the incremental approach also happened, was a big reduction in risk. That meant that the whole move, the whole program, we managed to do with no business disruption in getting there.

Our digital savings have now released their third end-to-end customer journey and have been iterating those journeys. They've been getting better and better, and the changes that they've put in have allowed us to reduce the time for customers to register online by 30%. The customers are a lot happier now with it. Dropout rates are down. Failure demand into the contact center is also down.

Finally, mortgages, where I think the most dramatic impact has happened. Having put in our new mortgage origination system over 18 months ago, we've been relentlessly improving it with release after release, making it easier for our brokers to use, adding more integration into their own systems, automating more of the end-to-end customer journey. The result is that those brokers now love it. For the simpler mortgages, we have absolutely blown away the speed records. It used to take typically 12, maybe 15 days or so from someone making an application for a mortgage until we could make a formal mortgage offer to them. We're now doing it for some of those mortgages in less than a minute.

We believe we now have best-in-class mortgage origination capability. What's more, the mortgage market over the last 18 months has been pretty unusual, and there's been an opportunity to write a lot of very profitable business, but only if you can move at speed and can scale to do so. The ability to release frequently has allowed us to make a lot of changes to take on business without taking on more people. We didn't expect this two years ago. We never expected the market to play out like it did, and we never would have planned for it. But that flexibility and that new business has been a major driver in us being able to grow the business by 10% and doubling profits this year.

So what have we learned from the last two years? Let's start with principles and pragmatism. We started out with the idea that we'd be able to take some standard patterns, some standard DevOps patterns, and apply them, albeit with the usual thoughtful change management. However, we found it simply wasn't going to work universally for us, so we had to be pragmatic. We could use some of those patterns in some places, apply some standardization, but what mattered more were principles. Smaller increments were better than larger increments. It didn't matter that we weren't going to get to a release a day. Moving from 18-month increments to three-month increments was still hugely helpful for us. More cross-functional teams are still helpful even if you couldn't get to fully cross-functional teams. So principles and pragmatism mattered much more than the standard patterns.

Next, business alignment and end-to-end accountability. Moving to those three delivery streams has been far more powerful in improving nearly every aspect of delivery than we expected. If you can get to a model where delivery streams broadly align with your business, with leaders clearly accountable end to end, and have broadly independent goals and broadly independent delivery teams, then it is incredibly powerful. Making the problem a third of the size seems to have led to more than a three-times reduction in complexity and more than a three-times improvement in performance. Essentially, this is a problem that doesn't seem to scale linearly.

Then we come on to good OKRs. Good objectives and key results were really helpful in driving that business alignment, really helpful in driving a top-of-house prioritization. But actually writing them proved quite hard. In the first year, we had about eight of them for each of the delivery streams, which was far too many. This year, we've managed to get down to three or four for each delivery stream. But getting people to move away from setting an objective like implement a new mortgage origination platform to one that was much more business outcome-focused, that actually proved pretty hard.

Which brings me on to the next learning. This is not particularly surprising, but mindset change was pretty difficult for a large minority of the team. Thinking about business outcomes rather than deliverables, or thinking about flowing small increments of work through a persistent team rather than getting a team together to deliver a project, just proved really conceptually difficult actually for some people, which really surprised me.

But what did help was COVID. When COVID hit, we had to deliver some change very quickly. Everyone was ready to throw out the rule book. After all, it was a crisis. One particular initiative to put in place mortgage payment holidays provided a fantastic case study of a true agile approach with a single cross-functional ring-fenced team. Once everyone had seen it and seen how it worked and thought that the outcome was fantastic, then we were able to use that as a shorthand for saying all our operating model changes are trying to do is simply roll out that approach everywhere.

So that's us. We've still got a lot to do. We're investing now heavily in capability building. Now we've returned to our fantastic new head office, we're working hard on the culture. We still have a lot of work to do with our architecture, but we're all pretty excited about where we go next.

I hope you found this helpful, and hope you find it helpful for your own journey. I'd be very happy to answer any of your questions on the speaker Slack channel. Thanks for listening.