Architecture Without the Architects: Xapo’s Advisory Model

Most organisations that reach a certain scale end up with a centralised architecture function. The rationale is usually sound: ensure consistency, promote good patterns, and keep the technical estate coherent. But in practice, that central team often becomes a bottleneck. Knowledge concentrates in a few heads, feedback loops with delivery teams stretch, and the people doing the building lose any real sense of ownership over design decisions. Xapo Bank—a fully remote, globally distributed organisation—decided that model no longer worked for it, and replaced it with a decentralised, advisory approach built on the Architecture Advice Process.

From Bitcoin Custodian to Licensed Bank

Xapo began in 2014 as a Bitcoin services provider, offering wallets, trading, and cold storage. In 2018, it pivoted toward becoming a fully licensed bank and Virtual Asset Service Provider (VASP) under Gibraltar’s GFSC, and by 2020 it had secured the necessary licences. Much of the existing software estate carried over, but six years of technical debt, tight coupling, and low service cohesion were dragging on delivery.

Teams were organised around functional departments—Product, Design, Architecture, Engineering, QA—with work flowing through them in near-waterfall fashion. A small architecture team had to review and approve every design, and queuing was endemic. The engineers themselves were skilled: the problem was the system around them. Adding to the difficulty, staff were spread across more than 40 countries and 25 timezones. An earlier attempt at collective decision-making, a forum called “the athenaeum,” had struggled to reach conclusions; discussions dragged on and decisions were frequently revisited or rolled back.

Reorganising Around Domains

The first move was structural. Xapo began viewing its software through the lens of business domains rather than technology functions. Using Domain-Driven Design as an organising concept and leaning on Team Topologies, leadership migrated the delivery organisation into business-aligned Stream Aligned Teams (SATs). That work happened in partnership with Product and Operations over several months.

In parallel, the developer experience needed attention. Centralised operations and tight controls had made it painful to create services, change configurations, or move without raising a ticket. The Platform team’s mission was shifted to support team autonomy and full service ownership across the entire lifecycle, and work began to refactor infrastructure and tooling accordingly. Thoughtworks was brought in to accelerate the change, with a focus on helping people learn the new principles safely.

Core engineering principles were defined, centred on optimising for team autonomy and reducing hand-offs. Bounded contexts were mapped in increasing detail, aligned ever more closely with teams, informing roadmaps and allowing incremental architectural improvement. The direction was clear; the open question was how to make it work in a fully remote, async-first environment.

The Architecture Advisory Forum

The answer came in the form of the Architecture Advice Process, and Xapo implemented it as the Architecture Advisory Forum (AAF). It is a decentralised, conversational approach that lets teams make their own decisions but requires them to seek advice from the right stakeholders and experts along the way. There is no central approving authority—a fitting choice for a company founded on decentralised finance.

Key details of how the forum operates at Xapo include:

  • A standard template for architecture decisions that captures each decision in a structured, reviewable format.
  • A broad advisory group representing engineering, product, design, and other relevant interests, drawn from across the organisation.
  • Written, asynchronous review first, giving advisors time to digest proposals regardless of timezone, with synchronous discussions only where genuinely needed.
  • Consultation is obligatory, compliance is not: teams must seek and consider advice on material decisions, but the final choice remains within the team’s own accountability.
  • The forum is advisory, not a gate: it does not approve or reject proposals; it offers input that helps raise the quality of the eventual decision.

This structure preserves the benefits of collective intelligence while deliberately avoiding the bottlenecks of a central approval board. Because decisions are written down and shared, new team members can trace not just what was chosen, but why—critical in an organisation spread across dozens of timezones where synchronous communication is rare.

Early Outcomes and Lessons

The AAF has delivered measurable changes. Teams report a stronger shared understanding of the reasoning behind architectural decisions—something that previously eroded as people moved on or as context was lost in hand-offs. Delivery teams now exercise real ownership over their designs, while still benefiting from a structured mechanism for surfacing concerns early, before costly rework becomes necessary.

The move has also reshaped the architecture function’s role: instead of designing in isolation and handing down specifications, architects now participate in the process as advisors and reviewers with a clearer view of the realities on the ground. Feedback loops shortened considerably, and the wait times that once plagued the centralised model are gone.

A few lessons stand out from the experience. First, the structure of the advisory group and the clarity of contribution rules matter: too broad a forum becomes unmanageable, too narrow defeats the purpose. Second, investing in the quality of written proposals is essential—asynchronous review of a poorly documented decision is low value for everyone. Finally, ensuring that advisors are empowered to make connections between decisions and raise risks from adjacent domains takes an active effort, particularly as the organisation grows and the number of concurrent decisions increases.

At the same time, Xapo acknowledges the model still depends on a sufficient baseline of architectural seniority distributed across the engineering organisation. It does not remove the need for expertise; it repositions it, spreading it closer to the teams that need it daily.

