Evolving teams and software at Wealth Wizards using Team Topologies

Financial Services

24 Aug

Real-world experience applying principles, techniques, and tools from Team Topologies in a financial services context.

By Becky Pauley (Platform Engineer) and Marc Burton (Head of Software Engineering) - Wealth Wizards

“We used Dunbar’s number to help promote deep levels of trust within our teams in order to enable delivering safely, at a consistent pace, whilst fostering innovation and making our people feel safe to experiment.“
“Instead of recreating the existing communication structures within our organisation, we were then able to identify discrete domain areas, growing and re-aligning our existing teams to match the desired architecture.“
“we noticed that collaboration began happening earlier and in a more planned way, such as early and well-planned use of asynchronous discussion and documentation around architectural decisions.”
“it ‘... has led to each team being able to move quicker, be more agile and become the masters of their domain’.”
“The four fundamental Team Topologies gave us the clarity we needed to redesign our team structures, reduce cognitive load and achieve autonomy and ownership for our teams.“

Overview

Wealth Wizards was founded in 2009 with one aim: to use technology to make expert financial advice affordable and accessible to everyone. Our flagship software-as-a-service (SAAS) platform, Turo, is pioneering the automation of financial advice in the UK, establishing a reputation in the corporate and workplace markets.

Our financial advice engine, which we call the "intelligent automation inside the advice industry", has evolved into Wealth Wizards' own brand of digital guidance and advice, MyEva, and has been adopted by market leaders in fast-moving consumer goods (FMCG), luxury retail and central government.

How Wealth Wizards arrived at Team Topologies

We first began automating financial advice around retirement and pensions: two separate products with independent code bases. Each capability was its own application monolith, and with a small engineering team this proved effective. However, as our products and teams grew, releases became increasingly complex and higher risk.

The solution seemed simple: break these monoliths into microservices, with one team aligned to each product. Over time, two products (and teams) became three, shared code became an issue, and so we shifted our teams to align with user personas (Adviser and Direct Consumer).

In 2019, we experienced a period of rapid product growth, with a six-fold increase in the products and services we offered. Despite our move to a microservices architecture, development again started to slow. Our team working on Advice had become large, making the boundaries and lines of communication between services increasingly cumbersome. The cognitive load on our engineers was high as they switched from one problem space to another. By the summer, things had ground to a halt, and we knew there was something wrong with the way our teams were interacting.

At the same time as we were grappling with these problems, some of us had come across Matthew Skelton’s talks online. We had begun using his and Manuel Pais’ existing work, such as the Independent Service Heuristics, to guide our thinking on team boundaries, and we were eagerly awaiting the release of their new book - Team Topologies. Two principles that resonated strongly with us at that time were aligning to the flow of work, and Conway’s Law: organisations design systems that mirror their own communication structure. If we wanted to change the interactions within and between our teams, we needed to design our teams with this desired communication structure in mind.

Iteration 1: Stream-Aligned Team for each capability

We started with a team-first approach. Our goal was to identify boundaries based on the flow of change and break our large team into smaller ones. This led to the creation of four teams organised around regulatory compliance and change cadence: three Stream-Aligned Teams (Retirement, Consolidation, Digital Guidance) and a Complicated-Subsystem Team to reduce the cognitive load surrounding Financial Modelling. Each team was cross-functional, including Software Engineers, a Platform Engineer, Quality Engineer and Product Owner (Fig 1).

*Figure 1: Three cross-functional, Stream-Aligned teams and introduction of a Complicated Subsystem Team.*

This first change led to some significant improvements. Our move towards smaller, cross-functional teams of 5-9 people now fell within the boundaries of Dunbar’s number (the number of people a person can trust deeply). As these new teams became established, we observed improvements in our weekly pulse survey metrics. Most notable were increased scores for Trust with Peers (8.1 -> 9.0), Engagement (7.6 -> 8.4) and Mastery (6.8 -> 7.9), which we attribute to a greater sense of ownership and community within these new team structures:

“We believe that building psychological safety is a key factor in enabling high performing teams who have a bias for action and do not fear failure. We used Dunbar’s number to help promote deep levels of trust within our teams in order to enable delivering safely, at a consistent pace, whilst fostering innovation and making our people feel safe to experiment.” - Marc Burton, Head of Software Engineering at Wealth Wizards

However, we realised that there was still dysfunction in our team design. It was necessary for two of our Stream-Aligned Teams to collaborate closely, with interdependent flows of work. We needed to be careful to avoid ending up with a ‘distributed monolith’, with all changes requiring changes to other services that were ‘shared’ between teams – every service in the system needed to be owned by one team. In addition, the different user journeys across our Stream-Aligned Team products were not cohesive, meaning that it was difficult to interact between the two.

