The Agile Transformation at ING

The CIO of ING presents on the Agile DevOps transformation and their focus on IT talent.

ING’s Global Chief Information Officer (CIO) Ron van Kemenade overseas over 10,000 IT staff members (including externals.) He’s responsible for all banking technology at ING. ING serves over 34 million customers globally - showing that Agile transformation is scalable to large organizations.

Ron opened his presentation with the “We love IT” video highlighting ING’s milestones during the transition to DevOps. He goes on to explain that in order to serve ING’s mission of empowering people to stay a step ahead in life and business, their IT would need to change to serve that strategy.

After attending the Google I/O, Ron van Kemenade returned inspired to transform IT at ING. He started with a small mobile development team.

“If you want to make clear the impact of your change, you don’t put ten people in a row and all at the same time make a small step. Everybody moves at the same pace forward. So instead of that we asked one team to make a huge step forward. One meter in front of the other nine. Then everybody notices. And then you need to allow other teams to copy their behavior."

By focusing on internal talent, ING has become more responsive to customer needs.


Ron van Kemenade




What I'm going to talk about is actually about people. That's why it says nothing. Beats engineering talents. Banking is about technology. Technology is about people that people skills, people's competencies and their ability to change. That's what this story is about. It's a story about how we approached the change within ING. It's in that sense, it is not a cookbook. It's not a prescription for the dev ops doctor. It's our story. Right? And I hope it helps you. It truly helps you to find the inspiration to either start with your agile transformation or to continue with it because I'm more than aware. I still carry all the bruises, which you will basically, uh, no suffer during your transformation, but let's start with a video that shows the power of all these great engineers within ING


So they can like it.


I'm extremely proud of all these people in the video and all the other ones that are not in video, actually. Um, I'm starting to talk a bit about ING and very briefly about myself and otherwise you should look it up at LinkedIn or Twitter. Um, and then the major part is really about the transformation and ING. Then we enter into the third part of the presentation, which will be quite interactive. So I, this is good news for you all. I can encourage you to keep your mobile phone or your laptop on with the ringer off, of course. And at the end, I'll try to give you a bit of my advice, right? So not like Jean announced me. I'm the CIO of ING have been in this role for three years. I'm 51 years old, so way too old for technology, right? I'm a dinosaur.


Um, I have one wife, two kids, um, and I love basically technology. And I'm a big believer in the agile manifesto, a big believer in the whole dev ops transformation and a big fan of every engineering behind to continuous delivery and all of the above. We'll come back into my presentation. Now, for those who are maybe slightly less familiar with ING Burbank, or I should say, actually we're a technology company. And through that technology, we serve 34 million customers primarily in Europe, but I should say globally for the commercial bank as well. Now you can see, uh, the number of employees around 52,000 that's internal employees. So our head count, we have a market gap, or at least we had at the end of last year, around 48 billion, we have a balance of around to 840 top line. So the revenues of the bank, 16 billion and around the bottom line. So what is left after we've paid a lot of stuff, risks, costs, taxes, et cetera, of around 4 billion, right? So you get a bit of a, an understanding of what the size of the enterprise is because that's relevant to the story. It's really about the scalability of this agile and dev ops transformation in this bank.


Now our strategy is what we call the think forward strategy thing forward. It is about to empower our customers to stay a step ahead in life and business. Maybe traditionally banks were a bit in the rear business rear mirror business, right? We told you what your balance was, could be 20 milliseconds ago, but we should be actually looking forward and empowering our customers. And we do that by four promises. First is we promise you to have clear and easy products. We promise to deliver a service anytime and anywhere. And everybody who's a true engineer, knows that every time means something in terms of the number of nines. Then we empower our customers. So we look forward and we, and this is I'm really proud of this is really an agile principle, right? In our promises to our customers. We promise them to keep on improving, to keep getting better.


And this is quite a promise, right? Anytime, anywhere clear and easy looking forwards. So being predictive and keep on improving. Now, this was quite a challenge to live up to that promise and that triggered our transformation. And maybe part of that transformation had already started, but it became even more purposeful. And looking back when I joined the it parts of ING, I still remember that the first day it was my first day in the job. I had become the CIO of ING bank Netherlands. And the first day this guy walked into my office. He was one of the architects and he shook hands and he said, welcome to the dark side of the moon.


