A start-up with the obligations of a bank
Being part of the team creating a new digital retail bank was unlike joining an established organisation or delivering a single transformation programme. We were not only building a product. We were bringing an institution into existence: its customer proposition, technology, operations, controls, partnerships and ways of working had to become real at roughly the same time.
The start-up environment rewarded speed, experimentation and direct ownership. Banking demanded resilience, security, regulatory discipline and evidence. Neither side could be allowed to cancel the other. Move too cautiously and the proposition would never reach customers. Move carelessly and the bank could launch with risks embedded in its foundations.
You rarely have the complete picture
Early decisions had to be made while important information was still emerging. Customer behaviour was not yet visible at scale. Some operating processes existed only as designs. Technology choices depended on integrations that other teams were still defining. Regulatory interpretation, commercial terms and delivery estimates could all change the shape of the answer.
Waiting for certainty would have felt responsible, but often it would simply have transferred risk into the schedule. The practical discipline was to distinguish decisions that were reversible from those that would be expensive to unwind. Reversible decisions could move with explicit assumptions and a review point. Decisions affecting customer money, data, regulatory obligations or foundational architecture required stronger evidence and deliberate challenge.
Momentum is a managed condition
Momentum is sometimes confused with urgency. Urgency produces activity. Momentum means that decisions, dependencies and delivered capabilities are accumulating in the same direction. A team can work intensely while the programme remains stationary because every stream is waiting for another stream or repeatedly revisiting unresolved choices.
Maintaining momentum required a visible decision path. What had been decided? Which assumptions supported it? What evidence could invalidate it? Who had authority to close the question? A decision log, clear ownership and time-bound escalation were not administrative additions. They reduced the cost of uncertainty and stopped old debates from reopening without new evidence.
The work resembled a complex intersection
The bank was built through many streams: proposition and products, customer onboarding, channels, core banking, payments, cards, CRM, data, cybersecurity, compliance, finance, operations, infrastructure and third-party services. Each had its own specialists, plan and delivery pressure. None could create a functioning bank independently.
I came to think of the programme as a complex intersection under construction. Every road can progress for a time on its own. Eventually the levels, signals, utilities and traffic rules must meet precisely. A small alignment error made upstream can become an expensive obstruction when the roads converge. The job is not to slow every road to the pace of the slowest. It is to identify the convergence points early enough that each stream arrives compatible with the others.
Dependencies need more than a register
A dependency list records that one team needs something from another. It does not ensure that the two teams mean the same thing, need it at the same level of maturity or expect it at the same time. Many difficult dependencies sit at the boundary between interpretations rather than between tasks.
A customer journey may appear complete in the channel plan while still depending on product rules, identity checks, account creation, limits, notifications, accounting entries, servicing processes and exception handling. The dependency has to be expressed as an outcome with acceptance conditions, an accountable provider, an accountable consumer and a date connected to an integration or test event.
The most important dependencies should be governed through conversation and evidence, not merely coloured cells. If a dependency threatens a critical path, it needs a decision, a recovery action or a conscious change to scope. Reporting it repeatedly is not the same as resolving it.
Programmes must meet at portfolio level
Individual programme plans are optimised around their own milestones. The bank, however, launches as an integrated service. Portfolio coordination is where local success is tested against the wider outcome. It reveals when two programmes have assumed the same scarce resource, when a shared platform is scheduled after the products that depend on it or when separate releases collide in the same operating environment.
This requires an integrated roadmap built around business capabilities and convergence events, not only project completion dates. Architecture decisions, interface readiness, data migration, end-to-end testing, operational readiness, regulatory submissions and cutover rehearsals create the connective tissue. They show whether the institution is becoming operable rather than whether each team is becoming busy.
Architecture is also a sequencing discipline
Architecture choices determine more than the eventual shape of the technology. They determine what can be built independently, what must be shared and which decisions block others. Clear domain boundaries, interface contracts, identity patterns, data ownership and integration standards allow teams to move in parallel without designing a different bank in each stream.
Some interfaces can be mocked so that dependent teams continue while the provider is still building. Contract testing can reveal incompatibility before full environments are available. Feature controls can separate deployment from customer release. These practices preserve momentum, but only when temporary arrangements are visible and have owners. A shortcut that is never retired becomes part of the architecture.
End-to-end testing changes the conversation
Component progress can create false confidence. A channel may work, the core may work and a payment service may work, yet the complete customer outcome can still fail at the handover between them. End-to-end testing is where the organisation discovers whether its separate interpretations form one coherent service.
Testing must include more than the successful journey. Duplicate messages, delayed responses, partial account creation, reconciliation breaks, failed identity checks, interrupted payments and manual recovery paths reveal whether the bank can operate outside the ideal case. Defects at these boundaries are often not owned neatly by one team. Resolving them tests the quality of the delivery model as much as the software.
Operational readiness cannot wait for the product
A new bank needs people to monitor, support, reconcile, investigate, communicate and make decisions from the first day of operation. Those capabilities cannot be added after the technology is declared complete. Operational teams need to influence the design while there is still time to change it.
Readiness should include customer support, incident management, fraud and financial crime response, access management, finance and regulatory reporting, business continuity, vendor escalation and manual workarounds. A service is not ready because its normal path works. It is ready when the organisation can recognise and control what happens when that path breaks.
Governance should accelerate truth
In a programme of this scale, governance can either shorten the distance between a problem and a decision or become another queue. Useful governance concentrates on evidence, cross-stream impact and decisions that teams cannot make alone. It protects delivery by exposing uncertainty early rather than rewarding optimistic reporting.
This also requires psychological safety. Teams must be able to surface a weak assumption or missed dependency before it becomes a public failure. A red status reported early is useful information. A green status maintained until integration fails is not control.
What the 18 months changed for me
The journey taught me that building a bank is not the act of assembling completed systems. It is the continuous work of aligning decisions across customer experience, technology, operations and control while all four are still changing.
I learned to value interfaces as much as components, convergence as much as individual velocity and decision quality as much as delivery volume. I learned that an imperfect decision made transparently, with bounded risk and a review point, can be safer than indefinite delay. I also learned that some questions deserve resistance because their consequences are difficult to reverse.
Most of all, I learned that coordination is not a support function around delivery. In a complex start-up, coordination is part of the product. It is how dozens of specialised teams become one bank, and how a bold idea survives the journey into a service that customers can actually use and trust.