Iteration 2: A transitional phase

In our next iteration, we aimed to remove the dysfunction we had created by having teams working too closely in the same area. Our teams remained consistent but with re-defined ownership of services. We began to move towards Stream-Aligned Teams organised by business domain (as opposed to change cadence), with a Platform Team that would evolve our Core Platform as Software as a Service, which could be consumed by Stream-Aligned Teams.

*Figure 2: Stream-Aligned and Platform Teams with re-defined ownership of services.*

At this point, there were resource constraints, so decisions needed to be pragmatic. We still had some services that were shared between teams on a temporary basis: these were documented with a view to creating clearer ownership boundaries as soon as resources allowed. In the meantime, we acknowledged that at times the flow of change was disrupted by two teams needing to work in the same area at the same time. It also became apparent that system boundaries around our Core Platform were unclear.

In reality, these communication structures still matched our organisation, rather than the natural boundaries between domain areas.

Iteration 3: Visualising the logical components in our system and a Reverse Conway Manoeuvre

At this point, a few significant changes took place:

A new round of recruitment allowed us to grow our teams to their desired capacity.
We mapped out the logical components in our system and the lines of communication (dependencies) between them.

Visualising the logical components in our system helped us to understand the natural fracture planes or boundaries between them, and map these to business domain areas. Instead of recreating the existing communication structures within our organisation, we were then able to identify discrete domain areas, growing and re-aligning our existing teams to match the desired architecture.

This led to:

Redefining the boundaries of our three existing Stream-Aligned Teams, each aligned to a separate business domain bounded context (Advice, Interaction Management and Data Gathering).
Our Complicated-Subsystems team continued to focus on financial modelling, without also acting as ‘caretakers’ of other services.
Introduction of a highly skilled, cross-functional Enabling Team to support our Stream-Aligned Teams. This team would also continue to work with teams to refine Team APIs and interaction modes.

*Figure 3: Stream-Aligned, Enabling and Complicated-Subsystem teams with clearly defined interaction modes.*

These teams now collectively formed the ‘Turo Platform’, and we created a new Employer Solutions Stream-Aligned Team (My Adviser App) who would be consumers of our platform as Software as a Service.

Learning points… and glance at the future

Here are some things we have learned on our journey using Team Topologies.

Conway’s Law and identifying the natural fracture planes

The creation of Stream-Aligned Teams did not, in itself, solve the communication dysfunctions in our teams. This is because at first the new teams mirrored the existing architecture, rather than what we hoped to achieve. The point at which we were able to use Conway’s Law successfully was when we mapped out the desired architecture and then looked for the natural fracture planes (in this case, by business domain bounded context). When teams were organised by this approach, we noticed that collaboration began happening earlier and in a more planned way, such as early and well-planned use of asynchronous discussion and documentation around architectural decisions.

Cognitive Load

With our teams now aligned to the main streams of change within the organisation, there have been clear benefits: they no longer need an understanding of the domains outside of their system boundaries, the amount of context-switching has been reduced, and this has enabled a greater focus on quality and purpose (see Daniel Pink's elements of intrinsic motivation) as opposed to ‘delivery’. For example, there has been more dedicated ‘tech-debt’ time where teams have been able to proactively improve and maintain existing services.

In mapping out our services, we also recognised that our Stream-Aligned Team responsible for Advice are still dealing with considerable domain complexity. As this team evolves, collaboration with the new Enabling Team will help guide the direction of the team in the future, with consideration of whether the team will need to split into two smaller ones dedicated to different layers (for example, application and domain layers).

A Team-First Approach

Small and long-lived cross-functional teams have created a greater sense of ownership and trust. When our first and second iterations of a Team Topologies approach needed shifting in line with Conway’s Law, our existing teams remained as consistent as possible. Re-drawing the boundaries of ownership (and therefore the interaction modes) between those teams then allowed them greater autonomy to work towards a shared goal. In the words of one of our Software Engineers, Laurence Howard, it “... has led to each team being able to move quicker, be more agile and become the masters of their domain”.

When Wealth Wizards recognised dysfunction in the way our teams interacted, we knew we needed a new approach. The four fundamental Team Topologies gave us the clarity we needed to redesign our team structures, reduce cognitive load and achieve autonomy and ownership for our teams. At an exciting time in the business, we look forward to seeing our products and teams grow with the confidence that we have the language and principles to continue to guide us in the right direction.