It's a scary place, no lights, dust storms, freezing cold and dangerous gates to fall in recognize that, but let me allude a bit. So there is a couple of statements on the slide, and this is what it really was like. And I'm, I'm sure that in many enterprises there's used to be the situation or to a part still is technology was treated as a commodity. So basically everybody can do this, right? It's a matter of, uh, pulling the Prague into the wall and there you have your technology. We treated our colleagues as internal customers. So let's give them an SLA that's about, okay. Right. We considered it to be a cost center. So let's cut the budget.


All of these things, we had quality assurance through process at the urines. So CMI ruled the world. We had a very scattered it landscape. So it was quite hard to find anybody who could fix it. We had sourcing all over the place. So even to know what was happening, I needed to give like seven calls to different companies and say, do you know what is happening? And infra, those poor guys have infra. They were supposed to take care of all the non-functional in the bank. So the business could only concentrate on functionality. That was the situation. That's why it felt like the dark side of the moon. And I must say after three months in a job, I was more or less ready to give up to quit or even anything more rigorous.


So I decided to go to the Google IO that was still in the days where it took slightly. You don't get a two minutes to register since then. I actually never succeeded, but I can. I went there and, and that, that helped me spark the whole transformation. And I'll, I'll come back to that. So the whole transformation starts with me coming back from the Google IO. And I thought, how can I, how can I transform this organization? Where do I start? How can I transmit the feeling that I got on the Google IO to my people? So I started writing a block on the internet and it, you can see that the most important parts, but it went a bit like this. And this is the very short summary. We have a great profession and we're so honored to work every day with cool technology, providing great services to our customers and getting applause from our business colleagues.


But how often is that actually true? Because we keep on messing up things with acceptance criteria, documentation, process, adherence, governance, everything, but at least something, it is a very proud profession. Engineers are proud people, and I encourage them to say, instead of moaning and bitching about it, let's take matter into our own hands. Let's take responsibility. And that's where having, we started the so-called Java community. And I called for people to say, we have the worst app in the world. So why don't you all join me on a Tuesday evening as of six o'clock we'll simply occupy an office, an open space and I'll pay for the Peters, right? That was the spark and the spark that Enlighted the whole transformation. But then you have a spark and you've got people inspired and then starts the difficult part, because this was easy. That was one block.


Uh, the PGRs, um, cost me a little bit more than I expected because they kept on coming back every Tuesday. And every Tuesday, there were more people and nobody was willing to pay for them. So, so how do you now started the fire? This was only the spark. How do you start the fire? And that's when we used, uh, I need to, I needed to set an example. So I use the mobile app development as basically our start. We created two scrum teams. So let's just do it in a different way, because nobody likes the fault of our way of working. Nobody is happy. It's like staying in a bad marriage because divorce is even worse, right? Nobody there's the change. So I, we said let's, uh, two people came into my office and they said, Ron, if you really want us to create a great mobile experience, you're never going to get there with this waterfall way of working with prince to the, finding the world and the rhythm of how we do things, that's the way differently. So I said, okay, you're absolutely right. I'm not sure whether this is going to work, but it's at least different from how we have traditionally done things.


And they started. And we, we started in parallel this campaign with, uh, slogans on posters on the wall, close to the coffee machine. Of course that's where people stop. And we actually didn't tell what it was for, but we just gave them things to think about. And in parallel, we created these mobile app teams and we put them in the middle of the bin building. Nobody could ignore them. If you needed to go to the loo or to the restaurant, you needed to get past them and you couldn't ignore them. And when they had their first successes, we celebrated big time. And this is really an important message. If you want to make clear the impact of your change, you don't put 10 people in a row and all at the same time, make a small step, right? Everybody moves at the same pace forward. So instead of that, we asked one team in this case, two, to make a huge step forward, almost all the podium, one meter ahead of the other nine. That's where you have a big difference. Everybody notices, everybody notices. And then of course, you need to allow other teams to copy their behavior and to experiment themselves. Don't immediately standardize, give everybody the room to learn themselves. Everybody deserves their own middle medieval ages, right?


