Julia Bellis

Hello, everybody. I'm Julia Bellis. I'm an engagement manager with Equal Experts, and I'm reliably informed that American for engagement manager is director of product delivery.

I have to admit upfront, I am not going to talk about AI today. I could talk about AI because we are running some really cool AI experiments, but actually I want to focus on the human behaviors that took us to a successful finish of a large-scale government digital transformation.

I was supposed to have a co-presenter up on stage with me today, but she couldn't make it, unfortunately. And that is why on the bottom right of these slides, you can see it says, I don't know if you can read that small, actually. It says, "Equal Experts in partnership with the UK government."

And while I'm up here on stage, I'm not going to name the government department that we were working with. But I will say that our teams built a system that processes applications for an important government document, something like a work permit.

And as that first slide indicated, which I can't get back to now, I'm going to talk about what happened right at the end and the lessons that we learned after we'd crossed the finish line.

But before I do that, I want to switch over to my interactive deck here and ask you some questions so that I can find out more about who I'm speaking to.

So I'd like to invite you to join this deck with your mobile devices using the QR code and just answer these questions.

Oh no, that doesn't work. I need to do it over here.

Okay. So first of all, have you worked on a digital transformation program?

So most people have. That's good to know. It's good to know I'm talking to the right people.

Next question: can you describe in three words the challenges you'd expect at the end of a transformation program? And this is just to check that I'm going to talk about the right things.

Whoever said "turn off legacy" is spot on. I am going to talk about that.

Yeah, I'm going to talk about people. I think I've given that away already.

I'm going to talk about culture.

It's really nice seeing those big words in the middle: change, adoption, resistance, mindset.

I think I can take away from this that you've got a good idea of some of the challenges that we confronted at the end of our digital transformation.

And I have one more question, which you might find more difficult. I'd like to invite you to have a guess what percentage of government digital transformation programs succeed. And you can go from none at all to all of them.

A nice range. You are a pessimistic crowd, it looks like.

Oh right, it's going up. Okay, so I'm going to leave that there at just under 22%, and I'm going to reveal the answer.

In the US, you were bang on here. It's between 20% and 25%, and that depends a bit on where you get your data.

And I just want to finish off with this quote that I found from Boston Consulting Group: "Almost all large transformation projects face unforeseen implementation difficulties." And I found that quote quite cheering because it made me feel like I was in good company.

Okay, so thank you for telling me about your transformation experiences. I'm going to go back to talking about mine now.

First of all, I want to talk about the last mile.

Everyone's a bit tired. Everyone's laser-focused on the finish line. Tensions are high. And under these circumstances, it's quite tempting to put your head down and just plod on until you get to the end.

That might work in a real marathon. It does not work in a digital transformation marathon. In a digital transformation marathon, right up to the finish line, it's all about creative problem solving.

And I want to tell you a story that I hope will help illustrate that. Like all the best stories, it's about a legacy platform. Specifically, it's about applications that were stuck in our legacy platform.

So this wasn't a surprise. We had known we were going to have to deal with this before we got to the end of our digital transformation. But when it was just a speck on the horizon, it was easy for the optimists among us, of which I am one, to convince ourselves that it wasn't really a big problem.

And I'll explain why that is. The average lifespan of an application in our system was less than a week. For most applications, it was a lot less than a week.

So given that, it's easy to believe that if you've got no new applications going into legacy, a short period of dual running, say one or two months, would be enough for them to drain down naturally. That sounds like a reasonable assumption, but like so many reasonable-sounding assumptions, it's completely wrong.

And there's a little sum up here. That 0.01% represents the tiny amount of applications that were too complicated to process quickly and that did hang around in the system. Seven million is the number of applications a year that we had to process. We actually processed closer to eight towards the end of the program. And the legacy system had been live for many years.

So clearly, that number does not equal zero.

And as I'm sure everyone in this room is aware, the flaw in that reasonable-sounding assumption is that it was based on averages, and averages do not take edge cases into account.

So we had options for how we'd solve this problem. We could ask engineers to write code, but these were the most complicated applications. It was going to be complex code that we'd run once and throw away. It didn't seem very efficient.

We could ask operations staff to migrate these applications manually. We certainly had the experience and the knowledge to do that. We did not have the time. If we'd gone down the manual route, we'd have risked our deadline.

So we realized we needed a solution that used two of my three favorite C-words of software development, and they are creativity and collaboration.

We got a team made up of some developers and some operational staff and asked them to work on this problem together. They could try things out, change course where necessary, and identify what was efficient to migrate with code and what it made more sense to migrate manually.

And that way they managed to solve the problem, drain down all of the applications so that that number was zero, without risking our deadline.

Okay, so I want to talk about our next challenge, which is burnout. And I'd like to ask you for a bit of a show of hands. Actually, put your hand up if, at the end of a difficult week at work, you've ever felt like this poor lady on the left hand of my slide.

