ANZ's new CTO banks on "big technology bets"

ANZ will use 2022 to bring clarity to the “big technology bets” needed to power its long-term ambitions, a strategy it hopes will focus the business and drive more value out of every IT dollar it spends.

Fronting this effort is ANZ’s newly-appointed chief technology officer Tim Hogarth.

It is, in many ways, a natural evolution of Hogarth’s previous role as the bank’s chief architect, where he co-wrote and led an uplift of ANZ’s engineering and architecture standards and practices, an effort that continues, and that Hogarth continues to front.

“A lot of what I was doing around architecture and engineering standards brought me closer and closer to some of the business strategy work,” Hogarth tells iTnews in his first interview since being appointed.

“Every single part of our business that we work on has something to do with technology. There’s nothing you can do in banking that doesn’t involve some significant prowess around technology.

“So I’ll be working a lot more closely with the business to help them think about the longer term direction of what we need to do with technology and how we can enable that to help with both existing and emerging business needs.”

That will influence some of ANZ’s technology choices, particularly where there may be overlapping requirements between business units and opportunities, to encourage more of a platform thinking approach.

ANZ shared elements of its platform thinking approach last year as well as a drive to improve the value of every dollar it invests into IT. It’s clear Hogarth has a key role to play in the execution of both.

“Anyone can create software, but creating scalable and durable value is hard, particularly when the business priorities and technology landscape is changing,” he said.

“Trying to get to the right decision for the bank involves getting a lot of stakeholders together, getting down to really understanding the business problem you’ve got to solve, and then working out the most efficient way you can use technology to solve it.

“Sometimes it’s [with] new technology, sometimes it’s a better use of an older technology, sometimes it’s consolidation of applications onto shared platforms.

“My interest is in trying to help the bank make those big decisions to drive bigger value out of every technology dollar we spend.”

Getting started

To understand where ANZ is headed, it’s instructive to understand where they’ve been.

The bank has around 5000 engineers distributed geographically across its worldwide operations.

“The vast majority of our technology people are quite close to engineering, if not engineers themselves, and of course they take their direction from the business teams,” Hogarth said.

With teams distributed geographically and between business units, ANZ sought in 2020 to find a common ground among its engineering workforce.

This led to a discussion and a now two-year drive to create and uplift common standards, principles, platforms and skills development opportunities for all ANZ engineers.

“When I joined ANZ, we’d had quite a distributed set of teams, which is not uncommon, so there were lots of different groups that were working for individual excellence and focusing on building out their craft,” Hogarth said.

“If you’ve got different teams working on different technologies with different techniques, there’s some inefficiencies that can be seen.

“We started looking at what we could build to make engineers more efficient?

“Sometimes that’s about getting real clarity to say, ‘These are the kinds of bets we’re making, these are the kinds of technologies we want to optimise for, these are the kinds of techniques we want everybody to follow; sometimes that’s about maintaining our [risk and security] obligations and a safety angle; and sometimes it’s actually about just plain old efficiency.”

In ANZ’s case, it was also about simplifying how engineers worked, and removing anything that would interrupt their “flow”.

Hogarth, together with technology group executive Gerard Florian and other stakeholders, set about defining the technology strategies and proficiencies that the bank wanted its engineering and architecture teams to “be really good at”.

“That led to the observation that we probably needed to bring the engineering teams closer together,” he said.

That led to an internal “summit” in late 2020 that was attended by representatives from each business and technology-aligned domain.

“We brought all these representatives together across all of the disciplines, predominantly software engineering over infrastructure, and asked what is important, what do we focus on, and what are the common problems?”

This led to the creation of a series of engineering principles that now guide the engineering and architecture functions, as well as a centre of excellence and stakeholder council to oversee the ongoing change effort.

The council is effectively “a meritocracy of engineering leads from across the group” working through a backlog of problems identified as important to engineering as well as to ANZ’s future direction.

Engineering principles

The first ANZ engineering principle is about embracing the future.

“This isn’t about chasing shiny toys but making sure we go for newer technologies that are an inevitability and tell our teams we’re going to go after them as long as there’s a material advantage [to doing so],” Hogarth said.

This is somewhat counterbalanced by a second principle of respecting the past.

“Generally speaking, there’s a lot of engineering teams that chase newer technologies and sometimes don’t necessarily respect decisions that are made historically that [still] make a lot of sense,” Hogarth said.

Further principles encourage engineers to be more empowered to assume greater responsibility, and encourage diversity across a range of domains.