So those that was really the start. And the next part is really our story. And why do I say it's our story? We never had a PowerPoint presentation that said, this is how we're going to do the agile transformation. This is how we're going to implement dev ops. That presentation does not exist. Maybe we could ride it now, but that's not how it went. We had our moments of inspiration. We talked to people, we found problems that we needed to have a solution for. We read books, we went to conferences in every time. And again, we found out a new piece of the puzzle. Like I said, I became head of the it department. I was CIO. I was supposed to be responsible for it. My organization even was talking about it, but it simply didn't feel like it. And that's when I found the engineering culture at the Google IO. And that's where we started. We started with the people. Part, people needed to be highly skilled, proud engineers, because without the people, you can change the process. You can change the tooling, but like they say an it, a fool with a tool is still a fool, right? So you need to start at the people part.


And then we moved on. We started with scrum do scrum teams that I just discussed about driven by the bare necessity to catch up with competition and to bring a great mobile experience to the market. That's where we started with this two small teams doing scrub. And then somebody, one of my managers, he came up to me and I said, Ron, I read this great book by Jess humble and Farley it's called convenience delivery. I actually never imagined that this was already available in the market. We were still struggling with all kinds of tooling from the major vendors. I won't mention names, but you will all recognize them. They either start with an I or an H or an O or an M.


Yeah. You'll fill in the blank spots. And they're this whole continuous delivery suite was laid out in that book. And at that stuff like Jenkins and puppet and to know Leo and Artifactory and get all new names to us. So we said, Hey, if this is really available, that fills in all these manual things we're still doing. And we're so supposed to automate things, but actually all the stuff in it is still manual. So let's create this continuous delivery pipeline. That was the third moments. And then of course we, we, we had this great, uh, experiment with the CD pipeline. And then we, we hit a brick wall and the HIG hit, the brick wall was infra. And we had a conversation with the head of infra and we said, well, how do we fix this? How do the public cloud providers fix this? And then, then my colleague head of infrastructure at the ed, they offer you a platform as a service.


And I said, yes, that's what I want. I had no clue what it meant, but it sounded cool. And it was at least what the artists were at the artist, meaning the market was delivering. So that's what I wanted to internally as well. Again, an inspiring moment. And then, and we were a bit late. Maybe we heard about dev ops because my developers were now doing all this great stuff and continuous deployment. And the, the ops, the it ops guys simply couldn't catch up. And we left them in the dark. We could say, there are a couple of losers, but the developers left them out and they were throwing stuff at them. So we said, instead of again, bitching and moaning let's include the, it ops part into our development. And we found out that there was actually a word for that called dev ops. So we changed the organization, no separate departments anymore for system management or whatever you would call that a application maintenance, simply only value chain driven departments like channel development or core banking or customer domain, whatever, including development and ops.


And then we still were faced with the silos. So coming out of these, maybe 15, 20 years of fully siloed, separated it, the Fadimans we managed to build up such a huge pile of technical depths. It was, it was beyond belief and that started showing in our reliability. So we needed to change our architecture as well. That's why, and we came up with a web-scale architecture, again, a new words, and it's turned out to be that Netflix had faced a bit of similar reliability problems and they started to re-engineer that total architecture. And that's what we liked as well. And that's the moment when this total change in the skill mix of my engineer started to pay off because this was totally new. Again, new technology like history, Sioux keeper, engine X, all of the above, talking about API platforms and scaling databases, like a Sandra multi-node databases.


You need great engineers for that. Otherwise it's like a toddler in a BMW running into a wall now. And then at the end of the game, uh, you see the Spotify model. We included the business as well, because it was now cool. And still the business felt like, Hey, we have these great ideas, but still we need to hand over to ID and then they will go and fix it for us. So we said, instead of you being in the project board or the steerco or whatever you would call it, you simply take a place at the table. You take responsibility for the non functionals asks, will the engineers take responsible responsibility for the customer satisfaction? And we created this base dev ops model. And if you look it up at all the open source publications by Spotify, you'll recognize words like tribes and squats, chapters, gilts, and they're all there.


