Ron van Kemenade

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, their 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.

In that sense, it is not a cookbook. It's not a prescription for the DevOps doctor. It's our story, 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 suffer 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.

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. 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 this is good news for you all. I 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.

Now, like Gene announced me, I'm the CIO of ING. I have been in this role for three years. I'm 51 years old, so way too old for technology, right? I'm a dinosaur. I have one wife, two kids, and I love technology. 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 the number of employees, around 52,000. That's internal employees, so our head count. 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 $840 billion. 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, etc., of around $4 billion.

So you get a bit of 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, our strategy is what we call the Think Forward strategy. Think Forward is about empowering our customers to stay a step ahead in life and business. Maybe traditionally, banks were a bit in the rear-mirror business. We told you what your balance was. Could be 20 milliseconds ago. But we should actually be 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 "anytime" means something in terms of the number of nines. Then we empower our customers, so we look forward.

And this 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.

Looking back, when I joined the IT part 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 elaborate a bit. So there are a couple of statements on the slide, and this is what it really was like. And I'm sure that in many enterprises, this used to be the situation, or to a part still is.

Technology was treated as a commodity. So basically, everybody can do this. It's a matter of putting the plug 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 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 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.

So I decided to go to Google I/O. That was still in the days where it took slightly longer than two minutes to register. Since then, I have actually never succeeded. But I went there, and that helped me spark the whole transformation, and I'll come back to that.

So the whole transformation starts with me coming back from Google I/O. And I thought, "How can I transform this organization? Where do I start? How can I transmit the feeling that I got at Google I/O to my people?"

So I started writing a blog on the internet. You can see 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 encouraged 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 Tuesday evening as of 6:00? We'll simply occupy an office, an open space, and I'll pay for the pizzas.

That was the spark that enlightened 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 blog. The pizzas 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 how do you now start the fire? This was only the spark. How do you start the fire?

And that's when 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 waterfall way of working. Nobody is happy. It's like staying in a bad marriage because divorce is even worse, right? Nobody dares to change.

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 PRINCE2 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 started in parallel this campaign with 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 building. Nobody could ignore them. If you needed to go to the loo 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. 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 off the podium, one meter ahead of the other nine. That's where you have a big difference. 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 medieval ages, right?

So 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 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 Google I/O, 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 in 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, two Scrum teams that I just discussed, 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, came up to me and he said, "Ron, I read this great book by Jez Humble and Farley. It's called Continuous 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 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 Nolio and Artifactory and Git, 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."

We're 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 had this great experiment with the CD pipeline, and then we hit a brick wall. And 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 my colleague, head of infra, said, "Yeah, they offer you a platform as a service."

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 others, meaning the market, were delivering. So that's what I wanted internally as well. Again, an inspiring moment.

And we were a bit late, maybe. We heard about DevOps because my developers were now doing all this great stuff and continuous deployment, and the IT ops guys simply couldn't catch up. And we left them in the dark. We could say they're 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 DevOps.

So we changed the organization. No separate departments anymore for system management, or whatever you would call that, 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 debt, 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 web-scale architecture. Again, a new word. And it turned out to be that Netflix had faced a bit of similar reliability problems, and they started to re-engineer their 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 engineers started to pay off, because this was totally new. Again, new technology like Hystrix, ZooKeeper, NGINX, all of the above. Talking about API platforms and scaling databases like Cassandra, 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, 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 responsibility for the customer satisfaction."

And we created this BizDevOps 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.

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."

And how do you find a model in the market that helps you defining an 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 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 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 about me, by the way, but about my engineers and architects who have been invited by Gene, the previous ones in San Francisco.

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 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's always helpful to me. I can't live without structure. Really an engineering mind: it's always binary, or in three steps, or four paradigms, or whatever.

So you see here three big challenges: 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. 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 it when you're done."

They needed to take a different approach. Active, be included in the DevOps teams. How do you do that? What 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 them out and rehire new ones? Or do you give up and all outsource it 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 their tools. They love them. You could rather say, "Could I borrow your wife for a night 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 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, 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 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 key controls. And this is a horrible process, and engineers hate it.

So after we did that, now maybe slightly more than twice, like 10 times or 20 times, we decided this is such a horrible process. It's all manual. It's boring. Nobody gets... Let's automate this.

So we're now creating an audit robot. And 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 modeling, whether I do have that in place or not. This is a key control defined. I can do that every minute. Or my technical state compliancy, I can do that test 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.

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 Dreyfus 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, "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 inside. 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 continuous delivery pipeline for Linux and for Microsoft. We have cloud provisioning, fully automated. And we're still working on all the 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 where we are.

