E02: – Mike Dargan, Group CIO at UBS discussed their 5 pillars to digital transformation & culture.

Yeah, so we introduced a framework for innovation or digital transformation, which are really the levers by which we achieve things, which is the ABCDE: A for automation, B for unbundling, C for cloud, D for data, and E for experience. So these are really the levers we pull to try and drive the transformation. It's also a good way for people to remember what we're doing and therefore get the right focus to each of the areas.

I think the first is, I've seen all of these are super linked, so you can only really do this if you've got a cloud strategy, because you can operate obviously in the hyperscale environment. Getting the data organized is important to drive the right experience, and AI and automation is one of the biggest. So we've been focused at first on robotics or robotic process automation and moving along the value chain to try and drive AI, which can come in many different forms. The first is doing it in a very structured way, almost like an if-then type way, and then moving into machine learning, which can be NLP, natural language processing, and chatbots. So the first area of focus is really in the non-client-facing space: what we're doing in HR to have a chatbot, or what we're doing in technology to have what we call a smart bot, which helps everyone when they have a technology issue. So they can communicate live if they have an issue, and the computer itself will resolve issues and drive things in that way.

Yeah, it's a really important point. So UBS has a long heritage. We've obviously got a very big team in technology and spend a lot of money. You do have fintechs who are in a specific area and therefore slightly more nimble. What we're focused on as well is how we drive and be agile in the technology space. And I think agile is one of the most loaded and almost worst words that's used, and it means so many things to so many people. But we almost need to reset and think about it slightly differently. So what is agile for us? We want to try and get requirements into production as quickly and in as good quality as possible. So we kicked off last year a process to try and drive up our automated testing. We're now at sort of 60-70% up from 20-30%. We also kicked off a process to have the right tool chain process, so that we have three dev tool chains so that developers can come in and have the right experience from day one. And then it's about the right partnership with the business to ensure that we're working together on things. And we actually had an off-site last week, and we've got three or four big bets that we want to do in technology. The first is how do you create the right dynamic developer engineering experience so that you put as much of the testing experience and activities on the cloud and the development itself, so JIRA and Jenkins and GitHub, etc. The second big bet is how do you create a common services ecosystem, so we then have a marketplace for capabilities and services that offers that full spectrum of features that service providers and consumers need: inventory, discovery, provisioning, orchestration, etc., etc. So having the best engineering experience for our developers, less engineers as possible, so that it can be created within what is the ecosystem of UBS.

So I think there's a few aspects. The first is transitioning at least a technology workforce to be engineer focused, etc., and the culture more broadly. So hiring great talent is something that's been really important. So we created hiring questions that go above just testing the tech competencies. How do they build a strong culture? Someone who's accountable, collaborative, and capable of working within that environment. We also created something called a distinguished engineer program, which nurtures great engineering talent across the board. And then the other big focus for me, and especially for me personally, is the right learning program. So we have things focused on emerging technologies and disciplines like machine learning, cloud, and data science, and we've signed up with Coursera to offer some of these up. You know, for instance, our most popular course at the moment is neural networks and deep learning. And we are spending a lot of time supporting the managers and helping them become better managers through different programs. And it really is learning that I think helps make that step-by-step change. So it's not a scary set of changes, but something that's interesting and, if you like, evolutionary instead of revolutionary for them.

Yeah, I must say we haven't really had that issue. So we did a lot of hiring last year, partly as we look to insource and shift away from the sort of vendor-based model that we had the last two years. But I think the broader point is: technology will continue to evolve, and has been evolving for years, but I think is evolving faster than ever before. So I think the importance of learning and a learning culture is just critical. And it's not just for hiring, it's also just to ensure that people are evolving and learning. And one thing to be a UBS is because we're providing them the right experiences.

Yeah, it's a really difficult question, I think, and one that we debate a lot, because I also think people learn in different ways. So I personally learn best by reading, others learn best by classroom, others learn best by web-based training, others learn best actually by YouTube or other things. So we do look at all the different ways you can do this. There are tools which offer a sort of portal to enable people to do things in different ways. We do try and make sure there are different tools and mechanisms. I think you also, by definition, can't make learning on broader topics mandatory. We do have some regulatory training which is mandatory. But then also communication in general, I think, is difficult given the size of the workforce. So we do different things. We do as much communication as possible. We do run workshops, town halls, coffee corners, fireside chats. We do use different digital tools. So we do have a chatbot, actually, at the moment called Tenets, so that people can give direct feedback and people can convert. I do personally blog a lot, telling it's the simplest and most honest way of getting updates and personal thoughts to the team, on a variety of things: personal staff updates, milestones, strategy, or whatever. But other members of the management team do different things, so daily weekly webcasts or other things.

We have a responsibility to deliver the best possible technology that we can for UBS more broadly, but also the end client. And that can be through waterfall or DevOps or agile or Kanban or whatnot. But we also want to make sure that it's done efficiently and with good quality. And that is, in a nutshell, what agile is. But it also ensures that we evolve the teams and the culture. A good setup today or in the past would have you know program manager, a BA, a quant, a developer, and an ops person, et cetera. I think the skill set will become more multi-variant and integrated as we move forward. And you've heard more and more about the two-pizza rule, but ideally the size of a team should be that which two pizzas can feed. And we drive greater efficiency by getting stuff into production.

To a certain extent, but I think it's also just a different mindset of how things get done. So I think one can get very caught up in what we think about waterfall or agile or the different types of this, but it really is having definition, build, test, and release as an iterative process instead of having things that are truly waterfall. So I think it does decrease risk. I think it actually makes the teams from the business and technology more empowered and engaged throughout the process. I think you get better business value with that given velocity, and you can adapt to changing needs as things evolve. Also, to one of your earlier points around stability, I think the time to discover issues is just better because in a waterfall model you're sort of doing initiates, then analyze, plan, test, release, and doing you know whatever that may be monthly or quarterly releases. In some areas that's the right thing to do, but in other areas I'd rather have a defined build-test-release iterative approach as much as possible.

Yes, although what I would say is I think it happens in both methodologies. So if you have a long project, by definition it's easier to have scope creep and issues and budget overrun and whatnot. You can still have in a longer project, where you know it's going to be multi-year, to find three- or six-month milestones. So instead of waiting until you know three years ex-post, you do put defined sets of milestones or pre-release of code every three to six months. Now, in the agile model that would be even shorter, but under any scenario we want to make sure that we do this so that you've got defined sets of milestones every X months just to make sure that we're more honest with ourselves of what's being done.

Yes, we would never risk regulatory releases or client releases. So will we move to 100% agile slash DevOps? Absolutely not. There are certain things that we need to do with the right definition, the right analysis, etc. But there are still areas where it's appropriate and makes sense to move more and more to an iterative model, and that iterative model can take different forms even in the waterfall space. So it's the regulatory stringency and client requirement high in banking, absolutely, and it's something we would never ever dilute. But it can still be done in a more efficient and expedient way.