Interview by Vincent Snijder & Henk Venema
Vincent Snijder and Henk Venema had the privilege to interview Joost Brouwer. Joost Brouwer is grid-owner for Corporate Credits at ABN AMRO. Interestingly is that he also experienced what it takes to start up a brand new initiative and scale that towards a high level of maturity. In his current position as well as in his previous role at New10 he explored various ways to implement scaled agile.
What was the reason once to start New10?
New10 is a subsidiary of ABN AMRO Bank. In 2016 a new strategy was developed for the bank taking into account the different challenges and possibilities in terms of, for instance, new technology and new, agile ways of working. ABN AMRO looked at the way fintechs were able to quickly develop around certain financial services. They were able to act as a kind of speedboat while the big bank felt more like a mammoth tanker in terms of agility. Instead of buying such a start-up the idea was born to start one ourself. As of the start we could attract other type of staff, entrepreneurial professionals keen on a clear purpose. Working with new technology in a new organizational concept. Building value add services for small and medium sized enterprises. Delivering a first working version in a fast way and start learning based on the feedback of the first customers.
The idea was to create a kind of ‘best of both worlds’; the speed and technology of a startup while backed up by the bigger bank for, for instance, funding and specific expertise like risk management. But also with a solid base of existing customers as target group. New10 was chosen as such an ABN AMRO own initiative as it was recognized that the bank could profit from developing online corporate lending. Offering services based on new technologies but also by applying new risk strategies. After consulting a lot of potential customers, the objective was to be able to provide clarity to the customer about the loan application within 15 minutes. The traditional timelines for banks for this process were days and sometimes even weeks. The whole design of New10 was geared towards the objective of 15 minutes reply.
And did you succeed on that?
Yes, it started with an interesting agile experiment. There is tension between delivering fast with your MVP (Minimal Viable Product) and the need and necessity to have a kind of planning with milestones. The latter was important for managing the expectation amongst our stakeholders and for marketing communication. This planning was born after a kind of sprint zero where the first ideas were explored. We set the ambition to go live within 10 months from there. We combined incremental delivery in sprints with ballpark figure timelines. After 5-6 months we intended to have a kind of beta-version available for our launching customers. So we worked with a rough planning outline, refined in smaller sprints.
Do you believe that ‘having a planning’ is not in line with working in an agile way?
No not at all! It is one of the big myths of working agile that you don’t plan anymore. In reality you need a kind of planning and you work towards that moving target in an agile manner, constantly evaluating, learning and adapting. You need a kind of roadmap that you gradually refine into sprints. Some purist agilists are still opposing towards having a plan but in my view you need a plan in order to deliver. The real challenge was to find the balance between having a rough plan and the autonomy of the teams that deliver the value. It was a matter of facilitating the teams in terms of clarity and means to perform.
How did the way of working eventually succeed?
There were two important learnings for me.
In the first place a good product/market fit. Working towards an MVP we tried to reduce complexity in order to deliver fast, so we reduced complexity on many angles at the same time. Resulting in a situation where the resulting target group of customers for our MVP was too small. This made it almost impossible to find qualifying customers to our own constraints of the MVP. It took us 2 months to find our first customers; this revealed that we quick and drastically had to extend our scope before going live commercially. So applying an MVP approach should be used in a smart way. With the wisdom of hindsight I would have chosen an MVP with a larger reach in terms of potential customers.
A second learning point is that we were worried about the robustness of the end to end process flow. This was also a result of the bank-DNA, always focused on the risk you are willing to take. Especially in lending this is the case, think about potential fraud, compliancy with regulations, security risks etc. All kind of reasons not to go live. At the moment the beta version was ready, all traditional risk signs were flashing orange or even red. So the topic was raised to delay the implementation and increase robustness. This created a discussion. Some of the colleagues involved, with a more process oriented view, were concerned. Other, more entrepreneurial colleagues described that not going live with the MVP was even a bigger risk for the new company. You delay the moment of receiving feedback from your customer. Eventually we mitigated some of the banking risks and went live via an invite-only environment to control traffic. This gave way to start learning from the customer experience and eventually drastically impacted the new roadmap. So going live prevented us from going forward with a roadmap leading to a product that the customer wouldn’t like. A big learning point, especially for the people coming from a banking background was to start thinking in terms of business risk.
For a starting company like New10 we learned that there is a huge difference between bringing your first proposition live and the next phases of the company. First because of the fact that you have to service your new customers and later, when you are offering multiple products, that you also need to serve to thousands of customers.
In terms of working agile, the first phase was really focused on delivering an MVP and beta version, constantly refined by the feedback of the launching customers. One focused team with roles in the team geared towards agile delivery.
After going live, the organization was designed towards delivery of services while developing new and existing products. First of all with 2 purpose teams, one focused on customer experience and one focused on product development. We organized it in such a way that every individual in the organization was always linked to both teams. The technical staff as well as, for instance, the marketing experts. At a certain moment there was the need for an additional care-team, further extending the number of teams. The leadership team was constantly monitoring the situation and facilitating the teams from their individual point of view like product development (my focus), sales and technology. In the beginning the first team was a monolith handling everything and sharing the same code base. Later on, New10 was more and more organized in autonomous teams responsible for their own microservices, business KPI’s and roadmap towards the future. We learned a lot from studying best practices of other companies, startups and scaleups. One of the things we adopted was the use of OKR’s (Objective Key Results): derived from your longer term objective make clear choices for the priority of the next quarter. The leadership team described the strategic priorities and ambition, leaving the way how that could be delivered up to the teams. The teams created their own quarterly ambition of what was deemed feasible. This constantly designing of the best team compositions and the right combination of micro services was one of the most thrilling experiences for me working in the New10 setting. This was constantly experimenting on finding the best possible solutions.
It is super interesting to hear this story of a kind of lifecycle of an organization. Starting it up and experiencing what happens next. Especially the link with OKR’s is interesting. What did you do to make these OKR’s visible as meters on your dashboard?
We used the adagio that if there is software that can make your life easier, we use it. For instance, we used Perdoo for our performance board. It gave the transparency for all to check the status, also on your mobile if needed. This is more or less still the situation at New10 although it increased in staff from 10 to 100. And the experimenting still continues. For instance, the concentration of data scientists and UX designers in order to strengthen the combined craftmanship. Maybe later on these specialists will become part of the other teams again. So also your organizational design should be as agile as needed.
There is one aspect that I really would like to stress and that is the value of teams with staff from various backgrounds. They bring best practices from other industries like a booking expert from Booking.com and a branding expert from Coca Cola. This improves the learning time, combined with cultural diversity. New10 works with people of more than 20 nationalities. Creating such a best place to work attracts other international experts.
Do you think the level of agility at New10 will be restricted at a certain moment if you continue to expand?
In general, when complexity increases, the lead time to change increases too. It differs if you have to serve a few customers or products. But the DNA of the organization will secure a better business agility than in a company with another DNA.
Can you elaborate on the role of leadership for organizations like New10? What was needed in order to create a culture where experimenting was the norm?
What worked for us is that we did not have a CEO. We were a leadership of 3 people, each with our own focus. This caused sometimes tension between the various lenses but that tension is healthy. You have to find solutions in the balance between different aspects collaboratively, not by asking the boss for guidance. We asked everyone sometimes the question ‘what would you do if you were the boss here?’. This stimulates entrepreneurial behavior in the whole organization.
Let’s switch the focus from New10 to ABN AMRO. Can you elaborate a bit on the agile journey of ABN AMRO?
As with many other big organizations, agile ways of working started within IT. Considered first as the new hype following up Lean. In 2016 however the value of scaled agile was recognized as there was too much distance between business and IT with too much handover points. This caused disturbance and delay of delivery. The trigger to implement scaled agile was a strategic decision, inspired by what was happening in parts of the organization. But also inspired by other companies: what was their experience. Derived from that our own strategy was designed to organize ourselves in tribes, or grids as we call it. Centrally started, but further development within the grids was up to the grids themselves.
I noticed this myself when I returned in 2020 after a few years working at New10. In certain aspects the bank has further developed but in other aspects I would have expected more progress. It was to a large extend up to the grids themselves. Sometimes depending on the composition of teams and grid leadership.
There is also another aspect worthwhile mentioning. Contrary to New10, the bank has heavily outsourced its IT services meaning that the bank IT staff was more focused on directing the collaboration with the outsourcing partners. We realized that Tech is a core competency for a bank and that we needed to have our own IT staff, in balance with our IT partners for certain types of expertise.
In January I became grid owner of Corporate Credits. It was an interesting challenge to join the bank and attempt to apply the New10 learnings at scale. How can you increase entrepreneurship and client & tech focus in a more complex and traditional organization?
Is your grid in terms of size comparable with New10?
No, the grid is bigger also looking at some aspects like process and product development. But things like sales or operations are not part of the grid. New10 was more a kind of ‘mini-bank’ with all skills needed for running a bank. In a grid you have more people but working in a smaller context, with the need to collaborate with other parts of the bank.
There is one thing that I haven’t mentioned yet and that is the value of Obeya. Especially in bigger
organizations it is important to steer on portfolio and performance. Obeya is a way to look at things
from various angles. Every week we have created our virtual Obeya event with the whole leadership
team. We align on our change portfolio, our performance, our solutioning and then again, the
portfolio. So every 2 weeks we focus on the main anchor point, being the change portfolio. This is a good way to create collaboration over the various shops in the grid. The weekly Obeya events and the quarterly alignment on OKR’s are the handles to constantly keep the grid on the right course.
In the beginning you used the metaphor of New10 acting as a fast moving and agile speedboat. Do you think that ultimately the bank could be seen as a fleet of such speedboats?
Although the consequence of a big organization is to manage the complexity I strongly believe that also in bigger organization you can benefit by granting more autonomy to your teams and organize around your business architecture. Those two topics are my focus points within the grid. Use OKR’s to set the course for the WHAT and leave it up to the teams to decide upon the HOW. This can be implemented very well in our organization: make choices in your leadership on the main priorities on a quarterly basis and learn and adapt accordingly. We can improve on this: organizing priority setting in a value chain instead of the fractioned business lines can help enormously.
I strongly believe that our business architecture is a far better framework to design teams then by business lines. A business architecture composed of bank wide customer journeys and capabilities. This gives good guidance to organize your multidisciplinary teams. As an example, I would like to mention Collateral Management. There are a lot of regulatory requirements for that. You could use a project for each of those regulatory guidelines like EBA or Basel IV. This could easily lead to a lot of projects all focused on collateral management. So apparently collateral management is a capability that is important. So make sure that a dedicated team serves all the different stakeholders in an OKR based rhythm, on short and longer term.
This sounds like a major change for a bank to step away from the siloed approach. How do you see that?
It’s a process of gradually becoming better and better in implementing scaled agile. Learning by doing. This creates a growing number of people believing in the same way to go. I am confident that the bank is on the right course to become more and more agile, creating the speedboats. The biggest challenge is the time granted to get to that point. You have to do that better than your competitors in order to make the difference.
What is your opinion on the question that some people say that you need to change the organization first while others say that you best start implementing your agile collaboration processes and that structure will follow?
Within our own domain we choose to start by organizing ourselves around the business architecture of corporate lending. We than expanded towards other units that were needed to make it a success. This can be done rather quickly. If you would wait for the bigger structure of the bank to change first, you may have to wait a long time. At the same time, you need the senior management support for your own experiments. Important is to keep the generic principles constantly in mind like organizing around your business architecture and making the split between the WHAT and the HOW. You can experiment with that within certain boundaries.
You have the unique experience of being part of an agile journey within New10 as well as within ABN AMRO. What would be the main learning points of both organizations towards each other? What could others learn from your experience?
My New10 experience of working in a small team with focus on the customer and collaborative responsibility to solve issues is priceless. Cheering IT engineers when a new customer came in was great – but hard to implement in a big organization. Experiencing this as a leader is important.
Another element is that the role played in New10 automatically forced us into Tech. We sometimes said in New10 ‘we are all business, we are all tech, we are all risk’. Big organizations can learn from that.
It is much easier to act upon challenges in a small organization like New10, compared to ABN AMRO. So I think the biggest learning experience for ABN AMRO is the way how complexity is managed in a small organization.
New10 can definitely learn from ABN AMRO about the way they handled certain issues coming from bigger volumes. Not with the idea to just copy that approach but to be open to learn and implement an approach that is considered best in the context of New10. You can learn from your big brother without making the same choices.
Another important learning point between people at New10 and people at ABN AMRO is to value each other’s context. That is always the case when you assess a best practice. The true value comes if you understand the context of the experience.