What Comes Next

With the foundation in place, the immediate question is how widely and deeply the model can be applied as the estate grows. The AAF concept remains open to refinement—older decisions are revisited as circumstances change, new domains and new teams are onboarded into the practice, and the balance between autonomous decision-making and expert input is likely to shift as the organisation matures.

Getting the Advice Process Started

Xapo’s rollout of architecture advice followed the principles Andrew laid out in his post on scaling architecture conversationally, but the specifics of the organisation shaped how it played out. Three factors mattered most: Xapo was pivoting and entering a global scale-up phase, everyone worked remotely (making written, async communication the default), and the talent pool was deep—but that depth of opinion had sometimes slowed decision-making.

The initial rollout covered three core elements together: the AAF (architecture advice forum), ADRs, and the advice process itself. To seed the forum, the team pre-populated it with retrospective ADRs on a significant recent decision: migrating key services to a third-party supplier. The AAF invite list deliberately crossed disciplines—engineering, architecture, infosec, infra, product, delivery, regulatory, operations, treasury, and the executive.

The standing agenda went beyond the standard spike and in-play ADR review to include:

  • Team-coupling issues, reflecting the Team Topologies-driven re-org Xapo had initiated just as Thoughtworks engaged.
  • The four key metrics from the DORA State of DevOps Report and “Accelerate,” configured by Xapo’s Head of Continuous Improvement per “Software Architecture Metrics.”
  • Cloud spend.

After a few iterations, a further slot was added to review ADR progress—not just how quickly decisions were being made, but how fast they reached production. That prompted a new ADR status, adopted, set when the decision was implemented and running in prod.

Adapting to an Async-First Culture

Xapo’s “async-first” culture pushed the implementation towards asynchronicity—contrary to the usual instinct that conversation benefits everyone, not just participants. The compromise worked: the weekly face-to-face AAF shrank to a half-hour session, while the surrounding pre-work (sharing in-progress spikes and proposed ADRs) and post-work (capturing advice produced in the conversation) were done diligently in writing. The resulting ADR records, particularly the advice sections, became a valuable resource.

The team deliberately deferred two common additions: architectural principles and a tech radar. Technical principles already existed in written form and in the minds of the teams, so they weren’t urgent. The radar was introduced later as team self-management led to growing decoupling and potential “bounded buys.” When the tech landscape had been smaller, adoption had been organic—engineers evaluated and adopted useful tools without much ceremony.

ADR tooling itself evolved significantly. The team quickly moved from a Confluence-based repository to a Jira-based one. The key motivator was to expose the ADR status field and its transitions as a data point. With Jira, opening a new ADR ticket set draft; moving it to proposed before an AAF was a simple status change; and later transitions to accepted and then adopted were all time-stamped. The agenda for each AAF ran off a standing query for anything in proposed status. Teams lost nothing—the ticket template preserved the structured ADR sections and rich text—but gained automation: new high-status ADRs and changes were announced to Slack by a bot, and integration with the broader workflow became transparent.

What the Data Showed

The migration made it possible to answer meaningful questions about decision throughput. The headline metric was time from draft to adopted, both in aggregate and per stage—an analogue to DORA’s lead time metric and, as it turned out, a reliable indicator of process health. These data points were shared with teams, prompting self-corrective questions like “why has this been in proposed for so long?” A secondary benefit emerged when implementation stories were attached to ADR tickets: cross-team decisions with substantial implementation scope (such with a project meant to improve trace-routing across core systems) rewarded linking.

AFR and the Wider Effects

Running the AAF surfaced matters upstream of specific decisions and educated participants. CFRs naturally arose as ADRs were proposed; making them explicit let teams such as Regulatory and Product delegates weigh in on compliance needs in a technical forum. Technical strategy gained a testing ground: CTO-level input on the overall direction was discussed against real decisions, exposing teams to strategic constraints while stress-testing strategy against day-to-day reality.

The same dynamic applied to principles. Repeated exposure meant teams could give feedback in practice on how principles held up, propose changes, and build alignment—not abstractly, but whenever software was shipped. The AAF also accelerated the transition to domain-driven architecture. Domain language became more common week after week, and while it wasn’t always bounded or aligned to contexts, discussing it in relation to real ADRs accelerated understanding of DDD and turned it into a self-reinforcing cycle: spotting coupling, catching unneeded implementations, and resolving design issues more quickly.

The architects within the team never became irrelevant.

The architects within the organisation stayed as busy as ever. Focus shifted toward providing advice, supporting the AAF, and high-impact projects, while decisions moved closer to the codebase and the people best positioned to make them. Designs that previously took weeks or months now take days—and they are well-documented, widely understood, and becoming part of the technical community’s collective intelligence.

Making the Shift Stick