Okay, a few of you. Fifty percent.

And now hands up if you've been asked to work a weekend in the last 12 months.

Yeah, a few, but not many, which makes me think perhaps I should come and get a job in America, actually.

And then last question. Hands up if after your weekend work you've bounded into the office on a Monday morning ready to solve problems creatively and collaborate with people who see the world differently to you.

Yeah. No one. Oh no, I think there might have been someone at the back. Well done. Respect.

And the message here is that burnout kills creativity.

As our digital transformation deadline approached, we got the feeling that we were running out of a precious resource, which is time. And so it was tempting to try and buy more time by asking people to work weekends and evenings.

But as we've just demonstrated, doing that risks another precious limited resource, which is creativity.

So we gave ourselves three rules about asking people to work overtime.

The first one was that it would be an ask and never a demand. And that had a really useful side effect. Because it was an ask and somebody was doing it almost voluntarily, we needed to have a clear story about the value that it would offer the program. It could be the opportunity to access resources that were in competition during the working week, or it could be the chance to get a job done undisturbed. But because it was always a request, we had to be really clear about what it was going to offer.

The second rule was that we would pay people quite generously for working overtime, which certainly helped get them to say yes. And it also had a useful side effect, which is it forced us to explore other options. We wanted to make sure that it was a real value-for-money solution.

And then the third rule was, if a team was going to be working overtime, we wanted to make sure that they would have everything available that they needed to get the job done. Weekends and evenings are precious times to recharge your batteries, spend time with your loved ones. There is nothing more frustrating than giving that up and then being unable to achieve your goal because you depend on someone else who's out there enjoying their Saturday.

So I can't claim that we never asked anybody to work any overtime, but we were very aware of the cost of it and the balance between buying back that time and spending our precious creativity budget.

The third thing that we found in the run-up to that finish line was that sometimes it's quite useful to bring in a third-party expert with an objective view.

So a digital transformation involves all parts of an organization. We collaborated very, very closely with operational staff, but they were not the only people affected. And every different group was subject to different pressures and different drivers that we as the digital teams could try to empathize with, but we wouldn't experience firsthand.

I've mentioned that with the deadline finish line looming, time felt like a precious resource. And under those circumstances, it's normal for different groups of people to have different opinions on what is a must-have for your transformation to be complete and what can safely be left until later.

And this is one of the joys of working for government, actually. Somebody could come in with a list of boxes that needed ticking, and once we ticked all the boxes, we could say, yes, we are done, and save time negotiating our way to that finish line with all of the different groups.

Okay, so now we've crossed the finish line. Our digital transformation is complete.

These people behind me all look quite serious, quite determined, quite focused, and I'd say they look in control of what they're doing. That is not a very accurate depiction of how we were feeling.

Now, a few decades ago, I ran the London Marathon, and I've got a photo of me crossing the finish line. I turned my house upside down looking for it to put it in this deck so I could show it to you today, but I couldn't find it.

What I did find is the T-shirt that I wore. So I thought I might attempt to recreate that photo, and I'll try not to bash my microphone.

So I was wearing this T-shirt. I had my hands in the air, wide-eyed, open mouth. And the reason I've done that is because what I was thinking when I crossed the finish line is, "Does this mean it's okay to stop running?"

And I think that's quite an accurate reflection of how some of our teams felt.

Okay. So the first challenge after we'd crossed that finish line is that we lost our North Star.

I don't think we knew how good we had it with this chart. And this chart represents numbers of new applications going into the legacy platform.

So we knew that if this number went down, that was evidence that we were doing the right thing. And I wrote down something that Gene said this morning. It was evidence that everyone was solving important problems all the time.

And we took this for granted, actually. It was really easy when somebody asked us to do a piece of work to think of this chart and ask the question, "Will doing this help us reduce the numbers of applications going into that legacy platform?" And if the answer was no, we could write it on a list to look at later and move on.

But then, sometime in December 2024, that number got down to zero and stayed at zero. We had lost that really useful prioritization question.

Now, I've called this a new North Star. This is not a North Star. I think this is more of a cluster of stars. So maybe we could call it a Southern Cross.

And this was a temporary set of metrics that we could focus on that would try to do the same job as that numbers of applications in the digital platform.

We knew we cared about the health of our teams and our processes, so we tracked DORA metrics.

We knew we wanted to spend money responsibly, so we looked at tracking cost per application. That was actually quite difficult to get hold of all of the data that we needed to do that well, so we used time taken to process an application as a useful proxy.

And then I talked about our great collaboration with ops. We didn't want to jeopardize all of the goodwill that we'd built up by ruining their user experience because we were focusing on time per application, so we tracked user experience as well.

And this gave us a sort of good enough focus to keep on after we'd finished our digital transformation, while we get everybody aligned around a new set of organizational priorities.

