From Streamlined Teams to KPI Mastery: Xapo’s Blueprint for Business-Technology Alignment
In today’s rapidly evolving tech landscape, aligning business strategy with effective team structures and technology execution is crucial for organizational success. At Xapo Bank, we’ve pioneered a unique approach combining team topologies, Domain-Driven Design (DDD), and Key Performance Indicators (KPIs) to bridge this gap.
Here’s how we do it.
Foundation of Our Team Structure
Adopting the ‘Team Topologies’ framework by Matthew Skelton & Manuel Pais fundamentally shifted our approach to structuring teams at Xapo Bank. Initially, the concept of Stream Aligned Teams (SATs) was met with curiosity and some skepticism. However, as we began to see the impact of this model — enhanced collaboration and streamlined processes — the value became undeniably clear. This wasn’t just a new team model; it was a strategic shift towards greater efficiency.
Stream Aligned Teams (SATs) are composed to be self-sufficient and usually consist of backend engineers, mobile engineers, technical leads, product owners, and designers. I intentionally didn’t use the word “cross-functional,” as there might be teams that don’t require all of those roles. For example, teams focusing on back office work won’t require front-end engineers, obviously. Other teams might require additional roles like web engineers, etc.
To support our SATs, we have multiple platform and enabling teams, such as Apps Platform, Platform Engineering, Data, Security, or Engineering Enabling team. Those teams focus primarily on improving efficiency of SATs (or other supporting teams).
Enabling teams are designed to step in, assist, and then step back. Their primary objective is to empower the main team, strategically planning their own redundancy as the project progresses and the main team is finally able to fully take over the newly introduced method, framework, etc.
Platform teams, like the Platform Engineering Team, develop internal platforms as a product to make the work of product-focused engineers much more efficient and, of course, ensure our infrastructure is robust.
The same rule applies to remaining supporting teams, depending on the need they have for their primary team topology. This helps them to understand the nature of their work, how to engage with other teams, set the right goals, and execute what is needed.
Utilizing Conway’s Law to Our Advantage
We’ve structured our setup to ensure Conway’s Law works in our favor. If you haven’t had a chance to hear what that is, in short, it explains how the software we build and the architecture beneath it resemble communication patterns and organizational structures within the company. In other words, bad team structures translate into poor architectural design and, with that, very often, poor time to market.
Empowering Teams with Domain-Driven Design
Responsibilities between our Stream Aligned Teams (SATs) are spread so that, on the one hand, teams have as much autonomy as possible and, on the other hand, cognitive load is on a healthy level. And this is where implementing Domain Driven Design is of great aid. A while ago, we did a discovery of all the subdomains that are present at Xapo Bank. With that, a division of bounded contexts also emerged.
The way we approached discovery was, through series of workshops. Our goal was to create a context map for our architecture. But to get there, we first started with big picture event storming done by all teams to discover subdomains.
After that, we utilized a helpful method to find details about discovered subdomains and map them to bounded contexts. For that, we used Bounded Context Canvas, as described by Nick Tune. We slightly adjusted the template for our needs, but below, you can see an example of one of the bounded contexts at Xapo Bank.
Last but not least, with all the information, our final goal was to create two versions of context maps.
- As is — reflecting the current situation
- To be — reflecting where we want to get to
If you’re curious about what those mysterious abbreviations like CF, OHS, D, U, etc. mean, I recommend you check out context-mapping GitHub from ddd-crew, where you’ll be able to find useful explanations & cheat sheets.
This exercise established clear ownership throughout our architecture, with each bounded context being managed by a specific team. While other teams can contribute as needed, having defined ownership is crucial for preventing disorder and maintaining organizational clarity.
I remember the initial resistance when introducing the concept of DDD. It was a major shift from a traditional approach to architecture, but the transformation in our project delivery speed was undeniable. Now, Domain-Driven design is ingrained in our engineering culture.
Of course, things are not perfect, but I believe continuous improvement is much more important than aiming for perfection from day one — the latter is expensive and rarely works anyway.
Bridging Business and Tech with KPIs
I described how team topologies helped us structure our teams to be efficient; I explained how Domain Driven Design is helping us spread responsibilities and ownership between our teams. One ingredient missing here that we felt is essential for a functional setup. How can the gap between business direction and technology focus be bridged? For that, we introduced the notion of tribes. These structural constructs combine multiple SATs, and the tribes reflect key business metrics Xapo Bank wants to focus on. This allows for interesting maneuvers, like sharing mobile engineers within a tribe based on prioritization instead of assigning them full-time to one team. It allows for more efficiency while maintaining the correct level of domain ownership.
An example of one such tribe was our Conversion tribe. Product teams (SATs) in that tribe had one KPI to improve. Conversion rate. In that metric, we track how many users who started the registration process became trial members. Clear ownership of one critical KPI for teams that belong to that tribe, like Customer Acquisition & Onboarding (CAO) and Financial Crime Prevention (FCP), allowed them to prioritize initiatives to move the needle on this critical business metric. They had complete autonomy in making decisions like which parts of the funnel to improve and how. Improving UX, improving internal processes or even upgrading vendors. This setup had such effectiveness that it allowed us to increase the conversion rate by 9x. This is an excellent example of a strategic use of KPIs.
Adapting to Change
You may have noticed I wrote that this tribe “was” called Conversion tribe. That is because it has evolved into Growth tribe. This change was more than symbolic—it reflected a deeper shift in our goals and strategy, focusing not just on conversion but on wider business growth. After surpassing our targets for conversion rates, it became clear that the scope of this tribe’s influence could be broadened. So, we refocused one of the teams to start collaborating very closely with our marketing team to enhance their work with technology. With that, we became much more efficient in our performance marketing, allowing us to bring more quality applicants with smaller marketing spend.
I mentioned the above change to emphasize the importance of evolving organizational structures. The pace of change is incredibly fast these days. To be a successful business, one needs to adapt to new demands quickly. Even at the moment of writing this article, I already know there will be new teams and tribes introduced in the near future, and that inevitably will also introduce evolutions to existing teams. And that is natural.
The way our Technology department is set up and the way we collaborate with Product & the rest of the organization allows for efficient delivery while maintaining elite-level reliability. Of course, just the organizational setup won’t suffice; this must be combined with high talent density, high-performing culture, and exemplary leadership at multiple levels. But that probably deserves a separate article ;)
In the swiftly changing landscape of global business, the only constant is change itself. At Xapo Bank, our adaptive structures not only support our current goals but are poised to evolve with our ambitious vision. Is your organization ready for the next shift?
How does your organization align business and tech? Share your strategies or thoughts in the comments below!
If you’re interested in learning more about Xapo Bank — The simplest way to bank with Bitcoin, explore the resources at xapobank.com.