They're all there. And finally, again, we came back to the engineering, the people parts and say, guys, we actually do have great engineers, but we need to take them to the next level. We need to take them to the next level. And how do you find a model in the market that helps you defining a engineering profile? What is it a good engineer should look like? So we completely redefined the roles based on what we call observable behavior. What is the role an engineer place? Is he or she is somebody who is able to perform a task that somebody else spells out. Are you able to, um, more or less copy your task have experience? I knew the person who is able to decide on the tooling or the language you're using, or are you the go-to person that everybody drops by and says, Hey, I have this tough problem.


Can you help me and find a solution? Or are you even the guy or girl who is invited to conferences like the dev of summits? And it's considered to be a guru. I'm not talking about me, uh, by, uh, by the way, but by my, uh, engineers and architects who have been invited by gene, the previous ones in, uh, in San Francisco. Right? So, and we did that based on a model for knowledge, acquisition, application, and transfer, it's called the Dreyfus model. You can look it up on the internet. Again, we did not invent anything. We went outside and found the inspiration. This is what the journey looked like. These were the moments of truth to us. These were the companies and the external events where we found inspiration and we faced a lot of challenges. I can tell you, and I structured them a bit for you.


That that's always helpful to me. I can't leave without structure. So really an engineering mind it's always binary or in three steps or four paradigms or whatever. So you see here, three big challenges, right? The capabilities of our engineers, how do we include the business? And what about our tooling? Those were the three major challenges. And we still struggle with them. Let's be honest. We haven't found the ultimate solution, but what you typically see is how to involve the business, right? How to change their role, not allowing them anymore to be laid back and say, this is what we want you to do. And we'll hear about when you're done, right? They needed to take a different approach, active, be included in the dev ops teams. How do you do that? What are the typical skills of fully men? That product owner look at our own engineers.


They needed to have different knowledge, different tooling, different capabilities, understand the business, take responsibility, not Mt. About all the requirements being clear first before you're starting to do something. So they needed to change as well. And how do you do that? Key question is, do you train your people and hope for the best? Do your own, kick them out and rehire new ones, or do you give up and all outsource this to somebody else, three beds alternatives. So it should be about the balance, right? All of the above is helpful and then find the right tooling. And the moment you say, Hey, now I have my great tooling. There is something new. And they have already, again, endorsed that tooling and engineers simply stick to that tools. They love them. You could, you could rather say, uh, could I, uh, borrow your wife or a night and of drinking right of drinking instead of, could I have your tool and replace it by something else?


And by that I said, wife, I meant husband or partner should be careful here. So lots of challenges. And we had a paradigm to face those challenges. And the paradigm again is around people, process and technology. This is maybe the most important thing you need to remember because it is not just about people. It's not just about the process. It's not just about the technology. It's the combination of the three. And we have three paradigms, simplify the technology, everything we don't need. We take out everything that is almost redundant. We'll make sure there is a functional, alternative and decommission instead of having six or seven operating systems, let's concentrate only on two only windows and Linux. In our case for the x86 architecture, as an example on the processes, we said, everything you do twice, there is a case for automation. So if you deploy VMs and you do it manually twice, there should be a case for automation, even to the point where today, well, you all know your, you will all know about Sox, right?


Sarbanes-Oxley and you need to do this horrible testing twice a year, at least to comply with the Sox, uh, key controls. And this is a horrible process and engineers hate it. So after we did it now, maybe a slightly more than twice, like, uh, 10 times or 20 times, we decided this is such a horrible process. It's all manual. It's, it's boring. Nobody gets let's automate this. So we're now creating an audit robots and we don't need w w we can do it as often as we like, because it's no effort anymore. We just need to maintain the scripts. I can do my security event monitoring, whether I do have that in place or not. This is a key control. The fines. I can do that. Uh, every minute or my, uh, technical, safe, compliance fee. I can do the tests every minute, twice an hour.


You just tell me how often to do so that's all about automation. And again, the third paradigm, a high-performing workforce of highly skilled engineers. That's a paradigm. It's a bit of a holy trilogy, right? People process technology, simplify, automate high-performing workforce. So that's all about the journey. And now you should ask me, so where did it leave you? Right? What's the current status? Where are you? This is basically where we are. We rehired on the people side, we rehired over 600 software engineers, highly skilled software engineers. And we retrained basically all of the organization we introduced, like I said, the engineering profile. So the drivers model that facilitates that engineers across countries have the same skills, the same knowledge base. And if I say, I need an expert, I get an experts. If I say I it's okay to have three competent engineers or advanced beginners, I know that there is no difference between Poland, Romania, Australia, Netherlands, whatever country.