“One of the things I firmly believe in there’s always going to be a diversity of technologies,” Hogarth said.

“You’re rarely going to have a very narrow set of technologies. It doesnt mean that you embrace everything, but it’s important to have a diverse set of technologies, experiences and people.

“That always makes you stronger.”

A previously mentioned area of focus, which is also reflected within ANZ’s principles, is this idea of flow.

“How we ensure the flowstate of engineers when they’re building things is important, but so is how teams work so we can achieve consistency and speed of collaboration,” Hogarth said.

“It’s about how we get code flowing from source to the customer as quickly as possible.”

There is also a principle around openness, with the intention being to share code and work openly and transparently, potentially accepting cross-team review and contributions.

This has some commonalities with innersource, a set of software engineering practices that are used to create an open source-like culture inside of an organisation.

Innersource has become popular particularly in Australian banking circles, and ANZ is also on that path.

The final principle is around continuous learning, which Hogarth sees as “a privilege and a responsibility” in the fast-moving, digitally-driven world of banking.

“I really love working in this industry. It just doesnt stand still,” he said.

“That basically means it’s fun because every year you’ve got to learn something new - newer technologies, newer techniques - which is good for the individual but is also a big responsibility.

“You’ve got that responsibility of making sure the technology evolves every single year and matches customer and shareholder needs.”

The CTO mindset

Where ANZ lands on its engineering and architecture uplift, though it is clearly an organisation-wide effort, is also very much influenced by Hogarth’s mindset.
The principles make it clear that there needs to be a material advantage present in going in a certain technology direction.

“I’m big on materiality,” Hogarth tells iTnews.

For developers and engineers, that - for example - means a choice of integrated development environments (IDEs) left to their individual preferences.

Supporting multiple IDEs isn’t seen as creating a material issue. “It’s like choosing a different colour pen,” Hogarth said.

However, tools for source control or binary management or that run developer pipelines are standardised; Hogarth sees no material advantage in having teams run different ones.

“The level of material benefit that a team had doing something in a different way when it comes to source control management or binary management just doesn’t add any value,” he said.

“So, to me, the key thing is those standards are - even if they’re hard conversations, they’re unequivocal in terms of their logic.

“One of the things we’re starting to do is consolidate where we’ve got duplication [of tooling] that’s low value.

“It often creeps into large organisations where people do things their own way for local optimisation, but if we want to get enterprise optimisation we’ve got to do a couple of things the right way for everyone.”

Hogarth noted that speed-to-market is sometimes put forward as a reason to “do things quickly in a non-standard way”, but said it was important to resist this.

One way to get coders using single tools - and the way ANZ is approaching the challenge - is to make using the standard tools so simple that other options are unpalatable.

“We want to make sure that the reason you want to use a common technique to store your source code or your binaries is because it’s really easy to use and it doesn’t take too long,” Hogarth said.

“That means teams have an incentive to use it - it’s as-a-service, turn it on, it takes care of us, it’s safe and easy to use, it’s transparent, it’s got a one-size policy that helps me and then empowers me, rather than constrains me.”

The wins so far

The standardisation work is ongoing, some of it still tightly-held within ANZ as commercially sensitive.

However, Hogarth said that two key outcomes of the work so far had been new and clearer career pathways for engineers, and a renewed focus on software provenance.

The career development aspect is clearly an area of personal interest to Hogarth, and he talks enthusiastically about his own path in the bank, and the need to provide all engineers with a similarly meaningful trajectory and opportunities.

“One of the reasons I like working in a bank like ANZ is there’s always lots of great opportunities in terms of business challenges to solve,” he said.

“In banking, engineering has gone from a niche to mainstream in terms of a ‘job family’. How you manage large groups of engineers, how you actually give them guidance, and how you optimise their skill sets is an evolving area of responsibility in financial services.

“The number of engineers is very significant, and we’ve got to be able to create good career and learning pathways for them.”

Software provenance, meanwhile, is a “newer topic” but one that had gained prominence in the past couple of years, owing to the rise of supply chain attacks and bugs discovered in commonly-used open source software libraries.

Hogarth highlighted the long “dependency chain” in enterprise software and expressed a belief that it is “incumbent on senior engineers to be fully cognisant of the entire chain of software that we’re actually using.”

“That’s not always an easy thing to do, but as you’ve seen from some of the problems we saw last year with supply chain attacks, it’s pretty important to have that depth of understanding that if you’re going to use a piece of technology or a software library that you’re deeply familiar with what you’re actually committing to,” Hogarth said.

“That’s one of the active discussions we’re having now.”