Digital proficiency is no longer just “nice to have” for banks; it is a requirement for successful customer engagement and long-term growth, explains Ron van Kemenade, ING Bank’s chief information officer. In 2010, the company adopted an agile approach to software development and delivery—launching products in rapid iterations and adjusting them based on customer feedback. The shift to agile helped the bank clarify its development strategy and its customer value proposition. It also prompted ING to redefine its employee value proposition by shining a bright spotlight on the high-quality engineering talent required to lead digital innovation. In this edited conversation—with McKinsey’s Robert Carsouw, Andrea Del Miglio, and Naomi Smit—van Kemenade discusses the critical role that skilled software engineers have played as the company shifts to agile ways of working.
McKinsey: You’ve been vocal about the importance of digital technologies in today’s banks. What do they look like at ING?
Ron van Kemenade: Digital is not a temporary thing. It’s not a one-time program. It’s a change that is affecting the whole industry, and getting better at it has become a permanent ambition for us. Since I joined the bank, we’ve been working hard to make it more digital. The role of technology within ING has had to change from being a support function to being a fully integrated part of the business, actually driving strategy for the bank.
You can see the evidence of that. We’ve digitized our processes to make transactions clear and easy for our customers. We’ve invested heavily in channels and touchpoints with our customers, introducing mobile and other technologies so that we can offer our services 24/7, anytime, anywhere. We’ve invested in analytics and in getting a 360-degree view of customers to better empower them to make important decisions about their financial assets. And we’ve introduced agile1 ways of working—in particular, a DevOps model.2
McKinsey: You’ve also talked about the importance of developing a strong IT function and skilled software engineers to support agile initiatives. Why is this so important?
Ron van Kemenade: My first day in my new job—actually, in the first or second hour—one of the lead architects came into my office, shook my hand, and said, “Ron, welcome to the dark side of the moon.” And he couldn’t have said it better, because back then, IT was definitely not the place to be in the company. It was considered a pure support function, a cost center, located somewhere in the basement. As an IT guy, you would only come out of the basement to take responsibility for yet another failure—an outage or a project that was overdue. That made people shy, if not uncertain, about their roles.
Ron van Kemenade
This situation has completely changed at ING over the past couple of years. We now fully recognize the importance of software engineering because it is driving our strategy. You can’t have any impact without highly skilled engineers; even if you change the technology or digitize processes, you need top talent behind all that.
McKinsey: What did you do to turn things around?
Ron van Kemenade: We started out by stressing the need for and importance of an engineering culture at ING, particularly given our push to become digital. I’ll give you an example. Once I had been in my position for a couple of months, I wrote an internal blog aimed at our software engineers, basically saying we have the greatest profession on earth. We get to work with the best technology, supporting great customer propositions, and we get applauded for that by our business colleagues every day. But I also raised the questions, How different is this picture from day-to-day reality? How excited are you about your job? Building on that blog, I asked the engineers to step up and participate in what we, back then, called the Java Community, with the goal of building the best mobile app in the world. The first meeting, on a Tuesday evening, 30 engineers showed up. They were curious, not convinced that this would actually turn into something. Maybe they showed up because they knew I was paying for the pizzas. But from that effort, from those meetings, came our mobile-banking app, which has been very successful in the Netherlands and Europe for many years now. You need to start somewhere, and we started by calling on people’s sense of purpose and their pride as engineers, and we built something beautiful.
McKinsey: How did you scale up this cultural change?
Ron van Kemenade: The Java Community was the first step. We showed the engineers that a small success could be inspiring, and that they would be acknowledged for their efforts. We put the mobile-app team in the middle of the building, so everybody would see that these guys were working in a totally different way. That prompted other teams to hook up with them, as well. I had negotiated with the head of IT channels to move six teams to an agile model within six months, but within half a year I had 26 teams. Non-negotiated. It was simply because people wanted to be part of the success. Even teams that I wouldn’t have expected, like those in the mainframe area, started thinking: how do we do agile, what tools are available, and how can we make the change? It was an organic, stimulated change rather than a fully controlled and orchestrated change.
McKinsey: I’m sure you encountered some obstacles as you attempted to introduce agile within the greater bank community and to empower IT engineers.
Ron van Kemenade: Yes, there were many obstacles, and they were all over the place. For example, we found it was difficult for engineers to acquire new knowledge, given our existing budgets for development and education. We saw impediments in our appraisals and in most of our formal development processes, which were waterfall and CMMI3 driven. We had to look at management behavior, as well. In all industries, but particularly in banking, you try to mitigate risk. The waterfall way of working—where every step is predictable, at least in theory—gives you a sense that you know what the actual outcome will be. The agile way of working, where you drive toward the next minimally viable product, learn by doing, and change course based on feedback, brings you closer to the biggest possible mistakes and hence to more risk. Of course, getting closer to customers can also help you mitigate risk, but it’s been quite a challenge getting management to believe that. We could only convince them by showing them.
McKinsey: How did you bring management around to your way of thinking?
Ron van Kemenade: The transformation itself was an agile journey. We set short-term goals. There was a defined point on the horizon, but we knew only what we would do over the next 90 days and changed course depending on how things worked out. During that process, we had many milestones that turned out differently than we expected.
I’ll give you one example: the role of the infrastructure organization in the bank totally changed. We used to throw all the nonfunctional requirements at the infrastructure group and say, “You take care of that,” for disaster recovery, day-to-day monitoring—basically, everything. But when we adopted a DevOps model, we found that we needed to change the way the infrastructure team interacted with the engineers working on applications. More standardization and more automation were essential.
We never try to figure out these things ourselves. We always look outside for answers. Others ahead of us will have encountered the same impediments, and they probably will have found some solutions. In this case, we learned a lot by studying what digital-born companies had done to reorganize themselves into tribes, squads, and chapters; the technologies they used; and how they redefined their competency models.
McKinsey: How did you change the way you evaluate and appraise talent as you shifted to agile?
Ron van Kemenade: We needed top engineering talent to carry out digital initiatives, so we needed to change the way we attracted and developed people and the way we appraised them. Our HR processes weren’t fit for that purpose, so two years ago, we looked outside—specifically, at Netflix and what they were doing. We found the five-stage Dreyfus model,4 which is based on observable behaviors, not the number of diplomas you have. It measures how you acquire knowledge, how you apply it, and how you transfer it across teams and the organization. We defined our own five stages of IT-engineering performance. We involved the engineers themselves in this process. We asked them which areas of knowledge and which competencies they would expect themselves and their peers to have at various levels of maturity.
At the bottom level, novices are capable of performing small tasks based on limited knowledge about the technology or the environment, but they still need guidance to perform their work. At the highest level, the experts are fully technology agnostic. They find solutions to new problems. They are the lighthouses—people come to them for guidance. What we learned from Dreyfus is that one expert is actually the equivalent of many novices or advanced beginners. Nothing beats top talent. If you have people with the competency and knowledge to thoroughly understand problems and to oversee the consequences of proposed solutions, that is so valuable.
An operating model for company-wide agile development
McKinsey: What challenges did you face in implementing this new engineering profile?
Ron van Kemenade: People immediately understood the intrinsic logic behind it and their roles under Dreyfus. But there was a bit of a mismatch between roles and pay grades—what they were, and what we wanted them to be. We had to make some adjustments. We needed to explain to people what we’re measuring now and why we’re emphasizing certain skills or performance factors. We needed to explain to people why they would be appraised in a way different from what they had been used to. Our process now involves collecting 360-degree feedback from peer engineers, line managers, and even managers in adjacent domains. In the end, we appraise engineers based on observable behaviors, and we make adjustments.
McKinsey: You’ve made a number of changes to strengthen the IT organization. What sort of impact have you seen so far?
Ron van Kemenade: Let me give you an example. When we created our first two scrum teams for mobile development, we were already behind in the market. The other banks had launched their first mobile apps a year and a half ahead of us. We needed to catch up. If we had tried to do that in the traditional waterfall way, designing a multiyear app-development program, we never would have caught up. Now, we’re among the first to implement new functionality. And I’m even more proud that our engineers are implementing the backlog of what the business has wanted to bring to our customers. We are now offering you the ability not just to know what your balance is and what transactions occurred but also how to look ahead and start planning what you can spend until the next moment you will receive money.
McKinsey: What challenges remain?
Ron van Kemenade: We want to make sure we have the same global scalability that fintechs and other competitors have. We need to improve our portfolio management; address our underlying technology architecture, which today is still quite distributed; and continue to invest in a single way of working and a successful, collaborative community. We want to leverage all the great talent we have—in marketing, engineering, operations—and use it to have a global impact, not just a local one.
McKinsey: What would you do differently if you were starting all over again?
Ron van Kemenade: There is one thing. We addressed the automation of our processes, creating a continuous-delivery pipeline. We introduced agile ways of working. But we were relatively late to the game with our redefined engineering profile. We should have done that earlier. My recommendation to anybody embarking on a journey like this would be to start on the people side—make that the most important area of change early on.