And we have committed to open source communities because I can't keep my engineer's insight. They need to prove to the world that they can do great engineering. So they contributes to streaming data frameworks. They contribute to OpenStack. They contribute to a lot. And we encourage that. And again, this was a struggle with legal because yes, that's scary open source, even ING engineers contributing to that. What about responsibility and claims and that kind of stuff, but we'd let them on the process side. On the automation side, we now have a full continuous delivery pipeline for Linux and for Microsoft, we have cloud provisioning fully automated, and we're still working on all the, uh, security and risk stuff. So firewall automation, identity and access management automation, all of that key control testing, like I said, and on the technology part, you see, uh, where we are now, what we learned is that there is different levels of adoption of change.


And again, there is a model here it's by Ryan and Daisey. So not by home from Cayman island, but by Ryan and AC. And the left part is from the original model. And it's show difficult. The words you can immediately forget them. So I made a bit, bit of a personal translation. That's on the right side. The first way to adopt change is the boss tells me to do so. So I'll be compliant, right? You recognize that or not. The second part is a bit of a natural thing for people to do. If Mr. Akin do this, Mrs. B will prove that she can do it as well. And that's a bit of a one-time change because once you've proven it, there is no incentive more to continue with the change. So even more deeper level is I fully understand the rationale so I can basically transfer the same knowledge to other people I can judge in decision-making whether something makes sense, given the rationale or not, but still it's not good enough because if the next CIO comes around or the next digital officer or the next supermarket here, and he, or she has a better rationale, you will still give up.


So the fourth and true level of adoption is it has become a religion. It has become a belief. It detects your daily behavior. You dream about it, it's in your genes. Then anybody could come along and have a different rationale, but you won't change anymore. And that's the level we all should aim for. And this is really difficult. It's really hard.


And that brings us to the part where I, I hope we all are interested in how far we are as the dev ops community, right? And that's the part where you get a vote. And I promise I won't, uh, immediately connect consequences to this. You all are aware of what that could mean, but it gives our us all insight and where we are. So it's only five questions. So don't be scared. It's fully anonymous. You see that because you have a non-personal account. So no, a registration of credentials. And it is really to learn where are we as a community? There is no wrong, or right. It only will help you and myself to understand what kind of challenges do we all acknowledge. So you go to a and I'll give you some time. The log home is dev ops it's by the way, not case sensitive. So to start could be a, a capital D or a small, and I'll give you some time. And if I'm correct, I get a bit of a signal from a mark when I can actually start. Okay. If you are still not long dorm, that's, that's no big deal because we'll actually start with a test question. Right? So what do you think about the presentation so far? There is three choices.


You make a choice, And by the way, if you choose one, you're lying because then you're not supposed to be able to read the slides. Right. So only two and three are options. Okay.


So let's go meet


You guys. Um, I've been told are more or less with 400. So if there is now 200 votes, that means that sill, somebody is struggling to log on or to find a website or doesn't know how to get his laptop, reboot it, or has fallen asleep. Mark, what is the outcome of the vote of this first test question?


Okay. But that was already before I started or, okay. So this one is only the test question, right? It was a bit of a joke, but sale. Thanks for the compliment now to the serious ones. Again, three choices. It is about because you guys went to this dev ops conference. So I assume that people say, yes, we're working in an agile way and we all do more or less. And what did we actually take out in terms of handovers? Did we take out the handover between design and build or that we take out the handover between dev and ops or that we take out the handover between it and business? Where are we as a community? Again, your votes


I'll be ready, mark.


And we are almost equals around.


Okay. So that means that the business is still a bit left out guys. And this is, I think what we all recognize in many cases, the agile transformation starts driven from the it or digital officers, because the necessity is quite high because people are complaining and they deserve better. And that's where overall I N G is as well, except for the Netherlands where they fully adopted the biz dev ops model by Spotify. And I would really encourage you guys to have a look at that. There is a lot of YouTube videos about it, read about Spotify itself. It's a remarkable model is really very equal where I thrive has basically no single leader. There is no hierarchy, but it's a, uh, a three party, uh, leadership, a design lead, a product owner and a delivery manager. At least those are the roles, how we call them.


