Introduction

Adopting Thought Machine’s cloud-native core banking platform, Vault Core, brings unique considerations for organisations looking to optimise their team designs and organisational structures. Based on our experiences with Thought Machine clients, this article aims to:

1. Summarise the common team designs and organisational structures observed in Vault Core implementation, offering practical insights and guidance for navigating the complexities of its adoption and considerations to make.
2. Provide a framework that helps organisations make informed decisions about team structures and organisational architecture, based on real-world experiences and lessons learned.
3. Encourage readers to think about the importance of adaptability, agility, and efficient team interactions in achieving success with Thought Machine technology and the rest of a bank's technology ecosystem.
4. Initiate conversations within the industry (and Thought Machine user group) about best practices for team design and organisational structures in the context of emerging technologies like Vault Core.

Establishing the Context

Drawing from our extensive experience in building digital banks and working with Vault Core, we have learned about various stages of adoption and team structures in different organisations. We have partnered with banks through the initial stages of Vault Core implementation, as well as helping them transition to more mature stages with optimised team structures. Through ongoing conversations with existing and potential Thought Machine customers, we have deepened our understanding of Team Topologies and the considerations organisations must make when adopting this technology.

Our expertise, coupled with our dedication to assisting banks on their journey, enables us to provide valuable guidance on team structures, organisational transformation, and the successful implementation of Vault Core in the banking industry. We believe that our insights can have a significant impact on banks, driving positive change and empowering them to thrive in today's competitive landscape.

Our Principles

We base our principles on three key beliefs:

1. Prioritising adaptability and agility is essential in today's fast-paced world. We aim to create organisations optimised for efficient team interactions and cognitive load management.
2. Conway's Law states that an organisation's architecture influences its systems and solutions. If the two conflict, the organisation's architecture wins.
3. Design patterns used for technical systems can also apply to organisations, with team communication being a critical component.

Following these architecture principles, we emphasise value stream alignment, rapid feedback loops, and autonomous cross-functional teams while balancing freedom and responsibility. These guidelines help create efficient, adaptable teams prepared to tackle Vault Core implementation challenges.

Team designs and observed stages

In the early stages of implementing Vault Core, teams acquaint themselves with concepts and engage with the Vault APIs through smart contract product requirements and API specifications. At this point, Thought Machine play a significant role in smart contract delivery, ensuring clear boundaries and interfaces for product teams. However, it's essential to be aware of the challenges that may arise during this stage:

• Developing specialist expertise: the bank’s engineers might not have expected to learn about proprietary systems, which can lead to cognitive overload.
• Communication barriers: without a designated point of contact at the bank to communicate with Thought Machine’s team, targeted support is more challenging to receive.
• Knowledge transfer scalability: the process of transferring knowledge to the bank's wider team can be challenging depending on the size of that team. While the entire team needs to be aware of the concepts, only a select group of individuals require in-depth expertise, making large-scale knowledge transfer less efficient.

Fig 1. Initial Adoption (centralised external)

Following the initial adoption phase, banks often consider transitioning to the next stage, known as the "Centralised in-house (intermediate)" stage. This decision is often driven by the need to address challenges in scaling knowledge transfer by focusing on upskilling specific individuals, which enables more efficient team development and better management of the learning process. Banks are motivated by the desire to exercise greater control over their technology stack, reduce dependency on external parties, and potentially minimise costs and communication delays, all of which contribute to the move towards this stage.

Fig 2. Centralised in-house (intermediate)

As financial institutions acknowledge the need for profound technical expertise in smart contract delivery, owing to its specialised nature and initial learning curve, they often establish centralised core banking teams as a stepping stone towards eventually embedding Thought Machine subject-matter experts directly into their product teams. This approach entails forming a dedicated team responsible for developing and managing smart contracts in-house, resembling a "complicated-subsystem team" from Team Topologies, to focus on addressing specific complex aspects of the system.

At this stage, the core banking team serves as the primary point of contact between the bank and Thought Machine, optimising communication and collaboration. By consolidating knowledge and expertise related to Vault Core and smart contracts, the team can effectively navigate the initial learning curve and develop subject matter expertise more swiftly.

This approach presents several advantages concerning coordination, knowledge sharing, and support for other teams within the organisation. However, it also brings forth potential drawbacks, as outlined below.

➕ Pros

• Faster subject matter expertise development: motivated individuals can quickly grow their knowledge in a focused, centralised team.
• Straightforward communication: Thought Machine and the bank have a central contact group, facilitating effective collaboration.

➖ Cons

• Architectural anti-pattern: one product requirement is handled by two teams, resulting in potential inefficiencies that lead to a violation of "loose coupling high cohesion".
• Scalability concerns: the central team's backlog may become overwhelmed as it serves the entire organisation, causing strain on cognitive load and team interactions.
• Transitioning to this stage requires thoughtful planning, dedication, and attention to detail, as it involves time, resources, and a thorough knowledge transfer from the Thought Machine team.
• It is essential to adjust communication lines and establish a clear mandate for the bank’s internal team. We have seen this need with an under-prioritised centralised team that required more focused attention and guidance.

