London 2016
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.
Rv
Ron van Kemenade
CIO, ING Bank
Transcript
What I'm going to talk about is actually about people. That's why it says nothing beats engineering talent. Banking is about technology. Technology is about people, the 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 DevOps 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 <laugh> during your transformation. But let's start with a video that shows the power of all these great engineers within ING. So did you like it?
I'm extremely proud of all these people in the video and all the other ones that are not in the video actually. Um, I'm starting to talk a bit, uh, 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 at 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, nah, 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 DevOps transformation, and a big fan of every engineering behind the continuous delivery. And all of the above will come back into my presentation. Now, for those who are maybe slightly less familiar with ING, we're a bank, 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 headcount, we have a market cap, or at least we had at the end of last year, around 48 billion. We have a balance of around, uh, 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, risk, cost, 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 DevOps transformation in this bank.
Now, a strategy is what we call the think forward strategy. Think 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 our 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 forward. So being predictive and keep on improving. Now, this was quite a challenge to live up to that promise and that triggered a 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 light dust storms, freezing cold and dangerous caves 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, this used to be the situation or two apart still is technology was treated as a commodity. So basically everybody can do this, right? It's a matter of, uh, pulling the pro 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 adherence. So CMMI 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 of infra, they were supposed to take care of all the non functionals 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 it, I must say, after three months in the job, I was more or less ready to give up to quit, or even anything more rigorous
<laugh>.
So I decided to go to the Google io. That was still in the days where, uh, it took slightly longer than two minutes to register. Since then, I actually never succeeded. But I, 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 the, 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 it is 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 when 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, uh, Tuesday evening as of six o'clock, we'll simply occupy an office, an open space, and I'll pay for the PTAs, right? That was the, the spark. The spark that then light 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. There was one block.
Uh, the pizzas, um, cost me a little bit more than I expected because, uh, they kept on coming back every Tuesday. And every Tuesday there were more people <laugh> and nobody was willing to pay for them. So <laugh>, so how do you now start a fire? This was only the spark. How do you start a fire? And that's when we used, um, I, I need to, I needed to set an example. So I used 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 thoughtful way of working. Nobody is happy. It's like staying in a bad marriage because divorce is even worse, right? Nobody dares to change. So I, we said, let's, two people came into my office and they said, Ron, if you really want us to create a great mobile experience, you are never going to get there with this waterfall way of working with Prince two, defining the world and the rhythm of how we do things. Let's do it 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 top. And we actually didn't tell what, 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 lu or to the restaurant, you needed to get past them. 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 of 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 R 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 DevOps. That presentation does not exist. Maybe we could write 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. And 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. 'cause without the people, you can change the process, you can change the tooling. But like they say in it, a fool with a tool is still a fool, right? So you need to try start at the people part. And then we moved on, we started with scrum two 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 these two small teams doing scrum. 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, uh, Farley, it's called Convenience Delivery. I actually never imagined that this was already available in the markets. We were still struggling with all kind 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 <laugh>. Yeah, you fill in the blank spots.
And there this whole continuous delivery suite was laid out in that book. And it had stuff like Jenkins and Puppet and, uh, Nolio 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 moment. 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, the, the brick wall was infra. And we had a conversation with the head of infra. And we said, what, how do we fix this? How do the public cloud providers fix this? And then, then my colleague, head of infra said, yeah, they offer you a platform as a service and 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 others were, uh, the others, meaning the market was delivering. So that's what I wanted internally as well. Again, an inspiring moment. And then, and, and we were a bit late. Maybe we heard about DevOps because my developers were now, uh, 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 were 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 morning, let's include the IT ops part into our development. And we found out that there was actually a word for that called DevOps. So we changed the organization, no separate departments anymore for system management or whatever you would call that. Uh, 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 development, we managed to build up such a huge pile of technical depth. It was, it was beyond belief. And that started showing in our reliability. So we needed to change our architecture as well. That's when we came up with a webscale architecture, again, a new word. 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 historic zookeeper, gins, all of the above, talking about API platforms and scaling databases like Casandra, 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, 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 it. 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, as will the engineers take responsible responsibility for the customer satisfaction. And we created this biz DevOps model. And if you look it up at all the open source publications by Spotify, you recognize words like tribes and squads, chapters, guilds, and they're all there.
They're all there. And finally, again, we came back to the engineering, the people part and said, 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 plays? Is he or she somebody who's able to perform a task that somebody else spells out? Are you able to, um, more or less copy your task, have experience? Are you 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, uh, 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 DevOps summit and is considered to be a guru? I'm not talking by me, uh, by, uh, by the way, but by my, uh, engineers and architects who have been invited by Jean, 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 driver's model. You can look it up on the internet. Again, we did not invent anything. We went outside and found 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 live without structure. And so really an engineering mind, it's always binary or in three steps or four paradigms or whatever. So <laugh>, you see here, three big challenges, right? The capabilities of our engineers, how to 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 in, uh, 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 DevOps teams. How do you do that? What is are the typical skills of a fully mandated product owner? Look at our own engineers. They needed to have different knowledge, different tooling, different capabilities.
Understand the business, take responsibility, not moan 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 you all kick 'em out and rehire new ones? Or do you give up and all outsources to somebody else? Three bad 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. It, you could, you could rather say, uh, could I, uh, borrow your wife for a night and and of drinking, right? Of drinking instead of, could I have your tool and replace it by something else?
And where 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, 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 had three paradigms simplify the technology. Everything we don't need, we kick out everything that is almost redundant, will 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 X 86 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 you, you will all know about socks, right?
Surveying oxley. And you need to do this horrible testing twice a year, at least to comply with the, the socks, uh, key controls. And this is a horrible process and engineers hate it. So after we did it, uh, now maybe slightly more than twice <laugh> 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 robot. And we don't need, 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 defined. I can do that, uh, every minute or my, uh, technical state compliancy. 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 whether 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 driver's 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 expert. 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 engineers sight. They need to prove to the world that they can do great engineering. So they contribute 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 let them on the process side, on the automation side, we now have a full containers delivery pipeline for Linux and for, uh, 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, uh, part, you see, uh, where we are <affirmative> now, what we learned is that there is different levels of adoption of a change. And again, there is a model here. It's by Ryan and Daisy, so not by Adam, but by Ryan and Daisy. And the left part is from the original model. And it's so difficult, the words, you can immediately forget them. So I made a 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. A can 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 a 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, uh, 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 did take 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 a DevOps community, right? And that's the part where you get a vote, and I promise I won't, uh, uh, immediately connect consequences to this. You all are aware 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, uh, non-personal account. So no, uh, 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 uh, sensei.com and I'll give you some time. The, the log on is DevOps. It's by the way, not case sensitive. So the, the start could be a, a capital D or a small. And I'll give you some time, and I, if I'm correct, I get a bit of a signal from, uh, mark when I can actually start. Okay? If you're still not logged on, 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. <laugh>, you make a choice,
<laugh>,
And by the way, if you choose one, you are lying because then you're not supposed to be able to read the slides, right? So only two and three are options. <laugh>
Rolling now past the 200. So let's going in ion,
You guys, I'm, I've been told are more or less with 400. So if there is now 200 votes, that means that still somebody is struggling to log on or to find a website or doesn't know how to get his laptop rebooted or has fallen asleep. Mark, what is the outcome of the vote of this first test question
Around 85% already transformed.
So,
Okay, but that was already before I started or <laugh>. Okay, so this was only the test question, right? It was a bit of a joke, but still, thanks for the compliment. Now to the serious ones, again, three choices. It is about, because you guys went to this DevOps 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 did we take out the handover between dev and ops, or did we take out the handover between IT and business? Where are we as a community? Again, your vote.
Hold over again.
<laugh>.
Are we ready, mark? Yeah.
Rolling. A and B are almost equal. So the endover between design and build is three, six, and handover between offices around the same.
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 ING is as well, except for the Netherlands, where they fully adopted the biz DevOps 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. It's really very equal, where a tribe 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 the, I mean, I'm at the DevOps summit, right? So there should be a question about DevOps. Again, three choices. And you can read them. I I won't read them out loud. Um, yeah. So we do a bit of, uh, scrum and ban development, which is really helpful to, uh, lower your time to market or you have DevOps teams and your resources are still allocated from those teams to projects. Or you have fixed teams managing a backlog that facilitates more than one initiative. It's all possible. It's different levels, different stages, whatever you call it. Again, your votes
Our rolling start stabilizing get around 43% for the scrum independent. Uh, next one is the permanent team. So 30 and, uh, combine the on around 25.
Hey, 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 DevOps thing, but we will still have our projects, right? And we allocate budgets to our projects and uh, 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 DevOps, but in reality, we're still very much project driven and PRINCE two and bids 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 DevOps and uh, you continue DevOps, 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, uh, uh, lift their to, to mature their skills? Or are they the owners of the p and l of the proposition itself? Where are we as a community?
Well, number A and C are fighting for the first place in this case. So r from IT and having the full responsibilities for the proposition. And uh, the last one,
Yeah, I think that there are more or less choices I would've expected. But within ING, actually there was, uh, 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 IT 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 such a proposal, point them to this presentation and tell them, rom hated that model
<laugh>.
And I made sure that department was reorganized, 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 its processes. Uh, want 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, uh, you could lay your hands on and still you do releases like twice or four times a year. Uh, for example, in release 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, in place and we bring functionality to the market. New releases quite frequently. Where are we as a community?
That's a clear for number A, that is 56. We have some automation.
Okay?
Okay. That's, that's an amazing one because there is a whole industry around tooling. There is companies who earn money on this. Um, again, uh, all the companies with an I and O and m and h, 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. 'cause I think we as a DevOps community, we need to do better on this. Okay? Now a real tricky one. Think about 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
<laugh>,
Most likely <laugh>. I'm not predicting the outcome here, but it's only human behavior, right? You're right. Oh, it, we truly take, um, true mess ups, true failures out of the market. We declare failure. Where are we
Also a clear winner? We take customer survey feedback.
Okay,
Now I would, I would, and 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 would 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 <laugh>, 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, like, 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, everybody, 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 bravely from yourself. So a bit of character, and like we said, if you fail, you need to be accountable and declare failure and try again and try harder and prove you are right. So don't get this encouraged, discouraged, is that the right word? By just some 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 a roadmap and say, this is not a quick win. This is not something that you can do overnight. It takes time to take onboard that 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, beware of senior management day. Want to declare standards? You're now so successful. Let's write a cookbook and declare the standard and we're done. 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. But probably there will never be an end to this story because in the meanwhile, like I said, you, we all continue to find answers to the important questions. And the moment 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. Very absolutely fabulous. Thank you so much. Uh, are we live? Thank you.
Is there still some room for some questions or am I way over time?
Oh, we are.
You're the boss.
<laugh>. I have a question. <laugh>, I asked you, um, you, you had told me a story about Denny Remy, uh, about Denny, where the idea came from. Could you just tell us that story? Uh, because that or idea around the mobile team wasn't your idea. Would you mind just briefly telling a story of, uh, yeah, where the idea came from and what you did about it?
It's, 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 E Evelyn. And e Evelyn is here in the room, but you will get extremely annoyed if I point her out.
<laugh>,
I'll give you one hint. She, once she laughs she laughs really loud and now she isn't laughing.
<laugh>,
Okay? So we had a, 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 star.
That was our situation, and our competitors were way ahead. So with our board, we sat down and said, we, we need to do something about this. And marketing was all of a sudden in a hurry. And we, we needed to deliver fast and perform miracles. And I went to one of my, uh, teams and I said, we need to do, uh, 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 Avila, and they came into my office bit, uh, uncertain. We're going to the boss and we're going to tell him that the way he has organized stuff, it's sucks <laugh>, but how do we tell it? So they took an hour to tell me a 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, <laugh>. So I kept on listening, and the more I listened and the more nervous they got
<laugh>.
And after about, I think 40 minutes, and they were really thinking big, like beyond the point where we are today, right? And 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 reward. Uh, that's how I, I talked yesterday over dinner to <inaudible> because I could remember what they said, but I couldn't remember what I said. <laugh>, I must have repressed that, right? <laugh>. And that's how the whole change started. Two brave people telling, uh, me, you're 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, I am still, I owe a lot of this change to those two people, two second line manager people in my organization. That's how it started. Thanks.