So I mentioned that great question: "Will this help us switch off legacy?" To quote the answer in my word cloud earlier.

We'd heard a lot of good ideas when the answer to that question was no. So we'd written them all down in a list, which became a bit of a Pandora's box.

And I think this definition, "a metaphor for something that brings about great trouble or misfortune, but also holds hope," is quite apt. And the box represents the curiosity and desire for knowledge that can lead to negative consequences and positive outcomes.

So throughout our digital transformation, we had developed this list, and it became a bit scary. It was very tempting not to look at it and to just throw it away and start from scratch.

And it's actually my colleague who's supposed to be up here speaking with me today, she said to me one morning, "Julia, we are not going to do that. We are going to go through that list, and what's more, we are going to do it in public."

And I was like, "What? Are you crazy?" But she wasn't crazy. She was absolutely right.

We didn't go through a list of 700 items in public. We did a bit of work beforehand to condense that list of 700 things to 50 problem statements. We had kind of 700 symptoms of 50 of the same problems.

And we went through those 50 problem statements in an all-day workshop where we invited all of our stakeholders. And we talked about them all. And we came out having agreed a rough priority order.

That is not something that we ever want to have to do again. But it was worth doing because it was evidence that we had been listening to all of the ideas that people brought to us. And when we said, "No, not yet," that's what we meant. No, not yet. And it was something that we were willing to go back and look at and evaluate later.

Okay. And now we get to my third favorite C-word of software development, which is celebrate.

I'm a fan of lots of small celebrations, but when we'd got to the successful end of a large-scale government digital transformation, we thought that was worth a big party. And here we are enjoying our big party.

We invited all of the people who had contributed to the program throughout the years, so it felt like a really nice reunion.

And it is worth pointing out that our celebrations did not revolve around alcohol. We always made sure we had other activities. Over the years, we did things like bowling, lawn bowls, shuffleboard, darts, so that everyone could get to know each other and have a good time outside work.

Okay. And then the next challenge is how to shift gears.

It was really interesting. What we had inadvertently done is trained everybody to be brilliant marathon runners with that laser focus on the deadline. And once we'd hit that deadline, it was as though we were asking our marathon runners, with their sore muscles and aching joints, to become really good at weightlifting.

And actually, when you're brilliant at something, it's very hard to switch and do something that you still need to learn all of the lessons at.

And one symptom of this is that we had trained everybody to seek quick fixes. When you've got the knowledge of an imminent deadline and a new problem arises, you are motivated to solve it as fast as possible.

And even after we'd crossed that finish line and the pressure of delivery had eased quite a lot, the pace did not change. People kept on delivering just as fast as before.

So we needed to be really intentional about stepping back and giving people permission to move away from that quick-fix mentality. It can get quite addictive because if you solve a problem quickly, you get that dopamine hit that makes you feel good.

So how did we reassess our focus?

We'd lost that great question: "Will this help us turn off the legacy system?" It didn't help us achieve our goals anymore. And under those circumstances, it was easy to slip into short-term thinking, which could lead to high levels of work in progress.

And in order to address that, we found this Ward Cunningham quote, which is actually about debt. And he says, "If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program does not contain any understanding and efforts to work on it take longer and longer."

And what he's saying here is, it's okay to build up debt in the service of a higher goal, but you must pay it back.

And at this point in the program, at the end, our understanding of the system was better than it had ever been when we'd written any of that code. So it felt really important and valuable to consolidate that understanding and at least make a plan to get that consolidated understanding reflected in our system.

We certainly didn't want another team to be replacing it in 10 years' time.

Okay, so I'm going to sum up with my three key learnings from our digital transformation program.

And the first one, and this is the most important one, is bring the whole organization with you.

We had started off collaborating really closely with operations. From the early days, we would have developers and ops people sitting together in a room processing live applications in our new system. And the developers could hear the feedback from the ops team and tweak it and update it and change it. And that way, we built relationships between people on the ground.

We also benefited from relationships between leadership in digital and in operations. And I think this fits quite nicely with the previous talk. We had a real sense of ownership. So they felt that they owned the digital transformation just as much as we did.

It wasn't something that we were doing to the organization. It was something that the whole organization was invested in.

Our next lesson is you don't have to keep on running. Once you've crossed the finish line, it's okay to allow yourselves a breather. And it doesn't happen accidentally. You need to be quite deliberate about the change in focus. You can't expect to keep going at the same pace. That is not sustainable.

And then finally, you have to keep the focus on creative problem solving.

For us, this was all about relationships and fostering relationships between not only members of our digital teams, but also between other teams across the organization.

And this is the slide where I'm supposed to talk about help that I would like. I mentioned that Southern Cross, that cluster of metrics that we used that were good enough for now. I would love to hear your stories of coming up with metrics frameworks that have helped you get direction and focus on solving a problem.

Thank you.