And it's a very inspiring model. Okay. We move on to the next question, which is about, I mean, I'm at the dev ops summit, right? So there should be a question about dev ops, again, three choices, and you can read them. I won't read them out loud. Um, yeah, so we do a bit of a scrum and Kanban development, which is really helpful to lower your time to market, or you have dev ops teams and your resources are still allocated from those teams to projects, or you have fixed teams managing and backlog that facilitates more than one initiative. It's all possible. It's different levels, different stages, whatever you call it again, your votes


I stabilized and you're getting around 43% from the scrubbing. Then the next one is the permanent theme. So 38 and the combined the hopelessness around 25.


And actually there is some good news in there because in, um, in our transformation, we had several places where people said, yeah, it's absolutely okay, you go and do your dev ops thing, but we will still have our projects. Right. And we allocate budgets to our projects and we need to have, um, dedicated capacity from all those teams. And it shouldn't interfere with anything else on the backlog. So in name, it was dev ops, but in reality, we're still very much project driven and prince two and P IDs and exception reports. So it seems that as a community, we are relatively mature here and we try to avoid this and I would seriously recommend to do so if, if you start dev ops and you continue dev ops, try to avoid mixing up a backlog with a project roadmap, it's a big difference. And that's why I included the question. Now we move on. What about product owners? I think we will all more or less have product owners. Now, are they located at the it side of the organization? Are they organized in a pool of product owners really helpful to, let's say a lift there to mature their skills, or are they the owners of the P and L of the proposition itself? Where are we as a community?


I remember a and C are fighting for the first place and this guy. So for my D and having that full response to that would be a proposition. Uh,


Yeah, I think that they're more or less choices I would have expected, but within ING, actually, there was a, a couple of very creative people on the business side who said, okay, you'll have your product owners, but we'll organize them in a separate department. So they were basically nothing. They were not involved on the ID side and they had no business mandate either. So it was actually the worst place to end up and again, in your transformation, if somebody would come up with structure, proposal, point them to this presentation and tell them Rome hated that model.


And I made sure that the apartment was reorganized. It wasn't even in my domain, but I made it kind of a religious point. Okay, let's move on to continuous delivery. I'm sure everybody has been looking at his processes. Uh, one to reduce the time to market, do a lot of automation increase the velocity. Right. And what do we typically see a bit of three choices. Again, you see some automation, uh, popping up people experimenting with tooling, you see a full continuous delivery pipeline in place. So you bought all the tooling. You could lay your hands on and still you do release this like twice or four times a year. Um, for example, in released range, maybe, you know, the, uh, scalable agile framework, it, it tells you to create release trains, or you say, I have my CD pipelines in place, and we bring functionality to the markets, new releases quite frequently, where are we as a community?


Okay. That's, that's an amazing one because there is a whole industry around tooling, the risk companies who earn money on this. Um, again, uh, all the companies with an I and O and M and age, but smaller ones as well. Again, I won't make, I won't do advertising, but a lot of open source tooling as well. And I think, uh, I'll promise you guys to, uh, publish a YouTube video about our own CD pipeline, because it might simply help you and accelerate because I think we, as a dev ops community, we need to do better on this. Okay. Now, a real tricky one. Think about the agile. It is about learning from your customer response, right? And we say, we, we aim to fail fast address the biggest problem. First, it's a mindset thing, and I'm sure we all learn by failing fast, but again, three choices. We every now and then get some survey based feedback. We do include feedback into our backlog and we prioritize through giving the bleeders somewhat less budget. Most likely I'm not predicting the outcome here, but it's only human behavior, right? Oh, it's we truly take, um, through mess ups, through failures, out of the markets, we declare failure. Where are we?


I'm also a clear winner.


