How we scaled a team to 180 mobile engineers and are delivering better than ever
Mitchell Johnson outlines the 10 principles behind the delivery framework that enabled ANZ to build a large world-class mobile development team.
When ANZ decided to build a brand-new digital bank, we knew it would require a new approach.
To deliver a dramatically new type of customer experience through a world class app meant we’d need to look beyond a traditional ‘shift left’ approach as it relates to software testing and agile delivery.
Bogging our engineers down with more communication and rituals or adding more process and redundancy to the system would be counterproductive to our goal of empowering them as much as possible.
And when the engineers are working across multiple countries, in this case Australia, New Zealand, India and Vietnam, it is critical that we not only empower them – but also actively try to remove bottlenecks and give them the flexibility to thrive.
We knew from the outset that if we didn’t do this well, the project would fail.
ANZ Plus’ four guiding development principles
We have evolved four guiding principles for the build of ANZ Plus (the new banking proposition delivered by ANZ). The nucleus of these existed before the first line of code was written in 2019 and have been battle tested throughout the delivery and scaling of the app.
Five years later, and with the number of talented engineers working on the Plus app now surpassing 150, we still strive for the same things -
Deliver a world-class application, built by a world-class team, using world-class technology, with world-class longevity.
Principles are easy and look great on the wall in the office kitchen, but living by them is much harder. That’s where our 10 pillars of large-scale mobile app development come in.
ANZ Plus’ 10 pillars of large-scale mobile app development
Bigger isn’t typically better when it comes to app development. Small squads doing niche things has been - and still is - the norm for most companies and app teams.
So, to pull everything together with a larger than normal and geographically dispersed team we needed a reliable and robust delivery framework to guide us.
The framework consists of 10 pillars, and we focused on each and every one of them throughout the build (and still do). Following the framework has accelerated our delivery, brought impressive reliability, and empowered our engineers as we’d hoped by giving them the flexibility to do great work and deliver a truly world-class mobile app.
The 10 pillars are -
1. Product vision
Customer-centric focus
At ANZ Plus, our product vision is firmly rooted in being customer-centric and prioritising their financial wellbeing. We strive to understand the diverse needs and challenges our customers face in their financial journeys.
Every decision we make is guided by the desire to create solutions that enhance their financial health, simplify their lives, and empower them to achieve their goals. We listen intently to their feedback and use it as the cornerstone of our development process.
Building high-quality, native apps
We are dedicated to crafting apps that are not only functional and high quality but also elegant in their simplicity. Our goal is to ensure that our applications ‘just work’ seamlessly and provide a smooth, intuitive user experience.
Our approach to app development is to lean into the strengths of native mobile platforms. By leveraging the unique capabilities of iOS and Android, we can deliver richer, faster, and more responsive experiences. Native development allows us to take full advantage of the hardware and software optimisations specific to each platform like the Jetpack Compose and Swift UI front ends that ensure our apps perform at their best.
This focus on customer experience has allowed us to keep our apps loading a customer's home screen under 1 second in any network environment by utilising offline storage of the customer's own data.
Only syncing with our systems when a new transaction has arrived allows us to offer one of the most performant mobile apps in the market - as well as reducing load on our backend services.
Continuous evolution through feedback and data
We recognise that the digital landscape is ever-changing, and so are the needs of our customers. That’s why we are committed to constantly evolving our products based on user feedback and data-driven insights. We maintain an agile development process that allows us to quickly adapt and iterate on our apps, ensuring they remain relevant and effective.
By analysing user behavior, collecting feedback, and staying attuned to market trends, we can make informed decisions that drive continuous improvement. This iterative approach ensures that our products not only meet but exceed our customers’ expectations, delivering lasting value over time.
2. Values driven
We are driven by a set of shared values. These values guide the team, rather than relying on processes, procedures or hierarchy.
We empower our team to take ownership of the complete application and the customer outcomes that they contribute to. To take responsibility of seeing tasks through from inception to the customers’ hands.
Every member of our team has an equal voice, and every person's opinion matters. If you think something can be done better, even if it’s not engineering related, say something. If you think something seems out of place or does not seem right, say something. Through doing so we will see positive change, either through action, or through learning, so always be curious, and always seek to understand.
We decide on things by discussing them openly, asking questions and building consensus. Anybody can float a suggestion; we then work out as a team what we would like to achieve, agree on a plan, and act to see it through to completion.
We resolve any problems that may arise as best they can, with no finger-pointing. We’re all in this together.
We celebrate our differences, be those cultural or opinions. We strive to be respectful and inclusive at all times and to create a sense of belonging.
First and foremost, we want our team to take care of themselves and those that they care for. If you have a personal matter of importance to attend to, then attend to it. If you’re feeling under the weather, take the time you need to rest. Just remember to inform your team .
We want our team to be able to question everything; from the purpose of entire systems, down to particular features and business rules. This ensures that we’re building the best possible product for our customers (and in some cases for each other). Whenever questions are asked, we all learn more, and the product improves. There are no ’stupid questions,’ because even the most ‘trivial’ question makes things better for us all.
Remember the human. Everyone is generally communicating and providing feedback with the best intent. Be mindful that it's hard to convey intent through text, so assume best intent when listening, and over-communicate when talking. Don't forget that there is another human being at the other end of the screen, with all the messy complexities and capacity for transcendence that entails. Have empathy for that person.
We enable our team to bring their whole selves to work.
3. Transparent communication
We believe in the power of direct communication. We prioritise talking directly to the right person, bypassing unnecessary hierarchical channels. This approach fosters clarity, reduces misunderstandings, and accelerates decision-making. By encouraging team members to connect directly with stakeholders and cross functional peers, we create a more agile and responsive work environment where issues are addressed promptly and efficiently.
Often in corporate software engineering situations, the ‘production line’ style pushes the tasks of communication to non-technical team members under the guise of improving ‘efficiency’. However, in practice, this reduces the feeling of ownership within the team and leads to more waterfall style requirements rather than agile problem solving.
4. Build and run
Ensures quality and reliability
By making teams responsible for the features they develop, we ensure a high standard of quality and reliability. Teams are motivated to write clean, maintainable code and to thoroughly test their features, knowing they will be accountable for any issues that arise or compromises that they make. This ownership leads to more empowered individuals who are connected to the customer. This would be impossible otherwise.
Promotes continuous improvement
Ownership also drives continuous improvement. As teams monitor the performance and health of their features, they can quickly identify and address any problems. This proactive approach allows for ongoing refinement and enhancement, ensuring that features remain relevant, efficient, and effective over time. This dissuades teams from shipping an MVP or tactical solution to a problem and never coming back to fix/improve it.
Fosters expertise and deep understanding
When teams own a feature, they develop a deep understanding of its functionality and technical intricacies. This expertise enables them to troubleshoot issues more effectively and implement enhancements with confidence. It also encourages knowledge sharing within the team and builds a stronger collective skill set.
Enhances user satisfaction
Accountability for feature performance directly impacts user satisfaction. When teams are dedicated to the long-term success of their features, they are more attentive to user feedback and more responsive to user needs. This commitment to excellence helps build trust and loyalty among our users.
Encourages collaboration and innovation
Ownership fosters a sense of pride and responsibility that encourages collaboration and innovation. Teams are more likely to take initiative in exploring new technologies and approaches to improve their features. This culture of ownership and innovation drives the development of cutting-edge solutions that set our app apart.
5. Empowered engineers
Cultivating a culture of empowerment
At ANZ Plus, our engineers are more than just code writers—they are empowered and curious problem solvers who thrive in a strong engineering culture.
We believe in nurturing a collaborative environment where engineers have the autonomy to explore new ideas, take risks, and push the boundaries of innovation. This empowerment is central to fostering creativity, removing bottlenecks, and driving technological advancements.
Center for engineering crafts
We view our engineering team as a center for engineering crafts, not a production line.
This distinction highlights our commitment to quality, precision, and craftsmanship in every project we undertake. Our engineers are dedicated to honing their skills, continually learning, and mastering their craft.
This focus on craftsmanship ensures that our solutions are not only functional but also elegant and high-quality. This approach provides us with the ability to scale well beyond the accepted norms for mobile app development. By all measures we have scaled linearly in code contributions with the number of engineers in the project.
Ownership and accountability
Engineers at ANZ Plus are responsible for their own time and outcomes. They understand the opportunity cost of their decisions and take ownership of their work.
This responsibility empowers them to prioritise tasks effectively, manage their schedules, and ensure that their contributions align with the broader goals of the organisation. By taking ownership, engineers are deeply invested in the success of their projects and the overall success of ANZ Plus.
Fostering collaboration and innovation
Empowered engineers thrive in collaborative environments. We encourage our engineers to work together, share knowledge, and leverage each other's strengths. This collaboration fosters innovation, as diverse perspectives come together to create unique and effective solutions. By working in a supportive and collaborative setting, our engineers are able to achieve more collectively than they could individually.
6. Rich client application
This generation of mobile applications is the first where users are primary app first. It’s for this reason that ANZ Plus is a mobile first product and why we have fully embraced the rich client and native development methodology. Customers want beautiful, responsive applications and that gives us some concrete requirements to aim towards. We want:
No loading spinners for ‘read’ functions
The app to look and feel smooth and simple (under all network conditions and supported devices)
Security and convenience to be the highest priority.
To provide that vision we took the bold step of building an offline-first native mobile app. This approach is the only way we can provide the instant responsiveness that our customers deserve. One emerging pattern is offline capability. Because we represent the apps as a node in a distributed database (rather than an output for an API), then, using GRDB backed on iOS and Room , we synchronise a user’s full transaction history and other relevant information securely on their device, ready for instant access when they open their app.
7. Enablement and platform
We are building a '10-year app’. This promise means that it should take as long to implement a feature 10 years from now as it does today when it's new and shiny.
One part of this is investing in native tooling which is going to always give us progressive update capability eg Java -> Kotlin, Obj-C -> Swift, XML -> Compose, UIKit -> SwiftUI.
The other part is building and maintaining a strong app platform. Empowering a core group of engineers to dynamically solve problems and build tech wealth wherever they see a need has unlocked capability that was previously impossible.
The Enablement team, (or ‘Platform team’ in the Team Topologies methodology), has ~10 members, no central prioritised task list, no product owner, and no fixed sprints. In the modern rigid 'Agile' world such a team would be judged as wildly inefficient. However, supported by our pillars of empowered engineers and transparent communication, these individuals are empowered to find the most difficult problems and to dig in and solve them.
In many cases those problems are directly assisting feature delivery teams. In other cases, it’s working individually to deliver platform improvements or working as a group to break down a large piece of platform work.
8. Continuous delivery
At ANZ Plus, our primary focus has been to deliver value to our customers as swiftly and securely as possible. Through our continuous improvement efforts, we've identified a critical phase transition in release overhead and production failures when shifting our release cycle from once a week to twice a week. This pivotal shift has underscored the necessity of automation. By automating processes wherever feasible, we have not only minimised manual intervention but also established a consistent release cadence. This regular schedule ensures that updates are frequent and predictable, enhancing our ability to meet customer needs promptly.
9. Zero tech debt
We aim to have zero tech debt. But it's a goal we will never reach!
‘Tech debt’ is just another term for unsuitable code. The moment it's merged, all the code we write should be suitable. If it's unsuitable, why would we merge it? But over time our understanding evolves. Code becomes unsuitable because we have learnt something new.
Sometimes we learn about features we want to implement, or customer feedback takes the product in different directions.
Sometimes new technologies are developed, or libraries that were previously immature become usable.
Sometimes as developers, we learn new techniques, or discover that something we previously thought worked well has unforeseen consequences.
Sometimes we merge code, with an understanding that there may be better ways to do it, but we haven't had the time to uncover them yet.
Sometimes we have chosen a ‘simple’ approach to something, with the understanding that we will replace it once it no longer scales - and we may have hit that point.
Sometimes we update our guidelines and standards to better align our codebase, and our preferred ways of doing things.
When we realise that code is unsuitable, we need to plan on how to make it suitable. We try to execute the plan rapidly. The longer unsuitable code stays in the system the more it costs to fix it.
10. Always evolving
Our values remain constant, but the way they are expressed by the team evolves.
We are never perfect, we are always changing, and always learning!
How’d it all go?
Two important indicators of development success – code contributions by engineer and release frequency - would suggest we’re doing well. But the ultimate measure comes from our customers and how well they’ve received the app.
Satisfaction with the ANZ Plus app right now is one of the highest in the industry. With all the work we have planned - we hope to keep it that way.
Mitchell Johnson is an Engineering Chapter Lead at ANZ. He is an experienced mobile lead with a demonstrated history of working with all shapes and sizes of companies on their mobile journey. He has been with ANZ for the last 4 years leading the build for the ANZ Plus mobile application. His formal education includes a Bachelor of Science (B.Sc.HONS) focused in Computer Science from Massey University. He is skilled in Android, iOS and Microservice backends.
This article contains general information only – it does not take into account your personal needs, financial circumstances and objectives, it does not constitute any offer or inducement to acquire products and services or is not an endorsement of any products and services. Any opinions or views expressed in the article may not necessarily be the opinions or views of the ANZ Group, and to the maximum extent permitted by law, the ANZ Group makes no representation and gives no warranty as to the accuracy, currency or completeness of any information contained.