Thought Machine recognises the challenges of the potential learning curve and proactively works to make their technology more accessible. Their responsiveness to customer feedback and ongoing improvements, as showcased by the evolution of Vault Core, highlights their progress. In a future article, we will spotlight the positive example and industry role model that Thought Machine represents, by demonstrating how they have enhanced the Vault Core developer experience based on customer feedback.

Organisations that attempt to bypass the essential intermediate centralised stage, transitioning directly from an external centralised team (Thought Machine delivery) to integrating Thought Machine smart contract work into stream-aligned product teams without first developing subject matter expertise, risk encountering chaos. This abrupt shift in responsibilities, without a proper transition period through a centralised setup, can result in severe consequences, including:

• Cognitive overload: the bank’s engineers may struggle to adapt to the new technology, leading to disorganised problem-solving, frustration, and the potential risk of team members leaving the organisation.
• Lack of clear ownership: when different teams work with the same technology, confusion and inefficiency can arise, likely increasing failure rates and extending recovery times.
• Communication challenges: Thought Machine may struggle to provide targeted support without a designated point of contact within the bank, exacerbating the difficulties faced by the organisation.

To mitigate these potential issues, organisations should prioritise the intermediate centralised stage, dedicating time and resources to knowledge transfer, skill development, and communication lines establishment. This careful approach ensures a smoother transition to the mature stage, where Subject Matter Experts (SMEs) can be successfully embedded in product teams, resulting in a more effective and efficient organisation.

During this stage, the goal is to achieve an optimal balance between the benefits of the "Early Adoption" and "Centralised Internal Team" stages while mitigating their challenges. The focus shifts to embedding SMEs within product teams, ensuring that their specialised knowledge directly contributes to product development while fostering a collaborative environment. The objective is to create an adaptive organisation that aligns with key concepts from Team Topologies.

To successfully reach this stage, the following strategies can be employed:

1. Embed SMEs within product teams: forming cross-functional teams with diverse skill sets and expertise enables team members to learn from one another and apply their specialised knowledge to product development.
2. Establish mentorship pairings: pair product team members with SMEs for one-on-one knowledge transfer and guidance, ultimately enhancing the team's overall expertise.
3. Implement rotation programs: SMEs spend a designated period working with product teams, sharing their knowledge and learning from team members, fostering a continuous exchange of skills and ideas.

Furthermore, forming a central guild for Vault Core smart contract subject matter expertise encourages the creation of informal groups where SMEs and product team members can share knowledge, discuss challenges, and exchange ideas, promoting continuous learning and expertise sharing across the organisation. A centralised team can still be maintained to handle shared aspects, such as keeping an up-to-date integration library that product teams can use, and acting as a single point of contact for bilateral interaction with Thought Machine. This includes managing notifications about new product features, platform feature requests and SaaS upgrades (if relevant). The central team can provide extra support during incidents, ensuring a streamlined response and efficient recovery. By allowing a sufficient period in the "Centralised Internal Team" stage, a group of SMEs can be developed as a prerequisite for the strategies mentioned above.

Fig 3. Mature, North Star, Distributed(SMEs embedded in stream-aligned product teams)

Conclusion and Recommendations

The proposed mature stage emphasises autonomous, collaborative teams, stream-aligned for product delivery, and enabling teams for specialised expertise support, fostering effective communication and rapid feedback loops. This stage resolves previous challenges while following Team Topology and Domain-Driven Design (DDD) concepts but requires advanced enterprise architecture maturity, a strong group of SMEs, and careful management.

Strong leadership and a culture that promotes learning, collaboration, and experimentation are crucial for navigating team design stages and successful Vault Core adoption. Fostering an organisational culture that supports innovation and continuous improvement is essential for managing complexities when implementing Vault Core.

While many banking platforms face common challenges like initial learning curves and the need for specialised expertise, Vault Core distinguishes itself through its smart contract engineering, which enables rapid iterative development. This feature provides increased flexibility and customisation, allowing banks to adapt and innovate swiftly. To harness the full potential of these benefits, teams require a deeper understanding of the underlying technology and a distinct approach to team structures and organisation. In contrast, traditional banking platforms may offer more familiar, monolithic structures, but might lack the adaptability and agility inherent in Vault Core. By understanding these differences, banks can customise their team designs and organisational structures to effectively tap into the potential of Vault Core

As experts in Vault Core and Team Topologies, we offer valuable insights in an area that has not yet been publicly discussed or written about within the industry. We invite further discussions to explore your bank's unique situation, acknowledging that there may be alternative solutions beyond the outlined stages.

References and further reading

• Team topologies
• Let’s Unfix Team Topologies