Now I would, I would, and this is a bit what I was expecting. And, and we've seen this happening as well. A couple of things here, what I wrote really encourage your, uh, engineers to do. And it's a very simple thing. Every single user interface should have a button that says, I want to give feedback whether it's your mobile app or whether it's your back office system supporting your mid and back office processes, or whether it's people in your shops or branches or whatever you call them. Every single user interface should have a button that says, I want to give feedback. And there is a format for this. It's the famous five star rating model. Everybody understands that. And a bit of an open field that gives you some true feedback, right? And it's really, again, a mindset thing, design everything for feedback. And then I hope you avoid the second one. And you move from a to C, right? So I hear you think this is all cool, but what do I need to do with this? And it's a fair question. And I've asked this question many times, myself, many times. So let me tell a bit of a story. Every light, like we said earlier, everybody hates a traditional way of working. Everybody wants to move forward, but somebody needs to take the initiative.


Everybody, once you have taken the initiative, every body, the system will be against you. Where is your PID? Do you meet the acceptance requirements? What about your key controls? What about your budget? And to be honest, they're all fair questions. They're not the wrong questions to ask, but you need to give yourself a bit of room to prove on a small scale that you are right, but that needs some brave from yourself. So a bit of character. And like we said, if you feel you need to be accountable and declare failure and try again and try harder and prove your right. So don't get this encouraged. This courage is that the right word by Jeff's on failure, endorse failure, it's easily said, but very difficult to be done, but you can only be successful by being able to declare failure. And once you have this first success and you celebrate it, that's when the scary part begins, because then people start to have high expectations and you need to lay out the roadmap and say, this is not a quick win. This is not something that you can do overnight. It takes time to take onboard the full transformation, transforming people that might send the behavior, bring in the new tooling, change your processes, involve the business. It's a true journey. So manage the expectations by laying out the roadmap and finally be aware of senior management.


They want to declare standards. You're now show successful. Let's write the cookbook and declare the standard and return. So remain the mandate for your teams to keep on learning and experimenting. It's the only way you will keep the momentum in your change. Now, if we look back at this story, I should say, yes, there was a beginning that was that original block with probably there will never be an end to the story because in the meanwhile, like I said to you, we all continue to find answers to the important questions and the moments we declare victory and say, this transformation is done. That's the moment when the transformation stops. I thank you a lot for your attention. Thanks.


Thank you so much. Thank you.


Is there still some room for some questions or am I way over time? You're the boss.


I have a question. I asked you, um, you had told me a story about Denny Remi, uh, about where the idea came from. Could you just tell us that story, uh, because that idea around the mobile team, wasn't your idea. Would you mind just briefly telling me a story of, uh, where did that idea came from and what you did about it?


It's indeed a cool story. And I told Jean, and there were actually two people, two people, one was called Danny and the other one was called Everlane. And Everline is here in the room, but you will get extremely annoyed if I find the right, I'll give you one hint. She went, she laughs she laughs really loud And now she isn't laughing. Okay. So we had a horrible mobile app in the market, truly horrible. It had one star. And the only reason it had one star is the fact that you can't rate a app with zero.


That was our situation. And our competitors were way ahead. So with our board, we said that, and I said, do we need to do something about this? And marketing was all of a sudden in a hurry and we needed to deliver fast and perform miracles. And I went to one of my, uh, teams and I said, we need to do a mobile banking. Uh, let's go and create a project. Yeah. So I was thinking traditionally as well. And then after two weeks, I got an appointment in my schedule with Danny and Avalon and they Kwame into my office bits, uh, uncertain. We're going to the boss and we're going to tell him that the way he has organized stuff, it sucks. But how do we tell it? So they took an hour to tell me your story about how we should change things. And they were extremely nervous because I was so excited by their story that I kept on listening, which they weren't used to because normally I mess up people's presentations within five minutes by starting to make comments.


So I kept on listening and the more I listened and the more nervous they got and after about I think, 40 minutes and they were really thinking big, like beyond the point where we are today. Right? And I say, guys, I think we're going to do this, but I can't promise you we'll do it all over the place, but let's start small. Start with mobile. And you asked for one team for mobile, I'll actually give you two, you asked for two months to prove, I'll give you three and we'll put you in the middle of the building and I'll protect you in every way possible. So it was a true rewards. And that's how I talked yesterday over there, not to April line because I could remember what they said, but I couldn't remember what I said. I must have repressed that. Right. And that's how the whole chain started to brief people telling me you are not ever, ever going to get your mobile app. If we continue to do it like this. So let's try and change this. And I am still, I owe a lot of this change to those two people to second line manager, people in my organization. That's how it started.