District

The proposition, scope, architecture and delivery organisation all took shape while the first release was already being built. Strategy, design and engineering did not follow in sequence; each changed the others as the work progressed.

The banking proposition and the shared platform had separate but closely connected leadership. I led the technology effort behind the first release, assembling a cross-functional organisation across engineering, UX and quality assurance, establishing how we would work, and translating an expanding set of ideas into a coherent product we could release in five months.

Much of that spring was spent moving between whiteboards, prototypes, planning sessions and technical discussions. I worked beside designers and engineers as concepts took shape, challenged architectural constraints when they compromised the intended customer experience, and reconciled the ambition of the proposition with what the teams could credibly deliver by June. Meetings with customers in several markets helped us test whether the emerging product reflected how they actually worked rather than how the bank happened to organise its services.

The first version reached production in June and was introduced to a small group of customers. It included a financial dashboard with basic account features, cash-flow forecasting, recommendations and connections to existing services, but could not yet support a customer’s full banking day. We had shown that the bank could build and release a new kind of product at speed. We had not yet established what District needed to become.

Payments, accounts, FX and cash-flow forecasting had their own product owners. I was responsible for the shared platform that allowed them to work as one channel.

At first, that responsibility appeared as a series of immediate product questions. How should customers move between services? What information and context should follow them? Which capabilities should the platform provide once for everyone, and which should remain under the control of each specialist application?

As more applications joined District, I found myself thinking less about individual features and more about the environment they collectively created. The bank divided its services into business domains, technical systems and ownership structures; customers encountered one bank. They expected their identity, company, permissions and current task to follow them without needing to understand which division owned an application or why one part of the channel behaved differently from another.

I led the work of defining that boundary with designers, engineers, architects and the teams responsible for the individual products. We sketched and prototyped how navigation, customer context, permissions and interaction patterns should work across applications, and decided which services belonged in the shared platform rather than being recreated by every team. Conversations with customers across markets helped us test those models against the different needs of small-business owners, finance teams and professional treasurers.

The challenge was finding the boundary. If each application controlled its own navigation, terminology and support patterns, District would become a collection of separate destinations. If the platform prescribed too much, specialist teams would lose the freedom to design for their own domains. My responsibility was to create enough shared structure for coherence without making the platform team responsible for every product inside it.

As District expanded beyond its initial treasury proposition, more teams needed to bring accounts, payments and other banking products into the channel. The organisation around it grew across countries, product areas and development locations. Coherence could no longer depend on a small group having participated in the same conversations.

My focus shifted from shaping District’s initial experience to defining how independently owned products could extend it. I travelled regularly to work with product teams, designers and architects across locations, using workshops, sketches and prototypes to settle questions that documentation alone could not: what the shared platform would provide, what an application could control, and what should happen to customer context as someone moved from one product into another.

With one or two applications, those questions could be resolved through direct collaboration. At larger scale, the answers had to be designed into the platform. We began developing reusable services, clearer integration models and guidance for teams bringing products into District. The aim was not simply to make another application load, but to allow it to participate credibly in the wider channel.

District now had two user groups: business customers using it and product teams building into it. The challenge was no longer just integrating software, but enabling separately owned products to join one customer environment without reproducing the bank’s internal fragmentation in the experience. That second relationship would later become a product in its own right. At this stage, the purpose was still District: to let more teams contribute while preserving the channel as a coherent whole.

By 2018, Danske Bank had begun moving existing Business Online customers onto District, country by country. District now had to support not only new services, but the banking work customers already relied on every day. Business Online contained decades of functionality; rebuilding it all first would have delayed migration for years, yet customers could not move to a channel that covered only part of their work.

We had tested one version of the solution during the MVP. OneTrader, the FX platform I had worked on before District, was integrated without first being rebuilt, showing how an established product could participate in the new channel while retaining much of its existing implementation. As migration became central, that early example developed into a broader approach: product, architecture and programme leadership converged on a model in which existing services would be embedded within District and adapted where possible.

My responsibility was to define the customer-side rules around that compromise: which identity, permissions and context the shared platform should preserve; how customers would enter and leave an embedded service; and where inconsistency could be tolerated without breaking the sense of one channel.

Embedding was not desirable in itself, but where it was necessary, coherence around it had to be designed deliberately. We could not modernise every legacy screen, and the compromise remained visible when new applications sat beside interfaces shaped by older technologies and assumptions. The challenge was no longer simply to make old software appear inside a new frame, but to decide how much of the bank’s underlying complexity the customer should have to carry.

By this point, decisions about the customer experience depended on infrastructure stability, legacy-system readiness, migration sequencing and work owned by teams across the bank. During a critical phase of the migration, I assumed broader responsibility across District’s technology organisation for roughly six months while several members of the leadership group were on leave.

I reorganised the platform teams and designed and facilitated Product Increment Planning events as migrations progressed across several countries. These multi-day working sessions brought the distributed organisation together around shared priorities. Product owners, designers, architects and delivery teams shaped initiatives, tested feasibility, exposed dependencies and committed to common outcomes. We combined planning with ideation and hands-on work because the relationships between teams mattered as much as the plans they produced.

At that scale, a decision about the channel could depend on several independently managed products, technical systems and country rollouts. My responsibility had expanded from making an undefined proposition buildable, to shaping the shared platform within District, to organising a large product system around that coherence without centralising every decision.