Adopting a decentralized architecture practice is more than introducing a new process; it requires changing an organization's collective “common sense.” The hardest part of that change was letting go of the comfort of consensus. The Architectural Advice Process has a single rule—anyone can take an architectural decision—and explicitly does not require agreement or approval from a higher power. Yet, even after everyone consciously accepted the idea, the phrase “so, do we all agree?” kept slipping out at the end of discussions. That vocalized habit became a useful signal that the mindset shift was incomplete, and it allowed attendees to be reminded that decisions could be taken and actioned without consensus.

A related habit was the pursuit of “perfect” solutions that made no compromises with the stated principles. Less experienced decision-makers initially assumed the former “architects” could find a path that satisfied all constraints. Explicit focus on trade-offs, and capturing those trade-offs in ADRs, slowly unpicked that assumption. Bringing compromises into the open made it clear that they were not just acceptable but inevitable. Optimizing for team autonomy, for example, inevitably duplicates some effort. Whether that is a problem depends on the cost of coordination versus the value of the duplication itself. In some cases, duplication could cause a disjointed user experience, and the alignment effort was clearly worth it. Considering these factors up front, as a collective, helped everyone understand where to place emphasis when making compromises.

Grounding decisions in business context also proved critical. Often, the “best” technical option was determined by product or business strategy. Having product representation in the Architectural Advice Forums (AAFs) gave everyone the context needed to weigh options and offer advice. A foundational example was the product and design decision to have a single, universal user experience across mobile platforms. Aligning iOS and Android experiences required significant effort, and without clear product guidance, it might have been seen as a waste. But because it was central to the product ethos, teams could make many strategically-aligned decisions rapidly, knowing why the direction was essential.

Beyond the decisions themselves, the regular synchronous sessions had broad educational value. Everyone present was exposed to Xapo’s business specifics and collective reasoning process, even when a decision was not directly pertinent to their work. This made asynchronous work far more effective, as teams were more aware of the nuances of the company’s weekly direction. Autonomy without guidance results in chaos; the constraints provided by the Advice Process, including its responsibility component, helped set the team free. The investment in clearly defined tech pillars and principles was a key success factor, and the weekly AAF reinforced that shared understanding.

These sessions also made it safe to be wrong. When teams learned more about Domain-Driven Design (DDD) and saw its patterns manifest in Xapo’s software, it became necessary to re-assign services and refactor them to align with more appropriate bounded contexts. The CTO, who had made the initial team and software allocations, supported these refactorings. Watching organizational designs change in practice demonstrated that designs don’t need to be right the first time—they just need to be good enough to make progress and then be improved.

Sustaining this model required ongoing care. Consistent curation of the ADR backlog and clear ADR ownership were essential. Xapo decided to dedicate a full-time person to driving collaboration across engineering and beyond, a necessity given the asynchronous, global nature of the company. This paid off when ADRs were revisited. Because decisions are made at a point in time, capturing the decision-context is critical. When that context changes predictably, a re-evaluation can be scheduled. Xapo did this when a non-strategic hosting decision, made as the only viable option at the time, was revisited and migrated back to the strategic cloud provider via a subsequent ADR.

The AAFs did not exist in isolation. Their success was built on prior groundwork: the move to a Team-Topologies structure, a focus on product thinking, continuous delivery infrastructure, and data from the DORA four key metrics. Moving from a functional to a stream-aligned team (SAT) model is difficult in practice, even if it looks straightforward on paper. It was important to let the new structure bed in and begin to work well.

A crucial final lesson is that creating a forum or structure is not enough to ensure its continued success. The process requires regular assessment, support, and adaptation. Participation must be encouraged, and any issues that arise must be addressed. Only by consistently nurturing the approach can it remain effective and valuable over the long term.

On the Horizon

The AAF and Advice Process have delivered clear benefits, but the engineering team is not resting. Several improvements are under consideration to continue enhancing development practices and culture.

One initiative is to formalise an internal open-source model that would allow teams to contribute across bounded contexts. This would enable sharing code and best practices, reduce duplicated effort, and provide opportunities for knowledge sharing. The goal is to accelerate innovation, improve code quality, and reduce queuing and friction.

Work will continue on improving developer experience (DevX) and tooling. Streamlining development and reducing friction enables developers to work more efficiently. In addition, the entire engineering team will keep developing and refining its tech principles to ensure they stay aligned with evolving business goals. Regular reviews of those principles will ensure they remain relevant and continue to guide development efforts.

The implementation of the AAF is seen as the beginning of a journey toward continuously improving software development practices. By pursuing these initiatives, developers can be enabled to work more collaboratively, experiment with new ideas, and make better-informed decisions, ultimately supporting broader business goals. A recurring message from this work is clear: don’t get too hung up on perfection. Get it good enough, and make progress.