Now, what we learned is that there are different levels of adoption of a change. And again, there is a model here. It's by Ryan and Deci, so not by Ron van Kemenade, but by Ryan and Deci. 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 an even 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 supermarketeer, 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 dictates 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 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 immediately connect consequences to this. You all are aware what that could mean, but it gives us all insight in 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 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 Sendsteps.com, and I'll give you some time. The logon is DevOps. It's, by the way, not case sensitive, so the start could be 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 Mark when I can actually start.

Okay, if you're still not logged on, 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 are 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.

We're already now past the 200, so it's going in the right direction. You guys, I've been told, are more or less with 400. So if there are now 200 votes, that means that still somebody is struggling to log on, or to find the 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? Okay, but that was already before I started, or...

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.

It's a slightly different... They're more or less against.

Are we ready, Mark?

Yeah, Ron, A and B are almost equal. So the handover between design and build is 26, and handover between dev and ops is 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 BizDevOps model by Spotify.

And I would really encourage you guys to have a look at that. There are 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 three-party 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'm at the DevOps Summit, so there should be a question about DevOps. Again, three choices, and you can read them. I won't read them out loud.

So we do a bit of Scrum and Kanban development, which is really helpful to 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.

Well, it starts stabilizing a bit around 43% for the Scrum and Kanban. Next one is the permanent teams on 30, and the combined DevOps is around 25.

Hey, and actually there is some good news in there because 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. And we allocate budgets to our projects, and we need to have 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, it was still very much project-driven and PRINCE2, and PIDs 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 you start DevOps and 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, mature their skills? Or are they the owners of the P&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 are from IT and having the full responsibilities for the proposition. And the last one is the C number.

Yeah, I think they're more or less choices I would have expected. But within ING, actually, there were 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 Ron hated that model. 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 his processes, wants 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 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 releases like twice or four times a year. For example, in release trains, maybe you know the Scaled Agile Framework, it tells you to create release trains.

Or you say, "I have my CD pipelines in place, and we bring functionality to the market, new releases, quite frequently." Where are we as a community?

Well, that's a clear victory for number A. That is 56. We have some automation.

Okay. That's an amazing one because there is a whole industry around tooling. There are companies who earn money on this. Again, all the companies with an I, an O, an M, and H. But smaller ones as well. Again, I won't do advertising, but a lot of open source tooling as well.

And I think I'll promise you guys to publish a YouTube video about our own CD pipeline, because it might simply help you and accelerate. Because 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 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?

Or we truly take true mess-ups, true failures out of the market. We declare failure. Where are we?

Ron, also a clear winner, and that is we take customer survey feedback into...

Okay. Now, and this is a bit what I was expecting, and we have seen this happening as well.

A couple of things here. What I would really encourage your 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.

Like we said earlier, everybody hates a traditional way of working. Everybody wants to move forward, but somebody needs to take the initiative.

Once you've taken the initiative, 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 bravery 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're right. So don't get 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 the roadmap and say, "This is not a quick win. This is not something that you can do overnight."

It takes time to take on board the full transformation, transforming people, their mindset, their 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. They want to declare standards. You're now so successful, let's write a cookbook and declare the standards, and we're done. So retain 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 blog. But probably there will never be an end to this story. Because in the meanwhile, like I said to 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.

Q&A

Thank you very much. Thank you very much. Absolutely fabulous. Thank you so much.

Are we live? Thank you.

Is there still some room for some questions? Are we live? Are we live? Or am I way over time?

You're the boss.

Q: I have a question. I asked you... You had told me a story about Danny, Remy...

A: About Danny.

Q: ...about where the idea came from. Could you just tell us that story? Because that idea around the mobile team wasn't your idea. Would you mind just briefly telling a story of where the idea came from and what you did about it?

A: Yeah. It's indeed a cool story, and I told Gene. And there were actually two people. One was called Danny and the other one was called Eveline, and Eveline is here in the room, but she will get extremely annoyed if I point her out.

I'll give you one hint. When 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 an app with zero stars. That was our situation. And our competitors were way ahead.

So, with our board, we sat down and said, "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 teams, and I said, "We need to do mobile banking. 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 Eveline. And they came into my office a bit 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 him?"

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.

So I kept on listening, and the more I listened, 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? I said, "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. That's how I talked yesterday over dinner to Eveline, because I could remember what they said, but I couldn't remember what I said. I must have repressed it, right?

And that's how the whole change started. Two brave people telling 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 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 a lot. Thank you.