I was at a conference recently and came across Dawie Olivier, CIO of Westpac Bank and Australasian-operating bank. That it took a trip to Texas to discover someone who lives in the same country as me was an ironic reflection on why industry conferences are still useful events.
Notwithstanding the weirdness that we’d never met previously, I was interested to hear of Olivier’s experiences within three different banks in different geographies. After the event, I caught up with him (and thanks must go out to Chef’s awesome PR company for arranging the conversation) to get deeper insight into how banks operate and what it means to innovate within their traditionally constrained environments.
I’ve spent some time consulting within financial services organizations in general, and banks in particular, and I have always been surprised at just how much legacy technology solutions prove to be a barrier to innovation. Add to that a highly risk-averse complex where regulation is often held up as a reason for NOT moving faster, and you have a setting that is, perhaps, the very antithesis of Silicon Valley pace. So, with this background, I sat down to chat with Olivier about his experiences.
CIO New Zealand Westpac Bank CIO Dawie Olivier
Westpac is Olivier’s third bank, and he has seen first hand what he calls banks' “theatre of governance”—an overwhelming culture that creates a semblance of control that banks (and, in fairness, other large organizations) cling to. A culture exists that clings to strong and strict gated review-delivery mechanisms. Olivier paraphrased Conway’s Law, saying the “complexity of the systems that an organization designs are domed to be as complex as the organizations themselves.”
Innovating within a complex organization
How can you be innovative within an organization like that? In Olivier's view, innovation is a result of learning to be agile and requires thinking about different things and, fundamentally, thinking differently. Olivier reflects on a move from big-picture thinking to taking small hypotheses and reacting to them. This approach is, of course, the opposite of the orthodox approach, which seeks cycles of validation before a project is even undertaken.
Riffing on his Conway’s Law theme, Olivier reflected on the approach that takes an existing complex organization and increases the complexity of the systems that are charged with maintaining them.
Not too long ago, as he recounted, development teams at Westpac would have a work life that consisted of a series of individual tasks that needed to be fulfilled. These tasks were generally disconnected from any single outcomes. Developer performance was measured by specification and output—once a task was finished, the developer would, waterfall style, move on to the next one. The problem with that approach is if the upfront documentation, or core hypothesis about the task was wrong, the work would simply be rejected. Similarly, work with errors would be rejected from downstream parties.
This goes against the basic humanistic desire to work within a specific context. This waterfall approach has no context and simply consists of tick boxes. Developers working a 40- to 60-hour week in that style would complete their timesheet but have no sense of closure or completeness upon which to reflect.
Thus, disempowered with any perspective on a finished product, organizations would have to create a large management overhead, with large teams of predominantly disconnected workers being applied to small tasks. This, of course, created a need for large resource planning systems and many management layers.
Fundamentally this is not an inspirational way to live, and morale suffers. The reason, as Olivier sees it, why developers move form large organizations to startups is because in the smaller organizations, agile teams can understand a single, consistent vision. Smaller organizations don’t have the “luxury” of lots of people waiting to be tasked, and hence people simply roll up their sleeves and get working. The feedback loops are immediate and obvious. And at the end of the week, workers can see progress to a bigger task and feel far greater job satisfaction.
Breaking away from waterfall and moving to agile
With this problem identified, what is a large organization to do? Moving from one culture to an entirely different one is a really hard thing. Simply saying to people “let’s change our working methodology” doesn’t help with the deeper-seated problem. The first step is simply to allow teams to have a conversation and identify how a great day at work would feel fro them. From there, you can uncover the behaviors that everyone individually would demonstrate. As Olivier put it, this creates a self-regulating principle.
Once this approach is created and people have the aspiration to feel and act differently, dissatisfaction with the current methods in place quickly rolls in. It then becomes a relatively easy step to allow people to experiment with the methods that allow them to work the way they really want to. It sounds trite, but Olivier's experience tells him that people aspire to be trusted and to trust others. They aspire to have their interests acknowledged, to collaborate, to learn and to have fun.
But, and here’s the rub, while those are lofty goals, how does that occur within an industry that is so focused, rightly or wrongly, on governance, risk and compliance? Olivier suggests something somewhat counter-intuitive: that these development stacks that are built to embrace and deliver agile actually result in better indications when things are wrong.
There is hard engineering underpinning the softer cultural aims of the agile organization, and this ensures faster feedback loops and clearer visibility are all steps in the development chain.
Olivier is a huge critic of what he calls “Gartner’s bimodal nonsense”—the idea of having two individual approaches to technology within an organization: one agile for blue skies projects and one traditional for more legacy projects. As he sees it, control from a heavily gated and governed process is an absolute fallacy. Compliance isn’t actually measured until the end of the project, and hence risks and impacts are far larger.
But Olivier isn’t just a theorist. He is tasked with delivering product innovation for Westpac. He points to the example of an entirely new payment engine that the bank is building on an agile basis using DevOps approaches. It is a big, hairy project, and traditional planning processes would have tried to have delivered a specification from the outset that, as a matter of course, would have had poor visibility into issues until the go-live date—despite the fact that during a project, invariably things break.
In terms of project planning, on a program like this, over half of what would have been original technical scope under traditional approaches was identified, in progress, as not being required. Much of the governance requirement that would have been in place from the outset to comply is no longer required.
The new agile methods work
The results, according to Olivier, speak for themselves. The team built compliance visibility throughout the project. What would have once been taken as faith until the go-live date can now be proved on an ongoing basis. Oliver and his team have added measures to show that the new methods are more effective and robust.
I wanted to quiz Olivier on his views about monolithic banking stacks and the different philosophies around what to do them. As he sees it, banks have two options: They can replace their core systems internally, thereby creating new legacy systems that only the bank understands. Or they can outsource this work to a vendor and create a future that largely rests in those vendors hands. Far better, as he sees it, is to build a capability within the organization that is able to contemplate good customer outcomes and to create modular, componentized technology solutions. Olivier’s mantra is to create nothing that is so monolithic that parts cannot be replaced in isolation.
And so, with a destination point achieved, what comes next? Olivier is quick to point out that banking agility is not a journey with a destination. He says banks should always be moving on to the next iteration—striving for a continuous evolution on the basis of what works well within the particular environment.
That is, of course, far from static. Olivier said in 10 years time, we’ll likely look back and think of today’s approaches a quaint and inefficient.
Finally, Olivier said he has no expectation of homogeneity in terms of how teams work. Only the people themselves can define how work should be done, he said. He fosters an active process of crowdsourcing technology tools and method.
This was a refreshing conversation with an industry thought leader. Olivier is aware of both the technological and cultural barriers and levers to innovation and agility, and he is doing a stellar job of shepherding his organization into the new age.