The following is an excerpt from a presentation by Jelena Laketić, Head of Asset Management SWAT at UBS, titled “Twelve Years of Injecting Agile and DevOps at UBS.”
You can watch the video of the presentation, which was originally delivered at the 2018 DevOps Enterprise Summit in London.
I’d like to share with you a bit about the last 12 years of my professional life, and about injecting Agile in DevOps — I really feel that injecting is the appropriate word here because it’s much easier to be the person giving injections than the one receiving. And it is very important to make sure that you don’t kill the patient, because in this case, the patient is somebody who we are trying to keep healthy — the organization, and that’s never easy.
before I actually go into my story, let me tell you a bit about myself.
My name is Jelena Laketic and in my current role, I am a Head of Asset Management SWAT, which stands for SoftWare Action Team.
To give you a little bit more information about UBS, it’s one of the largest banks in the world, and our workforce at a glance is quite interesting. We are the largest bank in Switzerland, but we have a truly global print. There are 61,000 people in the company, and 34% of them are in States in America. 34 in Switzerland, 18 in EMEA, and 14 in Asia.
We are also very old. More than 150 years old, and we offer financial services to wealthy, institutional, and corporate clients worldwide, as well as the private clients in Switzerland.
In order to actually satisfy our clients’ needs, we have five divisions. Global Wealth Management, Asset Management, Investment Bank, Personal and Corporate, and Corporate Center. Corporate Center is where IT is, and this is essentially where I am as well.
But where do I sit, actually? Where is my place in UBS?
We call IT in UBS, IT Group Technology, and if you look at this complicated map, it’s actually a matrix organization.
On one side, we are aligned with our businesses. On the other side, we have the functionalities that are across all the businesses, like CTO or infrastructure, etc.
In the case of a SWAT Team, I sit in an asset management IT, which means that Asset Management Business are my clients.
Before all this, I was working in investment banking, and when I was moving to asset management, I was trying to better understand the difference between the two. One thing that I found out, and this is a big simplification, but asset management is about managing the money that companies and clients already have, while investment bank was more about raising the money that companies don’t have but would like to have. And this, while kind of illogical, makes asset management much more static than investment banking.
From the moment I joined asset management, I felt that they were maybe 10-15 years behind investment banking. Which meant there was a lot of work to do there.
One of the main problems that I’ve seen, was that asset management has historically been built from several small organizations and is scattered everywhere in isolated teams.
On the other side, the IT has been heavily outsourced, which means working toward the common goal was almost impossible.
Two years ago, I was invited to help them achieve more efficient organization. And with that invite, I also had the possibility to come up with a concept that I built based off my experiences before.
What is the SWAT Team?
SWAT Team is the SoftWare Action Team set to explore the possibilities of innovating and digitizing UBS Asset Management. It is also there to catalyze the transformation from these huge complex applications to smaller scale and lower cost applications. SWAT Team is Design Thinking meets Agile and DevOps practices and all of that should enable UBS Asset Management to achieve some competitive advantage in a industry because smaller asset management companies have been doing this for a while.
How does SWAT do that?
When I was coming up with this concept, I was trying to identify what the pillars of work were for the SWAT team.
One of the most important ones for me was the applied innovation pillar. What that means is that we are trying to deliver a production-ready product in close collaboration with our clients, using a Design Thinking approach. Meaning that we would really work with them towards the solution and iterate as many times as we need to so that we can create something they will be happy to use. Of course, in order to achieve that, using Agile methodologies and DevOps practices just made sense.
In addition, I also wanted for my team to have the possibility to explore new technologies. Unfortunately, asset management in the state relies on a lot of legacy application that is, frankly speaking, out-of-date, especially regarding technology. The idea was to assess what we could be using, where, and of course in a better way. But also, creating the production-ready products meant that all these new technologies would be made in the environment that was easier to create. Moving them into the production would enable us to assess what the efforts we needed to invest to create a better technology organization.
In order to do that, we obviously needed people, and working together with the IT was very important to me. I didn’t really want to create a team that excluded itself from the rest of the IT. Actually, I wanted to create a team that would complement IT, that could help them, empower them, and teach them better ways of working, new technology, etc.
The idea was every time when we’d create the product, we should be delivering it to regular IT. And through that handover process, we would teach them about the technology that we used, the ways we used it, and start empowering them along the way — enabling, what I call, bottom-up innovation.
ATTEND THE DEVOPS ENTERPRISE SUMMIT
Obviously, for a team like SWAT to exist, top-down innovations were there too. However, during all the years I worked at UBS and in my software engineering experience, I realized that top-down innovations don’t really matter if it’s not supported with a bottom-up innovation. In this way, I found and identified allies across the organization, and helped them to be more creative. Ultimately, transformation takes time, and you need people onboard who are motivated and happy to jump on the train of the transformation.
In addition, we tried to increase the key talent that we had in the organization, which was very important. Being a heavily outsourced organization, there was not a lot of things we could do to achieve this objective. But, my team also helped in interviewing people, connecting, and bringing in new members that they meet at a conference, etc. So that overall we were bringing on good developers to the organization.
The third pillar we needed to achieve was a more global one. At UBS, we have innovation on a global level, and while this is really great because we do get the possibility to explore new ideas, what would happen is that funding would be assigned to an external vendor, and then, they would have all the funds working on innovative projects outside of our IT.
Instead, we sought to help the Global Innovation Board to keep the knowledge about interesting projects and innovative technologies inside the bank. We were helping them to not only work on the projects, but to think about the concepts, aligning them with the teams that exist across the organization, and involving them in innovation projects that had already a good funding and an interesting subject. Right now, this pillar is only on a level of passive management, but the idea is to continue on to the global level.
Who’s on the SWAT Team?
The SWAT Team is at the moment a very small team, and that is the whole idea. Starting it with a smaller scale team, and then rebuilding it in a similar way across the organization would be the ideal plan. At the moment, I have a four high-performing IT specialist, full stack developers, and one UX expert, who is very important in our work with the clients with the business clients.
No matter what their roles are though, what I am looking for are people with a fresh mind, and are outside of UBS, if possible. Usually, students, young people with a growth mindset because I want to have people that are open to learning new technologies, adapting to the ways, and being able to work with lots of different types of people. Ultimately, somebody, who is very flexible and open. Of course, ideally, they would be interested in an innovative subject, new technologies, methodologies, and best practices.
To add to this, it’s important to note that there are some points that enable this kind of a team.
Now, I already mentioned that outside of the team there was top-down support — senior management support. In this case, we had support from a mix of business and IT, which enables the team like this to be aligned with the overall strategy of the organization. Obviously, what is also important is that we are able to work closely with our clients, in this case, UBS Asset Management business.
Internally, I was trying to build up more of a startup-like culture. We work with the open space. We have regular talks. We discuss anything from technology to task-related projects, but also things that we’ve read about and we always discuss how we could use it in our work. But what is also important is that there are clear tasks and goals and that everybody in the team is capable to jump into either a task from their colleagues or something that comes up out of nowhere, without being too strict about it.
Of course, during all of this, we’re using an Agile methodology. In this case, we chose the whole Atlassian package and DevOps practices. We’re working with the cloud technology and my team at the moment writes all the build scripts and deployment scripts. This will obviously develop later on in more automated ways, but since the team is still new we are keeping it on this level.
One really important factor that enables the team to be so creative is a so-called adapted sandbox technical setup. What I mean by that is that I came up with an external infrastructure setup that is quite simple. It’s not something that is mind-blowing, but it allows the people to join the team and immediately, the day after, start coding.
To give you a kind of a comparison, when a developer joins UBS, it takes up to three weeks until they start coding. With this sandbox approach, we have external machines and we are running them on a secure network, and therefore, we are not only secure but also very flexible to do what needs to be done for our clients or to explore a new technology.
this is a story about how I came to my current role.
I want to go a little bit back in time, and discuss some of the things that inspired me to create the concepts that I mentioned for the SWAT. So, I am going to throw back to 2006 and how it all started.
I joined UBS in 2006 in Investment Bank as a software engineer. I was a bit of an experiment for the investment bank at that time. They were doing very well, and they just hired the team to rewrite all trading application system that we had. They wanted to find somebody with a different mind and I wasn’t the typical person that would be hired in a bank because I worked in a different industry.
I remember when I was headhunted by UBS, I wasn’t really interested. I didn’t think there was anything for me to do in a bank. I thought that bank-related work for IT was going to be really boring. But then, I did a bit of a research and I saw that UBS Investment Bank is slightly different. They were working on some projects with the university, and I thought I’d give it a try.
ATTEND THE DEVOPS ENTERPRISE SUMMIT
What really made me agree to work for them was when I met a team of older guys. They were the guys that developed the first electronic trading systems, and they were just before their retirement. I start talking to them about their work, and you know they had this sparkle in their eye. They were so excited to still about their work, and that was really for me breaking point because I thought, ‘If these guys are still excited to work and they’ve been there for more than 20 years, then you know this is a place for me.’
I decided to join the team that was developing a high-speed electronic system. I started with a team that developed the first electronic trading system, back in the ’90s, and these guys were amazing developers and really knew the business in its core.
Then, I moved to the new team that was supposed to rewrite that system, and we were not doing the Big Bang. We were working with those guys to create something that used that new technology but still relied on all the business logic and efforts of the previous team.
Before UBS, in all the companies where I worked, we worked with a waterfall model, release frequency of every three months, and frankly speaking, I was always bored. I would come up with so many crazy inventions. I remember at Siemens, I came up with an improvement of the QA system because I just really didn’t know what to do with myself while waiting for the next project to start.
Now, here at UBS, my team was working differently, and this is something that really amazed me. I hadn’t experienced that before. They had a waterfall model, but it felt more flexible. Their release frequency was less than three months, and they worked closely with the QA team and support, and ops team. They were more dynamic than what I was used to before. However, they were still not fully efficient. But one of the breaking points, I would say there is always a silver lining in everything, was probably in 2007 when subprime mortgage crisis happened.
I joined the organization in December of 2006 and they were super happy. They even had money to spend on resources like me, and then 2007 started. And guess what? UBS was actually the first Wall Street company to declare a big loss. Until 2008, we lost more than 50 billion, we had 11,000 job cuts, and it was a bit of a bloodbath. There was an ambulance every other day in our offices, helping people recover from some stress. It was a bit horrible.
In addition, at the end of 2008, we were bailed out by the Swiss National Bank. Now, this sounds like a very good thing. But what this meant was that our reputation in Switzerland went down the drain. Everybody was against us. I mean when we left the office for the day, we would have people throwing eggs at us. It was really a horrible situation.
Now, for me, I felt right at home. Maybe it’s due to my background. I am coming from ex-Yugoslavia and I lived there until 2000. I was very much used to having a little bit of drama and chaos around. While other people were feeling uncomfortable and couldn’t handle it, I actually felt reasonably okay, and so I decided to stay.
How did this whole situation affect my team?
My team was a group of developers, but we got even closer now with the support, Ops, and QA. What we needed to do was to continuously develop new features, while fixing bugs. We needed to have a shorter release cycle. We needed to do this while maintaining quality, and making sure that everything that we delivered didn’t jeopardize the older features.
On the other hand, our clients also had to change. The front, middle, and back office, and these are some of the really tough guys, especially front office, but they also had to change. There weren’t going to be any more stars bringing millions to the bank.
They start working closely with us, explaining to us what could we do better, or how we can help them fix their pain points. They had to share the business with us so that we can do this properly. When they had an issue, they had to report it with enough details for us to actually be able to fix it. Finally, they had to really trust us that we are the technical expert and that we could provide them with the best possible solution. All of that obviously resulted in us absolutely embracing an Agile style of work, and DevOps practices.
Now, during this time while we were embracing these practices, we didn’t call them that. We were just working more efficiently, more organized, more together. We were just doing something in a very natural way. It was only later on that we figured out this was DevOps. And over the time, we perfected the way. In the beginning, we were very manual, later on, we started developing the tools. The ops guys would develop the tools for release, approval, and so on.
Eventually, what happened, is that we started having a reputation as a team that was getting things done. We actually, we were smaller than ever because all the people that couldn’t handle the pressure left, or they were made redundant as one would expect. But we stayed, and we delivered in a most efficient way we could.
Then across the organization, people started recognizing our standard as the gold standard, and they wanted to learn more about us. Somehow we got even the name the Topaz Way, Topaz was the application that we were developing.
This was all great, and I really loved working in this team. However, when I got an offer to make a difference in another part of the organization, I jumped on that opportunity and I used many of the things that I learned and observed with this team in my current job.